Cross-account roles and SCPs: DOP-C02 study notes and practice questions
What to know about Cross-account roles and SCPs for the DOP-C02 exam, from the Configuration Management and IaC domain (17% of the exam guide), then 1 free question to test it. Part of the DOP-C02 study guide.
These questions ask how to give central teams access to member accounts, or enforce rules no local admin can override.
Cross-account roles
A role in the target account with a trust policy naming the source account or role, and a permissions policy for what it can do.
The caller needs sts:AssumeRole on that role ARN.
Third parties use an external ID in the trust policy to avoid the confused deputy problem.
IAM Identity Center permission sets give people access to many accounts without per-account roles.
Service control policies
Apply to every principal in member accounts, including the account’s root user and admins. They don’t apply to the management account or to service-linked roles.
They grant nothing; they set the maximum. An action needs an IAM allow and no SCP deny.
Common uses:
Deny leaving the organization or disabling CloudTrail, Config or GuardDuty.
Restrict Regions (with exceptions for global services).
Require a permissions boundary when creating roles (deny iam:CreateRole unless iam:PermissionsBoundary matches).
Protect central roles from changes.
Resource-side controls
aws:PrincipalOrgID in bucket, key or topic policies allows only principals from your organization.
Resource control policies (RCPs) set maximum permissions on resources (such as S3, KMS, STS, SQS, Secrets Manager) across accounts, for example to block access from outside the organization.
aws:ResourceOrgID in identity policies limits callers to your own resources.
Common traps
Expecting an SCP to grant access.
Account-level IAM policies to enforce rules local admins could edit.
Forgetting the external ID for a vendor’s role.
SCPs on the management account; they don’t apply there, so keep workloads out of it.
A SaaS startup runs 25 AWS accounts in an AWS Organization. Its developers build serverless applications in development accounts, and they create IAM roles for their Lambda functions in those accounts.
A recent incident showed that a developer role could create a role with broad permissions, and another role could stop CloudTrail logging. The security team wants both risks blocked for every member account, including developers with full IAM access in their own accounts.
Developers must still be able to create roles for their functions, but only when each role carries the company's approved permissions boundary, and the controls must not depend on each account being configured correctly.
Which TWO actions meet these requirements? (Choose two.)
Choose two answers.
AA. Attach an IAM policy to each developer role in every account that allows iam:CreateRole only when the permissions boundary is set to the approved policy.
BB. Attach a service control policy to the development organizational unit that denies iam:CreateRole unless the iam:PermissionsBoundary condition key equals the approved boundary policy ARN.
CC. Attach a service control policy to the organization root that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail for all member accounts, except for the security audit role.
DD. Give the developers' roles a permissions boundary that denies CloudTrail changes, and rely on the boundary to stop logging changes by any role that the developers create.
EE. Enable AWS Config rules that detect new roles without the boundary and CloudTrail changes, and alert the security team, so that problems are found soon after they happen.
B. Right: Correct. A service control policy applies to every principal in the member accounts, including account administrators, so the boundary requirement cannot be bypassed locally. The policy uses the condition key to check the boundary on each role creation. Learn more: Service control policies (SCPs) (opens in a new tab)
C. Right: Correct. The SCP stops member accounts from disabling or deleting their trails, which holds even for administrators in those accounts. The security audit role is excluded so that the security team keeps its own access. Learn more: SCP evaluation (opens in a new tab)
D. Wrong: A permissions boundary limits the permissions of one role and does not restrict other principals, so roles created without the boundary would be unaffected. The boundary also does not apply to the account's root user. Learn more: Permissions boundaries for IAM entities (opens in a new tab)
Service control policies apply to every principal in member accounts, so they can require a permissions boundary on new roles and block changes to CloudTrail regardless of local IAM settings. Account-level policies depend on each account being set up correctly, while permissions boundaries and detective rules do not block the actions the security team cares about.
Want more on Cross-account roles and SCPs? The 5 full-length practice sets have 4 more Cross-account roles and SCPs questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →