Day 5 - Week 1 Synthesis: Integrating IAM and Credentials Through Scenarios

Week 1 has laid the foundation of SCS-C03. We drew the big picture with the Shared Responsibility Model and 6 domains (Day 1), mastered IAM building blocks and policy evaluation algorithm (Day 2), dug into Identity/Resource policies, Condition keys, and least-privilege design (Day 3), and covered STS, federation, role chaining, Confused Deputy prevention (Day 4). Separately, each is its topic. But exam scenario questions always bundle two or three together.

One problem tangles implicit Deny, SCP guardrails, cross-account both-sides allowing, and Permissions Boundary simultaneously: "Why is access denied?" A "delegate safely to third parties" question tests Role + trust policy + ExternalId + least privilege all at once. Today we solidify that synthesis through scenario solving. Week 1's one-liner: "Every access decision at AWS reduces to the IAM evaluation algorithm, and a security engineer's job is inputting precise policies into that algorithm."

One-Page Compact — Week 1 Core

Shared Responsibility + Control Types (Day 1)

IAM Evaluation Algorithm (Day 2·3)

1. Any explicit Deny?             ──▶ Yes → DENY (absolute)
2. Does SCP allow the Action?      ──▶ No → DENY
3. Does Permissions Boundary allow? ──▶ No → DENY
4. (cross-account) Both allow?      ──▶ Either missing → DENY
5. Any explicit Allow?              ──▶ No → implicit DENY
   All pass ──▶ ALLOW

• SCP·Boundary are filters that cut ceilings, not grant permissions
• Same account: Identity OR Resource policy enough / cross-account: both needed
• KMS: key policy is first authority — key policy must open before IAM policy works

Policy Types and Tools (Day 3)

• Condition traps: BoolIfExists(MFA), aws:SourceArn/SourceAccount(Confused Deputy), use aws:SourceVpc for VPC
• ABAC: aws:PrincipalTag == aws:ResourceTag keeps policies constant as scale grows

STS·Credentials (Day 4)

• Temporary credentials = AccessKeyId + SecretAccessKey + SessionToken(expiring)
• AssumeRole: trust(who) + permission(what) two policies
• Federation: SAML(AssumeRoleWithSAML)·OIDC(AssumeRoleWithWebIdentity)·Identity Center
• Confused Deputy: third-party uses ExternalId(vendor-issued), AWS service uses aws:SourceArn
• Role chaining: session max 1 hour fixed / IMDSv2 enforced to stop credential theft

Scenario Solving 4-Step Flow

When facing IAM problems in exam, consciously decompose by this order:

1. Decompose the request: Who(Principal) · What(Action) · Where(Resource) · same-account or cross-account? KMS involved?
2. Check filters: Explicit Deny? SCP? Boundary? Cross-account both sides? KMS key policy?
3. Judge least privilege: Among choices, pick one narrowing wildcards, using temp credentials, forcing guardrails
4. Remove traps: Long-key use / root use / Bool vs BoolIfExists / missing ExternalId / single control only

🎯 Scenario: "Developer has admin, but specific S3 bucket access is denied." Four-step decomposition — admin is explicit Allow (passes step 5). But denied means hitting filters 1-4. Most common: SCP or bucket policy's explicit Deny, or that bucket is KMS-encrypted but key policy doesn't allow developer. "Permissions exist but denied" almost always hits a filter (upper ceiling).

---

📝 10 Comprehensive Scenarios

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

Company wants application running on EC2 to access S3. Most security best-practice method is?

• ACreate IAM User, generate access key, store in EC2 instance environment variables
• BAttach IAM Role as instance profile to EC2 and enforce IMDSv2
• CStore root credentials on EC2 and use as needed
• DOpen S3 bucket as public-read so it authenticates without credentials

Question 2

Account A's CodePipeline deploys to Account B's ECS service; artifacts encrypted with Account A KMS key. For deployment to work, required permission boundaries are?

• AGive pipeline role all permissions; cross-account works automatically
• BAccount B role with A as trust + Account A KMS key policy allows B + B role has ECS permissions + artifact bucket policy allows B read
• CStore Account B root credentials in Account A
• DIAM Identity Center SSO alone solves this

Question 3

User has `PowerUserAccess`, no SCP or Boundary restrictions, yet `dynamodb:Query` call is denied. Most likely cause?

• ADynamoDB isn't controlled by IAM
• BSomewhere an explicit Deny for `dynamodb:Query` (or wildcard parent) exists
• CPowerUserAccess doesn't include DynamoDB; no explicit Allow means implicit Deny
• DBoth B and C possible

Question 4

Company wants to safely delegate cross-account S3 bucket access to third-party backup vendor. Most appropriate setup?

• AIssue IAM User access key to vendor
• BCreate Role with vendor account in trust policy and vendor-issued ExternalId; permission restricts to bucket and needed Actions
• COpen bucket as public so vendor accesses without auth
• DShare company root credentials with vendor

Question 5

Security team wants to prevent anyone (admin, root) in all member accounts from disabling CloudTrail and block non-US region use. Most appropriate combo is?

• AAdd CloudTrail Deny one-by-one to every member user policy
• BSCP with `cloudtrail:StopLogging`/`DeleteTrail` Deny and `aws:RequestedRegion` Deny, excluding global services with `NotAction`
• CGuardDuty detects CloudTrail shutdown and CloudWatch alerts
• DIAM Permissions Boundary applied to all accounts

Question 6

A policy intended to block sensitive actions without MFA used `"Bool": {"aws:MultiFactorAuthPresent": "false"}`, unexpectedly blocking service automation calls. Correct fix?

• AChange condition to `"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}`
• BSwitch Deny to Allow
• CRemove MFA condition entirely
• DForce-register MFA on all users

Question 7

Dozens of teams operate resources; policy additions per new team causes explosion. Most scalable least-privilege approach?

• AGrant all teams same admin policy
• BUnify with ABAC: `aws:PrincipalTag/team` matches `aws:ResourceTag/team` in one Condition
• CContinue adding team-specific roles and policies
• DAbandon permission management; manual approval only

Question 8

Thousands of corporate employees need multi-account access. Avoid IAM User-per-account anti-pattern most appropriately how?

• ACreate one shared IAM User per account for team use
• BIAM Identity Center defines permission sets, federate external IdP, SSO issues temp credentials
• CDistribute root credentials to all employees
• DIssue long-term access keys to each employee

Question 9

Account A's role can't read KMS-encrypted S3 object in Account B. S3 bucket and A's IAM policy correctly allow GetObject. Most likely gap?

• AAccount B's KMS key policy doesn't allow A role `kms:Decrypt`
• BS3 doesn't support cross-account read
• CDifferent regions make it impossible
• DGetObject alone auto-permits KMS decryption

Question 10

SNS topic policy allows S3 service principal to post events. Block other people's S3 buckets from triggering this topic how?

• AChange Principal to `*`
• BAdd Condition with `aws:SourceArn`(specific bucket) and `aws:SourceAccount` to allow only our bucket
• CDelete topic, replace with SQS
• DMake S3 bucket private

Week 1 Closing — Bridge to Next Week

This week's five — Shared Responsibility Model, policy evaluation algorithm, Identity/Resource policies, Condition and least privilege, STS and federation — are Domain 4 (IAM) core and prerequisite for all other five domains. Next week we enter data protection (KMS, encryption) in-depth; key policies, grants, encryption context there all unlock on these two questions learned here:

1. "At which stage of the IAM evaluation algorithm is this access decided?" (explicit Deny → filters → explicit Allow)
2. "Is this credential temporary or long-term, and is the delegation boundary safe?" (STS · trust policy · ExternalId)

Hold these two questions, and next week's KMS key policies, S3 encryption enforcement, Secrets Manager rotation become "this week's IAM thinking applied to data" instead of "separate tools to memorize."