AWS Certified Solutions Architect - Professional (SAP-C02) Study Guide

AWS Certified Solutions Architect - Professional (SAP-C02) Study Guide

Issuing body: Amazon Web Services (AWS) Jurisdiction: Global (vendor certification — not a legal license to practice) Level: Professional Prerequisites: None formal. AWS recommends 2+ years of hands-on experience designing and operating AWS workloads and an Associate-level certification first. (Source: catalogue record software-cert-001.) Renewal: Valid 3 years; recertify by passing the current Professional-level exam.

1. What this exam is

SAP-C02 is AWS's flagship architecture credential and the hardest multiple-choice exam AWS offers. Where the Associate exam (SAA) tests whether you know what each service does, SAP-C02 tests whether you can design production-grade systems under constraints: multi-account governance, cost ceilings, RPO/RTO budgets, throughput targets, compliance regimes. Every question is a trade study in disguise.

2. Pathway and exam format

• Typical path: AWS Certified Solutions Architect – Associate (SAA-C03) first, then 1–2 years of real build experience, then SAP-C02. Associate is not required, but skipping it is usually a mistake — SAP-C02 assumes the full Associate body of knowledge.
• Format: 75 multiple-choice / multiple-response questions, 180 minutes (2.4 min/question), scored 100–1000, passing 750. Exam fee $300 USD. Delivered via Pearson VUE (test center or online proctoring).
• The exam is scenario-dense: expect long stems with 3–4 business/technical constraints and 4–5 answer options, often "choose two" or "which combination meets ALL requirements." Multi-select is the core skill being tested — can you hold all constraints simultaneously.
• Mark the answer against the constraints, not against AWS best practice. The most common failure mode is picking the "textbook best" answer that violates one stated requirement (e.g., proposing a feature in a region it hasn't launched in, or a cost-optimized design that misses an RTO).

3. Knowledge domains (with theory)

AWS publishes domain weightings for SAP-C02 (approximate): Domain 1 — Design Solutions for Organizational Complexity (~26%), Domain 2 — Design for New Solutions (~29%), Domain 3 — Continuous Improvement for Existing Solutions (~25%), Domain 4 — Accelerate Workload Migration and Modernization (~20%). These are approximate public figures; learn the whole blueprint.

Domain 1: Organizational complexity — multi-account strategy

The theory: blast radius, policy hierarchy, and the billing boundary. The account is the fundamental isolation boundary in AWS: it is the unit of billing, of IAM trust boundaries, and of failure isolation. Organizations + SCPs + Control Tower + Service Catalog are one coherent system:

• AWS Organizations / OUs give you a policy tree. Service Control Policies (SCPs) are permission ceilings (they never grant, only filter the maximum). The effective permission is the intersection of: identity policy ∩ resource policy ∩ permission boundary ∩ SCPs of every OU on the path.
• Prevention vs. detection: SCPs and permissions boundaries prevent; AWS Config rules, CloudTrail, Security Hub detect; Systems Manager Automation / Lambda remediate. Exam questions love mixing these up — the scenario will describe detective controls and ask for prevention.
• Landing zones: Control Tower provides account vending (Account Factory), guardrails (preventive SCPs + detective Config rules), and centralized logging. Know why a company with 40 accounts should use Control Tower instead of hand-rolled Organizations: drift prevention and auditability, not features.

Network architecture at scale: Transit Gateway (TGW) is the hub-and-spoke replacement for VPC peering meshes (peering is O(n^2); TGW is O(n)). TGW route tables let you segment routing domains (dev/prod/shared) on one fabric. Shared VPC vs. RAM-shared subnets vs. PrivateLink endpoints: each answers a different sharing question (network ownership, resource ownership, service consumption). Direct Connect Gateway + TGW connects on-premises to all VPCs; beware asymmetric routing in multi-path designs (return traffic must flow through the same stateful device — ALB/NGINX/IDS — that saw the inbound leg).

Domain 2: Design for new solutions — the service-selection core

Storage selection as a cost/latency/durability trade:

• S3 Standard: 99.999999999% (11 nines) durability. S3 Intelligent-Tiering saves ~20–40% on unpredictable access patterns at a small per-object monitoring fee — but it is pointless for <128 KB objects or lifecycle-predictable data.
• EBS gp3 vs gp2: gp3 decouples IOPS/throughput from volume size and is cheaper — the exam's default right answer for new general-purpose volumes. io2/Block Express only when sub-ms latency + multi-attach matters. Instance store is ephemeral: blazing, but data dies with the instance.
• EFS (multi-AZ NFS) vs FSx for Lustre (HPC scratch) vs FSx for ONTAP (NetApp feature set) — match protocol and workload shape.

Compute selection: Lambda (event-driven, spiky, <15 min), Fargate (containerized without node management), EC2 (control over kernel/AZ placement/licensing), Batch (queued batch HPC). Graviton (ARM) instances give ~20–40% price-performance wins where binaries are portable — the exam's favorite "reduce compute cost" lever for stateless services.

Database selection (the deepest decision tree on the exam):

• Relational OLTP → RDS (managed, single-writer) vs Aurora (distributed storage, 15 read replicas, backtrack, Global Database for cross-region). Aurora storage auto-scales 10 GB → 128 TB in 10 GB increments; replicas share the same underlying storage volume (no replication lag from storage copying).
• Key-value, single-digit ms → DynamoDB. On-demand vs provisioned capacity; DAX for read caching; Global Tables for multi-region active-active.
• Analytics → Redshift (RA3 separates compute/storage; data sharing across clusters); Athena for ad-hoc S3 queries; EMR for Spark/Hadoop control.
• Search → OpenSearch; graph → Neptune; ledger → QLDB (immutable journal); time-series → Timestream; in-memory → ElastiCache (Redis) / MemoryDB (durable Redis).
• The trap: questions will tempt you with "use DynamoDB for everything." DynamoDB fails when you need joins, ad-hoc analytics, or complex transactions — that's Aurora/Redshift.

Decoupling and messaging: SQS (queue, pull, at-least-once), SNS (fan-out pub/sub), EventBridge (event bus with schema registry, SaaS integrations, archive/replay), Kinesis (ordered streams, replayable, sub-second), MSK (managed Kafka when you need Kafka semantics/ecosystem). Ordering + exactly-once is the axis: FIFO SQS/Kinesis shards give ordering; exactly-once is a design property (idempotent consumers), not a service guarantee — know where deduplication IDs live.

High availability math: Design for failure, not uptime. Multi-AZ (synchronous, same region, for resilience) vs multi-Region (asynchronous, for disaster recovery and data sovereignty). Route 53 routing policies: failover (active-passive health checks), weighted (canary/blue-green), latency/geolocation/geoproximity. RTO/RPO mapping: backup/restore (hours, cheapest), pilot light (tens of minutes), warm standby (minutes), multi-site active-active (near-zero, most expensive). The exam expects you to match the DR strategy to stated RTO/RPO, not reflexively pick multi-site.

Domain 3: Continuous improvement — cost, security, reliability

Cost optimization levers (know the hierarchy): right-size (Compute Optimizer) → Graviton → Savings Plans/Reserved Instances (commitment, 1–3 yr, up to ~72% off) → Spot (up to ~90% off, interruptible, 2-min warning) → S3 lifecycle/Intelligent-Tiering → delete idle resources. Spot Fleet / EC2 Fleet with diversified allocation for fault-tolerant batch. Compute Savings Plans cover EC2/Fargate/Lambda regardless of region/family — more flexible than EC2 RIs.

Security architecture: KMS key policies vs grants; envelope encryption (data key encrypts data, master key encrypts data key — limits master-key usage and blast radius). Secrets Manager (rotation built in) vs Parameter Store. IAM: roles everywhere, no long-lived keys; cross-account roles with external IDs for third-party access; permission boundaries to delegate safely. Private subnets + NAT Gateway vs NAT instances (managed, AZ-resilient); VPC endpoints (Gateway for S3/DynamoDB — free; Interface via PrivateLink — per-AZ hourly + data fees).

Reliability patterns: health checks that test depth (dependency-aware), circuit breakers, bulkheads, backpressure, retries with exponential backoff + jitter (full jitter: sleep = random(0, min(cap, base * 2^attempt))). Know why jitter matters: synchronized retries cause thundering-herd retries that re-crash a recovering service.

Domain 4: Migration and modernization

The 7 Rs: rehost (lift-and-shift), replatform (lift-and-tinker), repurchase (SaaS), rearchitect/refactor, retain, retire, relocate. Application Discovery Service / Migration Evaluator for portfolio assessment (TCO modeling). AWS MGN (Application Migration Service) for lift-and-shift replication; DMS for database migration with minimal downtime (full load + CDC); SCT for schema conversion (Oracle→Postgres/Aurora). DataSync for NFS/SMB→S3/EFS/FSx bulk transfer; Snowball/Snowmobile for petabyte-scale offline (bandwidth math: 100 TB over 1 Gbps ≈ 10 days — know when the network can't win).

Modernization: strangler-fig pattern (facade + incremental service extraction behind ALB weighted routing or API Gateway), anti-corruption layer, event-driven decomposition. Database strangler: dual-write or CDC-based outbox pattern during transition.

4. Key formulas and decision rules

• Availability of series components: A_total = A1 × A2 × ... × An. Two AZs at 99.99% in series ≈ 99.98%. Parallel (redundant): A = 1 − (1−A1)(1−A2). This is how you justify multi-AZ quantitatively.
• Monthly downtime: (1 − A) × 43,800 min/month. 99.9% = 43.8 min/month; 99.99% = 4.38 min; 99.95% = 21.9 min. Memorize these three.
• Little's Law (queue sizing): L = λW — average queue depth = arrival rate × average wait. Use to size SQS visibility timeouts and consumer fleets.
• Retry budget: attempts × timeout < downstream SLA. If downstream p99 is 2 s and your budget is 5 s, you get at most 2 retries with backoff.
• Bandwidth-delay product: throughput ≤ window / RTT — why cross-region transfers need parallel streams (DataSync/S3 multipart) to saturate links.
• Break-even for commitment discounts: monthly_on_demand × (1 − discount) vs upfront — only commit to the steady-state baseline, keep the variable portion on-demand/Spot.

5. Worked examples

Example 1 — Multi-account governance with a contractor requirement. Scenario: A fintech has 60 AWS accounts, must enforce "no public S3 buckets, no unencrypted EBS, logging in all regions," and give an external audit firm read-only access to security findings for 90 days. Solution: Control Tower landing zone; preventive SCPs (deny s3:PutBucketPolicy allowing public, deny ec2 actions without encrypted volumes); detective Config managed rules (s3-bucket-public-read-prohibited, encrypted-volumes) aggregated to the audit account via Config aggregator; CloudTrail organization trail to a centralized log-archive account; auditor gets a cross-account IAM role with external ID, scoped to Security Hub/Config read actions, with a role session policy expiring after 90 days (or an IAM policy with aws:CurrentTime condition). This hits prevention (SCP), detection (Config), and time-bounded third-party access (external ID + condition) — each maps to a distinct exam domain.

Example 2 — Cost-optimized analytics. Scenario: 40 TB of clickstream in S3, queried ad hoc by analysts 5–10×/day, plus a nightly aggregate feeding a dashboard. Minimize cost, no servers. Solution: S3 Intelligent-Tiering or lifecycle to S3 Standard-IA for raw data; Athena for ad hoc (pay per TB scanned — partition by date and use Parquet + Snappy to cut scanned bytes 10–100×); scheduled Athena/CTAS or a Glue job writing pre-aggregated Parquet for the dashboard; QuickSight SPICE for the dashboard cache. A Redshift cluster would idle 20 h/day — the classic trap answer.

Example 3 — Zero-downtime database migration with rollback. Scenario: Oracle 11g on-prem (2 TB) → Aurora PostgreSQL, <5 min cutover, rollback possible. Solution: SCT converts schema; DMS full load + ongoing CDC replication to Aurora; validate with DMS validation + row counts; cutover by stopping writes, letting CDC drain (lag → 0), flipping the app connection string (or Route 53 weighted DNS / proxy endpoint); keep Oracle running read-only for 48 h as rollback. RTO comes from DNS TTL/proxy flip time, not the replication.

Example 4 — Spiky ingestion with ordering. Scenario: 50k events/sec from IoT devices, per-device ordering required, occasional 10× traffic bursts, downstream ML inference. Solution: Kinesis Data Streams with partition key = device ID (ordering within shard), on-demand capacity mode for bursts; Lambda or Kinesis Data Analytics for windowed aggregation; dead-letter handling via failed-record routing to SQS; idempotent consumers (DynamoDB conditional writes on event ID). SQS FIFO would also order but Kinesis gives replay for model retraining — the deciding factor.

Example 5 — Secure hybrid connectivity. Scenario: On-prem data center + 12 VPCs, must inspect all egress traffic, private connectivity to S3. Solution: Direct Connect → Direct Connect Gateway → Transit Gateway; centralized egress VPC with firewall appliances (Gateway Load Balancer to scale inspection); TGW route tables isolate prod/dev; S3 via Gateway VPC endpoints in each VPC (no NAT charges, no internet traversal). Watch for the asymmetric-routing trap: return traffic must hairpin through the same inspection VPC — enforce with TGW route tables, not hope.

6. Standards and regulations cross-reference

SAP-C02 doesn't test regulations directly, but scenario constraints routinely encode them. From the catalogue:

• EU Cyber Resilience Act (Regulation (EU) 2024/2847) — products with digital elements need secure-by-design, SBOMs, and vulnerability handling. Architecturally this pushes: centralized patching (Systems Manager Patch Manager), software inventory (Inspector), signed artifacts (Signer), and audit trails (CloudTrail + Config). Know what "secure by design" means operationally on AWS.
• GDPR — data residency (region selection, and proving data stays — SCPs denying cross-region replication), right to erasure (crypto-shredding via KMS key deletion vs. physical delete in backups — know the trade-off), DPA/logging requirements (CloudTrail as evidence).
• PCI DSS v4.0.1 — cardholder data environment scoping: network segmentation (dedicated VPC/accounts), no long-lived credentials, encryption in transit/at rest, centralized logging with integrity (CloudTrail log file validation, S3 Object Lock). The exam's favorite PCI scenario is "reduce PCI scope" → tokenization + dedicated accounts.
• NIST SP 800-218 (SSDF) — secure software development practices map to CodePipeline/CodeBuild provenance, artifact signing, and dependency scanning in CI/CD designs.
• Section 508 / ADA Title III / European Accessibility Act — for public-facing workloads: CloudFront + WAF in front, but accessibility is an application-layer concern; know it exists as a constraint class, not an AWS feature.
• FDA SaMD / ISO/IEC 27001 / SOC 2 — appear as "the workload must pass audit X" constraints driving centralized logging, change control (CloudTrail + Config + approved AMIs via EC2 Image Builder), and evidence collection.

7. Pitfalls, traps, and exam strategy

Trap patterns:

1. The region-feature trap: the scenario names a region; the "best" answer uses a feature not available there. Always sanity-check regional availability for exotic services.
2. The over-engineering trap: multi-region active-active for an RTO of 4 hours. Match the DR tier to the numbers.
3. The "choose TWO" trap: questions asking for the combination — each option alone is insufficient. Read the ask twice.
4. The cost-blind trap: NAT Gateway per AZ at $0.045/hr + data processing vs. VPC endpoints; CloudFront vs. cross-region transfer; gp3 vs gp2 defaults.
5. The ordering/exactly-once trap: SQS standard does not order; exactly-once is achieved by idempotent consumers, not by the queue.
6. The SCP trap: SCPs never grant permissions — an answer claiming an SCP "allows" something is always wrong.

Strategy: 180 min / 75 questions = 2.4 min each. Flag scenario questions with 4+ constraints and return to them; bank the short factual ones first. For design questions, write down (mentally) the constraints as a checklist and eliminate options that violate any single one — two eliminations usually leave the answer. Memorize: the three availability/downtime numbers, S3 storage classes and their minimum durations (Standard-IA 30 days, One Zone-IA 30 days, Glacier Instant 90 days, Glacier Flexible 90 days, Deep Archive 180 days — early-deletion fees are a favorite), RDS vs Aurora differentiators, and the DR tier ladder. Derive the rest from first principles.

8. Practice problems

P1. A media company stores 500 TB of video masters accessed rarely but with millisecond retrieval required a few times per month. Current bill uses S3 Standard. What is the cheapest compliant design, and roughly how much does the storage-class change save per month? (S3 Standard ≈ $0.023/GB-mo; Glacier Instant Retrieval ≈ $0.004/GB-mo; retrieval fees apply per request.) Answer: Move masters to S3 Glacier Instant Retrieval (ms retrieval, archive pricing). 500 TB = 500,000 GB; savings ≈ 500,000 × ($0.023 − $0.004) = ~$9,500/month, minus small per-request retrieval fees. Add S3 Inventory + lifecycle policy; keep a Standard copy only of the hot working set. Trap: Deep Archive is cheaper still but has hours-long retrieval — violates the ms requirement.

P2. Two AZs each advertise 99.99% availability host your database primary and synchronous standby (Aurora-style quorum). What is the composite availability, and how many minutes of downtime per month does it imply? If the app tier is a single AZ (99.99%) in series with the DB, what changes? Answer: Parallel: 1 − (0.0001)² = 99.999999% → ~0.00026 min/month (negligible). Adding the single-AZ app tier in series: total = 0.9999 × ~1.0 ≈ 99.99% → 4.38 min/month. Lesson: the weakest series link dominates — multi-AZ the app tier too.

P3. A workload runs 100 c6i.2xlarge instances at 60% average utilization with strong diurnal pattern (peak 8h/day). Compare: (a) all on-demand, (b) baseline 40 instances on 3-yr Compute Savings Plan + rest on-demand, (c) baseline on Savings Plan + peaks on Spot. Which is cheapest and what is the risk of (c)? Answer: (c) is cheapest: Savings Plan covers the 24/7 baseline (~40 instances × 60% ≈ 24 instances steady) at up to ~72% off; Spot covers peaks at up to ~90% off. Risk of (c): Spot interruptions — acceptable only if the workload is fault-tolerant (stateless, checkpointed, or queue-drained); the 2-minute warning must be handled. If the workload can't tolerate interruption, (b) is the safe optimum.

P4. Design the IAM for a SaaS vendor that needs to read CloudWatch metrics in 200 customer accounts. What mechanism, and what prevents the confused-deputy problem? Answer: Each customer creates a cross-account role trusting the vendor's account/role ARN with an external ID (a secret shared out-of-band); vendor assumes the role. The external ID prevents confused deputy: without it, a malicious customer B could trick the vendor into using its role session to access customer A's account. Scope the role policy to cloudwatch:Get/List only.

P5. An e-commerce site must survive AZ failure with RTO < 5 min and RPO ≈ 0 for orders, on a moderate budget. Sketch the architecture and name the DR tier. Answer: Warm standby / active-passive multi-AZ design scaled up: ALB + Auto Scaling across 3 AZs (active), Aurora Global or Aurora with cross-region replica (pilot-light-to-warm in second region for regional DR), Route 53 failover routing, DynamoDB Global Tables or Aurora for the orders table (RPO≈0 needs synchronous or near-synchronous replication — Global Tables replicate <1s). DR tier: warm standby for regional failover; multi-AZ active for AZ failure (RTO ~1–2 min via ALB health checks). Full active-active multi-region is overkill for the budget.

P6. A company must prove to auditors that no EC2 instance in any of 80 accounts can reach the public internet directly, while developers still need outbound HTTPS for patches. Give the preventive control and the detective control. Answer: Preventive: SCP denying ec2:RunInstances unless subnets are tagged private / denying iam:PassRole tricks won't do it — the correct preventive control is an SCP that denies creation of internet gateways and NAT gateways in workload OUs (or denies RunInstances except in approved private subnets), plus no public IPs via denying ec2:AssociateAddress. Detective: Config rule (restricted-ssh / vpc-sg-open-only-to-authorized-ports style custom rule, or ec2-instance-no-public-ip) aggregated org-wide. Patches flow through VPC endpoints (SSM, S3 gateway endpoint) — no NAT needed.

Original ETS reference writing, verified against public sources on 2026-09-30. Thin sourcing is flagged inline. Not legal advice — confirm current editions with the issuing body.