| Relational Database Service (RDS) | • managed relational DB service → AWS handles provisioning, patching, backups, failover, scaling • engines → MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, plus Aurora • runs on an EC2 instance class you choose, with EBS storage (storage autoscaling available) • scale up by resizing the instance; scale reads with read replicas; HA with Multi-AZ • you own schema, queries, tuning; AWS owns the undifferentiated admin • not serverless (except Aurora Serverless) → you pay for the running instance • exam → "managed relational DB, reduce admin overhead" = RDS | | --- | --- | | RDS multi AZ deployments | • HA feature → synchronous standby replica in a different AZ • automatic failover (~60-120s) on AZ outage, instance failure, or maintenance • standby is not readable → availability/DR only, not read scaling • same endpoint → DNS flips to the standby on failover (transparent to the app) • Multi-AZ DB cluster → newer option with 2 readable standbys + faster failover • exam → "high availability / automatic failover" = Multi-AZ; "scale reads" = read replicas | | RDS read replicas | • asynchronous read-only copies → scale read-heavy workloads • up to 15 (Aurora) / 5 (other engines); can be cross-region • each has its own endpoint → app directs reads there • can be promoted to a standalone read/write DB (breaks replication) • cross-region replica → aids DR + lowers read latency for distant users • exam → "offload / scale reads" = read replica (not Multi-AZ) | | synchronous vs asynchronous replicas | • synchronous → write is confirmed only after the standby also commits ◦ zero data loss; used by Multi-AZ standby + Aurora storage ◦ small write-latency cost • asynchronous → the replica catches up after the primary writes ◦ used by read replicas ◦ possible replica lag → eventually consistent reads • exam → Multi-AZ = synchronous (HA/durability); read replica = asynchronous (scaling) | | RDS backups + snapshots | • automated backups → daily full + transaction logs → point-in-time recovery (PITR) ◦ retention 1-35 days (0 disables); stored in S3 • manual snapshots → user-triggered, kept until you delete them (survive DB deletion) • restoring always creates a new DB instance with a new endpoint • snapshots can be copied + shared across regions/accounts • exam → keep backups beyond 35 days = manual snapshot; recover to a moment in time = automated backups/PITR | | RDS encryption | • at rest → AWS KMS (AES-256); covers the DB, automated backups, snapshots, + read replicas • must enable at creation → to encrypt an existing DB: snapshot it, copy the snapshot as encrypted, restore • in transit → SSL/TLS • encrypted snapshot → encrypted restore; replicas inherit encryption • exam → "encrypt an existing unencrypted RDS" = snapshot → copy with encryption → restore | | Amazon Aurora | • AWS cloud-native relational DB, MySQL + PostgreSQL compatible • up to 5x MySQL / 3x PostgreSQL throughput at ~1/10 the cost of commercial DBs • storage auto-scales in 10 GB increments up to 128 TB • 6 copies of data across 3 AZs, self-healing • up to 15 low-latency read replicas + fast failover • fully managed, distributed, fault-tolerant storage • exam → "MySQL/Postgres-compatible, high performance + availability, managed" = Aurora | | aurora architecture | • compute (DB instances) is separated from a shared distributed storage volume • storage → 6 copies across 3 AZs; writes acknowledged by a 4-of-6 quorum • single writer (primary) + up to 15 readers share the same storage → minimal replica lag • cluster endpoint (writes) + reader endpoint (load-balanced reads) • continuous backup to S3, self-healing storage • failover → a reader is promoted in ~30s • exam → shared storage is why Aurora replicas are faster + lag-free vs RDS | | aurora serverless | • auto-scales DB capacity (ACUs) up/down with load → no instance sizing • v2 → fine-grained, fast scaling; supports replicas, Multi-AZ, + global (production-grade) • pay per ACU-second consumed • use for → variable, unpredictable, intermittent workloads, dev/test • exam → "unpredictable or spiky DB load, don't want to manage capacity" = Aurora Serverless | | aurora global database | • 1 primary region + up to 5 secondary (read-only) regions • storage-level replication, typically < 1s lag • DR → promote a secondary region in < 1 min (RTO), RPO ~1s • low-latency global reads + cross-region resilience • exam → "global reads + cross-region DR for a relational DB" = Aurora Global Database | | Amazon DynamoDB | • fully managed, serverless NoSQL key-value + document database • single-digit millisecond latency at any scale; auto-scales, no servers • multi-AZ by default; 99.999% availability with global tables • virtually unlimited throughput + storage • integrates with Lambda (streams), IAM, point-in-time recovery • exam → "serverless NoSQL, massive scale, low latency, no admin" = DynamoDB | | dynamodb data model | • table → items (rows) → attributes (fields); schemaless beyond the key • primary key: ◦ partition key (hash) → decides which partition stores the item ◦ optional sort key (range) → composite key, orders items within a partition • items ≤ 400 KB; choose a high-cardinality partition key to spread load • exam → good partition key = even distribution; bad key = throttled hot partition | | dynamodb secondary indexes | • Global Secondary Index (GSI) → different partition + sort key ◦ own capacity, eventually consistent, can add anytime • Local Secondary Index (LSI) → same partition key, different sort key ◦ shares table capacity, supports strong consistency, must be created with the table • indexes let you query on non-key attributes • exam → query a non-key attribute after creation = GSI; strong consistency on an alt sort key = LSI | | dynamodb capacity modes | • On-Demand → pay per request, instant scaling, no planning → unpredictable/spiky traffic, new apps • Provisioned → set RCUs + WCUs (with optional auto scaling) → predictable traffic, cheaper at steady high volume • 1 RCU = 1 strong (or 2 eventual) reads/s of 4 KB; 1 WCU = 1 write/s of 1 KB • exam → spiky/unknown = on-demand; steady + cost-sensitive = provisioned | | dynamodb read consistency | • eventually consistent (default) → may miss a very recent write; cheaper, higher throughput • strongly consistent → always the latest data; costs 2x RCU, slightly higher latency, not available on GSIs • transactional reads/writes → ACID across multiple items • exam → "must read the latest write" = strongly consistent read | | dynamodb streams | • ordered, time-sequenced change log of item-level changes (insert/update/delete) • 24-hour retention; triggers Lambda for event-driven processing • use for → replication, aggregations, notifications, audit, global tables • exam → "react to a DynamoDB change / trigger a function on write" = Streams + Lambda | | dynamodb accelerator (DAX) | • fully managed in-memory cache purpose-built for DynamoDB • microsecond read latency (vs single-digit ms), no app rewrite (DynamoDB-compatible API) • write-through cache; for read-heavy + bursty workloads • not for strongly consistent reads (pass through) or write-heavy apps • exam → "speed up DynamoDB reads to microseconds with minimal code change" = DAX | | Amazon ElastiCache | • managed in-memory cache (Redis / Memcached) → microsecond latency • offloads read-heavy DB workloads; stores sessions, leaderboards, real-time data • reduces DB load + cost; you add cache logic in the app • strategies → lazy loading (cache-aside), write-through, TTL • exam → "reduce DB load / sub-ms reads for any database" = ElastiCache | | Elasticach engines | • Redis → persistence, replication, Multi-AZ failover, backups, pub/sub, sorted sets, transactions, geospatial ◦ use for → HA caching, leaderboards, sessions, rich data types • Memcached → simple, multi-threaded, horizontally scalable, no persistence/replication ◦ use for → simple key-value caching, scale-out across nodes • caching patterns: ◦ lazy loading (cache-aside) → load on a miss; data can be stale ◦ write-through → write cache + DB together; fresh but extra writes ◦ TTL → expire keys to bound staleness • exam → need persistence/HA/replication = Redis; simplest scale-out cache = Memcached | | elasticach vs dynamodb dax | • DAX → purpose-built cache for DynamoDB only; transparent (same API, no app logic) • ElastiCache → general-purpose cache for any data source; you write the cache logic • exam → cache DynamoDB with no code changes = DAX; cache RDS/other or custom data = ElastiCache |

| Elastic Load Balancing (ELB) | • distributes incoming traffic across targets (EC2, containers, IPs, Lambda) in one or more AZs • improves availability + fault tolerance → routes only to healthy targets • scales automatically; integrates with Auto Scaling • 4 types → ALB (L7), NLB (L4), GWLB (L3), CLB (legacy) • regional; cross-zone load balancing spreads evenly across AZs • exam → match the type to the layer/protocol of the scenario | | --- | --- | | Application Load Balancer (ALB) | • Layer 7 (HTTP/HTTPS) • routing → path-based, host-based, header / query / method-based • targets → EC2, ECS, Lambda, IP; supports WebSocket, HTTP/2, redirects, fixed responses • features → TLS termination, sticky sessions, user auth (Cognito/OIDC), WAF integration • use for → web apps, microservices, container routing • exam → "route by URL path / host / header" = ALB | | Network Load Balancer (NLB) | • Layer 4 (TCP / UDP / TLS) • ultra-low latency, millions of requests/sec • static IP per AZ (or assign an Elastic IP); preserves the client source IP • targets → EC2, IP, ALB; integrates with PrivateLink • use for → extreme performance, gaming, IoT, static IP needs, non-HTTP protocols • exam → "static IP / millions of req / TCP-UDP / lowest latency" = NLB | | Gateway Load Balancer (GWLB) | • Layer 3 → deploy + scale third-party virtual appliances (firewalls, IDS/IPS, deep packet inspection) • single entry/exit point for inspecting traffic; transparent "bump-in-the-wire" • uses the GENEVE protocol on port 6081 • exam → "insert third-party security/firewall appliances at scale" = GWLB | | Load Balancer Concepts | • listener → the port + protocol the LB listens on • target group → set of targets + its own health check; the routing destination • health checks → route only to healthy targets • cross-zone → spread evenly across all AZs (always on for ALB; optional on NLB) • sticky sessions → bind a client to one target (cookie-based) • TLS termination → decrypt at the LB using ACM certs • deregistration delay (connection draining) → finish in-flight requests before removing a target • exam → these knobs explain odd routing / health behavior | | Amazon CloudFront | • Content Delivery Network (CDN) → caches + serves content from locations near users → low latency • edge locations → global points of presence that cache content; requests go to the nearest one • serves static + dynamic content; origins → S3, ALB, EC2, API Gateway, any HTTP server • integrates with Shield + WAF; supports HTTPS, signed URLs/cookies, OAC, Lambda@Edge / CloudFront Functions • exam → "cache content globally / reduce download latency / protect the origin" = CloudFront | | S3 Origin | • CloudFront serving content from an S3 bucket origin • Origin Access Control (OAC) → recommended; locks the bucket so only CloudFront can read it (bucket stays private) • Origin Access Identity (OAI) → the legacy predecessor of OAC, being phased out • pattern → keep the bucket private + Block Public Access on; grant read only via OAC • exam → "serve S3 through CloudFront but keep the bucket private" = OAC | | cache control | • TTL → how long an object stays cached (Cache-Control / Expires headers, or CloudFront min/default/max TTL) • cache behaviors → per-path-pattern rules (TTL, allowed methods, origin) • cache key → what makes an entry unique (headers, cookies, query strings) • invalidation → force-remove cached objects before TTL (a few free, then per-path cost) • tip → use versioned object names to avoid invalidations • exam → "stale content after an update" = lower the TTL or invalidate | | signed URL vs singed cookie | • both restrict access to private CloudFront content for authorized users • signed URL → grants access to one specific file; the URL carries the policy • signed cookie → grants access to multiple files / whole content without changing URLs • use cookies when you don't want to change URLs or are serving many files (e.g. streaming) • exam → single file = signed URL; many files / keep URLs = signed cookie | | cloudfront vs. s3 transfer acceleration | • CloudFront → caches content at the edge for fast downloads / delivery to viewers • S3 Transfer Acceleration → speeds uploads to a bucket via edge + AWS backbone (no caching) • exam → accelerate global uploads to S3 = Transfer Acceleration; cache + deliver content = CloudFront | | route 53 | • managed, highly available + scalable authoritative DNS and domain registrar • translates domain names to IPs; global service • supports health checks + many routing policies; integrates with ELB, CloudFront, S3 via Alias records • 100% availability SLA • exam → "DNS routing, failover, traffic distribution by geography/latency" = Route 53 | | routing policies | • Simple → one record, no logic • Weighted → split traffic by % (A/B testing, gradual rollout) • Latency → route to the region with the lowest latency for the user • Failover → primary/secondary with health checks (active-passive DR) • Geolocation → route by the user's location (compliance, localization) • Geoproximity → route by distance with an adjustable bias (Traffic Flow) • Multivalue Answer → return multiple healthy IPs (basic spreading) • exam → match the keyword (region latency, % split, DR failover, geo) to the policy | | health checks | • monitor endpoint health (HTTP/HTTPS/TCP) from global checkers • can monitor an endpoint, other health checks (calculated), or a CloudWatch alarm • drive DNS failover → unhealthy records are removed from responses • exam → automatic DNS failover requires health checks on the records | | record types | • A → name to IPv4; AAAA → name to IPv6 • CNAME → name to another name (not allowed at the zone apex) • Alias → Route 53-specific; maps a name to an AWS resource (ELB, CloudFront, S3, API GW), free, works at the apex • MX → mail; TXT → verification/SPF; NS / SOA → zone delegation • exam → point a naked/apex domain at an ELB/CloudFront = Alias | | cname vs alias at zone apex | • DNS rules forbid a CNAME at the zone apex (the naked domain, e.g. example.com) • Alias records (AWS-only) can sit at the apex and point to AWS resources • Alias → no query charge, auto-updates target IPs, supports apex + health checks • CNAME → only for subdomains (www.example.com), can point to any DNS name • exam → "apex/root domain to an AWS resource" = Alias, never CNAME |

| aws lambda | • serverless compute → run code with no servers to provision or manage • event-driven; pay per request + duration (ms), nothing when idle • runtimes → Python, Node, Java, Go, .NET + custom + container images • limits → 15-min max timeout, up to 10 GB memory, 512 MB-10 GB /tmp • auto-scales by running more concurrent executions • exam → "run code on events, no servers, pay per use" = Lambda | | --- | --- | | lambda execution model | • synchronous → caller waits for the result (API Gateway, ALB, CLI) • asynchronous → event queued, Lambda retries on failure (S3, SNS, EventBridge) • poll-based / stream → Lambda polls the source (SQS, Kinesis, DynamoDB Streams) • cold start → first invoke initializes the environment (extra latency); warm = reused • the environment is reused → cache connections outside the handler • exam → match invocation type to the source; cut cold starts = provisioned concurrency | | lambda concurrency | • concurrency = number of simultaneous executions • account limit → 1,000 concurrent by default (soft, raisable) • reserved concurrency → caps + guarantees capacity for a function (protects others) • provisioned concurrency → pre-initialized environments → no cold starts (predictable latency) • throttling (429) when the limit is hit → async retries, sync errors • exam → eliminate cold starts = provisioned; guarantee/limit a function's capacity = reserved | | Lambda in VPCs | • by default Lambda runs in an AWS-managed VPC (has internet, no access to your private resources) • attach to your VPC subnets → reach private resources (RDS, ElastiCache, internal services) • a VPC-attached Lambda has no internet by default → needs a NAT gateway for outbound internet • use VPC endpoints to reach AWS services privately • exam → "Lambda must reach a private RDS" = put it in the VPC; "also needs internet" = add NAT | | lambda key configuration | • memory (128 MB-10 GB) → also scales CPU + network proportionally • timeout → up to 15 min • IAM execution role → the permissions the function receives • environment variables → config (can be KMS-encrypted) • layers → shared libraries/dependencies • triggers + destinations / DLQ → event sources + where failures go • exam → slow function = raise memory (gets more CPU); secrets = env vars + KMS / Secrets Manager | | amazon simple queue service (SQS) | • fully managed message queue → decouples producers from consumers • producer sends → queue stores → consumer pulls (pull-based) • absorbs spikes; lets components scale + fail independently • messages up to 256 KB; retained up to 14 days; near-unlimited throughput (Standard) • exam → "buffer requests / decouple / process at own pace / smooth spikes" = SQS | | sqs queue types | • Standard → unlimited throughput, at-least-once delivery, best-effort ordering (possible duplicates / out-of-order) • FIFO → exactly-once processing, strict ordering; 300 msg/s (3,000 with batching) ◦ message group ID (ordering) + deduplication ID • exam → strict order + no duplicates = FIFO; max throughput + order-tolerant = Standard | | queue visibility | • visibility timeout → after a consumer receives a message it is hidden from others for a period • default 30s, up to 12h; the consumer must delete before it expires or the message reappears (redelivery) • too short → duplicate processing; too long → slow retries on failure • extend with ChangeMessageVisibility for long jobs • exam → message processed twice = visibility timeout shorter than processing time | | dead letter queue (DLQ) | • a separate queue that captures messages that repeatedly fail processing • triggered after maxReceiveCount retries (redrive policy) • isolates "poison" messages for debugging without blocking the main queue • supported by SQS, SNS, + Lambda async • exam → "handle messages that keep failing / poison pill" = DLQ | | long polling vs short polling | • short polling → returns immediately, may be empty even if messages exist → more empty calls = higher cost • long polling → waits up to 20s (WaitTimeSeconds) for a message → fewer empty responses, lower cost, less latency • long polling is the recommended default • exam → reduce empty receives + cost = long polling | | message retention | • how long SQS keeps a message if not deleted → 1 minute to 14 days (default 4 days) • after retention expires the message is dropped • exam → "messages must persist up to N days until processed" = set the retention period | | amazon simple notification service (SNS) | • fully managed pub/sub messaging → push-based • a publisher sends to a topic → fans out to all subscribers • decouples one-to-many; subscribers process independently • supports message filtering, DLQ, encryption, + FIFO topics • exam → "notify many endpoints / fan-out a message" = SNS | | sns subscription endpoints | • SQS, Lambda, HTTP/HTTPS, email, email-JSON, SMS, mobile push, Kinesis Data Firehose • each subscriber gets its own copy of the message • exam → SNS to SQS / Lambda are the common architecture targets | | sns + sqs fan-out pattern | • one SNS topic → multiple SQS queues subscribed → each service processes the same event independently • adds durability (SQS persists) + decoupling + parallel processing • each consumer scales/retries on its own; add subscribers without changing the publisher • exam → "fan out one event to several systems durably" = SNS + SQS fan-out | | sns message filtering | • subscription filter policies → each subscriber receives only messages matching attributes/body • avoids sending everything everywhere + filtering inside the consumer • exam → "route only relevant messages to each subscriber" = SNS filter policy | | amazon eventbridge | • serverless event bus → routes events from AWS services, SaaS apps, + custom apps to targets via rules • content-based rules (pattern matching) + schema registry • buses → default (AWS events), custom, + partner (SaaS) • targets → Lambda, SQS, SNS, Step Functions, Kinesis, and more • exam → "event-driven routing with filtering + SaaS integration" = EventBridge | | eventbridge scheduler | • managed scheduler → run tasks on a cron or rate schedule (one-time or recurring) • scales to millions of schedules, time zones, flexible time windows, retries • replaces CloudWatch Events scheduled rules at scale • exam → "scheduled / cron trigger for a Lambda or other target" = EventBridge Scheduler | | sqs vs sns vs eventbridge | • SQS → queue, point-to-point, pull, buffer + decouple • SNS → pub/sub, push, fan-out to many subscribers • EventBridge → event router with content filtering, many AWS/SaaS sources, scheduling • exam → buffer/smooth load = SQS; broadcast = SNS; route/filter events from many sources = EventBridge | | amazon api gateway | • fully managed service to create, publish, secure, + monitor APIs at scale • a "front door" for backends (Lambda, HTTP, AWS services) • handles auth (IAM, Cognito, Lambda authorizers), throttling, caching, request/response transforms, stages/versions • exam → "managed API front end for serverless/microservices with auth + throttling" = API Gateway | | api types | • REST API → full feature set (API keys, usage plans, request validation, caching, WAF) — higher cost • HTTP API → lower cost + latency, simpler, fewer features — favored for basic Lambda/HTTP proxies • WebSocket API → persistent two-way connections for real-time apps (chat, live feeds) • exam → cheap simple proxy = HTTP API; advanced features = REST API; real-time bidirectional = WebSocket | | api integration types | • Lambda proxy → passes the whole request to Lambda, returns its response (most common) • AWS service → call an AWS service directly (e.g. put to SQS/DynamoDB) without Lambda • HTTP → proxy to any HTTP backend • Mock → return a response with no backend (testing) • exam → invoke an AWS service with no code = AWS service integration | | api throttling + caching | • throttling → rate + burst limits protect the backend (token bucket); 429 Too Many Requests when exceeded • usage plans + API keys → per-client quotas + throttles • caching → cache responses at the stage with a TTL → fewer backend calls, lower latency • exam → protect the backend from overload = throttling/usage plans; reduce backend load + latency = caching |

| amazon cloudwatch | • monitoring + observability → metrics, logs, alarms, dashboards, events • collects + tracks performance data across AWS + custom apps • drives alarms → SNS, Auto Scaling, EC2 actions → automate responses • exam → "monitor performance / set alarms / collect metrics + logs" = CloudWatch | | --- | --- | | cloudwatch metrics | • time-ordered data points organized into namespaces • default metrics → CPU, network, disk I/O (note: not memory or disk-space usage) • custom metrics → push your own (memory, disk usage, app metrics) via the agent/API • resolution → standard (1-min / 5-min) vs high-resolution (1-sec) • exam → memory / disk-space usage = custom metric via the CloudWatch agent | | cloudwatch agent | • installed on EC2 / on-prem servers to collect OS-level metrics + logs not available by default • gathers memory, disk space, processes, swap + ships custom logs to CloudWatch • needs an IAM role with CloudWatch permissions • exam → "monitor RAM / disk usage on EC2" = install the CloudWatch agent | | cloudwatch alarms | • watch a metric against a threshold over periods → states OK / ALARM / INSUFFICIENT_DATA • actions → notify via SNS, trigger Auto Scaling, stop/terminate/reboot EC2 • composite alarms → combine multiple alarms with AND/OR logic (reduce noise) • exam → "auto-scale or notify when a metric crosses a threshold" = CloudWatch alarm | | cloudwatch logs | • centralized log storage → log groups → log streams • sources → EC2 (agent), Lambda, VPC Flow Logs, many services • metric filters → turn log patterns into metrics/alarms • Logs Insights → query logs interactively; set retention per log group • exam → search/analyze logs + alarm on a pattern = CloudWatch Logs + metric filter | | cloudwatch dashboards | • customizable visual views of metrics + alarms across regions + accounts • build at-a-glance operational monitoring; share with teams • exam → "single pane of glass for metrics across accounts/regions" = dashboards | | aws cloudtrail | • governance + audit → records API calls + account activity (who, what, when, from where) • on by default for 90 days of management-event history (console) • delivers to S3 (+ optionally CloudWatch Logs) for long-term retention + analysis • exam → "who deleted/created this resource / audit API activity" = CloudTrail | | cloudtrail event types | • management events → control-plane ops (create/delete/configure); logged by default • data events → data-plane ops (S3 object-level GET/PUT, Lambda invokes); high volume, off by default, extra cost • Insights events → detect unusual API activity / anomalies • exam → track S3 object-level access = enable data events | | cloudtrail trails | • a trail persists events to S3 beyond the 90-day history • can be multi-region and organization-wide (all accounts) • enable log-file integrity validation; send to CloudWatch Logs for alarms • exam → "audit across all regions + accounts, retain long-term" = org multi-region trail | | cloudwatch vs. cloudtrail | • CloudWatch → performance + operational monitoring → "what is happening / how is it performing" • CloudTrail → API audit log → "who did what, when" • exam → performance metric/alarm = CloudWatch; identity of an API caller = CloudTrail | | aws config capabilities | • records + evaluates resource configurations + changes over time • config rules → check compliance (managed or custom); flag non-compliant resources • configuration history + timeline + resource relationships; auto-remediation via SSM • exam → "is this resource compliant / track config changes over time" = AWS Config | | config vs cloudtrail | • Config → resource state and compliance over time → "what does it look like now / did it drift / is it compliant" • CloudTrail → API actions → "who made the change/call" • often used together → CloudTrail (who) with Config (what changed) • exam → compliance + config drift = Config; caller identity = CloudTrail | | security monitoring services | • GuardDuty → ML threat detection from VPC Flow Logs, DNS, + CloudTrail; no agents • Inspector → automated vulnerability scanning of EC2, ECR images, + Lambda • Macie → ML discovery + protection of sensitive data (PII) in S3 • Security Hub → aggregates + prioritizes findings across services + runs compliance checks • exam → threat detection = GuardDuty; vuln scan = Inspector; PII in S3 = Macie; central findings = Security Hub | | aws key management service (KMS) | • managed service to create + control encryption keys; integrates with most AWS services • keys never leave KMS unencrypted; FIPS 140-2 validated HSMs; all use logged in CloudTrail • access via key policies and IAM; keys are region-scoped • exam → "manage encryption keys with audit + access control" = KMS | | kms key types | • AWS managed keys → created/managed by AWS per service (aws/s3), rotated yearly, free • customer managed keys (CMK) → you control policy, rotation, enable/disable (has a cost) • AWS owned keys → shared, invisible to you • symmetric (default, AES-256) vs asymmetric (public/private, RSA/ECC) vs HMAC • exam → need control over rotation/policy/access = customer managed key | | kms envelope encryption | • encrypt data with a data key, then encrypt the data key with a KMS key → store the encrypted data key beside the data • avoids sending large payloads to KMS (KMS only handles the small key) • GenerateDataKey returns a plaintext + an encrypted data key → discard the plaintext after use • exam → "encrypt large data efficiently with KMS" = envelope encryption | | key policies | • the resource-based policy on a KMS key → the primary access control for that key • a key with no policy granting access is unusable (even by account admins) • combine with IAM policies + grants; cross-account access via key policy + IAM • exam → "principal can't use the key despite an IAM allow" = the key policy doesn't grant it | | automatic key rotation | • customer managed symmetric keys → optional automatic rotation (yearly, now with a configurable period) • AWS managed keys → rotated automatically (yearly) • old key material is retained so previously encrypted data still decrypts; key ID/ARN is unchanged • asymmetric keys → no automatic rotation (manual) • exam → "rotate keys automatically without re-encrypting data" = enable key rotation (symmetric) |