SAP-C02 Practice Question 41: Permission Set Sprawl ABAC
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 5 · question 1 of 10
An engineering organization has 800 project teams working across 200 AWS accounts. Access is granted through AWS IAM Identity Center federated to the company's external identity provider, which already carries a costCenter and an environment attribute for every employee.
The current model creates one permission set per team per environment. There are now more than 3,000 permission sets, each with an inline policy that lists resource ARNs, and the identity team spends most of its week creating permission sets, editing policies, and re-assigning people who move between teams. Every resource in the estate is tagged with the owning cost centre and its environment, and tagging is enforced.
The target state is that an engineer can act only on resources whose tags match their own attributes, that moving someone between teams takes effect at their next sign-in with no change to anything in AWS, and that the number of permission sets to maintain collapses.
What should the solutions architect implement?
Show answer and explanation
Answer:
This is the problem ABAC in IAM Identity Center is designed for. User attributes from any configured identity source are passed into the AWS session as tags, and a permission set policy compares them against resource tags, so people with the same permission set end up with different effective permissions based on who they are. AWS gives exactly this example: two developers on different teams share one permission set, and each reaches only the resources whose team tag matches their own team attribute. The documented benefits line up with every requirement in the stem: fewer permission sets to create and manage, permissions for newly created resources granted automatically when the resource is tagged, and a team move handled by updating the attribute in the corporate directory, so the engineer picks up the new access at the next sign-in with no permissions update in AWS.
Option A automates the symptom rather than removing it. There are still thousands of permission sets and inline policies, ARN lists go stale between nightly runs, and a team move still waits for a pipeline instead of taking effect at sign-in.
Option C moves backwards: it replaces short-lived federated sessions with long-lived IAM users in 200 accounts, multiplying credential management and audit surface, and it throws away the identity provider attributes that make the tag comparison possible.
Option D leaves the 3,000 permission sets in place, so the sprawl is untouched. Service control policies are guardrails attached to accounts and OUs and never grant permissions, so they cannot express per-engineer access, and cost centres rarely map one-to-one onto the OU structure.
Reference: Attribute-based access control