Study Canvas

Patching an in-service instance? Put it in Standby (instance-level) or suspend ReplaceUnhealthy (group-level) so the ASG doesn't kill it.

• Standby: instance leaves InService, auto-detached from the LB, health checks paused. Exit standby → auto re-registers.
• Suspend ReplaceUnhealthy: instance stays in the pool, gets marked Unhealthy, but termination is forbidden. After patching: set Healthy manually + Resume.
• Standby = surgical, no user errors. Suspend = affects the whole group.

Scale-in order: AZ balance → allocation strategy → Launch Configuration before Launch Template → oldest config/template → closest to the next billing hour.

• 1. Pick the AZ with the most unprotected instances (keeps zones balanced).
• 2. Terminate instances on Launch Configurations before those on Launch Templates.
• 3. Then the oldest launch configuration / oldest launch template.
• 4. Tie-break: the instance closest to its next billing hour.
• Use instance protection or a custom termination policy when a specific box must survive.

Rebalancing = Launch BEFORE Terminate. Unhealthy replacement = Terminate BEFORE Launch.

• Rebalancing triggers on uneven AZ distribution; launch-first preserves capacity.
• Health-check failure (ALB or EC2) → terminate first, then launch replacement.

To keep N instances alive through one AZ failure: 2 AZs costs 2N instances, 3 AZs costs 1.5N. Spreading wider is cheaper, not more expensive.

• Need 4 survivors, 2 AZs: 4 per AZ → 8 total (lose one AZ, 4 remain).
• Need 4 survivors, 3 AZs: 2 per AZ → 6 total (lose one AZ, 4 remain).
• The spare capacity you must over-provision shrinks as AZ count grows.
• AWS best practice: ≥3 AZs for HA workloads — lowest cost and highest availability.

"Highly available, scalable, protected from web exploits" → Multi-AZ ASG + ALB + AWS WAF. WAF needs a Layer 7 endpoint.

• WAF attaches to: ALB, CloudFront, API Gateway, App Runner, Global Accelerator.
• WAF cannot attach to: an NLB, an ASG, or a bare EC2 instance.
• The ASG gives elasticity and self-healing; the ALB gives the WAF something to sit on.

Predictable recurring spikes → Scheduled Actions setting desired capacity, so capacity is ready before demand hits.

• Predictable / cron-like → Scheduled Scaling.
• Unpredictable → Target Tracking or Simple Scaling (reactive, always lags).
• Adjust desired capacity, not min/max locking.

ALB = Layer 7 content-based routing. NLB = Layer 4 raw TCP/UDP/TLS performance. ASG is not a load balancer.

• ALB: routes HTTP/HTTPS on headers, paths, hostnames.
• NLB: no HTTP awareness; static IP, ultra-low latency, extreme throughput.
• ASG + Multi-AZ: self-healing across zones — availability, not traffic distribution.
• Question says "route based on URL/path/content" → ALB, every time.

App takes forever to warm up in memory? Hibernate flushes RAM to the encrypted EBS root volume and reloads it on start.

• Mechanism: RAM contents written to the encrypted root EBS volume (root must be encrypted).
• Resume: RAM reloaded, processes restored, instance ID retained, data volumes reattached — no cold bootstrap.
• vs User Data: user data re-runs setup on every boot; hibernation preserves the already-warm state.

HDD volumes (st1, sc1) cannot be boot/root volumes.

• Bootable: SSD EBS — gp2, gp3, io1, io2 — plus Instance Store.
• Not bootable: Throughput Optimized HDD st1, Cold HDD sc1.

Three shapes: Cluster = lowest latency, Spread = maximum isolation, Partition = big distributed systems.

• Cluster: one AZ, packed tight — HPC, tightly coupled, 10/25/100 Gbps between nodes. Whole rack is a single failure domain.
• Spread: each instance on distinct hardware, max 7 per AZ — small critical fleets.
• Partition: groups of racks with separate power/network — HDFS, Cassandra, Kafka.
• Exam trigger: "low network latency, high throughput between instances" → Cluster.

An AMI is a regional resource: cross-Region means copy, cross-account means share. Encryption can be added or re-keyed on a copy, never removed.

• Cross-Region → CopyImage. It copies the backing snapshots and mints a new AMI ID in the target Region. Region B ends with 1 AMI + 1 auto-generated snapshot.
• Cross-account (same Region) → modify launchPermission to name the account IDs (or make it public). You must also share the underlying snapshot permissions and, if encrypted, the KMS key.
• Encryption on copy: unencrypted → unencrypted or encrypted; encrypted → always encrypted. You cannot decrypt an AMI by copying it. You can re-encrypt with a different KMS key.
• Sharing an encrypted AMI requires a customer-managed KMS key — the default AWS-managed EBS key can never be shared cross-account.
• A copy does not carry over: launch permissions, user-defined tags, or S3 bucket permissions.

Decouple writes with SQS + ASG workers, and add RDS Proxy for connection pooling.

• SQS queue: publish purchase events, ASG of workers polls asynchronously → absorbs write spikes.
• RDS Proxy: reuses/pools DB connections, prevents connection-exhaustion timeouts.
• Wrong: cross-region read replicas — replicas are read-only and need re-engineering.

Long-running containers with minimal ops → ECS on Fargate, not self-managed EKS nodes or EKS Anywhere.

• API Gateway + Lambda: lightweight REST, short-lived requests.
• Task exceeds Lambda's 15-min limit → Fargate.
• Anti-pattern: EC2 worker nodes / on-prem EKS Anywhere when "low operational overhead" is stated.
• App Runner: always-on web apps from source or a container — bills for idle time and expects a build/deploy pipeline, so it loses to Lambda for bursty, event-driven work.
• Fargate for a small microservice: still a Docker image plus task and service config — more setup than a function.
• EC2 Spot + ASG: cheapest compute, but interruptible and the heaviest to operate (AMIs, dependencies, scaling policies, health checks).

A containerised app that needs a real mounted volume with no servers to manage → ECS on Fargate with an EFS file system mounted into the task.

• Fargate removes the EC2/node layer; EFS is the only natively mountable, managed, persistent file system for it. Together they answer "persistent storage, nothing to operate".
• EBS: must be attached to an instance and its lifecycle managed by hand — not "fully managed".
• S3 "mounted" via s3fs or a sync script: object storage is not a POSIX file system; script-based mounting is unsupported and unreliable.
• Lambda's /tmp + periodic S3 sync: ephemeral, size-capped scratch space — a workaround, not a persistence guarantee.
• EKS with managed node groups: managed node groups are still EC2 instances you manage — it fails any "avoid managing servers" requirement.

Scale on the metric emitted by the thing doing the work. For ECS that is service CPU utilization (ECS/ClusterName/ServiceName) under Service Auto Scaling target tracking — not the load balancer’s metrics, and not the alarm.

• ECS CPUUtilization = percentage of the CPU reserved for the service that is in use. Cross the target (say 75%) → add a task; sit below it → remove one.
• An ALB emits no CPU metric at all — it is managed. It emits RequestCount, TargetResponseTime, ActiveConnectionCount, 5xx counts.
• Nor do target groups: HealthyHostCount, RequestCountPerTarget, TargetResponseTime. (RequestCountPerTarget is a legitimate target-tracking metric — "target group CPU" is not a thing.)
• A CloudWatch alarm has no CPU of its own — it evaluates a metric. It can trigger a policy; it is never the metric source.
• Two independent layers: Service Auto Scaling (task count) and Cluster/Capacity Provider Auto Scaling (EC2 container instances). On Fargate only the first exists.

Reserved caps and guarantees a slice of the account quota. Provisioned keeps environments warm to kill cold starts. They solve different problems.

• Reserved concurrency: carves N of the 1,000 account limit for one function — also throttles it at N, protecting downstream DBs.
• Provisioned concurrency: pre-initialised execution environments; costs money while idle; the answer to "latency-sensitive" / "cold start".
• Account quota exhausted → request an increase; buffering with SQS smooths the spike but doesn't raise the ceiling.
• The trap: "provisioned concurrency eliminates cold starts" is wrong as a blanket claim — it eliminates them only up to the number you provision. Concurrent requests beyond that ceiling still cold-start.

You pay a standing fee for every GB-second reserved, whether or not it serves a request. Size it from real ConcurrentExecutions data and schedule it down outside the hours you need it.

• Three cost components: the standing fee ($0.0000041667/GB-s, charged while reserved), a reduced compute rate while active ($0.0000097222/GB-s vs. the normal $0.0000166667), and standard per-request charges. No free tier once enabled.
• Standing fee formula: GB reserved × seconds active × $0.0000041667.
• Size from the right metric: peak ConcurrentExecutions in CloudWatch, not requests/sec — concurrency depends on request rate and invocation duration.
• Scale it to zero off-hours: pair it with an Application Auto Scaling scheduled action rather than leaving it on 24/7.
• At small scale it is cheap enough that over-provisioning by a unit or two is low-risk — 1 unit at 512 MB for 8 hrs/day is roughly $1.80/month standing.

A VPC set to dedicated tenancy forces every instance inside it to be dedicated, no exceptions. A VPC set to default defers to whatever the launch request asks for.

• default: shared hardware. dedicated: hardware dedicated to your account, but not a specific box. host: a named Dedicated Host you control (the BYOL / socket-licensing answer).
• A VPC-level dedicated setting is a one-way ratchet — read the VPC line in the question before the launch-template line.

A CloudWatch alarm with the recover action rebuilds the instance on new hardware — but only for EBS-backed instances, and only on a system status check failure.

• System status check = the host or its hardware/network is broken → recoverable. Instance status check = something inside your OS is broken → not what the recover action watches.
• The recovered instance keeps its instance ID, private and Elastic IPs, metadata and placement group — so it looks like a reboot to everything pointing at it.
• Instance store volumes are excluded — their data cannot survive a migration to a different host.
• Up to 3 recovery attempts per day before the instance is retired. A terminated instance can never be recovered.
• Recovery reboots the instance during the migration → in-memory (RAM) data is lost. "Preserves everything" is only true of identity and attached storage, never of RAM.
• It also keeps the public IPv4 address — the exception to the normal stop/start rule, where a non-Elastic public IPv4 is released.
• EventBridge: cannot trigger EC2 recovery directly. Trusted Advisor: reports, it does not remediate.

Queue-driven workers scale best on target tracking against a backlog-per-instance custom metric — a ratio the group can hold continuously, not a threshold it reacts to late.

• The metric: ApproximateNumberOfMessagesVisible ÷ in-service instance count. Publish it as a custom metric and target it.
• Raw queue depth is the wrong target — it says nothing about whether the current fleet can keep up.
• Simple scaling: a mandatory cooldown between actions, so it sits idle through a spike.
• Step scaling: steps sized to the alarm breach — closer, but still approximating rather than computing the capacity needed.
• Scheduled scaling: calendar-driven and blind to real queue depth; only right when the load is genuinely predictable by clock.

Split the workload: baseline on RIs / Savings Plans (up to 72% off), spikes on Spot + On-Demand through an ASG.

• Reserved Instances / Savings Plans: predictable, steady-state, 24/7 over 1–3 years.
• On-Demand: short-term, unpredictable, cannot tolerate interruption.
• Spot: stateless, batch, fault-tolerant — reclaimed on 2 minutes' notice.
• Launch templates let one ASG mix On-Demand + Spot across instance types and AZs.

70 always-on + 30 delay-tolerant batch → 70 Reserved Instances + 30 Spot Instances.

• Count the always-on machines → that's your RI/Savings Plan number.
• Anything described as batch, delay-tolerant or interruptible → Spot.
• Buying RIs for the batch tier is the classic wrong answer (you pay 24/7 for 2h/day of work).

"Withstand server failures" is the Spot keyword. Varied instance types/sizes → Spot Fleet, which maintains target capacity for you.

• Spot Instances: single instance-type request; AWS reclaims with a 2-minute warning and does not auto-replace at pool level.
• Spot Fleet: target capacity across heterogeneous types/sizes, strategies like lowestPrice, auto-provisions replacements.
• Scenario pattern: "runs ~2 hours a month" rules out RIs and Savings Plans; "various sizes / variable vCPU" picks Spot Fleet over plain Spot.
• Spot = up to 90% off, only for work that can be interrupted without corruption.

Compute Savings Plans are the flexible default; Standard RIs are the cheapest but the most rigid.

• Compute SP: $/hour commitment, applies across EC2 family, Region, OS, plus Fargate and Lambda. Most flexible.
• EC2 Instance SP: locked to a family in a Region; deeper discount.
• Standard RI: deepest discount, can be sold on the Marketplace; Convertible RI can be exchanged for another family.
• Both bill whether or not you use them — commit only to the true baseline.

Cost Explorer analyses the past, Budgets alerts on the future, Compute Optimizer right-sizes, Cost Allocation Tags attribute spend.

• Cost Explorer: visualise and forecast 12 months of spend by service/tag.
• AWS Budgets: threshold alerts (cost, usage, RI/SP coverage) via SNS — the "notify me before we overspend" answer.
• Compute Optimizer: ML right-sizing recommendations for EC2, ASGs, EBS, Lambda.
• Trusted Advisor: broad checks — idle resources, service quotas, security gaps.

EBS bills provisioned size; S3 and EFS bill only what you actually store.

• EBS: block storage, $/GB allocated per month.
• EFS: managed NFS, ≈$0.30/GB stored.
• S3 Standard: ≈$0.023/GB stored.
• Small files in big volumes: S3 < EFS < EBS.

Lifecycle rules only flow downward in cost and redundancy. You can never go back up.

• Invalid: anything → S3 Standard.
• Invalid: One Zone-IA → Standard-IA or Intelligent-Tiering.
• Valid: Standard → anything.
• Valid: Standard-IA → Intelligent-Tiering, One Zone-IA, Glacier/Deep Archive.
• Valid: Intelligent-Tiering → One Zone-IA, Glacier/Deep Archive.

Data living <30 days and read often is cheapest on S3 Standard — IA/Glacier bill 30/90-day minimums plus retrieval.

• Standard: 0-day minimum. Standard-IA / One Zone-IA: 30 days. Glacier Instant: 90 days.
• Classic trap: "temporary processing files" → do not pick IA.

S3 Standard-IA: infrequent access, still millisecond retrieval, lower storage cost.

• Standard: overpriced for 2 reads/year.
• Intelligent-Tiering: extra per-object monitoring fee; pointless when access pattern is already known.
• Deep Archive: 3–12 hr retrieval fails millisecond requirement.
• Step Functions retry logic covers IA's 99.9% availability.

Object Lock applies per object version; explicit retention always overrides bucket defaults.

• Explicit: a fixed Retain Until Date on the version.
• Bucket default: a duration (days/years), computed at upload time.
• Different versions of the same key can have different modes and periods.
• Requires Versioning enabled.

For accidental deletion use Versioning + MFA Delete. Object Lock is for WORM compliance, not operational safety.

• Versioning: writes a delete marker, keeps prior versions.
• MFA Delete: second factor required to permanently delete a version.
• Object Lock: too rigid — blocks all deletion in the window, causes surprise storage costs.

SSE-KMS with the AWS-managed key (aws/s3): zero key management, full CloudTrail key-usage audit trail.

• "No manual/customer-provided keys" → rules out SSE-C and client-side encryption.
• "Must audit key usage" → rules out SSE-S3 (no CloudTrail key logs).
• SSE-KMS with a CMK also works but adds key-creation overhead.

Compliance wants audit logs and automatic rotation with low overhead → SSE-KMS. Rotation generates new backing material yearly while old data still decrypts.

• SSE-S3: on by default, fully managed — but no CloudTrail key-usage logs.
• SSE-KMS: key policies, automatic annual rotation, full CloudTrail trail of encrypt/decrypt events.
• SSE-C: you supply the key on every request — highest operational overhead.
• Rotation: new cryptographic material, same key ID; previously encrypted objects stay readable.
• "A unique key per object, with no operational overhead" is already plain SSE-S3. S3 encrypts every object with its own data key, then wraps that key with a root key it rotates for you (AES-256). One bucket, nothing to configure.
• Since 5 Jan 2023 SSE-S3 is the default on every bucket — no extra cost, no performance impact. So "split the data into separate buckets by key" is the overhead the question is telling you to avoid.
• SSE-KMS encryption context is not a key-generation mechanism — it is additional authenticated data (AAD), key/value pairs that must be supplied again on decrypt. It binds a request; it does not make keys unique. (KMS already issues a unique data key per object anyway.)

Shared dataset, many teams? Give each one an S3 Access Point scoped to its prefix instead of growing one monolithic bucket policy.

• Bucket policies max out at 20 KB — access points sidestep the ceiling and simplify per-team administration.
• Each access point has its own name, policy and network origin (VPC-only if you want).
• Anti-patterns: Macie for access control (it's PII discovery), IAM users for applications (use roles), hardcoding every object ARN into one policy.

An object uploaded from another account is owned by the uploader — the bucket owner gets no implicit read access. Bites Redshift UNLOAD jobs.

• Fix A: the writer assumes a cross-account IAM role in the bucket owner's account and writes as them.
• Fix B: set Object Ownership / bucket-owner-enforced so the bucket owner owns everything written to it.
• Redshift pattern: create a role in the bucket account, let the Redshift cluster role assume it, then UNLOAD with those credentials.

Hitting 3,500 writes/sec? Partition into customer-specific prefixes — each prefix gets its own full quota.

• Limits are per prefix: 3,500 write, 5,500 read requests/sec.
• Uploading everything to bucket root = one prefix = one bottleneck.
• s3://bucket/customer-ID/file → scales linearly to tens of thousands/sec.

Inbound data to S3 is free, and you only pay S3TA fees when it actually made the transfer faster.

• S3 ingress from internet: $0.
• No measurable speedup → no S3TA charge. Risk-free to try.
• S3TA vs CloudFront — split on object size and direction. Large objects (>1 GB) moving to and from one bucket over long distances → S3TA. Many smaller, cacheable objects being served to global viewers → CloudFront.
• Both ride CloudFront edge locations and the AWS backbone, which is exactly why the distractor is tempting — but CloudFront caching is optimised for objects under 1 GB and does nothing for uploads.
• Global Accelerator: accelerates routing to ALB/NLB/EC2/EIP endpoints, never S3 transfer speed.

S3 Transfer Acceleration + Multipart Upload.

• S3TA: routes via CloudFront edge locations onto the AWS private backbone.
• Multipart: parallel parts (recommended >100 MB); a failed part is retried alone.
• Direct Connect: months to provision, overkill.
• Site-to-Site VPN: public internet, no acceleration.
• Global Accelerator: for ALB/NLB/EC2 endpoints, not S3 uploads.

Replication needs versioning on both buckets and is not retroactive — existing objects need S3 Batch Replication.

• CRR: cross-Region — compliance, latency, DR. SRR: same-Region — log aggregation, prod→test.
• Asynchronous; add Replication Time Control (RTC) for a 15-minute SLA.
• Delete markers are not replicated by default; replication is not chained (A→B→C needs explicit rules).
• Works cross-account, and can change storage class and ownership on the way.

When the same data must be reachable over SMB and NFS (Windows + Mac + Linux), FSx for NetApp ONTAP is the only FSx family member that speaks both at the same time.

• ONTAP's second hook is tiering: it auto-moves cold data to a capacity pool, so "frequent and infrequent access patterns, minimal ops" lands on it too.
• Method: list every protocol and OS the question names, then strike the services that miss one. Usually only ONTAP survives a mixed list.

A stated per-volume IOPS requirement is a hard filter. Above 16,000 IOPS only io1/io2 qualify — match the binding number, not the adjectives in the scenario.

• Provisioned IOPS is independent of volume size on io1/io2 — that is why they clear a 25,000 IOPS requirement that gp2 cannot.
• gp2's 3 IOPS/GB burst model is the distractor: the scenario sounds general-purpose, but the number rules it out.

io2 beats io1 on every axis at identical price, so pick io2 whenever both appear. io1 is only correct when io2 is not among the options.

• io2 Block Express: up to 256,000 IOPS, 4,000 MB/s, 64 TiB — Nitro instances only.
• Exam pattern: if the requirement exceeds 64,000 IOPS or 16 TiB, the answer is Block Express, not plain io2.

Two independent dials: performance mode = IOPS/parallelism, throughput mode = MiB/s. Don't confuse them in an answer.

• General Purpose: default, lowest per-operation latency — web servers, CMS, latency-sensitive file serving.
• Max I/O: higher aggregate IOPS and massive parallelism (big data, media processing) at slightly higher metadata latency.
• Bursting throughput: scales with how much you've stored. Provisioned throughput: fixed MiB/s regardless of size.
• Real-world footnote: AWS now steers new file systems to General Purpose + Elastic throughput; Max I/O still appears in exam questions.

Mount an EFS file system from another region over inter-region VPC peering (or Transit Gateway) — no data duplication.

• EFS is a regional service but reachable cross-region via network connections.
• Avoids S3 sync jobs, RDS migrations, and manual multi-region copies.

EFS resource policy + mount target in a shared/peered VPC + mount via an EFS access point.

• S3 + DataSync: lag, duplication, higher cost.
• API Gateway proxy: latency, payload limits, extra compute bill.
• Lambda Layers: capped at 250 MB unzipped.

Scheduled, native on-prem NFS → EFS replication = AWS DataSync + Interface VPC endpoints over a Private VIF. No staging bucket in the middle.

• DataSync: automates and schedules NFS/SMB ↔ EFS/S3/FSx transfers with encryption and validation.
• Private VIF: on-prem → private VPC resources via VGW / DX Gateway.
• Public VIF: on-prem → public AWS service endpoints (S3, DynamoDB) without the public internet.
• Transit VIF: on-prem → a Transit Gateway.

Native Microsoft DFS requirement → Amazon FSx for Windows File Server (SMB).

• Organizes massive shares into a single folder namespace.
• Managed Microsoft AD: directory service, not a file system.
• FSx for Lustre: HPC/ML, no DFS.
• SQL Server: relational DB, not a file system.

Parallel, distributed, sub-millisecond hot data + cheap cold tier → FSx for Lustre linked to S3.

• Massive throughput for EDA, HPC, ML workloads.
• Native S3 integration: pull in for processing, write back to S3 as the cold tier.
• Do not pick EMR as a raw parallel file system.

Hybrid, ongoing access to cloud storage from on-prem. Pick by the protocol in the question.

• File Gateway: NFS/SMB mount backed by S3 objects — file shares, backups landing in S3.
• Volume Gateway: iSCSI block volumes. Cached = hot data local, full copy in S3. Stored = full copy local, async backup to S3.
• Tape Gateway: virtual tape library for existing backup software → Glacier.
• Cached vs Stored — one question settles it: where does the full dataset live day to day? In S3 with only hot data held locally → Cached. On-premises, with S3 holding point-in-time backups → Stored.
• "Only frequently-accessed data cached locally, everything archived in S3" is the textbook Cached Volumes wording.
• Direct Connect: a network link, not storage or caching. Snowball Edge: offline transfer plus edge compute, not an ongoing hybrid cache.
• One-off bulk move instead of ongoing access? That's Snowball or DataSync, not Storage Gateway.

Decide on bandwidth and repetition: no/low bandwidth and one-off → Snow; network exists and it repeats → DataSync; partners speak SFTP → Transfer Family.

• Snowball Edge: tens of TB to PBs shipped physically; Snowmobile for exabyte-scale. Storage Optimized = 80 TB usable — offline only, for bandwidth-constrained or disconnected sites.
• DataSync: online, scheduled, incremental, validated — NFS/SMB/HDFS/object → S3, EFS, FSx.
• Transfer Family: managed SFTP/FTPS/FTP front door onto S3 or EFS only for external partners.
• DMS: databases only (with SCT for a dialect change).
• The multi-target tell: if the question names S3 and EFS and FSx in one migration, only DataSync covers all three — Transfer Family has no FSx support, and File Gateway is an ongoing access layer rather than a migration tool.
• DataSync's numbers: purpose-built protocol up to 10× faster than CLI copies, a single agent saturating 10 Gbps, with built-in scheduling, retries, integrity verification and CloudWatch/CloudTrail visibility.

Same engine either side → DMS alone. Different engines → SCT first to convert schema and code, then DMS to move the data. Two steps, in that order.

• Heterogeneous = the engine changes (Oracle or SQL Server → Aurora / PostgreSQL / MySQL). The dialect, procedural code and schema objects all have to be translated before any rows move — that is AWS SCT.
• Homogeneous = same engine both sides, so there is nothing to convert and DMS handles it on its own.
• The trap — DMS Basic Schema Copy: it auto-creates tables and primary keys only. It drops secondary indexes, foreign keys and stored procedures. Fine for a quick test migration; wrong whenever the question lists those objects as requirements.
• AWS Glue: ETL and batch processing, not database migration. Snowball Edge: physical bulk transfer, not a migration service.

Babelfish for Aurora PostgreSQL + AWS SCT with AWS DMS.

• Babelfish: Aurora PostgreSQL speaks T-SQL and the SQL Server wire protocol → near-zero app changes.
• SCT: converts schema and code objects. DMS: moves the data with minimal downtime.
• Custom endpoints: Aurora endpoints don't emulate SQL Server without Babelfish.
• AWS Glue: ETL, not SQL dialect translation.
• Aurora Global Database: cross-region DR/latency, not dialect compatibility.

Sensitive relational workload, strict compliance, minimal management → RDS for SQL Server, Multi-AZ, KMS-encrypted.

• You get automated patching and backups, built-in Multi-AZ failover, and native KMS integration.
• EC2-hosted SQL Server: IaaS — you own patching, backups, HA. Wrong when "minimal overhead" is stated.
• S3 / Timestream: you lose relational features and transactions.

You cannot encrypt an existing unencrypted RDS instance in place. The pattern is snapshot → copy snapshot with KMS → restore → cut over → delete the old one.

• Step 1: take a snapshot of the unencrypted DB.
• Step 2: copy the snapshot, enabling KMS encryption on the copy.
• Step 3: restore a new DB instance from the encrypted snapshot; repoint the app; terminate the original.
• Same idea for unencrypted EBS volumes — snapshot, encrypted copy, restore.

Multi-AZ = synchronous, HA/failover, ≥2 AZs in one region. Read Replicas = asynchronous, scaling reads.

• Multi-AZ standby serves no traffic — it exists for automatic failover.
• Read replicas can be same-AZ, cross-AZ, or cross-region — and are read-only.
• "Offload reporting queries" → replica. "Survive an AZ outage" → Multi-AZ.

Read throughput problem → add a read replica and point the app at the read endpoint. The Multi-AZ standby can never help.

• RDS read replica: dedicated read endpoint, offloads the primary. The app must be changed to use it.
• Multi-AZ standby: synchronous failover target only — accepts no reads or writes.
• Aurora reader endpoint: automatically load-balances connections across all available Aurora replicas — no app-side balancing.

Need a dev copy of prod without slowing prod down → Aurora continuous backups + fast database cloning.

• Backup overhead: Aurora's distributed storage backs up continuously with zero I/O impact. Single-AZ RDS suspends I/O during a snapshot; Multi-AZ RDS offloads it to the standby (SQL Server still briefly pauses).
• Cloning: Aurora fast clone is copy-on-write — instant, no upfront storage cost. RDS needs a full snapshot restore.
• Not usable as a dev DB: the RDS Multi-AZ standby (passive) and read replicas (read-only).
• Scale: Aurora supports up to 15 auto-scaling replicas over one storage layer spanning 3 AZs.

RDS MySQL/PostgreSQL replicas falling seconds behind under load, with minimal app or infra change → migrate to Aurora. Aurora Replicas read the same storage volume as the primary, so lag is milliseconds.

• Why it works: standard RDS replication ships and replays binlogs (seconds of lag under write pressure). Aurora replicas share one distributed storage layer — there is nothing to replay.
• Up to 15 low-latency replicas, plus Aurora Auto Scaling on the replica count.
• No application rewrite — same engine, same queries. That is what makes it the "minimal effort" answer.
• Adding a Redis cache: an application rewrite, and it doesn't fix replication lag.
• Self-managed MySQL on bigger EC2: wrong bottleneck plus a pile of operational overhead. DynamoDB: a full data-model and query rewrite.

ElastiCache pays off on read-heavy and compute-intensive workloads — repeated lookups of expensive or hot data. It is the wrong tool for write-heavy, ETL, or JOIN-heavy work.

• Good fit: caching, session stores, gaming leaderboards, geospatial, real-time analytics, Q&A portals — and recommendation engines, where you cache an expensive computation.
• Write-heavy apps: the cache goes stale as fast as you fill it.
• ETL: that is Glue or EMR. Complex JOIN queries: that is RDS or Aurora — a KV store cannot do them.
• "Millions of concurrent users, low latency, high elasticity" on a read path is the ElastiCache tell.

Aurora Global Database = sub-second cross-Region replication, ~1 min RTO promotion. A plain cross-Region read replica is slower and manual.

• One primary Region writes; up to five secondary Regions serve low-latency local reads.
• Storage-level replication, typically <1 s lag — the answer for "global app, regional DR, RPO seconds".
• Aurora Serverless v2: scales capacity in fine-grained increments for spiky or unpredictable load.
• DynamoDB equivalent: global tables (active-active multi-Region).

Serverless key-value, single-digit ms. Know capacity modes, index types, streams and TTL — they're the four things questions hinge on.

• On-demand: unpredictable/spiky, pay per request. Provisioned + auto scaling: predictable and cheaper.
• GSI: different partition key, added any time. LSI: same partition key, different sort key, only at table creation.
• Streams: change data capture → Lambda for event-driven work and cross-service fan-out.
• TTL: free automatic expiry of old items. DAX: microsecond cached reads. Global tables: multi-Region active-active.

Live leaderboards need sub-millisecond reads → ElastiCache for Redis or DynamoDB + DAX.

• Redis: sub-ms; native Sorted Sets are purpose-built for leaderboards.
• DAX: in-memory write-through cache in front of DynamoDB → microsecond reads.
• DynamoDB alone: SSD-backed, single-digit ms.
• Aurora / Neptune: relational and graph — not caches.

Same Region, one AWS Organization, EC2 in several accounts must talk privately at the lowest cost → share subnets with AWS RAM.

• VPC sharing (RAM): zero inter-VPC overhead — it's ordinary intra-VPC routing, so no per-GB or per-hour networking fee.
• Transit Gateway: hourly attachment fee per VPC + data processing.
• VPC Peering: data transfer charges and a full mesh to build and maintain.
• PrivateLink: hourly endpoint fee + per-GB processing.
• You share subnets, never a whole VPC — the subnet is the only shareable unit. An answer that says "share the VPC" is wrong on the mechanics alone.
• Who owns what: the owner account keeps every VPC-level construct (route tables, NACLs, IGW/NAT, peering, CIDR); participants only manage the EC2/RDS/ELB resources they launch into the shared subnets.
• Because everything lands in one VPC, you also drop duplicated NAT/IGW/TGW cost and get same-VPC latency with no peering mesh to maintain.
• Peering can never share a subnet — it connects VPCs, it does not grant another account the right to launch into yours.

Full-mesh routing across a lot of VPCs plus on-premises, at the least operational overhead → one Transit Gateway as the hub, with Direct Connect attached through a transit VIF.

• Attach every VPC to a single TGW and enable route propagation — inter-VPC routing becomes automatic, with no route tables to hand-edit as VPCs come and go.
• Transit VIF associates the DX connection to the TGW, giving one centralised on-prem path instead of a private VIF per VPC.
• Direct Connect gateway + a VGW per VPC: no transitive routing between VPCs — you still need peering or another routing layer on top.
• A Site-to-Site VPN per VPC: high complexity, and it throws away the Direct Connect throughput you already pay for.
• PrivateLink to a central services VPC: exposes one service, one direction — not general network-level routing.
• Recall the VIF trio: Private → VPC resources via VGW/DX gateway · Public → public AWS service endpoints · Transit → a Transit Gateway.

Hub-and-spoke with TGW? Put the common dependencies in one Shared Services VPC instead of duplicating them in every spoke.

• Centralise: Directory Services, interface endpoints/PrivateLink, monitoring, security appliances. Spokes reach them over TGW routes.
• Why: interface endpoints bill per hour per VPC — replicating them across dozens of spokes is pure waste.
• Direct Connect: solves on-prem connectivity, not inter-VPC consolidation.
• Full-mesh peering: no transitive routing, N² connections. Transit VPC: legacy EC2 VPN appliances.

Exposing one service? Use PrivateLink — peering and TGW hand over the whole VPC.

• Peering / TGW: full Layer-3 access across the entire VPC → violates least privilege for a single resource.
• PrivateLink: Interface VPC Endpoint exposing exactly one service (e.g. RDS behind an NLB).
• Peering and TGW are mutually exclusive for the same VPC pair.
• TGW is the hub-and-spoke answer once you have many VPCs.

Gateway endpoint = a route-table entry, S3 and DynamoDB only, free. Interface endpoint = an ENI in your subnet, almost every service, billed hourly + per GB.

• Gateway: cannot be reached from on-premises over Direct Connect or VPN, and never works cross-Region.
• The cost question: private-subnet EC2 doing high-volume S3 traffic through a NAT gateway is billed per GB processed. Add a free S3 gateway endpoint and keep the NAT gateway for everything else — the endpoint route only diverts S3-bound traffic.
• Cost order, private → S3: gateway endpoint (free) < interface endpoint (hourly + per-GB) < NAT gateway (hourly + per-GB processed).
• An endpoint policy controls what may be reached through the endpoint; the default policy is full access.
• A GWLB endpoint is for steering traffic to third-party firewall/IDS appliances — not an S3 access path. An egress-only IGW is IPv6-only, so it is an instant disqualifier on any IPv4 question. Adding an IGW route to a private subnet makes it public and still saves nothing.
• Interface (PrivateLink): reachable from on-prem over a Private VIF — the way to hit AWS APIs privately from the data centre.
• VPC peering connects VPC↔VPC only; no edge-to-edge/transitive routing from on-prem through a peer.
• Exam cue: "private access to S3 from on-premises" → interface endpoint (or a Public VIF), never a gateway endpoint.
• "Reach SQS/an AWS service without traversing the public internet" → interface endpoint (PrivateLink). IGW: grants the internet access you were told to avoid. NAT: still exits via the IGW — it manages egress, it does not avoid the internet. VPN: solves on-prem→VPC, irrelevant when there is no on-prem component.

Requirement says both dedicated low-latency and end-to-end encryption → Direct Connect + IPsec VPN.

• Direct Connect: dedicated, consistent bandwidth, low latency — unencrypted by default.
• Site-to-Site VPN: IPsec encrypted — but rides the public internet.
• Combined: private dedicated path plus IPsec.
• A VPN backup over the internet is also the cheap DR answer for a single DX link.

Global Layer 4 acceleration with 2 static Anycast IPs and near-instant regional failover, over the AWS backbone. Not a CDN.

• vs CloudFront: CloudFront is a Layer 7 HTTP CDN that caches. Global Accelerator proxies TCP/UDP with no caching — gaming, VoIP, IoT, non-HTTP.
• vs Route 53 latency routing: DNS just hands back an IP, then traffic crosses the public internet. GA enters the AWS network at the nearest edge immediately.
• Endpoints: ALB, NLB, EC2, Elastic IPs. Static IPs survive endpoint changes — handy for firewall allowlists.
• The consolidation cue: "too many IPs to manage across Regions / firewall allowlists are unmanageable" → Global Accelerator collapses them to 2 anycast IPs, and the user-facing IPs stop changing when the backend does.
• An ALB can never take a static or Elastic IP — its IPs are dynamic. NLB and EC2 can. That single fact kills a distractor in most "we need a static IP" questions.
• You cannot attach an Elastic IP to an Auto Scaling group — an ASG has no network identity of its own.

A CNAME is never allowed at the zone apex. Route 53 alias records exist precisely to solve that — and alias queries are free while CNAME queries are billed.

• The apex is the top node of the zone and already carries the required SOA and NS records; a CNAME there would conflict with them.
• So "point the apex at CloudFront/an ELB, cost-effectively" is always alias, and a subdomain pointing outside AWS is always CNAME.
• The mirror-image question: map your subdomain to a third-party-hosted name (yourapp.provider.com) → CNAME. A non-AWS target rules out alias immediately, whatever else the option says.
• A record: name → IPv4 address only, so it cannot do name-to-name. PTR: IP → name (reverse DNS) — the opposite direction.
• MX: mail routing only. NS: names the hosted zone's name servers. Neither routes web traffic.

Block by country at the edge (CloudFront Georestriction) or at DNS (Route 53 Geolocation).

• CloudFront Georestriction: country allow/deny list at edge locations.
• Route 53 Geolocation: route or deny DNS answers by user origin.
• Other Route 53 policies: Latency (lowest lag), Weighted (% split), Failover (health-check DR), Geoproximity (bias by distance), Multivalue (healthy answers, poor man's LB).

Dynamic backend must stay on-premises but Asia is slow → CloudFront with a custom origin pointing at the on-prem servers.

• CloudFront accepts any publicly reachable HTTP server as a custom origin.
• Caches static content globally; routes dynamic requests over the AWS private backbone.
• S3 + CRR: static websites only.
• Route 53 geo-proximity alone: DNS can't shorten physical distance without a CDN.

SG = stateful, instance level, allow-only. NACL = stateless, subnet level, allow and deny, evaluated in rule order.

• Stateful: an SG that allows inbound automatically permits the reply — no outbound rule needed.
• Stateless: a NACL needs an explicit rule for the return traffic, usually on ephemeral ports 1024–65535.
• Only NACLs can deny — so "block a specific malicious IP" is always a NACL answer.
• SGs can reference other SGs — the clean way to say "only the web tier may reach the DB tier". Membership is dynamic: add an instance to the web-tier SG and it gains DB access with no IP list to maintain.
• A rule source can only be an address-shaped thing: a single IPv4 /32 or IPv6 /128, a CIDR range, a prefix list ID, or another security group ID (same VPC or peered).
• Never valid as a source: an Internet Gateway ID, a NAT gateway, a subnet ID, a route table, a VPC ID, a DNS name. An IGW does routing, not filtering — a different layer entirely.
• NACLs accept CIDR ranges only — they cannot reference a security group.

Private subnets reaching the internet outbound only: managed NAT Gateway in a public subnet, one per AZ for HA.

• NAT Gateway: managed, 5 Gbps baseline scaling automatically to 100 Gbps, AZ-scoped — a single NAT GW is an AZ-level single point of failure.
• NAT instance: legacy EC2 you patch and scale yourself; can act as a bastion, needs source/dest check disabled.
• Egress-only IGW: the IPv6 equivalent of a NAT Gateway.
• Cost trap: heavy S3 traffic through a NAT GW is billed per GB — a free S3 gateway endpoint removes it.
• Who performs the NAT for a public subnet instance? The Internet Gateway — it does the 1:1 translation between the private address and the public/Elastic IP. NAT gateways and NAT instances are only for private subnet instances needing outbound-only access.
• In that same question the route table and the subnet are passive — one directs traffic, the other is an address range. Neither translates anything.
• Both flavours must sit in a public subnet. A NAT gateway in a private subnet is simply broken — with no route to the IGW it has nothing to NAT through. The most common trap on this topic.
• HA pattern: one NAT GW per AZ, each in that AZ's public subnet, with a per-AZ route table sending 0.0.0.0/0 to its own NAT GW. This bounds the blast radius of an AZ failure and avoids cross-AZ data transfer charges.
• An IGW is one per VPC, attached at the VPC level — never to a subnet. A subnet is "public" purely because its route table has a route to the IGW.

Endpoints are named from the VPC's point of view: inbound = queries coming into AWS from on-prem, outbound = queries leaving AWS toward on-prem. Bidirectional resolution needs both.

• Inbound endpoint: ENIs in your VPC with IPs that the on-prem resolver forwards to — this is how on-prem resolves private hosted zones and VPC records.
• Outbound endpoint: ENIs the Resolver sends queries out through, paired with Resolver rules that conditionally match a domain (corp.example.com) and forward it to on-prem resolver IPs.
• Conditional forwarding is outbound-only. An inbound endpoint just receives — it carries no rules.
• There is no "universal" endpoint type — only inbound and outbound. That is a standard distractor.
• Needs underlying connectivity (Direct Connect or VPN) plus security groups allowing TCP/UDP 53. Deploy across ≥2 AZs for HA.

The VGW is always the AWS side, the customer gateway is always the on-premises side. Never symmetric, never swapped — which is exactly what the distractors do.

• Virtual Private Gateway (VGW): the AWS-side VPN endpoint, attached to the VPC.
• Customer Gateway (CGW): the AWS resource that represents your on-prem device. The physical box itself is the "customer gateway device".
• VPN connection = the logical link. VPN tunnel = the encrypted path inside it (two per connection, for redundancy).
• Wrong answers reverse the two, or claim both ends are the same type.

A target group with target type instance always delivers to the primary private IPv4 of eth0. The load balancer never uses a public or Elastic IP, even when it is internet-facing.

• Target type instance: resolves to the primary private address on the primary interface. Identical behaviour on ALB and NLB.
• Target type ip: you register a specific private IP — must be in the VPC CIDR, a peered VPC, or on-prem via DX/VPN. This is how you reach a secondary IP or a non-eth0 interface.
• LB → target traffic never leaves the VPC. The instance ID is a registration identifier, not a routing address; an Elastic IP is an ingress/egress concept, not a target-routing one.
• NLB footnote: instance-ID targets preserve the client source IP; IP-mode targets do not, unless you enable proxy protocol v2.

CloudFront inherits nothing from an EC2 security group. Rebuild the restriction at each new layer: AWS WAF for the IP allowlist at the edge, plus OAI + a locked-down bucket policy so nobody can skip past it.

• The scenario: static content moves off EC2 (which sat behind an SG allowlisting supplier IPs) to S3 behind CloudFront. Two things must be rebuilt, not one.
• (1) AWS WAF Web ACL with an IP match condition on the distribution — CloudFront has no "security group"; WAF is the IP-filtering layer at the edge.
• (2) Origin Access Identity + S3 bucket policy allowing only that OAI — otherwise a caller hits the S3 URL directly and bypasses CloudFront and WAF entirely.
• Security groups and NACLs cannot attach to a CloudFront distribution — they are VPC constructs and CloudFront lives outside the VPC.
• A WAF ACL cannot attach to an S3 bucket policy — Web ACLs attach to CloudFront, ALB, API Gateway or AppSync.

us-west-2a is an account-scoped alias, randomised per account. Any cross-account coordination must use the AZ ID (usw2-az2), which names the same physical zone everywhere.

• Why it bites: two accounts both launch into "us-west-2a" and land in physically different zones — so a latency or co-location assumption quietly breaks.
• AWS randomises the mapping deliberately, to spread load evenly across a Region.
• Where it matters: VPC sharing via AWS RAM — a subnet shared from usw2-az2 shows up in the consumer account as usw2-az2, not as a matching letter.
• Find it: EC2 console → Service health → Availability Zone status, or aws ec2 describe-availability-zones (the ZoneId field).
• A VPC is regional and spans every AZ, so it can never identify one. A default subnet is labelled by AZ name, so it inherits the same aliasing problem. AWS Support is not needed — the AZ ID is self-service.

Multiple independent consumers or replay → Kinesis. Simple decoupling → SQS.

• Multiple parallel readers of the same stream → Kinesis Data Streams.
• Replay / lookback (24 hrs–365 days retention) → Kinesis. SQS deletes on processing.
• Zero-code load into S3/Redshift/OpenSearch/Splunk → Kinesis Data Firehose.
• Simple queuing + microservice decoupling → SQS + Lambda.
• Continuous ingestion that must survive downstream failure → Kinesis. Millions of PUTs/sec, records visible to consumers in ~70 ms, and retention that makes replay/retry a built-in rather than something you code.
• SNS: push-only pub/sub — no durable retry or replay if a subscriber fails. API Gateway: a request/response front door, never a streaming ingestion layer.

SQS bills per API request, so "minimise SQS cost" is almost always long polling — it collapses a storm of empty ReceiveMessage responses into one call that waits.

• Long polling: ReceiveMessageWaitTimeSeconds 1–20 s (0 = short polling). The call waits until a message arrives or the timer expires.
• It also queries all servers in the distributed set, so it avoids the false "no messages here" that short polling can return.
• Set it per queue (the queue attribute) or per request on ReceiveMessage.
• Short polling: samples a subset of servers and returns immediately even when empty → many empty responses → more billed requests.
• Two distractors that sound like retrieval controls but aren't: DelaySeconds (message timer) delays a new message's visibility and is a producer-side setting; visibility timeout (default 30 s, max 12 h) hides a message already received, preventing duplicate processing.

SQS queues work for one consumer group. SNS fans out the same message. EventBridge routes events by content to many targets, with schemas and SaaS sources.

• SNS → SQS fan-out: the classic pattern — each subscriber gets its own durable queue and drains at its own pace.
• EventBridge: content-based rules, schema registry, 20+ AWS event sources, third-party SaaS, and scheduled rules (cron replacement).
• DLQ: attach one to SQS and to Lambda/EventBridge targets to catch poison messages.
• Step Functions: for multi-step workflows with retries, branching and human approval — orchestration, not messaging.
• The store-and-forward tell: "a fast process hands work to a slower one", "must run and fail independently", "hold the message until the consumer is ready" → SQS. It is poll-based and stores messages redundantly across AZs until something collects them.
• The distractors all assume the consumer is available now: SNS pushes to whoever is subscribed, EventBridge delivers events as they arrive, and Kinesis is fan-out streaming — none of them is a buffer that waits.

Migrating an app that speaks AMQP, MQTT, JMS or STOMP with minimal code change → Amazon MQ (managed ActiveMQ / RabbitMQ).

• SQS/SNS use proprietary AWS APIs — adopting them means rewriting the messaging layer.
• Amazon MQ keeps the industry-standard protocols, so it's a lift-and-shift.
• Same question's compute half: EKS on Fargate — managed Kubernetes control plane plus serverless pods, no worker nodes to patch.
• Pattern: "minimal refactoring + operational efficiency" → managed services that speak open standards.

FIFO defaults to 300 API ops/sec. Batch up to 10 messages per call to multiply it.

• Batch 2 → 600 msg/sec · Batch 4 → 1,200 msg/sec · Batch 10 → 3,000 msg/sec.
• Need 1,000 msg/sec in strict order? Batch 4 is enough.
• Queue type is fixed at creation — there is no standard→FIFO conversion API. Migrating means deleting the standard queue and recreating it as FIFO.
• A FIFO queue name must end in the .fifo suffix, and that suffix counts toward the 80-character name limit.
• Guarantees: FIFO = exactly-once processing + strict ordering. Standard = at-least-once delivery + best-effort ordering.

100 → 5,000 req/sec spike drops notifications because Lambda hit the 1,000 concurrent execution account quota. Fix: request a limit increase from AWS Support.

• Serverless still has soft regional quotas — "it auto-scales" is not unlimited.
• You cannot "provision more servers" for SNS or Lambda.
• SNS itself scales fine; the bottleneck is downstream Lambda.
• Best practice: insert SQS (SNS → SQS → Lambda) to buffer the spike and let Lambda drain at a safe pace — but SQS alone doesn't raise the ceiling.

Fully serverless ingestion = SQS → Lambda → DynamoDB.

• SQS standard queues absorb variable volume with no capacity limit.
• Lambda polls in batches, zero server management.
• Firehose cannot write to DynamoDB — only S3, Redshift, OpenSearch (and Splunk).
• EC2: provisioned IaaS — instant anti-pattern when "serverless" is required.

Ordered, spiky real-time score updates → Kinesis Data Streams → Lambda → DynamoDB.

• Kinesis preserves record order within a shard.
• Lambda scales to spikes with no patching or servers.
• DynamoDB: managed NoSQL, single-digit ms leaderboard storage.
• SQS Standard: no ordering guarantee. EC2 fleets: heavy ops overhead.

Serverless real-time stream transformation and analysis — now Amazon Managed Service for Apache Flink.

• Live metrics: rolling averages, CTR, active users for dashboards.
• Streaming ETL: filter/enrich/reformat before landing in S3, Redshift, OpenSearch.
• Real-time alerts: anomalies, fraud, IoT thresholds.
• Stateful processing and windowing in Java, Python, Scala, or SQL. Ingests from KDS, MSK, API Gateway.

Managed big-data platform for Spark, Hadoop, Hive, Presto at scale — not a parallel file system.

• Primary (Master): coordinates the cluster.
• Core: runs tasks and hosts HDFS data.
• Task: compute only — ideal for Spot Instances.
• EMRFS: read/write straight to S3, decoupling compute from storage.
• Exam tip: big-data analytics/ML frameworks → EMR. High-performance parallel FS → FSx for Lustre.

Glue → Redshift Serverless → Redshift ML for serverless ETL + MPP warehouse + SQL-only ML.

• Glue: serverless clean/transform/load from the S3 data lake.
• Redshift Serverless: MPP analytical queries, no cluster management.
• Redshift ML: train and infer with native SQL — no Python.
• EMR: infrastructure management. RDS: OLTP, no MPP. Athena ML: no dedicated warehouse tier.

Visual, collaborative prep with lineage and column profiling → AWS Glue DataBrew.

• Point-and-click filtering, date normalization, aggregation — no code.
• Recipes: versioned, auditable, shareable transformation steps.
• Profiling: automatic column stats, cardinality, data types.
• Glue Studio: developer-oriented, generates Spark, no column profiling.
• Athena: SQL, not visual, no profiling. AppFlow: SaaS transfer, not ETL prep.

Extract custom entities from text with no ML expertise → Amazon Comprehend, not SageMaker.

• Pipeline: S3 Event → Lambda → Comprehend → DynamoDB.
• Serverless, code-free entity extraction.
• Anti-patterns: training custom SageMaker models when a managed NLP service suffices; Lookout for Vision for text.

Let developers attach their own policies without letting them escalate: a permissions boundary sets the ceiling. Effective permissions = identity policy ∩ boundary.

• Scope: IAM users and roles only — never groups.
• Use case: delegated administration — devs manage their own policies inside a hard maximum.
• SCPs: account/OU-wide guardrails via Organizations, not per-user delegation.
• A plain IAM policy: useless as a ceiling if the user can attach more policies.

Five layers show up in answers: SCP → permissions boundary → identity policy → resource policy → session policy. Deny always wins.

• SCP (Organizations): maximum permissions for a whole account/OU. Never grants — only limits.
• Permissions boundary: maximum for one user/role.
• Identity policy: what the principal may do. Resource policy: who may touch the resource (S3 bucket policy, KMS key policy, SQS, Lambda, API Gateway).
• Cross-account access needs both sides: the resource policy allows, and the caller's identity policy allows.

An SCP is a ceiling, never a grant: effective access = SCP ∩ IAM policy. It binds everyone in a member account including root — the only exemptions are service-linked roles and the management account.

• Applies to the root user of a member account. There is no root exemption; that is the most-missed line on this topic.
• Does not apply to service-linked roles — AWS services must keep working regardless of your guardrails.
• Does not apply to the organization's management account (the old "master account"), and that holds wherever in the OU hierarchy the SCP is attached.
• Two different "roots" get conflated: the *root user of a member account* is constrained; the *management account itself* is not.
• The classic trap: assuming a generous IAM policy can override an SCP. It cannot — an SCP only ever subtracts.

A CloudFormation stack is scoped to one account + one Region. The moment a question says "across accounts and Regions", the answer is StackSets.

• Template = the definition (JSON/YAML). Stack = one deployment of it, bound to a single account and Region. StackSet = one operation that fans that stack out to many accounts and Regions.
• Two permission models: *self-managed* (you create IAM roles in the admin and target accounts) and *service-managed* (integrates with AWS Organizations and auto-deploys into new accounts added to an OU).
• Operation controls worth knowing: concurrency, failure tolerance, and Region order.
• AWS RAM shares existing resources (subnets, TGWs, Route 53 rules, License Manager configs) — it does not deploy templates.
• Neighbours: Service Catalog for curated, approved products; SCPs for restricting what is allowed rather than provisioning it.

Restrict an API by caller IP with an API Gateway resource policy using aws:SourceIp. Security groups don't apply here.

• API Gateway is managed and lives outside your VPC subnets — you cannot attach a security group to it.
• Resource policies are JSON attached to the API: filter by IP range, AWS account, or VPC endpoint.
• Condition keys: IpAddress and NotIpAddress on aws:SourceIp.
• Need managed rule sets, rate limiting or SQLi/XSS protection instead? That's AWS WAF on the stage.

Per-client throttling and request quotas are an API Gateway usage plan + API keys feature. No load balancer does it natively.

• Usage plan: a rate limit (requests/sec plus burst) and a quota (requests per day/week/month), bound to an API key you issue per client.
• NLB: Layer 4 — no HTTP or client awareness at all, so no throttling.
• GWLB: Layer 3/4, for inserting third-party firewall/IDS appliances. Nothing to do with API limits.
• ALB: Layer 7, but its listener rules only do host/path routing. The closest it gets is WAF rate-based rules — which throttle by IP, not by API key, so they cannot express "this customer gets 1,000 requests/day".

Standards-based OIDC/JWT validation with no custom code → API Gateway HTTP API with its built-in JWT authorizer. Reach for a Lambda authorizer only when the auth logic is genuinely custom.

• HTTP API + JWT authorizer: point it at the issuer/JWKS and it validates signature, exp, aud and scopes automatically — cheaper and lower-latency than REST API.
• REST API + Lambda authorizer: you hand-write the JWT validation. That is custom logic, more cost, more latency — right only when the rules are not standard OIDC.
• WebSocket API + Lambda authorizer: authorises only at $connect, not per message — and it is the wrong transport for stateless REST-style calls.
• Validating the token inside a container on Fargate/App Runner: app-layer auth, and no longer "fully managed".
• Rule of thumb: HTTP API > REST API whenever you just need lightweight, standards-based auth with no custom code.

Add login to an EC2 app with minimal development → an ALB listener rule that authenticates against a Cognito User Pool (or any OIDC IdP).

• The ALB does the OIDC dance before forwarding to targets — no auth code in the app.
• User Pools: the directory — sign-up, sign-in, token issuance.
• Identity Pools: exchange a token for temporary AWS IAM credentials.
• CloudFront: would need custom Lambda@Edge — more development, more ops.

MFA everywhere, CloudTrail on, least privilege, individual credentials, roles for EC2.

• Enable MFA for all privileged users (virtual or hardware token).
• CloudTrail logs every IAM action — required for auditing.
• Least privilege: only the permissions the task needs.
• Never share credentials — one identity per person.
• IAM Roles for EC2 — never hardcode access keys on instances.

An instance gets permissions one way only: an IAM role attached through an instance profile. Credentials are then delivered and rotated automatically through instance metadata.

• Why it is the only right answer: temporary, auto-rotated credentials, nothing on disk, nothing in code.
• Anti-pattern 1: an IAM user with long-lived access keys stashed in S3 or on the box and read by the app. Hard-coded credentials in any disguise.
• Anti-pattern 2: creating the role but then "adding the instance to the role's trust relationship policy". Trust policies govern who may assume a role (cross-account, service principals) — binding a role to an instance is the instance profile's job, not theirs.
• One role at a time: an EC2 instance carries exactly one instance profile. "Attach a second role" is never an option.

Fleet already carrying task-specific IAM roles and you need centralised patching without touching those roles → Default Host Management Configuration (Systems Manager Quick Setup).

• DHMC turns on SSM management account-wide via a service-linked role, so you never edit an existing instance role and risk disturbing the permissions it already grants.
• Contrast the older approach: manually attaching AmazonSSMManagedInstanceCore to every instance role — workable, but it edits live permissions on a working fleet.
• Remember an instance has only one instance profile, which is exactly why "just add another role for SSM" is not on the table.
• Hybrid Activations: for non-EC2 / on-premises servers only.
• Manual agent installs plus cron patch scripts: the high-overhead anti-pattern, against native Patch Manager.

AD Connector + IAM Identity Center = lowest-overhead federation of on-prem AD across AWS Organizations.

• AD Connector: directory proxy — no domain controllers in the cloud.
• IAM Identity Center: group-based Permission Sets across all accounts.
• Anti-pattern: self-hosted IdP on EC2, or AWS Managed AD, when a proxy suffices.
• But flip it the moment the question asks for a trust relationship or directory-aware workloads (SQL Server, .NET apps): then only AWS Managed Microsoft AD works — real Windows Server AD, supports trusts, scales past 5,000 users.
• AD Connector: a proxy with no directory of its own, so it can host no workloads and establish no trusts.
• Simple AD: Samba 4, ≤5,000 users, and no trust relationship support.
• Amazon Cloud Directory: an unrelated hierarchical NoSQL data store — not Windows-compatible at all.

DDoS + reporting/audit + minimal architecture change → Shield Advanced. Pick WAF alone only when the threat is a known, static request pattern.

• Shield Advanced attaches to what you already run — ALB, CloudFront, Global Accelerator, Route 53, Elastic IPs — so there is nothing to re-architect. L3/L4/L7 auto-mitigation, attack diagnostics and reports (the audit trail), 24/7 Shield Response Team, DDoS cost protection, and WAF included.
• Shield Standard: free and always on, but L3/L4 only, no reporting, no DRT.
• WAF alone: matches known patterns — IP sets, geo, SQLi, rate limits. Static rules lose to rotating source IPs. And "put CloudFront in front of the ALB" is an architecture change when the question forbids one.
• GuardDuty: detection and findings only — it blocks nothing, and "then block them manually" is an exam anti-pattern.
• Inspector: software vulnerability and network-reachability scanning for EC2/ECR/Lambda. Unrelated to volumetric attacks.

Centralise security logs from many accounts with the least development effort → Amazon Security Lake, normalising into OCSF in your S3 bucket.

• Automatically pulls CloudTrail, GuardDuty, VPC Flow Logs, Route 53 logs and third-party sources.
• Normalises to the Open Cybersecurity Schema Framework — no custom ETL to write or maintain.
• Lake Formation + Glue: generic data lake, you still write the standardisation scripts.
• Custom Lambda ingestion: high maintenance. Athena + QuickSight over scattered buckets: queries fragments, no aggregation or common schema.

ACM auto-renews only ACM-issued certs. For imported third-party certs, watch them with the AWS Config managed rule acm-certificate-expiration-check + SNS.

• Auto-renewal: free and automatic for ACM-issued certs while DNS/email validation stays valid.
• Imported certs: ACM will never renew them — expiry tracking and re-import are on you.
• Least maintenance: the Config managed rule evaluates all current and future certs against a threshold (e.g. 30 days) and notifies via SNS on non-compliance.
• Alternative: alarm on ACM's DaysToExpiry CloudWatch metric — more setup, less central.

CloudTrail → CloudWatch Logs → Metric Filter → Alarm → SNS.

• Metric filter matches the error pattern; alarm fires SNS in near real time.
• CloudTrail → Kinesis: not supported — CloudTrail exports to S3 or CloudWatch Logs only.
• Athena + QuickSight: historical reporting, not alerting.
• Trusted Advisor: service quotas, not unauthorized API calls.

CloudTrail = who did what (API audit). CloudWatch = how it's performing (metrics, logs, alarms). Config = what it looks like and whether that's allowed (state + compliance).

• Config: resource configuration history, drift, managed compliance rules with auto-remediation.
• CloudWatch: metrics, dashboards, alarms, Logs Insights.
• Trusted Advisor: account-level checks — cost, quotas, security, fault tolerance.
• Question mentions "compliance rule" or "was this resource ever misconfigured" → Config, every time.

EC2's default metrics do not include memory or disk-space usage — you must install the CloudWatch agent to get them.

• Default metrics come from the hypervisor: CPU, network, disk I/O, status checks.
• Memory used, swap, free disk space, and OS/application logs all need the unified agent.
• Give the instance an IAM role with CloudWatchAgentServerPolicy; deploy the agent with Systems Manager.

Four different questions: is something attacking me, am I vulnerable, is sensitive data exposed, how am I doing overall.

• GuardDuty: threat detection from CloudTrail, VPC Flow Logs and DNS logs — crypto-mining, recon, compromised credentials.
• Inspector: vulnerability scanning of EC2, container images in ECR, and Lambda (CVEs, unintended network exposure).
• Macie: discovers and classifies sensitive data / PII in S3.
• Security Hub: aggregates findings and scores against standards (CIS, PCI). Detective: investigates the root cause of a finding.

One place to define backup policy across services and accounts — the "centrally manage and audit backups" answer.

• Covers EBS, EFS, FSx, RDS, Aurora, DynamoDB, Storage Gateway and more.
• Backup plans: schedule, lifecycle to cold storage, retention, cross-Region and cross-account copy.
• Vault Lock: WORM protection so backups can't be deleted early — the compliance answer.
• Beats hand-rolled Lambda + snapshot scripts whenever "operational overhead" appears.

Availability answers almost always combine Multi-AZ + a load balancer health check + an ASG. Add Route 53 health checks for cross-Region.

• ELB health check on the ASG (rather than the EC2 status check) catches an app that's up but broken.
• Connection draining / deregistration delay lets in-flight requests finish before an instance leaves.
• Lifecycle hooks pause launch/terminate so you can bootstrap or drain state.
• Stateless tiers + externalised session state (ElastiCache/DynamoDB) are what make any of this work.