Study SCS-C03 authorization strategies for IAM policies, ABAC, resource policies, SCPs, boundaries, and troubleshooting.
Authorization is where SCS-C03 becomes an evaluation-order exam. The hard part is rarely “what service is IAM?” The hard part is deciding which policy layer should enforce the rule and why a request was allowed or denied after all the layers intersected.
The current SCS-C03 domain page emphasizes five patterns:
That means many questions are really asking two things at once:
| Layer | What it answers |
|---|---|
| identity-based IAM policy | what the principal is allowed to do |
| resource policy | who the resource itself allows or denies |
| trust policy | who may assume the role |
| SCP | what the account or OU is prevented from doing |
| permission boundary | the maximum permissions a principal can receive |
| session policy | additional limits on the current session |
| KMS key policy | who may use the KMS key, even when IAM looks permissive |
Candidates miss questions when they treat all of these as interchangeable.
| Requirement | Strongest first fit | Why |
|---|---|---|
| Organization-wide prevention of risky actions | SCP | Enforces a top-level guardrail across accounts |
| Role assumption from another account | Trust policy plus role permissions | Cross-account entry and action rights are separate questions |
| Service resource shared across accounts | Resource policy where the service supports it | Enforcement belongs on the resource boundary |
| Team-based access that should scale by tags or attributes | ABAC | Avoids static role explosion |
| Narrow extra constraint on a delegated admin or builder role | Permission boundary | Caps what delegated role creation or attachment can grant |
If the user can sign in and obtain credentials but still cannot perform the action, stop looking at the authentication flow. This is where policy evaluation starts.
SCS-C03 likes distractors that tell you to change MFA or Cognito when the real issue is a trust policy, boundary, or explicit deny. Do not fix the wrong layer.
Use RBAC when stable roles map cleanly to job functions and the permissions do not need high attribute flexibility.
Use ABAC when access must scale across many resources or environments based on tags or attributes such as environment, project, data classification, or owner.
ABAC is often stronger where static role explosion would become unmanageable, but it only works well if tagging discipline is real. If the organization cannot trust consistent attributes, ABAC becomes weaker.
These show up because they are easy to forget during troubleshooting.
So “the IAM role policy allows it” is not enough. The final result may still be denied by one of these limiting layers.
SCS-C03 explicitly expects you to know when analysis tools help.
Use IAM policy simulator when you need to understand how a policy decision evaluates for a particular action and context.
Use IAM Access Analyzer when you need to detect unintended external or broader-than-expected access, or when you need to investigate whether a resource is exposed beyond its intended boundary.
These are not the same job.
Cross-account access usually requires two aligned pieces:
sts:AssumeRole.If either side is wrong, the flow breaks. If both are right but a higher-level deny still exists, the request still fails.
When a request is denied or unexpectedly allowed, use this order:
This sequence prevents random IAM edits that never fix the real blocker.
If the requirement says block this everywhere, think SCP. If it says limit what delegated builders can grant, think permission boundary. If it says this one shared resource needs cross-account control, think resource policy. If it says scale access by environment or owner tag, think ABAC. If it says why was this denied or exposed?, think policy evaluation order plus simulator or Access Analyzer.
If IAM questions still feel muddy after this page, go back to the chapter landing and separate the problem into three parts: authentication path, trust path, and final authorization path.