Exams / SAP-C03 / Study guide / Least privilege, cross-account roles, ABAC and IAM Roles Anywhere
Least privilege, cross-account roles, ABAC and IAM Roles Anywhere: SAP-C03 study notes and practice questions
What to know about Least privilege, cross-account roles, ABAC and IAM Roles Anywhere for the SAP-C03 exam, from the Security, Compliance, and Governance domain (25% of the exam guide), then 2 free questions to test it. Part of the SAP-C03 study guide.
These questions ask how to grant exactly the access a person, team, vendor or workload needs, across accounts, without long-lived keys and without a policy per resource.
Cross-account access with roles
A role in the target account has a trust policy (who may assume it) and a permissions policy (what it can do). The caller also needs sts:AssumeRole on that role.
A third party that assumes a role in your account should use an external ID condition in the trust policy, which prevents the confused deputy problem.
For resources that support resource-based policies (S3, KMS, SQS, SNS, Lambda, Secrets Manager), you can grant another account directly instead of a role. For KMS, the key policy must allow the other account and that account’s IAM policy must allow the principal.
aws:PrincipalOrgID in a resource policy allows every account in the organization without listing account IDs.
Limiting what a role can do
Permissions boundaries set the maximum permissions for a user or role. Use them to let developers create roles safely: they may create roles only if they attach the approved boundary.
Session policies passed at AssumeRole time narrow one session further; the result is the intersection of the role’s policies and the session policy.
SCPs and RCPs set organization-wide maximums (landing zone).
IAM Access Analyzer policy generation builds a policy from CloudTrail activity, and the unused access analyzer finds unused roles, keys and permissions to remove.
ABAC
Write one policy that compares principal tags with resource tags, for example aws:ResourceTag/project equal to ${aws:PrincipalTag/project}.
Scales to new projects without policy edits; new resources just need the right tags. Control who can set tags with aws:RequestTag and aws:TagKeys conditions.
Session tags can come from the IdP through Identity Center.
IAM Roles Anywhere
Gives servers, containers and applications outside AWS (on premises or in another cloud) temporary credentials in exchange for an X.509 certificate.
A trust anchor points at AWS Private CA or your own CA. A profile lists the roles it can assume and can add a session policy. The credential helper plugs into the CLI and SDKs.
Add conditions on certificate attributes in the role’s trust policy, because by default any certificate from a trust anchor in the account can try any role that trusts Roles Anywhere.
How to choose
Scenario wording
Pick
Vendor needs access to your account
Role with external ID
Developers create their own roles but can’t escalate
Permissions boundary, enforced by SCP
Hundreds of projects, one policy
ABAC with tags
One call needs less than the role allows
Session policy
On-premises servers, no access keys
IAM Roles Anywhere
Remove permissions nobody uses
Access Analyzer unused access and policy generation
Common traps
Long-lived access keys on servers or in other clouds when Roles Anywhere fits.
Expecting a permissions boundary or SCP to grant access. They only limit.
A role per project when ABAC scales.
Trusting a whole vendor account without an external ID.
Forgetting the key policy in cross-account KMS access.
A streaming company hires a monitoring vendor that runs its SaaS platform from the vendor's own AWS account. The vendor needs to read CloudWatch metrics and alarms from the company's 30 production accounts.
The company's security policy forbids long-lived credentials for third parties, and access must be limited to the read-only actions that the vendor's platform calls. The company must also stop another of the vendor's customers from tricking the platform into reaching the company's accounts.
Which solution meets these requirements?
Choose one answer.
AA. In each production account, create a role with a read-only CloudWatch policy that trusts the vendor's account and requires the unique external ID that the vendor assigned to the company.
BB. In each production account, create an IAM user for the vendor with a read-only CloudWatch policy, and send the access key pair to the vendor through the company's secrets vault for rotation every 90 days.
CC. In each production account, attach the AdministratorAccess policy to a role that trusts the vendor, and rely on CloudTrail alerts to spot any misuse by the vendor.
DD. Create a service control policy in the organization that allows the vendor's account to call CloudWatch read actions in every production account.
Show the answer and explanation
Answer: A
A. Right: Correct. A cross-account role gives the vendor temporary credentials with read-only permissions. The external ID ties the role to the company's own configuration in the vendor's platform, so another customer's request cannot use it, which prevents the confused deputy problem.
B. Wrong: The IAM user's access keys are long-lived and must be rotated by hand. The policy meets the read-only need, but the design breaks the rule against long-lived third-party credentials.
C. Wrong: Administrator access is far broader than metrics and alarms need. Alerts only report misuse after it happens, and they do not limit what the vendor can do.
D. Wrong: An SCP limits what principals can do and does not grant any permissions by itself. The vendor would still have no role or credentials to make the calls.
Explanation
A cross-account role with a read-only policy and an external ID gives temporary, scoped access and blocks the confused-deputy case. Long-lived IAM user keys break the credential rule, administrator access is far too broad, and an SCP grants nothing.
A streaming service has about 400 developers in 30 product teams. Every team's EC2 instances carry a team tag, and the platform team does not want to write or maintain a separate IAM policy for each team.
Developers must start and stop only the EC2 instances that carry their own team's tag. They may also create IAM roles for their applications, but no role they create may grant more permissions than the platform team allows, and they must not be able to remove that limit from the roles they create.
Which TWO policy designs meet these requirements? (Choose two.)
Choose two answers.
AA. Write one attribute-based access control policy that allows ec2:StartInstances and ec2:StopInstances when the instance's team tag matches the caller's team principal tag.
BB. Create one IAM group per team with a managed policy that lists the ARN of every instance that team owns, and add the team's developers to that group.
CC. Give developers AdministratorAccess, and rely on CloudTrail alerts and a monthly review to find roles that exceed the platform's limits.
DD. Allow developers to create roles only when the iam:PermissionsBoundary condition key equals the platform's boundary policy ARN, and deny them iam:DeleteRolePermissionsBoundary and any change to the boundary policy itself.
EE. Add an explicit deny for iam:CreateRole to every developer role, and have the platform team create each role on request through a ticket.
Show the answer and explanation
Answers: A, D
A. Right: Correct. The condition compares the instance's tag with the caller's own team tag, so one policy covers all 30 teams and new instances need no policy change. The developer can act only on their team's instances.
B. Wrong: The policy must be edited for every instance launch or retirement, which is the maintenance the platform team wants to avoid. It also does not follow the tags the teams already use.
C. Wrong: Alerts and reviews detect over-permissioned roles after the fact and do not stop developers from creating them. Administrator access also allows changes to any team's instances.
D. Right: Correct. A permissions boundary caps the permissions of each role developers create, and the conditions stop them from creating a role without it. Denying changes to the boundary keeps the limit in place on the roles they create.
E. Wrong: This stops the self-service need, since developers would wait on tickets for every application role. The requirement is for developers to create roles within the boundary, not to be blocked from doing so.
Explanation
Attribute-based access control scales one policy across tagged resources, and a permissions boundary caps every role developers create while the boundary itself stays locked. Per-team groups, administrator access and blanket role denials each miss a stated requirement.
Want more on Least privilege, cross-account roles, ABAC and IAM Roles Anywhere? The 5 full-length practice sets have 10 more Least privilege, cross-account roles, ABAC and IAM Roles Anywhere 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, cross-account roles, ABAC and IAM Roles Anywhere