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

🔍 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.