SAP-C02 Cheatsheet — Deep Architecture Patterns, Decision Tables & Diagrams

Keep this page open while drilling SAP‑C02 questions. Prioritize constraints → trade-offs → simplest compliant architecture.

Quick facts (SAP-C02)

SAP-C02 “professional level” mental model

SAP-C02 is rarely about knowing a single service. It’s about designing under constraints:

1. Organization + governance first (accounts, guardrails, identity)
2. Connectivity strategy (hybrid, multi-VPC, DNS, inspection)
3. Security controls (preventive + detective + response)
4. Resilience plan (multi-AZ, multi-Region DR, dependencies)
5. Delivery + operations (IaC, CI/CD, observability, automation)
6. Cost and performance trade-offs (TCO, data transfer, purchase options)

If an answer “works” but ignores governance, operations, or recoverability, it’s usually not the best answer.

1) Multi-account governance (Organizations + Control Tower)

A practical multi-account layout (common SAP-C02 pattern)

    flowchart TB
	  Root[Organizations Root] --> SecOU[Security OU]
	  Root --> InfraOU[Infrastructure OU]
	  Root --> WorkloadsOU[Workloads OU]
	  Root --> SandboxOU[Sandbox / Experiments]
	
	  SecOU --> LogArchive[Log Archive]
	  SecOU --> Audit[Security / Audit Tooling]
	
	  InfraOU --> Net[Networking]
	  InfraOU --> Shared[Shared Services]
	  InfraOU --> CI[CI/CD Tooling]
	
	  WorkloadsOU --> Prod[Prod Accounts]
	  WorkloadsOU --> NonProd[Non-Prod Accounts]

Why this pattern wins: it limits blast radius, supports centralized logging/security, and aligns with “organizational complexity” scenarios.

Landing zone checklist (what SAP-C02 expects you to think about)

Baseline checklist

• Define an OU structure that matches isolation boundaries (prod/non-prod, regulated, sandbox).
• Implement preventive guardrails (SCPs) and enforce tagging (tag policies + “tag-on-create” controls).
• Centralize identity (IdP → IAM Identity Center) and establish break-glass access procedures.
• Centralize logging (org CloudTrail + Config) and define retention/immutability requirements.
• Turn on detective controls org-wide (GuardDuty/Security Hub) with delegated admin and aggregation.
• Decide shared networking: TGW/Cloud WAN, shared services VPC, centralized inspection, and egress controls.
• Set up cost visibility early (cost categories, budgets, CUR) so the organization can do chargeback/showback.

Guardrails: SCP vs IAM vs resource policy vs key policy

High-yield rule: SCP is a boundary (it can only restrict). Even if IAM allows, an SCP deny still blocks the action.

Exam cue: If you see “prevent anyone in an account from doing X,” think SCP. If you see “allow this other account/service to access Y,” think resource policy + role (and confirm SCPs don’t block it).

Control Tower (landing zone) basics

Control Tower is often the “least operational overhead” answer when you need:

• Fast creation of a landing zone with guardrails
• Account factory / vending
• Centralized audit/log archive foundations

Use custom landing zones only when the question explicitly calls for it or constraints require non-standard behavior.

Cross-account access patterns (humans vs workloads)

Rule of thumb: Humans get federated, short-lived access; workloads assume roles.

2) Networking & connectivity (multi-VPC, hybrid, DNS, inspection)

Inter-VPC connectivity: choose the right primitive

Exam cue: If you see “dozens/hundreds of VPCs, shared services, on-prem connectivity,” think TGW (or Cloud WAN for global policy-driven networks).

Transit Gateway (TGW) design patterns (route tables + segmentation)

TGW questions are rarely “what is TGW?” They’re usually about segmentation, routing intent, and operational scale.

High-yield TGW concepts

• TGW enables transitive routing (solves the peering-mesh problem).
• Use multiple TGW route tables to enforce segmentation (prod vs non-prod vs shared vs inspection).
• Prefer “hub-and-spoke”: spokes attach to TGW; shared services and egress/inspection live in dedicated VPCs/accounts.
• For centralized inspection, design for symmetric flows (appliance mode / routing patterns) so return traffic goes through the inspection layer.

Common TGW route table layout

Exam cue: If the scenario says “separate business units and prevent lateral movement,” the best answer often includes separate accounts/VPCs + TGW segmentation (not one giant flat network).

Hub-and-spoke with centralized inspection (classic SAP-C02)

    flowchart LR
	  OnPrem[On-Premises] --- DX[Direct Connect]
	  DX --- DXGW[DX Gateway]
	  DXGW --- TGW[Transit Gateway]
	  TGW --- Egress[Central Egress + Inspection]
	  TGW --- Shared[Shared Services VPC]
	  TGW --- App1[App VPC - Account A]
	  TGW --- App2[App VPC - Account B]
	  Egress --> IGW[Internet Gateway]

Inspection building blocks:

• AWS Network Firewall for managed L3/L4 inspection
• GWLB to insert third-party appliances transparently
• Separate TGW route tables for segmentation (prod/non-prod, shared services, inspection)

Hybrid connectivity: DX vs VPN (and how to make it resilient)

Exam cue: If you see “must be encrypted” + “needs predictable performance,” choose DX + VPN (VPN for encryption/failover; DX for throughput).

DNS across hybrid and multi-account

High-yield components:

• Route 53 Resolver inbound endpoint: on-prem → AWS name resolution
• Route 53 Resolver outbound endpoint: AWS → on-prem DNS
• Resolver rules shared across accounts with AWS RAM
• Private hosted zones associated to VPCs (including shared VPC/subnet scenarios)

Common trap: Forgetting that DNS in large orgs needs a sharing model (RAM) and centralized governance.

Private access: endpoints beat NAT for security and cost

Default pattern: Private subnets use VPC endpoints wherever possible.

Exam cue: “No internet egress allowed” + “private subnets need to call AWS service” → VPC endpoint.

Egress control patterns (centralize, distribute, or eliminate)

High-yield guidance

• For resilience, NAT is typically one per AZ (avoid a single NAT as a SPOF and avoid cross-AZ routing).
• If the scenario emphasizes inspection, expect to see Network Firewall or GWLB patterns.
• If the scenario emphasizes cost and AWS service access, push toward VPC endpoints over NAT.

3) Security controls as architecture (IAM, KMS, logging, detection)

Identity and access: a few rules that show up everywhere

• Prefer roles + short-lived credentials (STS).
• Use MFA for privileged actions; use “break-glass” only with strict monitoring.
• In orgs: use Identity Center + permission sets, not IAM users in every account.
• For cross-account: lock down the trust policy (who can assume) and the permissions policy (what they can do).

IAM policy types: trust vs permissions (common SAP-C02 confusion)

Exam cue: If the scenario says “a pipeline in Account A must deploy to Account B,” the answer usually includes AssumeRole with a tight trust policy in Account B.

S3 security patterns that show up in architecture questions

High-yield defaults

• Turn on S3 Block Public Access at the account level (and keep it on).
• Prefer private buckets + controlled access: bucket policy, access points, and VPC endpoints.
• Enforce TLS (aws:SecureTransport) and require encryption (SSE-S3 or SSE-KMS) where needed.

Copy-ready snippets (adapt as needed)

Require TLS for all S3 requests:

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "DenyInsecureTransport",
 6      "Effect": "Deny",
 7      "Principal": "*",
 8      "Action": "s3:*",
 9      "Resource": [
10        "arn:aws:s3:::my-bucket",
11        "arn:aws:s3:::my-bucket/*"
12      ],
13      "Condition": {
14        "Bool": { "aws:SecureTransport": "false" }
15      }
16    }
17  ]
18}

Restrict access to principals in your AWS Organization:

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "DenyOutsideOrg",
 6      "Effect": "Deny",
 7      "Principal": "*",
 8      "Action": "s3:*",
 9      "Resource": [
10        "arn:aws:s3:::my-bucket",
11        "arn:aws:s3:::my-bucket/*"
12      ],
13      "Condition": {
14        "StringNotEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" }
15      }
16    }
17  ]
18}

CloudFront note: For public content, CloudFront should access S3 via Origin Access Control (OAC) (not a public bucket). The best answer often combines CloudFront + private S3 + controlled bucket policy.

Secrets and certificates (pick the right tool)

KMS “gotchas” (professional-level)

Mental model: To use a KMS key, permissions must line up across:

• Key policy
• IAM policy
• (Sometimes) grants / service integration
• Org guardrails (SCP can still block)

Copy-ready example: region restriction SCP (use with care)

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "DenyOutsideApprovedRegions",
 6      "Effect": "Deny",
 7      "Action": "*",
 8      "Resource": "*",
 9      "Condition": {
10        "StringNotEquals": {
11          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
12        }
13      }
14    }
15  ]
16}

Exam note: Region-deny SCPs can unintentionally block global services or required Regions. The “best” answer often includes a well-defined approved Region list + documented exceptions.

KMS key policy patterns (admin vs usage, cross-account)

High-yield rules

• Separate key administrators from key users (different principals).
• If a service can’t use the key, the first place to look is often the key policy (not the IAM role).
• For cross-account encryption/decryption, you must allow the external account principal to use the key (and ensure SCPs don’t block it).

Minimal example key policy pattern (illustrative):

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "KeyAdmins",
 6      "Effect": "Allow",
 7      "Principal": { "AWS": "arn:aws:iam::111122223333:role/SecOpsKmsAdmin" },
 8      "Action": "kms:*",
 9      "Resource": "*"
10    },
11    {
12      "Sid": "AllowUseFromAppRole",
13      "Effect": "Allow",
14      "Principal": { "AWS": "arn:aws:iam::444455556666:role/AppRole" },
15      "Action": [
16        "kms:Encrypt",
17        "kms:Decrypt",
18        "kms:GenerateDataKey*",
19        "kms:DescribeKey"
20      ],
21      "Resource": "*"
22    }
23  ]
24}

Exam cue: If the scenario mentions multi-Region DR with encrypted data, consider multi-Region keys (simplifies replicated encryption across Regions).

Logging and audit (centralize it)

High-yield pattern: Dedicated log archive account + org-wide CloudTrail + centralized S3 + lifecycle/immutability.

Core building blocks:

• Organizations trail (CloudTrail across accounts)
• CloudTrail Lake for queryable event storage and investigations
• AWS Config for config history and compliance
• Centralized aggregation for GuardDuty and Security Hub

Exam cue: “Need visibility across all accounts” → centralized security + logging accounts, delegated admin, org trail.

Detection and response: align to “least ops”

Common pro-level combinations:

• GuardDuty (threat detection) + Security Hub (posture + findings aggregation)
• EventBridge rules to trigger automation (SSM Automation / Lambda) for containment and response
• Config rules / conformance packs for continuous compliance

4) Reliability, DR, and business continuity (RTO/RPO selection)

DR strategy selection table (memorize this)

Exam cue: If you see strict RTO/RPO and “business can’t tolerate downtime,” you’re in warm standby or active-active territory.

Multi-Region data options (high-yield)

Traffic failover: Route 53 vs Global Accelerator vs CloudFront

Rule of thumb: If you need static anycast IPs and fast failover, look at Global Accelerator. If you need caching and HTTP edge, look at CloudFront.

Route 53 routing policies (quick selection table)

Exam cues

• “Active-passive DR” → Failover routing with health checks.
• “Gradually shift traffic / A/B testing” → Weighted routing.
• “Optimize latency for global users” → Latency routing (or Global Accelerator for faster failover with anycast IPs).

DR readiness checklist (what good answers include)

• Clear mapping from requirements to RTO/RPO and chosen DR strategy.
• Automated backup with cross-account/cross-region protection where needed (AWS Backup, vault lock, lifecycle).
• Explicit failover and failback plan (including DNS/traffic and data directionality).
• Validation plan: game days, restore tests, and monitoring for replication lag and backup failures.
• Awareness of dependencies (identity, DNS, certificates, secrets, third-party services).

DR architecture sketch (active-passive)

    flowchart LR
	  Users[Users] --> R53[Route 53 / GA]
	  R53 -->|Primary| RegionA[Region A]
	  R53 -->|Failover| RegionB[Region B]
	
	  subgraph Region A
	    ALBA[ALB] --> AppA[App Tier]
	    AppA --> DBA[(Primary DB)]
	  end
	
	  subgraph Region B
	    ALBB[ALB] --> AppB[Warm App Tier]
	    AppB --> DBB[(Replica/Global DB)]
	  end

5) Deployment strategy (CI/CD + IaC + multi-account)

A common “least operational overhead” pipeline design

    sequenceDiagram
	  participant Dev as Developer
	  participant Repo as Source Repo
	  participant Pipe as CI/CD (Tools Account)
	  participant Stg as Staging Account
	  participant Prod as Prod Account
	
	  Dev->>Repo: Commit / PR
	  Repo->>Pipe: Trigger build + tests
	  Pipe->>Stg: Assume deploy role\nDeploy IaC + app
	  Pipe->>Prod: Approval gate\nAssume deploy role\nDeploy
	  Prod-->>Pipe: Health checks + alarms

High-yield implementation pieces:

• Pipeline in a tools account
• Cross-account deployment via AssumeRole
• IaC promotion (dev → stage → prod)
• Automated rollback based on alarms/SLOs

Cross-account deployments: trust policy (example)

Target accounts typically expose a deployment role that the tools account can assume.

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "AllowToolsAccountToAssume",
 6      "Effect": "Allow",
 7      "Principal": { "AWS": "arn:aws:iam::111122223333:role/ToolsDeployRole" },
 8      "Action": "sts:AssumeRole"
 9    }
10  ]
11}

Exam cue: If the question mentions “many accounts” and “standard baselines,” consider CloudFormation StackSets (or Control Tower customizations) to deploy org-wide resources consistently.

Deployment patterns: pick based on risk and state

Exam cue: If the question says “minimize downtime and risk” → blue/green or canary with automated rollback.

6) Performance design (end-to-end)

Load balancers: ALB vs NLB vs GWLB

Compute selection (EC2 vs containers vs serverless)

Exam cue: If the scenario says “minimize operational overhead,” managed options (Fargate/Lambda/managed data stores) usually beat self-managed EC2.

Cache and edge: what improves “global performance” fastest

• CloudFront: caching, TLS offload, origin failover for HTTP(S)
• ElastiCache (Redis/Memcached): hot data, session caches, query caching
• DynamoDB DAX: microsecond read cache for DynamoDB-heavy workloads

Exam cue: If latency is for global users and content is cacheable → CloudFront.

7) Cost optimization & visibility (FinOps patterns)

Cost visibility building blocks (multi-account)

• Cost allocation tags + cost categories for showback/chargeback
• CUR to S3 + Athena/QuickSight for deep analysis
• Budgets + alerts + automated actions for guardrails
• Savings Plans / Reserved Instances governance for predictable workloads
• Compute Optimizer for rightsizing

Purchase options (fast table)

Exam cue: If the workload is fault-tolerant and batch/async, Spot is often the “most cost-effective” answer (paired with retries/checkpointing).

Data transfer cost quick wins (commonly tested)

• Prefer same-AZ traffic paths when possible (avoid hidden cross-AZ transfer).
• Replace NAT-heavy service access with VPC endpoints (especially S3/DynamoDB gateway endpoints).
• Use CloudFront for cacheable global content to reduce origin egress.
• Consider Direct Connect for large, steady hybrid data movement (and model the TCO).
• Watch “per-GB processing” services in the middle of flows (TGW, GWLB) when cost is a key constraint.

High-yield cost “gotchas” in architectures

• Cross-AZ data transfer: invisible until it’s huge; design for AZ-local paths when possible.
• NAT Gateway costs: expensive at scale; prefer VPC endpoints.
• Data processing costs: TGW, GWLB, and some managed services have per-GB processing fees.
• Logging costs: high-volume logs with long retention can explode budgets; tune retention and sampling.

8) Operational excellence (improve what already exists)

Professional-level answers often include:

• Standardized IaC + drift detection
• Centralized observability (logs/metrics/traces) across accounts
• Automated remediation (SSM Automation + EventBridge)
• Runbooks + game days + postmortems

Centralized observability (one common enterprise pattern)

    flowchart LR
	  subgraph Workloads
	    A1[Workload Account A] --> CW1[CloudWatch]
	    A2[Workload Account B] --> CW2[CloudWatch]
	  end
	
	  CW1 --> Agg[Central Observability]
	  CW2 --> Agg
	  Agg --> S3[(Central Log Archive S3)]
	  Agg --> SO[Search/Analytics]
	  Agg --> IR[Incident Response Runbooks]

High-yield implementation ideas:

• Centralize CloudTrail and Config in security/log archive accounts.
• Use log subscriptions/aggregation for app logs (central store with defined retention).
• Use dashboards + alarms tied to SLOs; wire alarms into incident workflows.

If the question is “how to improve,” the best answer is usually the one that is systematic and automatable (not a one-off manual fix).

9) Migration & modernization (portfolio → approach → target architecture)

The 6Rs (migration strategies)

Modernization patterns (what “professional-level” answers look like)

Common patterns that show up in SAP-C02 scenarios:

• Strangler fig: route a slice of traffic to new services while the monolith remains.
• Parallel run: run old and new in parallel with validation, then cut over.
• Event-driven decomposition: introduce events (EventBridge/SNS/SQS/Kinesis) to decouple domains.
• Managed service adoption: move from self-managed to managed databases/queues/cache to reduce ops.

Strangler fig sketch:

    flowchart LR
	  Users --> Edge[Edge/Router]
	  Edge -->|Legacy paths| Mono[Monolith]
	  Edge -->|New paths| New[New Service]
	  New --> Data[(Managed Data)]

Exam cue: When the question says “modernize with minimal downtime and risk,” incremental patterns like strangler fig + canary/weighted routing often beat “big bang” rewrites.

Migration tooling map (high-yield)

• Migration Hub: portfolio tracking and migration visibility
• Application Migration Service (MGN): server replication + cutover for rehost
• DMS + SCT: database migration with CDC and schema conversion
• Snowball / Direct Connect: large data transfer depending on constraints

Migration waves (sequencing and risk control)

    flowchart LR
	  A[Discover + Assess] --> B[Plan Waves]
	  B --> C[Build Landing Zone]
	  C --> D[Pilot Wave]
	  D --> E[Scale Waves]
	  E --> F[Stabilize + Optimize]

10) High-yield scenario cues (fast picks)

• Many VPCs across accounts + on-prem + transitive routing → Transit Gateway (or Cloud WAN for global policy control).
• Private access to AWS services without internet/NAT → VPC endpoints (gateway for S3/DynamoDB; interface for others).
• Need to expose a service privately across accounts without routing complexity → PrivateLink.
• Org-wide guardrail (“nobody in this OU may do X”) → SCP.
• “KMS access denied” in a cross-account setup → check key policy and grants (IAM alone isn’t enough).
• Strict RTO/RPO and business can’t tolerate downtime → warm standby or active-active (Route 53 / GA + replicated data).
• Need ultra-fast failover + static anycast IPs → Global Accelerator.
• Need edge caching for global HTTP performance → CloudFront.
• Improve an existing system long-term → Well-Architected review + automation + guardrails, not manual one-off fixes.
• Hybrid name resolution requirement (on-prem ↔ AWS) → Route 53 Resolver inbound/outbound endpoints + shared resolver rules (RAM).
• “Need a landing zone quickly with guardrails” → Control Tower (often least ops).
• “Share network building blocks across accounts” → AWS RAM (shared subnets, resolver rules, TGW attachments where applicable).
• “Centralize inspection for ingress/egress” → Network Firewall or GWLB + segmented TGW route tables.
• “Keep S3 private and accessible from private subnets” → Gateway VPC endpoint + bucket policy/VPC endpoint policy.
• “Make audit logs tamper-resistant” → dedicated log archive account + lifecycle/Object Lock controls.

Next steps

• Work the blueprint: Syllabus →
• Drill under time: Practice →
• Confirm format and weights: Overview →