Day 5 - Week 7 Wrap-Up: Everything About Data-Tier Decisions

A SaaS company runs production RDS MySQL. 500 Lambda functions are invoked concurrently during burst traffic, producing "Too many connections" errors, and the security team also demands all three: "no passwords in code + automatic rotation + connection stability." What is the most appropriate configuration?

• AStore the password in Lambda environment variables with KMS encryption + limit concurrency with reserved concurrency of 50 + mitigate cold starts with provisioned concurrency
• BUse RDS IAM Authentication alone, with Lambda generating a SigV4 token on every invocation and connecting directly
• CRDS Proxy + Secrets Manager automatic rotation + Lambda connecting to the Proxy with IAM authentication
• DFully migrate to DynamoDB and add a DAX cache tier to eliminate the very concept of connections

A fintech company wants an RDS configuration that satisfies all of the following: (1) RPO ≈ 0, (2) analytics queries can run on the standby, (3) failover time < 60 seconds. Which option fits best?

• ARDS Multi-AZ DB Instance Deployment (1 synchronous standby) + 2 separate Read Replicas for analytics queries
• BRDS Multi-AZ DB Cluster Deployment (new in 2022)
• CAurora MySQL Multi-AZ
• DRDS Single-AZ + 7-day automatic backup retention + restoring daily snapshots for analytics

In ElastiCache Redis Cluster Mode Enabled, traffic concentrates on one hot key (a popular product ID), so one shard's CPU is at 100% while the other shards are at 5%. What is the most effective fix?

• ASwitch Cluster Mode to Disabled and spread reads with a single shard + 5 Read Replicas
• BUse hash tags to spread that key across multiple slots (key sharding)
• CRaise the instance class one step from cache.r7g.large to secure CPU/memory headroom on the hot shard
• DAdd more Read Replicas

A company uses Aurora MySQL, and a developer accidentally ran DELETE FROM orders WHERE created_at > '2024-01-01' on the production DB. What is the fastest recovery method? (within 30 minutes of the incident)

• ACreate a new cluster at a point 5 minutes earlier with PITR, then export/import only the deleted rows with mysqldump
• BRecover in place to just before the incident with Backtrack
• CManually trigger a Multi-AZ failover to switch to the instance in another AZ and restart
• DRestore from the latest automatic snapshot to a separate cluster and swap the endpoint

A game company runs a real-time leaderboard for global users. It must satisfy all of: (1) sorting 100 million users' scores, (2) a specific user's rank lookup < 10ms, (3) 100,000 score updates per second. What configuration fits best?

• AIn DynamoDB, put the score as a GSI partition key and sort with Query + ScanIndexForward, accelerating reads with DAX
• BA B-tree index on a score column in RDS MySQL + ORDER BY score DESC LIMIT + spreading with Read Replicas
• CElastiCache Redis Sorted Set
• DLoad score events into S3 and use Athena ORDER BY queries + a QuickSight dashboard

A healthcare SaaS stores PHI (Protected Health Information) in RDS PostgreSQL. HIPAA audit requirements are: (1) encrypt stored data with a company KMS key, (2) enforce TLS, (3) retain "who ran which query" for 1 year, (4) WORM protection for backups. Which one is missing? Select all of the following items that should be applied: (A) Enable the pgaudit extension + CloudWatch Logs export (B) rds.force_ssl=1 parameter (C) Encrypt the instance with a KMS CMK (customer managed key) (D) Enable AWS Backup Vault Lock

• AA and C only
• BB and D only
• CAll of A, B, C, and D
• DC and D only

An e-commerce company implemented product info caching in ElastiCache Redis in front of Aurora MySQL, using Lazy Loading + a 1-hour TTL. The operations team reports, "even after we change a product price, the old price shows for 1 hour." What is the most appropriate fix?

• AShorten the TTL from 1 hour to 5 minutes and apply a differentiated, shorter TTL only to popular products
• BAdd the Write-Through pattern (update the cache at the same time when a product is updated)
• CRemove Lazy Loading and send all lookups directly to an Aurora Read Replica to avoid the cache consistency problem
• DSwitch to Memcached to take advantage of faster cache invalidation and multi-threaded processing

A company runs Aurora MySQL in Tokyo. As global users grow, read latency must be 50ms or less in the US and Europe too, and it must be possible to promote to another region automatically if the Tokyo region goes down. What is the appropriate configuration?

• APlace one Aurora Cross-Region Read Replica each in the US and Europe and synchronize with binlog asynchronous replication
• BAurora Global Database (Primary: Tokyo, Secondary: Virginia, Ireland)
• CConfigure multi-region multi-master with DynamoDB Global Tables and rewrite the application to a key-value model
• DExtend Aurora Multi-AZ to 3 AZs and connect global users to Tokyo with Route 53 latency routing

A startup wants to cut RDS cost for its dev/staging environment. It is used only 9:00-18:00 on weekdays and not at all on weekends and nights. What is the most cost-effective configuration?

• ARDS Single-AZ db.t3.micro + a 1-year All Upfront Reserved Instance for about 38% savings, keeping the instance running at night but lowering storage to gp3 to cut cost
• BRDS Multi-AZ db.t3.medium + Storage Auto Scaling that shrinks automatically to match nighttime load and a read replica to isolate analytics queries
• CAurora Serverless v2 (Min 0 ACU - auto-pause)
• DRDS Single-AZ automation with an EventBridge schedule that stops the instance at 18:00 and starts it at 9:00 on weekdays, accepting that storage/backup are still billed while stopped

A company runs Multi-AZ RDS MySQL. An automatic minor patch ran and caused 4 minutes of downtime at the weekday morning traffic peak. Which of the following is NOT an appropriate way to prevent the same incident in the future?

• AExplicitly set preferred-maintenance-window to the lowest-traffic time such as Sunday 03:00-04:00 UTC
• BChange auto-minor-version-upgrade to false, validate in staging, and manage a manual patch schedule
• CIntroduce RDS Proxy to secure connection stability
• DSwitch to Multi-AZ Cluster Deployment (synchronous quorum replication + failover within 35 seconds)

A company uses ElastiCache Redis, and when one node suddenly went down the whole cache emptied, traffic to RDS surged at that moment, and it suffered a cascading failure that took down RDS too. What is the most appropriate configuration to prevent the same incident in the future?

• AChange Redis to a Memcached multi-node setup and remove the single point of failure by distributing nodes
• BMulti-AZ Redis replication + application-side single-flight + RDS Proxy + the circuit breaker pattern
• CRaise the RDS instance class two steps and increase max_connections to absorb the surge traffic
• DSend all read requests only to ElastiCache and change it to return an empty response on a cache miss

In which of the following scenarios is DAX (DynamoDB Accelerator) NOT the answer?

• ACutting DynamoDB read latency from single-digit ms to microseconds (in-memory write-through cache)
• BReducing DynamoDB read cost (fewer RCUs consumed through cache hits + absorbing repeated lookup load)
• CUsing it as a general-purpose cache like ElastiCache Redis
• DImproving the repeated response time of DynamoDB Eventually Consistent Reads by returning immediately from the cache