SOA-C02 Security and Compliance Practice Question

An organization wants to centrally manage access to multiple AWS accounts in an AWS Organizations setup. Which AWS service should the SysOps administrator use to define and enforce fine-grained permissions across accounts?

⚠ Common exam trap

Many exam-takers confuse Service Control Policies (SCPs) with fine-grained permission enforcement, but SCPs only set guardrails and cannot grant cross-account access or define granular user-level permissions, which is the core requirement of this question.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

IAM roles with cross-account trust policies

IAM roles with cross-account trust policies allow a SysOps administrator to define fine-grained permissions centrally in a single AWS account (the management or security account) and then grant access to users or services in other accounts by assuming the role. This approach uses AWS Security Token Service (STS) to issue temporary credentials, enabling precise control over actions and resources across accounts without duplicating IAM users or policies.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
AWS Config rules
Why it's wrong here
AWS Config rules evaluate recorded resource configurations against a set of desired compliance policies, such as checking whether S3 buckets have encryption enabled. They do not issue API calls that grant or deny access, and they cannot create or alter IAM roles or trust relationships. While AWS Config can trigger auto-remediation via Systems Manager, that is a reactive fix for noncompliant resources, not a central access-control mechanism.
✗
Service control policies (SCPs)
Why it's wrong here
Service control policies act as an outer guardrail at the AWS Organizations root, OU, or account level, limiting the maximum permissions that IAM principals can use. They never grant a permission; they only deny or allow permissions that are already present in the identity- or resource-based policies. Because they cannot define fine-grained actions like 'read one S3 object' or 'write to a specific DynamoDB table,' they are unsuitable for centrally managing detailed cross-account access.
✓
IAM roles with cross-account trust policies
Why this is correct
IAM roles are the correct mechanism because a role in a target account can attach a permissions policy that precisely defines allowable actions and resources, and a trust policy in the same role lists which principals in a central account may assume it. When a user in the central account calls sts:AssumeRole, AWS returns temporary, scoped credentials that carry exactly the role's permissions, no more and no less. This gives fine-grained control while centralizing the decision about who gets to assume which role.
✗
AWS Single Sign-On (SSO)
Why it's wrong here
AWS Single Sign-On (now IAM Identity Center) primarily focuses on authenticating users across an organization and presenting a user portal for access, not on authoring resource-level permissions. Although SSO permission sets contain policy documents that ultimately map to IAM roles, those roles are created and managed under the hood; fine-grained access decisions are still enforced by IAM role policies. Thus, for directly defining and controlling granular cross-account permissions, the fundamental building block is the IAM role itself.

Go deeper

SOA-C02 Security and Compliance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question