Day 5 - Week 1 Wrap-Up: Fundamentals and IAM Hardened Through Scenarios

Over the week, we swept from global infrastructure to multi-account governance. Even if you feel you know it all in your head, the SAA-C03 exam always transforms it into one-line scenarios. From the single sentence "data cannot leave headquarters," Outposts must come to mind; from "minimizing global latency for a TCP game server," Global Accelerator must pop out instantly. The exam isn't trying to filter out people who memorized keywords — it's trying to select people who can quickly judge "what is the essence of this scenario."

This article revisits Week 1 while etching the scenario keyword → solution mapping into your head. Not rote memorization — we'll trace "why that answer" one more time. The scenario mapping is also an area where reading it through once more the day before the exam clearly raises your passing margin. And in practice, this mapping becomes "the ability to review someone else's design before an incident happens" — every incident we saw in Week 1 (Capital One, us-east-1, the Tokyo AZ, SolarWinds, Travis CI) ultimately happened when someone confused the same mapping.

Redrawing the Week 1 Picture

[ AWS Global Infrastructure ]
       │
       ├── Region (34) ──┬── AZ (3+) ──┬── DC
       │                 │             └── DC
       │                 └── AZ ── DC
       ├── Edge Location (600+) ── CloudFront / R53 / GA / WAF
       ├── Local Zone (30+) ── mini region
       ├── Wavelength ── 5G edge
       └── Outposts ── customer DC

[ Identity ]
   User / Group / Role / Policy
       │
   AssumeRole (STS) → temporary credentials
       │
   ┌─── External ID (Confused Deputy defense)
   ├─── Permissions Boundary (permission ceiling)
   ├─── ABAC (tag-based)
   └─── OIDC/SAML (federation)

[ Multi-Account ]
   Organizations → OU tree
       │
   ┌─── SCP (account permission ceiling)
   ├─── Control Tower (automated Landing Zone)
   ├─── RAM (resource sharing)
   └─── StackSets (bulk deployment)

These three areas are Week 1's conclusion, and it's accurate to see every service from Week 2 through Week 12 as layered on top of these three planes. Networking runs on top of AZs, security on top of IAM, and multi-account patterns on top of Organizations. And the intersection of these three planes — "who can do what to a resource in which AZ of which region of which account" — ultimately becomes the coordinate system of every SAA scenario.

💡 Related theory: This 3-layer model is actually a mapping of the classic 3 axes of distributed systems security — Where (location), Who (identity), What (resource) — onto cloud operations. In addition to the security triad NIST defined in 1985 (Confidentiality / Integrity / Availability), the three areas codified by NIST SP 800-53 in 2003 — Access Control (AC), Audit & Accountability (AU), and System and Communications Protection (SC) — match almost one-to-one. AC is implemented by IAM, AU by CloudTrail/Config, and SC by VPC/network controls.

🔍 Going deeper: These 3 layers are reflected as-is in AWS's actual permission evaluation engines. AWS Zelkova (IAM formal verification) and Tiros (network formal verification) convert IAM/SCP policies and VPC routing, respectively, into SMT constraints to solve "is this request reachable." The 2018 USENIX Security paper "Semantic-based Automated Reasoning for AWS Access Policies" is Zelkova's foundation, and "Reachability Analysis for AWS-based Networks," published the same year, is Tiros's. Access Analyzer, Reachability Analyzer, and IAM Access Advisor all run on top of these.

Scenario Keyword Mapping

This table reads through in 30 minutes the day before the exam, and after reviewing the same mapping 5+ times, candidate answers surface from the first line of a scenario in the exam room. The keyword → solution mapping best illustrates the SAA's nature as a "pattern recognition exam."

💡 Related theory: This pattern-mapping approach is exactly the Recognition-Primed Decision Making (RPD, Gary Klein 1989) model from cognitive psychology. It's the mode of thinking where ER doctors, firefighters, and chess masters don't "compute every option like a novice," but go straight to "this situation is pattern X, so solution Y." AWS SAA, too, is ultimately an exam of classifying roughly 200 scenario patterns. Viewed through System 1 (intuition) and System 2 (analysis) from Daniel Kahneman's Thinking, Fast and Slow (2011), the most efficient flow for the SAA exam is patternizing System 1 to narrow candidates quickly, then verifying with System 2.

⚠️ Pitfall: The same keyword often leads to different answers. Is "encryption" KMS or CloudHSM? Single-company use means KMS; FIPS 140-2 Level 3 regulation (FedRAMP High, some finance) means CloudHSM. Is "DR" Multi-AZ or Cross-Region? AZ-level isolation is Multi-AZ; region-level isolation is Cross-Region. Don't look at the keyword alone — also ask "what is this scenario's threat model."

CAP/PACELC and the AWS Service Mapping

SAA doesn't ask this directly, but it's decisive for interpreting scenarios. Without knowing distributed-systems trade-offs, you can't answer questions like "why can't this option provide strong consistency." And this mapping is used directly in practice when debugging "why did our service's global consistency break."

💡 Related theory: The CAP theorem (Brewer 2000, Gilbert & Lynch 2002) says that under a network partition, you must choose between Consistency and Availability. PACELC (Abadi 2012) adds that "even without a partition, there's a trade-off of Latency vs Consistency." Almost every AWS global service leans PA/EL (availability under partition, latency otherwise). S3 gaining strong read-after-write consistency in December 2020 was a big event in distributed systems history. Before then, new objects were visible immediately but updates/deletes were eventual, making it a staple SAA trap. Now every S3 operation is strongly consistent — though object metadata caching layers (CloudFront, ALB origin) remain eventual.

🔍 Going deeper: DynamoDB's strong consistency is offered only as an option within a single region (ConsistentRead=true), and Global Tables are always eventual. Global Table conflict resolution is Last-Writer-Wins (LWW) based, so concurrent writes carry data-loss potential. So if you need multi-master global writes, use DynamoDB Global Tables but first ask "is timestamp conflict acceptable for the business." If stricter consistency is needed, you need CRDTs (Conflict-free Replicated Data Types) or Paxos/Raft-based consensus algorithms, which AWS partially provides through Aurora's quorum-based replication (6-way write across 3 AZs, 4/6 read, 3/6 write quorum). The Aurora paper Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases (SIGMOD 2017) is the essence of this architecture.

📚 Case study: In 2015, GitHub had data consistency broken for 24 hours in a partition incident of its own MySQL cluster. A network partition occurred between two data centers, and both sides decided they were the primary and accepted writes — a split-brain event. In the post-mortem report, GitHub stated explicitly: "under a partition, we choose CP and give up availability." Such cases show CAP trade-offs are not abstract theory but decisions operators face daily. AWS made the same decision with RDS Multi-AZ, which is why availability drops for about 60 seconds during failover.

⚠️ Pitfall: Assuming "Aurora is strongly consistent, so its global DB is too" is wrong. Aurora Global Database is storage-level async replication (typically 1-second RPO) and secondary regions are read-only. If you want global writes you must use DynamoDB Global Tables, but that means accepting LWW's conflict risk. Also, viewing "ElastiCache Redis Cluster Mode as async replication but availability guaranteed via multi-AZ failover" is partially wrong — writes not yet acked can be lost during failover.

The Shared Responsibility Model, Reorganized

       Abstraction ↑                              AWS responsibility ↑
┌─────────────────────────────────────┐
│ S3, DynamoDB, Lambda (fully managed)│ only data classification & IAM are the customer's
│ RDS, Fargate (PaaS)                 │ + network settings are the customer's
│ ECS on EC2, EKS Self-Managed        │ + OS patching is the customer's
│ EC2 + EBS (IaaS)                    │ OS & apps entirely the customer's
└─────────────────────────────────────┘
       Abstraction ↓                              Customer responsibility ↑

As service abstraction rises, the responsibility boundary moves up. Yet data classification, IAM, and encryption key management are always the customer's — that's the key point. The Capital One incident shows this principle most clearly — AWS fulfilled its infrastructure responsibility, and the incident arose in the customer's domain: IMDSv1 and excessive IAM permissions.

📚 Case study: In June 2022, a Toyota subsidiary had an access key exposed in a public GitHub repository for 5 years. About 300,000 customers' data was put at risk, and the cause was a developer pushing credentials along with the code. AWS's responsibility: 0% — everything happened in the customer's responsibility area. The standard post-incident recommendations: ① IAM Roles + IRSA/Instance Profiles instead of IAM Users, ② if Access Keys must be issued, temporary credentials via IAM Identity Center, ③ block commits with Git pre-commit hooks (git-secrets, truffleHog). The same pattern of incident repeated at Uber (2016), Imperva (2019), and Codecov (2021).

🔍 Going deeper: The shared responsibility model differs subtly per service. For RDS, DB engine patches (minor versions) are AWS; major version upgrades are the customer's choice. For Lambda, runtime patches are AWS; migration after a runtime's EOL is the customer's (Node 14 → 18, etc.). For ECS Fargate, the container OS and runtime are AWS; patching OS packages inside the image is the customer's. These subtle differences appear frequently as exam traps. AWS Trusted Advisor and AWS Security Hub's Foundational Security Best Practices (FSBP) automatically check these responsibility boundaries.

The Policy Evaluation Decision Tree

Request → SCP(Org) → Resource Policy → Identity Policy → Permissions Boundary → Session Policy
   Explicit Deny at any stage → immediate DENY
   All stages passed → ALLOW
   No Allow anywhere → DENY (default)

Same account = union, cross-account = intersection, KMS = explicit delegation in the Key Policy required. These three lines are the entirety of IAM evaluation logic. If an interviewer asks "explain AWS IAM evaluation logic in under a minute," these three lines are the answer.

⚠️ Pitfall: "Just Allow in the Resource Policy and cross-account works" is the most common wrong answer. Within the same account that's true, but cross-account, the caller account's Identity Policy must also Allow. A staple exam trap. And KMS is a class of its own — unless the Key Policy explicitly delegates to IAM (the "Enable IAM User Permissions" statement), even an Allow in an IAM policy can't use the KMS key. That's because KMS follows the model that "the key owner is the final authority."

🔍 Going deeper: Policy evaluation is actually decided by the intersection of 6 policy types — SCP, Resource Policy, Identity Policy, Permissions Boundary, Session Policy, and VPC Endpoint Policy. The "Policy Evaluation Logic" flowchart in AWS's official documentation is the most accurate reference. Which policy types are "Allow required vs optional" differs per scenario. One-line summary: an explicit Deny is always final; an Allow must pass every boundary.

💡 Related theory: This model is a hybrid of security theory's Mandatory Access Control (MAC) and Discretionary Access Control (DAC). SCPs and Permissions Boundaries are MAC (limits enforced by a higher authority); Identity/Resource Policies are DAC (freely configured by the owner). It resembles the multilevel security concept of the US military security standard, the Bell-LaPadula Model (1973). The reason AWS can solve policy evaluation with an SMT solver is precisely that this model has a formally verifiable structure.

The Standard Multi-Account Topology

This topology is explicitly specified as the recommended form in the AWS Security Reference Architecture (SRA) document. It's accurate to assume every large enterprise customer uses a variation of it. Look at public presentations from Netflix, Capital One, Airbnb, Slack, and others, and nearly the same pattern repeats.

📚 Case study: In 2019, the Netflix Tech Blog published its multi-account strategy, revealing that while operating more than 1,000 AWS accounts, it standardized an "Account per Workload" pattern splitting accounts finely by workload, team, and environment. The reasons: ① blast radius limitation, ② cost/tag automation, ③ IAM permission simplification. Spotify, Lyft, and Stripe adopted the same pattern, and this is the real-world model behind the topology SRA recommends. As of 2023, large companies typically operate 100~5,000 accounts, with the AWS Organizations limit (10,000 accounts/Org) as the de facto ceiling.

🔍 Going deeper: The practical core of multi-account operations is two automations. ① Account provisioning automation — with Control Tower's Account Factory or Account Factory for Terraform (AFT), new account creation → baseline application → permission grants → notifications get tied into a GitOps flow. ② Automatic baseline deployment — CloudFormation StackSets' SERVICE_MANAGED + auto-deployment=Enabled option automatically pushes the security baseline (GuardDuty, Config Rules, IAM Password Policy, S3 BPA, etc.) into new accounts. Without these two automations, operating 100 accounts is humanly impossible.

Frequently Confused Key Comparisons

⚠️ Pitfall: ZoneName vs ZoneId rarely appears on the exam, but in practice it's decisive in security/cost scenarios asking about "using the same AZ as another account." CloudFront vs Global Accelerator is an exam staple; whenever the keywords "TCP/UDP," "gaming," "VoIP," "MQTT," or "WebRTC signaling" appear, it's unconditionally GA. CloudFront Functions vs Lambda@Edge follows the same comparison axis: "sub-millisecond responses" means Functions, "full Node.js/Python runtime" means Lambda@Edge.

🔍 Going deeper: When AWS provides the same capability via multiple services, the trade-off axis always differs. KMS vs CloudHSM is abstraction vs isolation, ALB vs NLB is L7 features vs L4 throughput, SQS vs SNS vs EventBridge is point-to-point vs fanout vs schema-routing. The SAA exam always requires identifying "which axis is the trade-off being asked on." Master this way of thinking, and even an unfamiliar new service can be mapped onto the same axes to narrow candidate answers.

Wrapping Up

Week 1 was about lodging "the coordinate system of the AWS universe" in your head. The Region/AZ/Edge isolation model, IAM's policy evaluation, multi-account governance. These three form the backdrop for every topic of the remaining 11 weeks. Next week we layer networking (VPC, subnets, routing) on top. Don't try to grasp everything at once; build the habit of reopening this table and mapping every time you solve a scenario question, and by exam eve the keyword → solution mapping will be lodged as an automatic reflex. And that automatic reflex is the core competency not just for passing the SAA, but of a senior engineer who "can sketch 3 solution candidates within a 30-minute meeting" in real-world design.

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

A global game company wants to provide consistent TCP-based game server response times to users worldwide. What is the most suitable solution?

• ACloudFront + Lambda@Edge — caches HTTP content at 600+ edge PoPs and even runs Node.js logic, but being L7 HTTP/HTTPS-only it can't accelerate the game's raw TCP sessions
• BGlobal Accelerator
• CRoute 53 Latency Routing — returns DNS answers pointing clients to the lowest-latency regional endpoint, but is bound by TTL caching and the actual packets ride the public internet as-is with no backbone acceleration
• DElastiCache Global Datastore — merely a cache layer replicating Redis data across regions in under 1 second, unrelated to routing game server TCP traffic

Question 2

A financial company must keep some data inside headquarters under Korean Financial Supervisory Service regulations while operating with AWS APIs. What is the most suitable solution?

• ADirect Connect only — connects headquarters and an AWS region with a low-latency dedicated line, but the data itself ends up stored in the AWS region, failing the "keep inside headquarters" regulatory requirement
• BLocal Zones — AWS-operated mini facilities in major cities providing low latency, but as AWS data centers rather than the customer's building, they're unsuitable for data sovereignty requirements
• COutposts
• DSnowball Edge — a one-off device for moving petabyte-scale data offline or short-term edge computing, unsuitable as an always-on AWS API operations platform

Question 3

A company wants to block use of all regions except us-east-1 across 50 AWS accounts. What is the most efficient method?

• AAdd IAM policies per account — you'd have to attach the same policy to every user and role in 50 accounts one by one, management explodes, and every new identity risks omission, making it unfit for governance
• BOrganizations SCP with an `aws:RequestedRegion` condition Deny
• CCloudTrail alerts — only detects and alerts on region usage after the fact via logs; it can't block the API calls themselves, so it isn't preventive
• DCreate VPCs only in us-east-1 — even without a VPC, region-scoped global services and services like S3/DynamoDB can still be called in other regions, so the block is incomplete

Question 4

What is the most secure way for EC2 to access S3?

• AStore the Access Key in ~/.aws/credentials — long-lived credentials sit in plaintext on disk, are stolen outright if the instance is compromised, and add a manual key rotation burden, making it dangerous
• BAttach an IAM Role via an Instance Profile + IMDSv2
• CUse a root Access Key — the top-level credential with unlimited account-wide permissions; exposure spreads damage account-wide, and AWS recommends absolutely never using it
• DAllow S3 Public Read — lets anyone read objects without authentication, leading directly to data leaks, a setting in the exact opposite direction of EC2 access control

Question 5

To eliminate key rotation burden when GitHub Actions deploys to AWS?

• AStore an IAM User Access Key as a Secret — keeping a long-lived key in GitHub Secrets works, but the periodic manual rotation burden remains, and if leaked via logs it's stolen outright, carrying the same risk as the Travis CI breach
• BShort-lived Role credentials via OIDC federation
• CSpin up EC2 with SSH keys — every deployment requires managing separate EC2 and SSH keys, complicating operations, and the key itself becomes another long-lived secret that doesn't eliminate rotation burden
• DRoot credentials — exposing unlimited account-wide permissions to CI, a head-on violation of least privilege and the worst possible choice

Question 6

A SaaS collects CloudWatch logs from our AWS. What is needed for Confused Deputy defense?

• ACross-Account Role + External ID condition
• BGrant an Access Key to an IAM User — handing a long-lived Access Key to the SaaS carries heavy leak/rotation burden and does nothing to solve the Confused Deputy problem itself
• CS3 Public Read — opens the log bucket to anyone, a data-leak configuration that is the exact opposite of safe delegated collection
• DVPN connection — provides only a network-layer tunnel, unrelated to the identity delegation and permission boundary problem when the SaaS borrows our account's role

Question 7

A company provisions 10 new AWS accounts every week and wants the same security baseline applied. What is the most suitable method?

• AOperators configure manually each time — a human must hand-apply the baseline to 10 accounts weekly, omissions and drift are inevitable, and operations collapse as scale grows
• BControl Tower Account Factory + StackSets auto-deployment
• CRun CloudFormation manually in each account — templates are consistent, but a person must run stacks and set up cross-account roles per new account, missing automatic propagation
• DRun Terraform Apply each time — IaC standardizes things, but without a separate pipeline tying in account creation/registration, a manual trigger is needed every time, falling short of full automation

Question 8

A company wants to let junior developers freely create IAM Roles but prevent creating AdministratorAccess-grade Roles. What is the most appropriate method?

• AAfter-the-fact detection with CloudTrail — logging Role creation allows retroactive tracing, but it can't prevent overly permissive Roles from being created in the first place, so it isn't preventive control
• BSpecify a Permissions Boundary as a mandatory attachment condition in the policy
• CRevoke all of the junior's permissions — this strips the Role creation ability itself, directly violating the requirement of "create freely but with only a ceiling"
• DUse only Organizations SCPs — an account/OU-level ceiling whose granularity is too coarse to enforce different limits per individual Role within the same account, so it's unsuitable

Question 9

EC2 goes down in one AZ due to a cooling failure. If the ASG is already configured multi-AZ?

• AAll services down — a multi-AZ ASG replenishes instances in surviving AZs, so the premise that one AZ failure takes everything down contradicts HA design itself
• BThe ASG automatically replenishes instances in other AZs; service continues
• CRDS Multi-AZ goes down too — RDS Multi-AZ has its standby in another AZ and fails over automatically within 30~60 seconds, so the claim that it goes down permanently alongside is wrong
• DManual failover required — ASG health checks and the ELB automatically replace unhealthy instances and redistribute, so no manual operator intervention is needed

Question 10

Which of the following is NOT AWS's responsibility?

• AHypervisor security — the virtualization layer including Nitro is the "security of the cloud" domain AWS designs, patches, and isolates, so it's entirely AWS's responsibility
• BGuest OS patching (EC2)
• CPhysical facility security — physical infrastructure like data center access control, power, and cooling is a hallmark AWS responsibility area handled exclusively by AWS
• DInter-AZ network encryption — backbone traffic linking AZs within a region has been automatically encrypted between Nitro instances since 2018, an AWS responsibility requiring no customer action

Question 11

A system requires sub-1ms RPO per transaction and operates in only one region. RDS should be?

• ASingle-AZ Standard — with only one instance in a single AZ, there's no replication at all; an AZ failure means data loss until backup restore, failing the 1ms RPO
• BMulti-AZ Synchronous Replication
• CCross-Region Read Replica — inter-region asynchronous replication has lag in the seconds range, far exceeding a 1ms RPO, and it's overkill given the same-region-only requirement
• DAurora Global Database — inter-region storage-level async replication (~1 second RPO) risks losing the secondary region's tail, and it's excessive for a single-region-only scenario

Question 12

A company within Organizations wants to share the central Networking account's VPC subnets with 30 other workload accounts. What is the most suitable solution?

• AVPC Peering 30 times — a point-to-point connection between the central VPC and each of 30 accounts; it's not sharing subnets but connecting separate-CIDR VPCs, differing from the requirement and carrying non-transitive constraints
• BShare subnets via AWS RAM
• CTransit Gateway only — merely a routing hub between VPCs, with each account still operating an independent VPC, failing the requirement of "directly sharing the central VPC's subnets"
• DDirect Connect — a dedicated-line service connecting on-premises and AWS, entirely unrelated to a cross-account VPC subnet sharing scenario