RDS, DynamoDB & Databases

Correct answer: .

Multi-AZ deployments maintain a synchronous, physically separate standby copy in a different Availability Zone purely for durability and automatic failover; RDS detects primary failure and flips the DNS endpoint to the standby without requiring an application change, typically completing in one to two minutes, and no read traffic is served from the standby under normal conditions. The option describing a same-AZ read replica is wrong because read replicas replicate asynchronously and exist to offload read traffic, not to provide automatic failover, and placing one in the same Availability Zone as the primary would not protect against an AZ-level outage anyway. The option describing promoting a read replica to standalone is wrong because promotion is a manual, one-way operation that breaks the replication relationship permanently; it cannot be used for automatic, transparent failover. The option describing RDS Proxy with a single endpoint is wrong because RDS Proxy manages connection pooling and can shorten failover time for a database that already has a failover target, but it does not itself create a standby or provide failover capability.

Source: AWS RDS documentation: Multi-AZ deployments

Correct answer: .

DynamoDB spreads a table's data and throughput across partitions based on the partition key's hash value, so a partition key with only a handful of distinct values funnels the overwhelming majority of read and write activity onto just a few physical partitions no matter how much total throughput is provisioned for the table, producing throttling on those hot partitions well before the table-wide capacity is exhausted; the fix is to choose a higher-cardinality key, such as a device ID, or add a randomizing suffix. The option about a missing GSI is wrong because a secondary index changes query flexibility, not the base table's write distribution, and would not by itself cause primary-table write throttling. The option about DynamoDB Streams is wrong because enabling Streams only captures a change log asynchronously and does not consume the table's provisioned read or write capacity. The option about the item size limit is wrong because exceeding that limit produces an explicit validation error on the offending write, not intermittent throttling across the table.

Source: AWS DynamoDB documentation: partition key design and hot partitions

Correct answer: .

RDS automated backups combine daily snapshots with continuously archived transaction logs, and as long as a timestamp falls within the retention window, point-in-time recovery can replay those logs up to the exact second requested; the result is always delivered as a new DB instance, since RDS never overwrites an existing instance in place. The option describing manually replaying transactions after restoring a snapshot is wrong because that duplicates work RDS already automates through point-in-time recovery and risks human error in reconstructing the exact state. The option describing a reboot with a restore flag is wrong because rebooting an RDS instance only restarts the database engine process; there is no such restore option on a reboot action. The option describing promoting a Multi-AZ standby is wrong because the standby is a continuously synchronized live replica of the current primary, not a historical snapshot, so promoting it would preserve the bad deployment's changes rather than undo them.

Source: AWS RDS documentation: backing up and restoring an RDS DB instance (point-in-time recovery)

Correct answer: .

DynamoDB global tables let a single table have replicas in multiple AWS regions, and every replica is multi-active, meaning applications can read and write to whichever regional replica is closest to them; writes propagate to the other regions asynchronously, typically within about a second, with conflicting concurrent writes to the same item resolved by a last-writer-wins rule based on the write's internal timestamp. The option describing RDS cross-region read replicas is wrong because that is a relational-database feature entirely separate from DynamoDB, and RDS read replicas only accept reads, not writes, in the secondary region. The option describing Global Accelerator is wrong because it only optimizes network routing to a single regional endpoint; it does not create or synchronize additional copies of table data. The option describing DAX is wrong because DAX is an in-memory read-through/write-through cache in front of a single region's table, not a mechanism for replicating table data across regions.

Source: AWS DynamoDB documentation: global tables (multi-active, multi-Region replication)

Correct answer: .

RDS Proxy sits between an application and the database, maintaining a warm pool of established database connections and multiplexing many short-lived client connections, such as those opened by frequently invoked Lambda functions, onto that pool, which directly solves connection exhaustion caused by high-concurrency, short-lived connection patterns without requiring any change to how the application code opens connections. The option about increasing Lambda memory is wrong because Lambda memory allocation affects CPU and execution speed, not the number of concurrent database connections the function pattern generates. The option about switching to DynamoDB is wrong because it would require redesigning the application's data model and queries around a non-relational engine, which the question explicitly rules out. The option about RDS storage autoscaling is wrong because that feature only manages disk space growth for the database's allocated storage and has no effect on the number of connections the database can accept.

Source: AWS RDS documentation: Amazon RDS Proxy

Correct answer: .

On-demand capacity mode charges per read and write request rather than for pre-allocated throughput, and DynamoDB automatically accommodates traffic increases without the customer setting or adjusting any read or write capacity units, making it well suited to workloads with sudden, hard-to-predict spikes like a viral event. The option describing provisioned capacity with no auto scaling is wrong because a fixed provisioned throughput number would throttle requests the moment traffic exceeds it, which is exactly the risk with unpredictable spikes. The option describing provisioned capacity fixed at the account maximum is wrong because permanently reserving the account's maximum throughput would be extremely wasteful and costly during normal, low-traffic periods, and DynamoDB capacity is not something reserved at the account level this way. The option describing a one-year reserved capacity purchase is wrong because reserved capacity commitments are a cost-optimization tool for steady, predictable baseline usage, which is the opposite of the described spiky, unpredictable workload.

Source: AWS DynamoDB documentation: read/write capacity modes

Correct answer: .

RDS storage autoscaling monitors free storage space and, once it drops to roughly 10 percent or less of allocated storage for a sustained period, automatically increases the allocated storage in the background, online, up to a maximum threshold the administrator configures, requiring no downtime or manual action. The option describing Multi-AZ is wrong because Multi-AZ addresses availability and failover through a synchronized standby; it has no bearing on how much storage is allocated to the instance. The option describing a larger DB instance class is wrong because instance class governs compute resources such as vCPU and memory, not the storage volume attached to the database, and resizing the instance class does not add storage. The option describing a manually triggered CloudWatch alarm is wrong because that describes a custom, human-built automation the team would have to design and maintain themselves, which is precisely the manual intervention the built-in storage autoscaling feature is meant to eliminate.

Source: AWS RDS documentation: managing capacity automatically with Amazon RDS storage autoscaling

Correct answer: .

Local secondary indexes are the only DynamoDB index type that can be read with strong consistency, but they share the base table's partition key and, critically, must be specified when the table is created; DynamoDB provides no way to add a local secondary index to a table that already exists, so a one-year-old production table can never gain one no matter how the requirement is phrased. Global secondary indexes can be added at any time and are useful for different partition or sort key combinations, but they only ever support eventually consistent reads, so they cannot satisfy the strong-consistency requirement even though they can be added later. The option describing a global secondary index because it supports strong consistency is wrong on the facts: global secondary indexes never support strongly consistent reads, only local secondary indexes do. The option describing a local secondary index created before any items are written is wrong because the constraint is about table creation time, not about whether items already exist; even an empty table cannot have a local secondary index added after its initial creation. The option describing a global secondary index because it can be added later with separate throughput is accurate about its mechanics but still wrong for this scenario because it ignores the explicit strong-consistency requirement.

Source: AWS DynamoDB documentation: general guidelines for secondary indexes (global vs. local)

Correct answer: .

Aurora Global Database replicates data to secondary regions at the storage layer rather than through the database engine's logical replication, which is why it achieves typical replication lag of about one second and supports a managed planned failover that promotes a secondary region to primary in roughly a minute, purpose-built for cross-region disaster recovery with a tight recovery point objective. The option describing standard binlog-based replication is wrong because logical, engine-level replication, the mechanism an ordinary cross-region read replica would use, is slower and less predictable than storage-layer replication, and Aurora Global Database specifically avoids it for this reason. The option describing Multi-AZ across two regions is wrong because Multi-AZ standbys are, by design, confined to a single region's Availability Zones for synchronous replication; Multi-AZ is not a mechanism that operates across regions at all. The option describing Aurora Serverless v2 at zero minimum capacity is wrong because Serverless v2 is a compute-scaling feature for a single database, entirely unrelated to cross-region replication or disaster recovery failover.

Source: AWS Aurora documentation: Aurora Global Database disaster recovery

Correct answer: .

DynamoDB Streams captures a time-ordered, near-real-time log of item-level changes, including inserts, updates, and deletes, and can invoke a Lambda function automatically for each batch of stream records, which is the standard event-driven pattern for reacting to writes without polling; stream records are retained for 24 hours and are subject to trimming after that, matching the acceptance that very old unprocessed changes can become unavailable. The option describing a scheduled EventBridge query is wrong because polling on an interval is exactly the pattern the requirement rules out, and it introduces both latency and unnecessary read costs. The option describing RDS event notifications is wrong because RDS event notifications report operational events about a relational database instance, such as failovers or backups, not item-level data changes in a DynamoDB table, which is a separate service entirely. The option describing subscribing to a global secondary index via SNS is wrong because secondary indexes are a query mechanism for existing data and have no built-in mechanism to publish change notifications to SNS.

Source: AWS DynamoDB documentation: change data capture with DynamoDB Streams

Correct answer: .

Option groups in RDS are specifically for enabling optional features that are not part of the core database engine installation, such as SQL Server's native backup and restore, the Oracle Application Express add-on, or the MySQL audit plugin, so an option group is the correct construct for the SQL Server scenario described. The option describing a DB subnet group is wrong because subnet groups define which VPC subnets an RDS instance can be placed in for networking purposes and have nothing to do with enabling database engine features. The option describing a parameter group is wrong because parameter groups control the database engine's runtime configuration values, such as memory-related or logging settings, rather than turning on optional add-on capabilities. The option describing a read replica is wrong because a read replica is an entirely separate database instance used for read scaling or disaster recovery, not a mechanism for enabling features on an existing instance.

Source: AWS RDS documentation: working with option groups and parameter groups

Correct answer: .

Optimistic locking in DynamoDB works by storing a version number on each item and having every update include a ConditionExpression that the current version still equals the value the process originally read; if another process updated the item in between, the version will have changed and DynamoDB rejects the second write with a conditional check failure instead of silently applying it, letting the application detect the conflict and retry with fresh data. The option describing DynamoDB Streams is wrong because Streams only reports changes after they have already been committed; it cannot prevent a write from happening and does not stop a silent overwrite. The option describing a global secondary index is wrong because writing to different indexes does not change the fact that both processes are updating the same base-table item, and indexes are a query mechanism, not a concurrency-control mechanism. The option describing increased write capacity is wrong because provisioned throughput only affects whether requests get throttled for capacity reasons; it does nothing to detect or prevent one process's write from overwriting another's uncommitted assumptions about the item's prior state.

Source: AWS DynamoDB documentation: optimistic locking with a version number

Correct answer: .

RDS snapshots, whether automated or manual, live in the same AWS region as the source DB instance by default, and the supported way to get a durable copy in another region is to explicitly copy the snapshot, which produces an independent snapshot in the destination region that can restore a new DB instance there if the primary region becomes unavailable. The option describing Multi-AZ is wrong because Multi-AZ standbys are confined to Availability Zones within the same region for synchronous replication; the feature has no cross-region component and does not touch snapshot storage at all. The option describing default automated backup behavior is wrong because automated backups do not automatically leave their source region; without an explicit copy action, no cross-region copy exists. The option describing converting to Aurora is wrong because standard RDS engines, including MySQL, PostgreSQL, MariaDB, SQL Server, and Oracle, all support manual cross-region snapshot copying; this capability is not exclusive to Aurora.

Source: AWS RDS documentation: copying a DB snapshot

Correct answer: .

Relational engines like those behind Amazon RDS are built around SQL, normalized schemas, and a query optimizer capable of executing arbitrary joins and aggregations across tables, which is exactly what ad hoc, evolving reporting queries with joins and group-by aggregation require; DynamoDB, by contrast, requires access patterns to be designed in advance around specific partition and sort keys and does not support general-purpose joins. The option favoring DynamoDB for write scaling is wrong because the question is about flexible ad hoc querying, not raw write throughput, and superior write scaling does not help a workload that needs SQL joins. The option describing global secondary indexes as a substitute for joins is wrong because they only support querying an item collection by an alternate key, not combining rows from two different tables the way a relational join does, so they cannot generally replace SQL joins for arbitrary reporting needs. The option requiring DAX is wrong because DAX is a caching layer for DynamoDB reads and is unrelated to RDS; it is not a prerequisite for RDS supporting SQL joins, which it already does natively.

Source: AWS documentation: choosing between DynamoDB and relational databases (RDS)

Correct answer: .

RDS read replicas are created from a snapshot of the source instance and kept current through the DB engine's own asynchronous replication, and applications can connect to them directly for read-only queries, which offloads reporting traffic without touching the primary's write path or its HA setup. The option describing a Multi-AZ standby is wrong because a standby instance exists purely for synchronous failover and cannot serve read traffic at all; it sits idle from an application's perspective until a failover promotes it. The option describing a second Multi-AZ deployment pointed at the same storage volume is wrong because Multi-AZ deployments don't share storage across separate deployments in this way, and stacking deployments doesn't create a queryable read target. The option describing AWS Database Migration Service is wrong because DMS is designed for migrating or continuously replicating data between different database instances or engines, not as an application-facing, ongoing read-scaling mechanism built into the source engine.

Source: AWS RDS documentation: Working with DB instance read replicas

Correct answer: .

Redis is the ElastiCache engine that supports sorted-set data structures, which are the natural fit for ranked leaderboard entries, along with disk-based snapshots for persistence across a reboot and native primary-replica replication that provides an automatic failover target, matching every requirement stated. The option praising Memcached's multi-threading is wrong because that architectural advantage doesn't compensate for the fact that Memcached has no sorted-set data structure and no persistence at all, so leaderboard ranking and surviving a reboot are simply not possible on that engine regardless of thread count. The option describing Memcached automatic node recovery is wrong because Memcached has no built-in replication or failover mechanism whatsoever; its nodes operate independently, and a failed node's cached data is lost rather than taken over by a replica. The option describing a single Redis node with no replicas is wrong because a node with no replicas has nothing to fail over to; on-disk snapshots help with data persistence and recovery but do not substitute for replica-based automatic failover to another running node.

Source: AWS ElastiCache documentation: Redis OSS versus Memcached comparison

Correct answer: .

DAX is a DynamoDB-compatible in-memory cache that requires only minimal application changes because it is API-compatible with DynamoDB, and it reduces eventually consistent read response times from single-digit milliseconds to microseconds, though it does not serve strongly consistent reads out of its cache. The option describing ElastiCache for Redis is wrong because Redis is a separate caching product with its own distinct client API, not compatible with DynamoDB SDK calls, so introducing it in front of DynamoDB would require rewriting the application's data-access code rather than dropping in a compatible client. The option describing raising provisioned read capacity units is wrong because additional RCUs increase how much concurrent read throughput a table can sustain, not the fundamental single-digit-millisecond latency floor of a direct DynamoDB read. The option describing point-in-time recovery is wrong because PITR is a continuous-backup and restore feature for recovering data to earlier points in time, and has no relationship to caching or read latency at all.

Source: AWS DynamoDB documentation: In-memory acceleration with DynamoDB Accelerator (DAX)

Correct answer: .

Time to Live works by reading a designated attribute that must be a Number storing the expiration time in Unix epoch seconds, and once that time has passed, DynamoDB's own background process deletes the item automatically, typically within a few days, without consuming any write capacity for the deletion, exactly matching the stated requirements. The option describing Streams triggering a Lambda deletion is wrong because that approach requires custom code to inspect items and issue deletes, and each of those application-driven deletes does consume write capacity, unlike TTL's built-in background process. The option describing a GSI with a scheduled Scan is wrong because it still requires the application to run and pay for a recurring scan-and-delete job, which is exactly the scheduled maintenance work the team wants to avoid. The option describing daily on-demand backups is wrong because backups create full point-in-time snapshots for recovery purposes; restoring non-expired items into a new table each day does not delete anything from the live table and is not an expiration mechanism at all.

Source: AWS DynamoDB documentation: Using Time to Live (TTL) in DynamoDB

Correct answer: .

TransactWriteItems groups multiple actions into a single all-or-nothing operation with full ACID guarantees, so either both the stock decrement and the order creation succeed or neither does, and DynamoDB performs two underlying writes per item, one to prepare and one to commit, which is why the effective write capacity consumed is roughly double that of the same writes done non-transactionally. The option describing BatchWriteItem is wrong because it explicitly does not guarantee all-or-nothing behavior; individual actions within a batch can succeed or fail independently of one another, which is the opposite of what an atomic inventory-and-order update needs. The option describing Streams plus a Lambda rollback is wrong because that is an eventually consistent, custom-built compensating action rather than a true atomic guarantee, leaving a window where a partially completed state is visible to other readers before the rollback runs. The option describing global tables is wrong because they replicate already-committed writes across regions for availability and low-latency access; they provide no mechanism for grouping multiple actions into one atomic, all-or-nothing unit within a single write.

Source: AWS DynamoDB documentation: DynamoDB Transactions - how it works (capacity management for transactions)

Correct answer: .

Amazon Redshift is a petabyte-scale, fully managed data warehouse that stores data in a columnar format and distributes query execution across many nodes through massively parallel processing, an architecture purpose-built for scanning and aggregating enormous datasets efficiently, which is exactly the quarterly-reporting workload described. The option describing RDS for PostgreSQL is wrong because its row-based storage engine is tuned for transactional, record-at-a-time access rather than the wide columnar scans that large-scale aggregation across many rows and few columns benefits from. The option describing DynamoDB is wrong because DynamoDB is optimized for fast key-based item retrieval, not for scanning and aggregating across an entire dataset, and it has no native SQL aggregation engine suited to historical, multi-billion-row analysis. The option describing Aurora Serverless v2 is wrong because it only automates compute scaling for a standard relational, OLTP-oriented engine; it does not add the columnar storage or parallel-processing architecture that makes large-scale analytical aggregation fast.

Source: AWS Redshift documentation: What is Amazon Redshift? (Redshift Management Guide)

Correct answer: .

Aurora Serverless v2 measures capacity in Aurora Capacity Units and scales a writer or reader within its configured minimum and maximum range in increments as small as 0.5 ACUs, with scaling designed to happen without dropping database connections during most scaling operations, which fits an idle-then-spiky flash-sale workload without any manual resizing. The option describing a provisioned cluster with auto scaling on the instance class is wrong because changing a DB instance class is a modification that is not instantaneous and typically involves the instance restarting to apply the new class, which is not the seconds-level, connection-preserving scaling the team needs. The option describing a fixed ACU value pinned to peak capacity is wrong because it removes the actual benefit of serverless scaling, leaving the cluster paying for peak-level capacity even during the long idle periods between sales. The option describing RDS Proxy is wrong because a proxy pools and manages client connections to reduce connection overhead; it does not add or change the underlying compute capacity, so it cannot absorb a genuinely compute-bound load spike.

Source: AWS Aurora documentation: How Aurora serverless works (Aurora Serverless v2 capacity and scaling)

Correct answer: .

Converting the schema first with the Schema Conversion Tool (or DMS Schema Conversion) handles the Oracle-to-PostgreSQL dialect differences before any data moves, and then AWS DMS performs the full load and switches into change data capture so that ongoing source changes keep replicating to the target throughout the many-hour copy, letting the team apply the last few minutes of changes and cut over with minimal downtime. The option describing DMS alone with automatic schema conversion is wrong because a plain DMS full load moves data between already-compatible schemas; it does not convert one engine's schema and dialect into another's, and without CDC the source would need to stay frozen for the entire multi-hour copy rather than just a few minutes. The option describing AWS Backup snapshots is wrong because backup snapshots are specific to their source engine's storage format, and a snapshot taken from a self-managed on-premises Oracle database cannot be restored directly into an Aurora PostgreSQL cluster running a different engine. The option describing DMS Fleet Advisor is wrong because Fleet Advisor is a discovery and inventory tool that analyzes on-premises servers to help plan a migration; it does not itself convert schemas, perform full loads, or run CDC replication.

Source: AWS DMS documentation: What is AWS Database Migration Service? (Schema Conversion and CDC replication)

Correct answer: .

Point-in-time recovery must be explicitly enabled per table, after which DynamoDB continuously backs up the table for a fixed 35-day retention window and lets the team choose any second within that window to restore, always creating a new table since PITR restores are never applied in place over the live table. The option describing DynamoDB Streams is wrong because Streams retains only a short rolling window of change records, on the order of 24 hours, intended for near-real-time processing such as triggering a Lambda function, not for reconstructing state weeks in the past. The option describing manual hourly on-demand backups is wrong because it would only allow restoring to the top of an hour rather than any specific second, and, like PITR, an on-demand backup restore also produces a new table rather than rolling back the existing one in place. The option describing global tables is wrong because replica tables in other regions hold the current, replicated state of items for availability and low-latency access, not a retained history of past item versions that can be queried for an arbitrary earlier point in time.

Source: AWS DynamoDB documentation: Point-in-time recovery (PITR) for DynamoDB

Correct answer: .

Amazon Neptune is a purpose-built graph database engine that indexes relationships directly and supports the property-graph query languages Gremlin and openCypher, letting it traverse highly connected data such as multi-hop friend networks with millisecond latency, which is exactly the recommendation query pattern described. The option describing DynamoDB with a global secondary index is wrong because a GSI supports efficient single-hop key-based lookups, but a multi-hop traversal like friends of friends would require the application to issue repeated round-trips and manually stitch the results together, which does not scale the way a native graph engine's relationship index does. The option describing Redshift is wrong because its columnar storage and massively parallel processing are tuned for scanning and aggregating large flat or star-schema datasets, not for recursively walking a graph of relationships hop by hop, which is a fundamentally different access pattern from analytical aggregation. The option describing Aurora PostgreSQL with recursive CTEs is wrong because although Aurora PostgreSQL can technically express a hop-by-hop traversal this way, performance degrades sharply as the relationship graph deepens since each hop requires another self-join over the full connections table, unlike a graph engine whose storage and indexes are built specifically for that traversal pattern.

Source: AWS Neptune documentation: What Is Amazon Neptune?