Least privilege, permissions boundaries and ABAC: DOP-C02 study notes and practice questions
What to know about Least privilege, permissions boundaries and ABAC for the DOP-C02 exam, from the Security and Compliance domain (17% of the exam guide), then 3 free questions to test it. Part of the DOP-C02 study guide.
IAM questions at this level ask how to let teams manage their own permissions without escalating privileges.
Policy types and evaluation
An action is allowed only if an identity or resource policy allows it, and it isn’t denied anywhere, and it’s within every applicable limit:
Limit
Applies to
SCPs / RCPs
Accounts in an organization
Permissions boundary
One IAM user or role
Session policy
One assumed-role session
Explicit deny always wins.
Permissions boundaries
Set the maximum permissions a role or user can have.
Delegate safely: let developers create roles only if they attach a specific boundary (condition iam:PermissionsBoundary), and deny changing or removing it.
An SCP can require the boundary across all accounts.
Session policies
Passed with AssumeRole (or federation) to narrow one session. Effective permissions are the overlap of the role policy and the session policy, useful for jobs that should touch only one prefix this time.
Attribute-based access control (ABAC)
Match principal tags to resource tags (aws:PrincipalTag/team = aws:ResourceTag/team).
One policy covers every team and every future resource, with no ARN lists to update.
Control who can set tags (aws:RequestTag, aws:TagKeys).
Third parties and services
External ID in trust policies prevents the confused deputy problem.
aws:SourceArn and aws:SourceAccount conditions stop services acting for other accounts.
Service-linked roles are managed by services.
Finding the right permissions
IAM Access Analyzer policy generation builds policies from CloudTrail activity; last accessed information shows unused permissions.
Common traps
Per-team policies listing ARNs that need constant updates. Use ABAC.
Letting developers create roles without a boundary.
A regional bank's engineering teams run EC2 instances that are tagged with the owning team's name in a tag called team. Each team has its own IAM principals, and each principal carries a team tag that matches its owning team.
The platform team wants developers to start and stop only the instances that belong to their own team, including instances that teams create in the future. The bank wants one shared policy rather than a separate policy for each team.
Which approach meets these requirements?
Choose one answer.
AA. Create one IAM group for each team with a policy that lists the ARNs of that team's current instances, and add the group's members to the policy as each instance is created.
BB. Attach a policy that allows ec2:StartInstances and ec2:StopInstances on all instances, and add a deny statement for each team that lists the instance IDs owned by every other team.
CC. Add a resource-based policy to each EC2 instance that allows the team's principals to start and stop it, so that access follows the instance wherever it is created.
DD. Attach one policy that allows start and stop actions when the instance's team tag matches the caller's team principal tag, using aws:ResourceTag and aws:PrincipalTag.
Show the answer and explanation
Answer: D
A. Wrong: This works for current instances, but the policy changes every time an instance is created. It also needs a separate group and policy for each team, which the bank wanted to avoid.
C. Wrong: EC2 instances do not support resource-based policies for starting and stopping, so this cannot be configured. The access control has to come from identity-based policies.
Attribute-based access control uses tags to match the caller's principal tags with the resource's tags, so one policy covers every team and every future instance. Per-team groups with instance ARNs need constant upkeep, broad allows with local denies are hard to keep right, and EC2 instances do not take resource-based start and stop policies.
An online retailer's CI system assumes a deployment role in the shared-services account. The role's policy is broad, because one of the release jobs needs to manage several buckets, but a single release job should only write to the bucket of its own release.
The security team wants each job's session to be restricted to the one bucket it needs at the moment it runs, without creating a new IAM role for every release. The job runs several times a day, so the access must be granted each time it starts.
Which approach meets these requirements?
Choose one answer.
AA. Create a new IAM role for each release that has a policy for that release's bucket only, and have the CI system assume that role for the job.
BB. Pass a session policy with the AssumeRole call that limits the session to write access on the release's bucket.
CC. Add a permissions boundary to the deployment role that limits it to the release bucket, so that each job that assumes the role can only write to that bucket.
DD. Attach a resource-based bucket policy that grants write access only to the job's session name, and let the job set its session name to the release identifier.
Show the answer and explanation
Answer: B
A. Wrong: This meets the access rule, but it creates and deletes a role for every release. The security team wanted to avoid that upkeep.
D. Wrong: A bucket policy can match a session name, but the job could choose any name, and the policy would have to change for each release. It is not a control the security team can rely on for this purpose.
Explanation
A session policy passed with AssumeRole narrows one session's permissions, and the effective permissions are the overlap of the role policy and the session policy. The job gets write access only to its release bucket, and the role does not change. Per-release roles add upkeep, while a permissions boundary and session names apply to the whole role or are not reliable controls.
A game studio sends player-analytics exports to a third-party vendor. The vendor's software assumes a role in the studio's account to read the export files in one S3 prefix, and the studio has allowed the vendor's AWS account in the role's trust policy.
The security team is concerned about the confused deputy problem: another customer of the same vendor could ask the vendor's software to assume this role on their behalf. The studio wants only its own vendor integration to be able to use the role.
The vendor's software already sends an external ID that the vendor assigns to each customer, and the studio can change the trust policy and the role's permissions.
Which change meets these requirements?
Choose one answer.
AA. Create an IAM user for the vendor in the studio's account, and give the vendor its access key, so that the vendor no longer needs to assume a role at all.
BB. Keep the trust policy as it is, and add a deny on the role for the vendor's account, with an exception for the vendor's main account role that the studio names.
CC. Make the S3 export bucket public for read-only access, so that the vendor can read the prefix without assuming any role, and remove the role from the account entirely.
DD. Require sts:ExternalId in the trust policy to match the unique external ID that the vendor assigned to the studio, and limit the role to read access on the export prefix.
Show the answer and explanation
Answer: D
A. Wrong: A long-lived access key for the vendor is a credential that can leak, and it does not address how the vendor's role is used. The studio would also lose the temporary, scoped access that the role gives.
B. Wrong: A deny that names the vendor's account does not stop other customers of the vendor from using their own calls. The confusion is about which request the vendor acts on, not which account owns it.
D. Right: Correct. The ExternalId condition allows the role to be assumed only when the vendor's call carries the studio's unique value, so a request made for another customer fails. Read-only permissions on one prefix limit what the role can reach. Learn more: Access to AWS accounts owned by third parties (opens in a new tab)
Explanation
The confused deputy problem is addressed by requiring an sts:ExternalId in the role's trust policy, which the vendor must supply on each AssumeRole call. Keeping the role's permissions limited to read access on one prefix bounds what it can reach. Access keys, account-level denies and public buckets each leave the studio open to misuse or exposure.
Want more on Least privilege, permissions boundaries and ABAC? The 5 full-length practice sets have 14 more Least privilege, permissions boundaries and ABAC questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Least privilege, permissions boundaries and ABAC