What's changed: Deepened SCS-C02 Chapter 4 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
4.1IAM Policies and Evaluation Logic
Understand the core of access control—identity/resource-based policies, explicit deny wins, SCPs, permissions boundaries, and condition keys. Precisely design who can access what.
IAM is central to security. Understand precisely how multiple policies evaluate—especially that explicit deny wins.
4.1.1Policy evaluation flow
- Explicit deny wins: an explicit Deny anywhere always denies (highest precedence).
- Allow required: access needs an explicit Allow in some policy; otherwise implicit deny.
- SCP/permissions boundary: define the permission ceiling (no grant); effective permission is the intersection.
- Condition keys: narrow allows by MFA/source IP/tags/required encryption, etc.
Most common on SCS-C02: explicit deny always wins, allow needs an explicit Allow else implicit deny, SCP/boundary are ceilings (intersection), not grants, condition keys for MFA/IP/tag restrictions. Access requires allow across SCP, boundary, IAM, AND resource policy.
The most tested topic on SCS-C02 is IAM policy evaluation logic. A request (1) gathers all relevant policies, (2) denies immediately if any explicit Deny exists (highest precedence, irreversible), (3) otherwise checks for an explicit Allow, and (4) allows if Allowed and not Denied; with no Allow anywhere it is an implicit deny (default deny). Multiple policy types contribute: identity-based (attached to users/roles), resource-based (S3 bucket policy, KMS key policy—specify the principal for cross-account), SCP (account ceiling in Organizations), permissions boundary (ceiling on an IAM entity), and session policy (passed at AssumeRole). SCPs and boundaries are "permission ceilings," not grants—effective permission is their intersection, and same-account access needs "an Allow in identity or resource AND within the SCP/boundary AND no Deny" (cross-account needs an Allow in both accounts). Condition keys (aws:MultiFactorAuthPresent, aws:SourceIp, aws:PrincipalTag, s3:x-amz-server-side-encryption) further narrow allows, and Deny + condition is the classic way to enforce "deny all without MFA," "deny outside specific IPs," or "deny PutObject without encryption." The key is to precisely understand "explicit deny > allow > implicit deny" and "SCP/boundary = ceiling (intersection)," and narrow in layers with condition keys.
| Policy type | Role | Key point |
|---|---|---|
| Identity-based | Attached to user/role | Grants explicit Allow |
| Resource-based | On the resource (S3/KMS) | Specify principal for cross-account |
| SCP / permissions boundary | Permission ceiling | No grant; intersection is effective |
| Condition keys | Narrow allows | MFA/source IP/tag/required encryption |
Scenario: Enforce org-wide "no user can do anything without MFA" and "in the production account, deny all regions except specific ones." → For MFA, use an IAM policy/SCP Deny with condition aws:MultiFactorAuthPresent: false (deny all when MFA absent). For regions, use an SCP Deny with aws:RequestedRegion denying non-allowed regions. These are ceilings (guardrails), so however member-account IAM allows, the SCP Deny wins. Access succeeds only after passing SCP, boundary, IAM, and resource policies.
FAQ: Does an Allow in an SCP grant permission? No. An SCP is a "ceiling (guardrail)," not a grant. Even if an SCP allows, actual access still needs a separate Allow in IAM (identity) or a resource policy. The SCP’s role is to bound "only up to here." Likewise, a permissions boundary is a ceiling; the grant comes from the IAM policy.
Exam trap: Even with an IAM Allow, if any of SCP/resource policy/permissions boundary has a Deny, the explicit deny wins and access is denied—the classic "I allowed it in IAM, why denied?" Also, an Allow in an SCP/boundary grants nothing (it only sets a ceiling), a frequent trap. Cross-account access requires an Allow in both accounts.
4.1.2Section summary
- Evaluation = explicit deny > allow > implicit deny
- Ceiling = SCP/boundary (intersection) / narrowing = condition keys
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. A user has an IAM allow for S3, but an SCP has an explicit deny. The result?
Q2. What happens for an action with no explicit Allow in any policy?
Q3. Cap the maximum permissions an IAM role can have to prevent over-permissioning on delegation. What?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.