SAA-C03 flashcards

Design Secure Architectures

• SCPs never grant permissions — they cap the maximum; effective access is the intersection of SCPs, boundaries, and IAM policies, and an explicit deny always wins.
• SCPs bind member accounts including their root users, but never affect the management account.
• Anything running on AWS compute gets an IAM role, never access keys — temporary STS credentials eliminate rotation and leakage.
• Cross-account: assume a role for broad access; use a resource-based policy when the caller must keep its own permissions (the Lambda pattern).
• Third-party vendor access = cross-account role + external ID (confused-deputy defense) — never shared access keys.
• Workforce across many accounts = IAM Identity Center federated to the corporate IdP; app customers = Cognito; neither gets IAM users.
• Permissions boundaries cap what a delegated identity can do — the answer to "let developers create roles without privilege escalation."
• Control Tower = managed landing zone on top of Organizations: preventive controls are SCPs, detective controls are Config rules, Account Factory vends compliant accounts.

• A route table defines the subnet: internet gateway route = public, NAT route = private, neither = isolated; only load balancers and NAT gateways belong in public subnets.
• Security groups are stateful, allow-only, per-resource; NACLs are stateless, ordered allow/deny, per-subnet — explicit deny of an IP means NACL.
• Reference security groups by ID between tiers (ALB SG → app SG → DB SG) instead of CIDRs — least privilege that survives Auto Scaling.
• Gateway endpoints (S3, DynamoDB only) are free route-table entries; interface endpoints (PrivateLink) cover most other services at a cost — prefer gateway for S3/DynamoDB in-VPC.
• Shield = DDoS at layers 3/4 (Advanced adds response team + cost protection); WAF = layer 7 (SQL injection, XSS, rate limiting) on CloudFront/ALB/API Gateway.
• GuardDuty detects threats from CloudTrail/flow/DNS logs; Macie finds sensitive data in S3 — behavior vs data.
• Cognito user pool = app sign-in and JWTs; identity pool = temporary AWS credentials (incl. guest access) — never ship access keys in an app.
• Secrets Manager when rotation or cross-account sharing is required; Parameter Store when cost-effective config/secret storage suffices; Direct Connect is private but unencrypted — add a VPN over it for encryption.

• Requirement mentions controlling key policies, rotation, disabling keys, or cross-account access → customer managed KMS key; AWS managed keys allow none of those.
• "Single-tenant," "dedicated hardware," or "AWS must never access key material" → CloudHSM; a plain audit/control requirement → KMS (CloudHSM loses every LEAST-operational-overhead contest).
• SSE-S3 for baseline encryption; SSE-KMS (customer managed key) when you must audit or control key usage; client-side encryption only when AWS must never see plaintext; Bucket Keys cut KMS costs at scale.
• EBS/RDS encryption is set at creation — encrypting existing resources is always snapshot → copy with encryption → restore/create new → cut over; in-place toggles are distractor bait.
• ACM certificates are regional and must match the resource's Region — except CloudFront, which always requires the certificate in us-east-1; ACM auto-renews its own DNS-validated certs, never imported ones.
• KMS automatic rotation keeps old key material, so nothing is re-encrypted and applications keying off the alias never change; imported key material can only be rotated manually via a new key + alias repoint.
• Enforce transit encryption explicitly: ALB HTTP→HTTPS redirect, CloudFront viewer protocol policy, and S3 bucket policies denying aws:SecureTransport=false.
• Retention language maps directly: "no one can delete, regulatory" → Object Lock compliance mode (+versioning); "recover from mistakes" → versioning/backups; "copy in another Region" → CRR; "find PII" → Macie; "never public" → Block Public Access.

Design Resilient Architectures

• A queue between tiers turns a traffic spike into a backlog: SQS plus a worker Auto Scaling group scaling on queue depth is the default spike-absorption redesign.
• SQS standard maximizes throughput with at-least-once delivery; FIFO trades throughput for strict ordering and exactly-once processing — pick FIFO only when the scenario demands order or no duplicates.
• Messages processed twice usually means the visibility timeout is shorter than processing time; messages that always fail belong in a dead-letter queue.
• One event, many independent consumers = SNS-to-SQS fan-out — every subscriber gets its own durable buffer, retries, and scaling signal.
• EventBridge wins when the scenario needs content-based routing, SaaS or AWS service events, or cross-account buses; SNS wins simple high-volume fan-out.
• Multi-step processes with retries, branching, or human approval are Step Functions — never chain Lambda functions synchronously.
• Lambda for short event-driven work (15-minute cap); Fargate for long-running containers with no servers to manage; ECS or EKS on EC2 only when you need instance-level control or Kubernetes itself.
• Scale horizontally behind an ELB across AZs with target tracking as the default policy; offload reads with ElastiCache and read replicas, and offload globally with CloudFront.

• High availability recovers quickly and may blip; fault tolerance never interrupts — "no interruption" or "no downtime" in the stem demands the costlier active-redundancy design.
• RPO is the data you can afford to lose, RTO is the downtime you can afford — extract both numbers before reading the options, then pick the cheapest strategy that meets them.
• The DR ladder trades cost for speed: backup and restore (hours) → pilot light (tens of minutes) → warm standby (minutes) → multi-site active-active (near zero).
• Pilot light replicates the data layer live with compute off; warm standby already serves at reduced capacity — "can it handle requests right now" is the boundary.
• RDS Multi-AZ is synchronous, automatic, in-Region availability with a standby that is NOT readable; read replicas are asynchronous, readable, and promoted manually for read scaling or cross-Region DR.
• Route 53 failover routing plus health checks moves users between Regions; weighted routing is the blue-green and canary lever.
• SPOFs hide in the setup: single instance (ASG + ELB), single AZ (span two), single NAT gateway (one per AZ), state on the instance (move it out).
• Raise service quotas in the recovery Region before you need failover capacity, and answer throttling errors with exponential backoff and jitter.

Design High-Performing Architectures

• Classify by access pattern first: mounted raw disk = EBS (block), shared directories across instances = EFS/FSx (file), API-accessed web-scale data = S3 (object).
• EBS ladder: gp3 by default; io2 only when sustained high IOPS or consistent sub-millisecond latency exceeds gp3; st1 for cheap sequential throughput; sc1 for cold data. HDDs never boot.
• gp3 decouples performance from capacity — provision more IOPS or throughput without a bigger volume.
• Instance store is the fastest storage EC2 can touch and vanishes on stop or failure — correct only for replaceable or replicated data (caches, scratch, replicated cluster nodes).
• EFS = shared POSIX across AZs with elastic capacity; provisioned throughput fixes the small-but-busy file system. Windows/SMB/AD → FSx for Windows; HPC over S3 data → FSx for Lustre.
• S3 optimizations map to bottlenecks: multipart upload and byte-range fetches for large objects, Transfer Acceleration for long-distance uploads, prefix spreading for extreme request rates, CloudFront for global reads.
• Hybrid: Storage Gateway when on-premises needs ongoing low-latency access to cloud data (local cache); DataSync when data needs one-time or scheduled movement into AWS.
• Under MOST cost-effective, pick the cheapest option that still meets the stated performance; under MOST performant, meet the requirement — an overshoot like io2 for a modest database is the trap either way.

• Pick the compute service by duration, trigger, and management appetite: event-driven and under 15 minutes = Lambda; containers with least overhead = Fargate; hardware control = EC2; queued heavy jobs = AWS Batch; named big-data frameworks = EMR.
• The Batch-vs-Lambda-vs-EMR two-step: over 15 minutes rules out Lambda; a named framework (Spark/Hadoop) means EMR; otherwise batch jobs mean AWS Batch — with Spot for cost-sensitive, interruption-tolerant work.
• Choose EC2 families by the bottleneck resource — C for CPU, R/X for memory, I/D for local storage I/O, P/G for accelerators, M as the balanced default — and remember T-family credit exhaustion explains sustained-load slowdowns.
• Lambda's memory setting scales CPU proportionally: more memory can make a function faster AND cheaper if duration drops; the 15-minute cap is the universal eliminator; provisioned concurrency answers cold-start latency.
• Target tracking is the default scaling policy (hold a metric at a value); step scaling for custom thresholds and magnitudes; scheduled for fixed clocks; predictive for recurring patterns where reactive scaling lags slow-to-ready instances.
• Scale worker fleets on backlog per instance (SQS visible messages ÷ instances) as a custom metric with target tracking — capacity follows work, not CPU.
• Decouple tiers with queues (or SNS fan-out) so each scales independently on its own signal and bursts buffer instead of failing.
• ECS vs EKS is decided by whether Kubernetes is a stated requirement; Fargate vs EC2 launch type is decided by whether anything demands host control — and offloading reads to CloudFront can beat adding instances.

• Read replicas scale reads (asynchronous, readable, cross-Region capable); Multi-AZ is availability only — its synchronous standby cannot serve reads.
• Aurora's shared storage across three AZs enables up to 15 low-lag replicas behind one reader endpoint; Global Database adds cross-Region local reads and DR, Serverless v2 fits variable load.
• DynamoDB: on-demand for unpredictable or spiky traffic, provisioned (with auto scaling) for steady traffic at lower cost — throttling with capacity to spare means a hot partition, not a capacity problem.
• Fix hot partitions with key design — high-cardinality keys or write sharding — never by buying more capacity.
• GSI = new partition key, add anytime, eventually consistent; LSI = same partition key with an alternate sort key, table-creation time only. Default to the GSI.
• DAX is the microsecond, API-compatible cache purpose-built for DynamoDB; ElastiCache is the general cache for everything else.
• Redis brings persistence, replication with Multi-AZ failover, and data structures like sorted sets; Memcached is the simple, multi-threaded cache with no durability.
• Lazy loading risks stale data (bound it with TTLs); write-through keeps data fresh at the cost of doubled writes; RDS Proxy pools connections for Lambda and connection-heavy apps.

• CloudFront caches and accelerates HTTP content; Global Accelerator provides two static anycast IPs for TCP/UDP with near-instant cross-Region failover — protocol and static-IP requirements decide between them.
• ALB for HTTP routing (path/host rules, Lambda targets); NLB for TCP/UDP at extreme scale, ultra-low latency, static IP/EIP, and source-IP preservation; GWLB for inline third-party security appliances.
• Size VPC CIDRs for future growth and keep every range non-overlapping — overlap permanently blocks peering and hybrid routing; secondary CIDRs relieve IP exhaustion.
• Placement groups: cluster = lowest latency, one AZ (HPC); spread = max seven instances per AZ on distinct hardware (critical few); partition = failure-isolated groups for large distributed systems (Kafka, Hadoop).
• VPC peering is never transitive — hub-and-spoke or many-VPC connectivity means Transit Gateway; a few stable VPC pairs stay on peering.
• PrivateLink exposes one NLB-fronted service to many consumer VPCs without merging networks — and it tolerates overlapping CIDRs, which peering and TGW cannot.
• Direct Connect buys consistent latency and bandwidth for steady heavy transfer (weeks to provision, not encrypted by default); Site-to-Site VPN is fast, cheap, encrypted, internet-variable — and the standard DX failover.
• Route 53 latency-based routing sends each user to the fastest Region; same-AZ placement minimizes latency and cross-AZ data charges, but multi-AZ spread wins whenever availability is the stated priority.

• Kinesis Data Streams = real-time with custom consumers, replay (up to 365-day retention), and per-shard ordering via partition key; on-demand mode when throughput is unpredictable.
• Amazon Data Firehose = fully managed near-real-time delivery to S3, Redshift, or OpenSearch with buffering, inline Lambda transforms, and built-in conversion to Parquet — no consumers, no shards, no replay.
• "Kafka" in the scenario means Amazon MSK; the classic composite is Data Streams for real-time consumers with Firehose archiving the same stream to S3.
• Transfer selection: DataSync = one-time or scheduled copies into S3/EFS/FSx; Storage Gateway = ongoing hybrid access; Transfer Family = managed SFTP/FTPS into S3; Snow family = offline bulk.
• The data lake is S3 plus the Glue Data Catalog; Lake Formation centralizes database/table/column-level permissions enforced across Athena, Redshift Spectrum, EMR, and Glue.
• Glue crawlers infer schemas into a catalog shared by Athena, EMR, and Redshift Spectrum; Glue jobs are the serverless (LEAST-overhead) way to run ETL like CSV-to-Parquet.
• Query selection: Athena for serverless ad hoc SQL on S3 (pay per data scanned), Redshift for repeated heavy BI on loaded data, EMR for custom Spark/Hadoop control; QuickSight for dashboards.
• Columnar Parquet/ORC plus compression plus date partitioning is THE Athena cost/performance fix — via a Glue job for existing data or Firehose format conversion for new streams.

Design Cost-Optimized Architectures

• Match S3 class to stated access frequency and retrieval tolerance, then veto any option whose minimum duration (IA 30 days, Glacier Instant/Flexible 90, Deep Archive 180) or retrieval fees conflict with the scenario's retention or access pattern.
• One Zone-IA is only correct for re-creatable or secondary-copy data — never the sole copy of anything important.
• Unknown or changing access patterns = S3 Intelligent-Tiering: monitoring fee, but no retrieval fees and no minimum-duration charges.
• Versioned buckets need noncurrent-version expiration, and every upload bucket needs AbortIncompleteMultipartUpload — both are lifecycle rules, not manual cleanup.
• gp3 beats gp2: lower per-GB price plus a free 3,000 IOPS / 125 MiB/s baseline independent of size — never oversize a volume to buy IOPS; use st1/sc1 for cheap sequential throughput.
• Audit for the four leaks: unattached EBS volumes, stale snapshots (incremental — old ones are safe to delete; automate with DLM, archive long-keep ones), noncurrent versions, incomplete multipart uploads.
• Cheapest service by requirement: S3 whenever object access works, EBS only for single-instance block, EFS only when many instances must mount a shared file system — and enable EFS lifecycle to IA either way.
• Archive tier = retrieval tolerance (ms → Glacier Instant, hours → Flexible, ~12h+ → Deep Archive); migrate by bandwidth math — DataSync when the link can carry it or sync is ongoing, Snowball when shipping is faster.

• Layer the purchase mix: Savings Plans/RIs sized to the steady baseline (up to 72% off), On-Demand behind Auto Scaling for the variable layer, Spot (up to 90% off) for interruptible work — never commit to peak, never put un-interruptible work on Spot.
• Expecting instance needs to change selects the flexible commitment: Compute Savings Plan (follows family, size, Region, OS — and covers Fargate and Lambda) or Convertible RIs; Standard RIs and EC2 Instance Savings Plans lock the family for the deepest discount.
• Spot is only for stateless, fault-tolerant, or checkpointable work — and only safe in an ASG mixed instances policy: On-Demand base, Spot percentage, many instance types across AZs, price-capacity-optimized allocation.
• Right-size before you discount: Compute Optimizer flags over-provisioned instances (and Lambda memory); newer generations and Graviton deliver better price-performance for compatible workloads.
• Pick compute by utilization: Lambda wins at low or spiky volume (pay per request; 15-minute cap), EC2 with commitments wins at sustained high utilization, Fargate wins for containers without cluster management — until high sustained density makes EC2-backed containers cheaper.
• Scale-in is the savings half of Auto Scaling: target tracking and scheduled scaling remove capacity off-peak, and non-production environments should stop outside working hours — never buy production availability for dev/test.
• Hibernation resumes with RAM intact — you pay storage, not compute, while hibernated — for intermittently used workloads with expensive warm-up.
• Offload before you scale: CloudFront caching shrinks the origin fleet; one ALB with path-based routing replaces per-service load balancers; NLB is for raw layer-4 throughput, not HTTP routing.

• Workload shape decides the pricing model: idle-heavy or unpredictable load belongs on serverless (Aurora Serverless v2, DynamoDB on-demand); steady 24/7 load belongs on provisioned capacity with Reserved Instances.
• RDS bills instance-hours whether or not queries arrive; DynamoDB bills requests and storage — an idle DynamoDB table costs almost nothing, an idle RDS instance costs full price.
• On-demand and serverless carry a per-unit premium: steady, well-utilized workloads are cheaper on provisioned capacity — never reserve an instance that sits idle, and never run steady high volume on on-demand.
• Repetitive read load plus staleness tolerance means cache (ElastiCache/DAX) — a cache node is cheaper than a bigger instance or full-price read replicas; diverse or must-be-fresh reads mean a replica.
• Open-source engines (MySQL, PostgreSQL, Aurora) carry no license cost; when a scenario complains about Oracle/SQL Server licensing, the answer is SCT + DMS heterogeneous migration — one-time effort for a permanent saving.
• Backup storage equal to your provisioned storage is included free for active databases — align retention to the stated RPO, delete stale manual snapshots, and archive long-term history via snapshot exports to S3/Glacier.
• Provisioned IOPS is for measured, sustained IOPS needs only — gp3 covers most databases; over-provisioned IOPS and oversized instance classes are planted waste in scenarios.
• Aurora's premium buys shared-storage replicas (up to 15 without duplicating storage) and pay-per-use storage — cheaper than RDS at replica-heavy scale, costlier for small single-instance workloads.

• Price the path before the fix: inbound is free, same-AZ private traffic is free, cross-AZ is charged both directions, cross-Region and internet egress are charged — the right answer moves traffic onto a free segment.
• Gateway VPC endpoints for S3 and DynamoDB are free and eliminate NAT processing charges for that traffic — the single most-tested network cost fix; interface endpoints for other services cost less than NAT only at volume.
• NAT gateways bill hourly plus per GB processed: single shared NAT for cost-first environments (accepting cross-AZ charges and AZ risk), per-AZ NATs when an availability requirement or heavy multi-AZ egress justifies the extra hourly fees.
• A NAT instance is the cheap, self-managed, legacy option — right only when the scenario accepts operational burden for minimum cost, wrong whenever managed or highly available is stated.
• CloudFront cuts egress twice: edge caching collapses origin fetches, and AWS-origin-to-CloudFront transfer is free — reach for it when an egress bill grows with content popularity, not Global Accelerator (a performance premium).
• VPN is low fixed cost, quick to deploy, ~1.25 Gbps per tunnel (scale with multiple tunnels + ECMP); Direct Connect is high fixed cost with a lower per-GB rate at steady volume and weeks to provision — volume and timeline decide.
• VPC peering has no hourly or processing fees — cheapest for a few stable VPCs; Transit Gateway's per-attachment and per-GB fees buy transitive routing and manageability that pay off at many VPCs; PrivateLink is for exposing one service to many VPCs.
• Never buy cost with a stated requirement: consolidating to one AZ or one NAT is only correct when the scenario imposes no availability requirement — MOST cost-effective always means cheapest among designs that still meet every requirement.

Yes — the whole SAA-C03 deck is free and needs no account. Create a free account only if you want to save progress and drill full practice questions and mock exams.