AWS SAP-C02 Cheat Sheet: Governance, DR, and Migration

SCP: Service control policy, the AWS Organizations guardrail that limits the maximum permissions an account or OU can use.

TGW: Transit Gateway, the AWS hub service for connecting many VPCs and on-premises networks with transitive routing.

KMS: Key Management Service for creating, governing, and using encryption keys.

RTO / RPO: Recovery Time Objective and Recovery Point Objective, the two recovery targets that drive disaster-recovery design.

Quick facts (SAP-C02)

I verified these current AWS exam facts on May 24, 2026.

Domain weights and review priority

AWS also notes that current SAP-C02 may include unscored pretest questions about emerging architecture topics, including security and responsible AI controls. Treat those as experimental: answer them with normal Well-Architected reasoning, but do not let one unfamiliar Bedrock or agentic-AI stem consume your time.

Professional architecture proof stack

SAP-C02 questions rarely ask whether a single AWS service can solve a problem. They ask whether the architecture can survive enterprise constraints. Before choosing an answer, walk the scenario through this stack:

1. Organization boundary: identify account, OU, identity, SCP, delegated admin, log archive, audit, shared-services, and workload ownership before workload design.
2. Blast radius: decide which boundary should contain failure, compromise, cost overrun, deployment error, or migration rollback.
3. Network path: prove routing, DNS, inspection, segmentation, private access, hybrid connectivity, and cross-account sharing before adding broad connectivity.
4. Security evidence: combine preventive controls, detective controls, centralized logs, KMS boundaries, findings, incident response, and compliance evidence.
5. Resilience target: match RTO/RPO, dependency readiness, data replication, failover, secrets, certificates, runbooks, and game-day testing.
6. Migration stage: separate assessment, wave planning, dependency grouping, 6R strategy, data movement, cutover, rollback, and modernization timing.
7. Improvement loop: use metrics, traces, logs, cost data, failure tests, Well-Architected reviews, automation, and IaC drift correction before redesigning blindly.

If an answer is technically valid but cannot explain governance, blast radius, recovery evidence, or operational ownership, it is usually too narrow for Solutions Architect - Professional.

Official task compression

Design Solutions for Organizational Complexity covers connectivity, security controls, resilience, multi-account design, cost visibility, shared services, and governance. Start with accounts, guardrails, shared networking, logging, identity, and cost allocation before picking workload services.

Design for New Solutions covers deployment, business continuity, security, reliability, performance, operations, and cost. Translate requirements into a complete architecture: deployment path, rollback, DR, controls, scaling model, cost model, and operational evidence.

Continuous Improvement for Existing Solutions covers operational excellence, security, performance, reliability, and cost across existing workloads. Use evidence from logs, metrics, traces, cost reports, incidents, Well-Architected reviews, and failure tests; then automate the durable fix.

Accelerate Workload Migration and Modernization covers portfolio assessment, migration approach, target architecture, cutover risk, and modernization. Choose a 6R strategy per workload, group dependencies into waves, reduce cutover risk, and modernize incrementally when business risk is high.

SAP-C02 boundary cues

AWS frames SAP-C02 around advanced architecture decisions inside the Well-Architected Framework. Use that boundary to reject off-scope or over-detailed answers:

• If the answer goes deep into frontend mobile development, 12-factor app methodology, or operating-system internals, it is probably not the exam’s target unless the stem clearly anchors it to an AWS architecture decision.
• If the answer solves one workload but ignores account structure, governance, logging, identity, and shared networking, it is probably too associate-level for organizational-complexity scenarios.
• If the answer chooses a DR pattern without RTO/RPO, data replication, DNS/traffic failover, dependency readiness, and test evidence, it is not professional enough.
• If the answer proposes migration tooling before portfolio assessment, dependency mapping, wave planning, 6R choice, and rollback, it is premature.
• If an emerging AI-control stem appears, treat it with normal architecture reasoning: content filtering, identity, approval workflows, logging, least privilege, and human oversight.

SAP-C02 answer sequence

Use this when the scenario mixes governance, networking, DR, and delivery.

    flowchart TD
	  S["Scenario"] --> G["Governance and accounts first"]
	  G --> N["Connectivity and inspection"]
	  N --> R["Security and logging"]
	  R --> D["Resilience and RTO/RPO"]
	  D --> O["Operations, automation, and cost"]

Question-type traps

Unanswered questions are incorrect and there is no penalty for guessing. With 75 questions in 180 minutes, your average budget is 2.4 minutes per question; mark long multi-paragraph scenarios once you have narrowed them to two plausible answers.

Scenario eliminations

Professional evidence map

Final 25-minute recall (exam day)

Cue -> best answer (pattern map)

Must-memorize professional-level defaults

Last-minute traps

• Picking technically valid architecture that ignores governance/operability.
• Forgetting shared-service blast radius and route table segmentation in TGW designs.
• Assuming IAM allow is enough when SCP or key policy denies.
• Proposing DR patterns without proving dependency readiness (data, DNS, secrets, pipeline).

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)

    flowchart TD
	  S["Scenario"] --> G["Governance / org design"]
	  G --> N["Connectivity / inspection / DNS"]
	  N --> R["Security controls and logging"]
	  R --> D["DR and dependency readiness"]
	  D --> O["Delivery, operations, cost, and performance"]

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

Enterprise architecture decision ladder

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

Continuous improvement triage

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

The 6Rs (migration strategies)

Migration approach chooser

Cutover risk checklist

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

• Use Resources to stay anchored to the official exam guide and enterprise AWS docs.
• Use the FAQ when you need a quick reset on pacing, RTO/RPO framing, and governance depth.
• Keep these decision tables open while you drill long-form architecture scenarios.

Quiz