Free SAA-C03 practice scenarios: cross-account access

A cross-account IAM role — with a trust policy naming the development account and a permissions policy for the allowed resources — lets developers assume it through STS and receive temporary credentials, the standard best-practice pattern. Why not the others: creating IAM users and sharing access keys reintroduces the long-term credentials the requirement forbids. Sharing root credentials is a severe violation and grants far too much. VPC peering connects networks; it does not grant identity-level access to resources. Temporary cross-account access is an assumed role.

An external ID is a shared secret placed in the role's trust policy; the third party must supply the matching value to assume the role, which prevents one customer's identifier from being used to access another's account — the defence against the confused-deputy problem. Why not the others: sharing access keys is exactly what roles exist to avoid. Making the role assumable by any account removes all protection. Disabling CloudTrail hides activity and provides no security. Third-party cross-account access uses a role with an external ID.

S3 supports resource-based policies, so a bucket policy in account B can grant a principal in account A direct access — no role assumption needed, which matches 'read directly, without assuming a role'. Why not the others: assuming a role works but is exactly what the requirement rules out for this direct-access case. Making the bucket public exposes it to everyone. Scheduled copying duplicates data and adds staleness and cost. Direct cross-account access to a resource that supports resource policies is granted by that resource's policy.

SCPs set the maximum permissions available to accounts in the organization; even an account administrator cannot exceed them, which is exactly the central, unbreakable guardrail described. Why not the others: an IAM policy in each account can be changed by that account's admin, so it is not a guarantee across the organization. Permissions boundaries cap an individual identity, not a whole account centrally, and would have to be maintained everywhere. Security groups filter network traffic, not service usage. Organization-wide guardrails are SCPs.

AWS Resource Access Manager (RAM) shares supported resources — such as VPC subnets and Transit Gateways — across accounts, so other accounts can deploy into the shared network directly. Why not the others: an IAM role grants identity-level access to API actions, not shared use of a subnet. VPC peering connects separate VPCs and would be a mesh of connections, not shared subnets. SCPs restrict permissions; they do not share resources. Sharing resources like subnets across accounts is RAM.

A role provides temporary credentials through STS that expire on their own, eliminating the long-lived access key a cross-account IAM user would require — the core security reason roles are preferred. Why not the others: cost is not the distinction; both are free to create. Roles absolutely require a trust relationship — that is how cross-account assumption is authorised. And a role still needs a permissions policy defining what it can do. The advantage is expiring credentials with nothing to leak.