CCNA Db Design Questions — Page 6 of 6

376

Multi-Selecteasy

Which TWO design patterns are commonly used to handle hot partitions in Amazon DynamoDB? (Choose 2.)

Select 2 answers

A.Write sharding

B.Decreasing write capacity units

C.Using a single partition key

D.Increasing read capacity units

E.Adding random suffixes to partition keys

AnswersA, E

Distributes writes across many partition key values.

Why this answer

Write sharding distributes writes across multiple partition keys to prevent a single partition from exceeding the 1,000 WCU limit. Adding random suffixes to partition keys is a specific write sharding technique that spreads writes across many partitions, avoiding hot spots.

Exam trap

AWS often tests the misconception that increasing capacity units alone resolves hot partitions, but the real solution requires redistributing the workload across partitions via sharding or suffix-based strategies.

Practice this question →

377

MCQhard

An e-commerce platform uses Amazon DynamoDB for a shopping cart table with partition key 'user_id' and sort key 'product_id'. The table experiences throttled write requests during flash sales. The access pattern includes reading the entire cart at checkout. Which design change would improve write performance without changing the read pattern?

A.Enable DynamoDB Accelerator (DAX) to cache writes

B.Increase the provisioned write capacity units (WCU) to a higher value

C.Change the table design to use only partition key 'user_id' and remove the sort key

D.Enable DynamoDB Adaptive Capacity and ensure the table uses on-demand capacity mode

AnswerD

Adaptive capacity helps distribute traffic across partitions, and on-demand mode handles spikes.

Why this answer

Enabling DynamoDB Adaptive Capacity with on-demand capacity mode automatically scales write capacity to handle traffic spikes during flash sales without requiring manual provisioning. This eliminates throttling while preserving the existing table schema (partition key 'user_id' and sort key 'product_id'), so the read pattern of querying the entire cart by user_id remains unchanged.

Exam trap

The trap here is that candidates often confuse DAX as a write accelerator or assume that simply increasing provisioned capacity is sufficient, overlooking that on-demand mode with adaptive capacity is the correct solution for unpredictable traffic spikes without schema changes.

How to eliminate wrong answers

Option A is wrong because DAX is an in-memory cache that accelerates reads, not writes; it cannot improve write performance or reduce write throttling. Option B is wrong because increasing provisioned WCU only helps if the traffic pattern is predictable; during flash sales, traffic spikes can still exceed the new provisioned limit, leading to continued throttling unless capacity is over-provisioned. Option C is wrong because removing the sort key 'product_id' would break the ability to store multiple products per user in the cart, fundamentally altering the data model and potentially causing data loss or overwrites.

Practice this question →

378

Multi-Selectmedium

Which TWO factors should you consider when choosing between Amazon RDS and Amazon DynamoDB for a new application?

Select 2 answers

A.RDS requires a predefined schema, while DynamoDB is schema-less.

B.DynamoDB can only be accessed from within a VPC, while RDS can be public.

C.Only RDS supports Multi-AZ deployments for high availability.

D.Both services support encryption at rest and in transit.

E.DynamoDB is better suited for unstructured data, while RDS is better for structured data with complex relationships.

AnswersA, E

This is a key difference that affects application design.

Why this answer

Amazon RDS (relational database service) requires a predefined schema with tables, columns, and data types before data can be inserted, enforcing ACID compliance and referential integrity. In contrast, Amazon DynamoDB is a NoSQL key-value and document database that is schema-less, allowing you to store items with varying attributes without upfront schema definition, which is ideal for agile development and unstructured data.

Exam trap

The trap here is that candidates often assume DynamoDB cannot be accessed publicly or that only RDS supports Multi-AZ, but in reality both services offer these features, and the key differentiator is the data model (schema vs. schema-less) and the nature of the data (structured with relationships vs. unstructured).

Practice this question →

379

MCQeasy

A startup is building a social media application with a news feed feature. The feed must be personalized and updated in real-time as users post. Which AWS database service is best suited for this workload?

A.Amazon DynamoDB with Global Secondary Indexes

B.Amazon S3 with Select and Glacier

C.Amazon RDS for PostgreSQL with read replicas

D.Amazon ElastiCache for Redis with sorted sets and pub/sub

AnswerD

Redis provides real-time data structures and pub/sub for feeds.

Why this answer

Amazon ElastiCache for Redis is the best choice because it provides in-memory data structures like sorted sets for ranking and scoring personalized feeds, and pub/sub for real-time notifications when new posts are published. This combination enables low-latency, real-time feed updates without the overhead of disk-based storage, making it ideal for a social media news feed that must be both personalized and updated in real-time.

Exam trap

The trap here is that candidates often choose DynamoDB or RDS because they are familiar with them for data storage, but they overlook the need for real-time, in-memory operations and the specific data structures (sorted sets, pub/sub) that only ElastiCache for Redis provides for this workload.

How to eliminate wrong answers

Option A is wrong because DynamoDB with Global Secondary Indexes is a NoSQL database optimized for key-value and document workloads, but it lacks native pub/sub and sorted set capabilities required for real-time feed personalization and push updates. Option B is wrong because S3 is an object storage service designed for static data archiving and retrieval, not for low-latency, real-time read/write operations; S3 Select and Glacier are for querying and cold storage, respectively, and cannot support live feed updates. Option C is wrong because RDS for PostgreSQL with read replicas is a relational database that can handle complex queries but introduces higher latency for real-time updates and lacks built-in sorted sets and pub/sub, making it unsuitable for high-throughput, low-latency feed personalization.

Practice this question →

380

MCQhard

A company uses Amazon DynamoDB as the primary database for a global gaming application. The application requires single-digit millisecond latency for user profile lookups by user ID. However, some queries need to retrieve all active users in a region (e.g., 'us-east-1') for administrative dashboards, and these queries currently perform full table scans, causing high costs and throttling. What design approach should be taken to optimize this?

A.Implement DynamoDB Accelerator (DAX) to cache the dashboard queries.

B.Increase the read capacity units (RCUs) on the base table.

C.Create a global secondary index (GSI) on the region attribute.

D.Create a local secondary index (LSI) on the region attribute.

AnswerC

A GSI allows efficient querying on region without scanning the base table, reducing cost and throttling.

Why this answer

Creating a Global Secondary Index (GSI) on the 'region' attribute allows the administrative dashboard queries to retrieve all active users in a specific region using an efficient index scan instead of a full table scan. This reduces read capacity consumption, avoids throttling, and maintains single-digit millisecond latency for the indexed queries, while the base table remains optimized for user ID lookups.

Exam trap

The trap here is that candidates often confuse LSIs with GSIs, assuming an LSI can be used to query by a non-key attribute like region, but LSIs are limited to the same partition key as the base table and cannot avoid a full scan when the query predicate is on a different partition key.

How to eliminate wrong answers

Option A is wrong because DynamoDB Accelerator (DAX) is an in-memory cache that accelerates reads on the base table or existing indexes, but it does not eliminate the need for a full table scan when querying by region; it would only cache the results of expensive scans, not prevent them. Option B is wrong because increasing read capacity units (RCUs) on the base table would temporarily reduce throttling but does not address the root cause—full table scans are inherently inefficient and costly at scale, and higher RCUs only mask the problem while increasing costs. Option D is wrong because a Local Secondary Index (LSI) can only be created at table creation time and shares the same partition key as the base table; since the base table's partition key is user ID (not region), an LSI on region would still require a full scan across all partitions to retrieve all users in a region, providing no performance benefit.

Practice this question →

381

MCQhard

A company uses Amazon DynamoDB for a gaming leaderboard. The application updates scores frequently. Reads must be strongly consistent, and writes must be optimized for cost. Which table design minimizes cost while meeting consistency requirements?

A.Use Amazon DynamoDB Accelerator (DAX) for caching.

B.Use eventually consistent reads with a conditional write.

C.Store scores in Amazon S3 and use S3 Select for reads.

D.Use DynamoDB Streams to replicate reads to a separate table.

AnswerA

DAX provides in-memory caching with strong consistency, reducing RCU cost.

Why this answer

Amazon DynamoDB Accelerator (DAX) provides an in-memory cache that supports strongly consistent reads, which meets the application's requirement for strongly consistent reads. By caching frequently accessed leaderboard data, DAX reduces the number of read capacity units consumed from the DynamoDB table, thereby lowering read costs. Writes are still performed directly on the DynamoDB table, and DAX does not affect write costs, so the design optimizes overall cost while maintaining consistency.

Exam trap

The trap here is that candidates may assume that eventually consistent reads are sufficient for a leaderboard, or that caching with DAX is only for performance and not for cost optimization, but the question explicitly requires strongly consistent reads and cost minimization, making DAX the correct choice.

How to eliminate wrong answers

Option B is wrong because eventually consistent reads do not meet the requirement for strongly consistent reads, and conditional writes are used for optimistic locking, not for consistency or cost optimization. Option C is wrong because storing scores in Amazon S3 and using S3 Select for reads introduces significant latency and does not support the low-latency, high-frequency updates required for a gaming leaderboard; S3 is not designed for real-time strongly consistent reads. Option D is wrong because using DynamoDB Streams to replicate reads to a separate table adds complexity, latency, and additional storage costs without providing strongly consistent reads from the replica; DynamoDB Streams is for change data capture, not for read consistency.

Practice this question →

382

Multi-Selecthard

A company is designing a document database on Amazon DocumentDB for a content management system. Which TWO design practices improve query performance and reduce costs?

Select 1 answer

A.Shard data based on access patterns to distribute load.

B.Design documents to avoid joins by frequently using $lookup.

C.Avoid denormalization to maintain strict normal forms.

D.Store all documents in a single collection without indexes to reduce overhead.

E.Use appropriate indexes to support common query patterns.

AnswersE

Correct: Using appropriate indexes minimizes the amount of data scanned, speeding up queries and reducing I/O costs.

Why this answer

In Amazon DocumentDB, only Option E (Use appropriate indexes to support common query patterns) is correct. Sharding (Option A) is not supported by DocumentDB. Options B, C, and D are incorrect because they would degrade performance or increase costs.

Note: The question asks for two, but only one option is correct.

Exam trap

Candidates often think DocumentDB supports native sharding like MongoDB. In reality, Amazon DocumentDB does not support sharding. Proper indexing is the primary performance optimization for DocumentDB.

Practice this question →

383

MCQhard

A company uses Amazon DynamoDB for a real-time analytics platform. The table has a partition key of 'customer_id' and a sort key of 'event_timestamp'. The table receives 50,000 write requests per second, evenly distributed across 10,000 customers. The application frequently queries the last 10 events for a given customer. The company notices that some queries are throttled during peak hours. The table's write capacity is set to 50,000 WCUs, and read capacity to 10,000 RCUs. The throttled queries are read requests. What is the most likely cause of the throttling, and what should be done to resolve it?

A.Increase the write capacity units to handle the write load.

B.Increase the read capacity units to 20,000 RCUs.

C.Optimize the query by using Query with KeyConditionExpression on the sort key and Limit=10.

D.Add a global secondary index with the same keys to distribute read load.

AnswerC

This ensures the query reads only the necessary items, reducing RCU consumption.

Why this answer

The throttling occurs because the application uses Scan or an inefficient query pattern that consumes excessive read capacity. Using Query with KeyConditionExpression on the sort key and Limit=10 retrieves only the last 10 events per customer efficiently, reducing read consumption and avoiding throttling without increasing RCUs.

Exam trap

The DBS-C01 exam often tests the misconception that throttling always requires increasing capacity, when in fact optimizing the access pattern with Query and Limit can resolve the issue without additional cost.

How to eliminate wrong answers

Option A is wrong because the issue is read throttling, not write throttling, and write capacity is already sufficient at 50,000 WCUs. Option B is wrong because increasing RCUs to 20,000 would mask the inefficiency without addressing the root cause—poor query design that consumes more capacity than necessary. Option D is wrong because adding a GSI with the same keys would not distribute read load differently; the base table already has the required keys, and a GSI would not improve query efficiency for this access pattern.

Practice this question →

384

MCQhard

Refer to the exhibit. A database specialist is troubleshooting an issue where an application cannot connect to an RDS for MySQL instance using IAM database authentication. The application uses the database user 'db_user1'. The IAM policy shown is attached to the IAM role used by the application. What is the most likely reason for the connection failure?

A.The action 'rds-db:connect' is not allowed for RDS MySQL.

B.The policy should have 'Deny' effect instead of 'Allow'.

C.The resource ARN in the policy uses an incorrect RDS resource ID.

D.The database user name in the ARN must be 'admin', not 'db_user1'.

AnswerC

The RDS resource ID must be exactly 14 alphanumeric characters. The example has 18.

Why this answer

IAM database authentication for RDS MySQL requires the resource ARN in the IAM policy to include the correct RDS resource ID (the 'db-xxxxx' identifier from the RDS console), not the DB instance name or endpoint. If the ARN uses an incorrect resource ID, the policy will not match the target RDS instance, causing the authentication to fail even if the user name and action are correct.

Exam trap

The trap here is that candidates often confuse the DB instance name or endpoint with the RDS resource ID, or assume the database user must be 'admin' for IAM authentication, when in fact the resource ID is a separate identifier and the user name must match the database user exactly.

How to eliminate wrong answers

Option A is wrong because the 'rds-db:connect' action is specifically allowed for RDS MySQL when using IAM database authentication; it is the required action for connecting. Option B is wrong because a 'Deny' effect would explicitly block the connection, whereas the goal is to allow it; the 'Allow' effect is correct for granting access. Option D is wrong because the database user name in the ARN must match the actual database user (here 'db_user1'), not 'admin'; the ARN format includes the database user name as it exists in the MySQL instance.

Practice this question →

385

MCQhard

An IAM policy is attached to an application role that accesses a DynamoDB table named 'Orders'. The table has a global secondary index named 'OrderDateIndex'. The application needs to write new orders and query the index. Based on the exhibit, will the application be able to perform these operations?

A.Yes, but only writes are allowed; index queries are denied.

B.Yes, the policy allows both writes and querying the index.

C.No, the policy does not grant access to the index.

D.No, the policy denies Query on the index.

AnswerB

PutItem allowed on table, Query allowed on index.

Why this answer

The IAM policy grants `dynamodb:PutItem` on the table and `dynamodb:Query` on the index. Since the policy explicitly allows both actions on their respective ARNs, the application can write new orders to the 'Orders' table and query the 'OrderDateIndex' global secondary index. Option B is correct because the policy covers both required operations.

Exam trap

The trap here is that candidates assume a policy allowing actions on a table automatically extends to its global secondary indexes, but DynamoDB requires separate ARN entries for index-level operations like Query.

How to eliminate wrong answers

Option A is wrong because the policy explicitly allows `dynamodb:Query` on the index ARN, so index queries are not denied. Option C is wrong because the policy grants `dynamodb:Query` on the index ARN, providing explicit access to the index. Option D is wrong because the policy does not deny Query on the index; it allows it with an `Effect: Allow` statement.

Practice this question →

386

MCQmedium

A company is designing a new application that requires a relational database with sub-millisecond read latency for a global user base. The workload is read-heavy with occasional writes. Which database solution should they choose?

A.Amazon DynamoDB with DAX

B.Amazon RDS for MySQL with Multi-AZ

C.Amazon Aurora with Auto Scaling

D.Amazon ElastiCache for Redis

AnswerC

Aurora provides low latency (single-digit ms) and is relational; Auto Scaling handles read scaling.

Why this answer

Amazon Aurora with Auto Scaling is the correct choice because it provides a relational database (MySQL/PostgreSQL-compatible) with sub-millisecond read latency via its distributed storage layer and read replicas. The read-heavy workload benefits from Aurora's automatic scaling of read capacity, while occasional writes are efficiently handled by the cluster volume. Aurora's architecture decouples compute and storage, enabling fast failover and consistent performance for global users.

Exam trap

The trap here is that candidates may confuse DynamoDB with DAX (which offers sub-millisecond latency) as a relational database, but DynamoDB is NoSQL and does not support relational features like joins or ACID transactions across multiple tables.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB with DAX is a NoSQL key-value/document database, not a relational database, and while DAX provides microsecond latency for reads, the question explicitly requires a relational database. Option B is wrong because Amazon RDS for MySQL with Multi-AZ provides high availability but does not achieve sub-millisecond read latency; typical RDS read latency is in the single-digit milliseconds, and Multi-AZ is for failover, not read performance. Option D is wrong because Amazon ElastiCache for Redis is an in-memory cache, not a relational database; it can accelerate reads but does not serve as the primary relational database with ACID transactions and SQL querying.

Practice this question →

387

MCQeasy

A startup is building a real-time chat application that requires storing messages with high write throughput and low-latency reads. The data model is simple: each message has a conversation ID, timestamp, and content. Which database design is MOST appropriate?

A.Amazon RDS for MySQL with a single table and indexes on conversation_id and timestamp

B.Amazon Timestream to store messages as time-series data

C.Amazon Redshift with columnar storage and compression

D.Amazon DynamoDB with conversation_id as partition key and timestamp as sort key

AnswerD

This model supports high write throughput and efficient queries by conversation.

Why this answer

Amazon DynamoDB with conversation_id as partition key and timestamp as sort key is the most appropriate design because it directly supports high write throughput and low-latency reads for a real-time chat application. The partition key enables even distribution of writes across partitions, while the sort key allows efficient range queries for messages within a conversation ordered by time, matching the access pattern perfectly.

Exam trap

The trap here is that candidates often choose Amazon RDS for MySQL because they are familiar with relational databases and indexes, but they overlook the fundamental scalability limitations of a single-node RDS instance for high-write workloads, which DynamoDB's distributed architecture solves natively.

How to eliminate wrong answers

Option A is wrong because Amazon RDS for MySQL, while supporting indexes on conversation_id and timestamp, cannot scale to the high write throughput required by a real-time chat application without significant vertical scaling or complex sharding, and it introduces overhead from ACID transactions and locking that are unnecessary for this use case. Option B is wrong because Amazon Timestream is optimized for time-series data with regular intervals and aggregations, not for storing individual chat messages with high write throughput and low-latency point reads; it is designed for IoT and operational metrics, not real-time messaging. Option C is wrong because Amazon Redshift is a columnar data warehouse optimized for complex analytical queries on large datasets, not for high-frequency writes or low-latency point reads; its write performance is poor for transactional workloads, and it is not suitable for a real-time chat application.

Practice this question →

388

Multi-Selectmedium

Which THREE factors should be considered when choosing between Amazon RDS and Amazon DynamoDB for a new application? (Choose 3.)

Select 3 answers

A.Cost of storage

B.Need for encryption at rest

C.Access patterns (predictable vs. ad-hoc)

D.Scalability requirements (horizontal vs. vertical)

E.Query complexity (joins, aggregations)

AnswersC, D, E

DynamoDB suits predictable patterns; RDS for complex queries.

Why this answer

Amazon RDS is a relational database service that excels at complex queries involving joins and aggregations, while DynamoDB is a NoSQL key-value and document database optimized for predictable, high-scale access patterns. The choice between them hinges on whether the application requires relational features (RDS) or can tolerate denormalized schemas for low-latency, horizontal scaling (DynamoDB). Option C is correct because DynamoDB is designed for ad-hoc, single-key lookups and simple queries, whereas RDS supports complex, ad-hoc SQL queries with joins.

Exam trap

The trap here is that candidates often assume encryption at rest is exclusive to one service, but both RDS and DynamoDB support it via AWS KMS, making it a non-differentiating factor.

Practice this question →

389

Multi-Selecteasy

A company uses Amazon RDS for PostgreSQL for its CRM application. The application experiences intermittent spikes in read traffic. Which TWO actions can the company take to improve read scalability with minimal application changes?

Select 2 answers

A.Enable Multi-AZ deployment for automatic failover.

B.Migrate to Amazon Aurora and enable Auto Scaling.

C.Create one or more read replicas in the same region.

D.Upgrade to a larger DB instance class.

E.Enable Amazon RDS Proxy to manage database connections.

AnswersC, E

Read replicas handle read traffic without application changes.

Why this answer

Creating read replicas in Amazon RDS for PostgreSQL offloads read traffic from the primary DB instance, directly addressing intermittent read spikes with minimal application changes. Read replicas are asynchronous replicas that can serve read queries, and the application only needs to update its connection string to point to the replica endpoint for read operations.

Exam trap

The trap here is that candidates often confuse Multi-AZ (which provides failover but no read scaling) with read replicas, or assume that scaling up the instance class is the only way to handle read spikes, ignoring the horizontal scaling benefit of read replicas with minimal application changes.

Practice this question →

390

MCQmedium

A company is investigating a performance issue with an Amazon Aurora MySQL database. The output of the describe-db-instances command is shown. The application experiences intermittent slowdowns during write-heavy periods. Which change would MOST likely improve write performance?

A.Add an Aurora Replica to distribute read traffic and reduce load on the writer

B.Increase the provisioned IOPS to 10000

C.Change StorageType to gp2 and increase AllocatedStorage to 200 GB

D.Set StorageEncrypted to false to reduce encryption overhead

AnswerB

Correct. Increasing provisioned IOPS directly addresses I/O bottlenecks during write-heavy periods, thereby improving write throughput.

Why this answer

Increasing provisioned IOPS directly improves write throughput by reducing I/O latency. In this scenario, write-heavy periods cause intermittent slowdowns, which are often due to hitting the IOPS limit of the current instance configuration. Option A is incorrect because Aurora Replicas only offload reads and have no effect on write performance.

The writer instance still handles all writes regardless of replicas.

Exam trap

The trap is that candidates may assume adding Aurora Replicas helps write performance by reducing load, but replicas only serve reads. Write performance is not improved by offloading reads; it requires addressing I/O capacity directly.

How to eliminate wrong answers

Option A is wrong because Aurora Replicas only offload read traffic and do not reduce write load on the primary instance; write performance is bottlenecked by the writer's CPU, memory, and storage I/O, not by read traffic. Option B is wrong because increasing provisioned IOPS to 10000 may help if the current IOPS are exhausted, but the question does not indicate an IOPS limit issue; the intermittent slowdowns during write-heavy periods suggest a different bottleneck, such as CPU or lock contention. Option C is wrong because changing StorageType to gp2 and increasing AllocatedStorage to 200 GB does not guarantee improved write performance; gp2 has burst credits that can be exhausted, and Aurora uses a shared distributed storage system where storage type and size are managed automatically, not by the user.

Option D is wrong because setting StorageEncrypted to false does not reduce encryption overhead in Aurora; encryption is handled at the storage layer with minimal performance impact, and disabling it would violate security best practices without addressing the write performance issue.

Practice this question →

391

MCQmedium

A company needs to run complex analytical queries on structured data in Amazon S3 without loading data into a database. The queries must execute quickly and support standard SQL. Which service should they use?

A.Amazon QuickSight

B.AWS Glue ETL jobs

C.Amazon Redshift Spectrum

D.Amazon Athena

AnswerD

Serverless, queries S3 directly with SQL.

Why this answer

Amazon Athena is a serverless interactive query service that allows you to run standard SQL directly on data stored in Amazon S3 without loading or transforming it. It uses Presto under the hood and supports complex analytical queries on structured data with fast execution, making it the ideal choice for this use case.

Exam trap

The trap here is that candidates often confuse Amazon Redshift Spectrum with Athena, but Spectrum requires an existing Redshift cluster (provisioned infrastructure), whereas Athena is truly serverless and directly queries S3 without any database setup.

How to eliminate wrong answers

Option A is wrong because Amazon QuickSight is a business intelligence (BI) visualization and dashboarding tool, not a query engine for running complex analytical SQL directly on S3 data. Option B is wrong because AWS Glue ETL jobs are designed for extract, transform, and load (ETL) processes, not for ad-hoc interactive querying; they require defining jobs and incur runtime costs even for simple queries. Option C is wrong because Amazon Redshift Spectrum extends Redshift to query data in S3, but it requires an active Redshift cluster to be provisioned and running, which adds cost and complexity that Athena avoids with its serverless model.

Practice this question →

392

MCQeasy

A company runs an application that requires a relational database with high availability across multiple Availability Zones. The database must automatically failover with minimal downtime. Which AWS service meets these requirements?

A.Amazon RDS for MySQL with Multi-AZ deployment.

B.Amazon DynamoDB with global tables.

C.Amazon Redshift with cross-Region snapshots.

D.Amazon RDS for MySQL with a single instance.

AnswerA

Automatic failover to standby in different AZ.

Why this answer

Amazon RDS for MySQL with Multi-AZ deployment automatically provisions and maintains a synchronous standby replica in a different Availability Zone. If the primary instance fails, Amazon RDS automatically fails over to the standby, typically within 60–120 seconds, providing high availability with minimal downtime. This meets the requirement for a relational database with automatic failover across multiple Availability Zones.

Exam trap

The trap here is that candidates may confuse DynamoDB global tables (multi-Region replication) with Multi-AZ failover, or assume that a single RDS instance with automated backups provides the same availability as Multi-AZ, but automated backups do not provide automatic failover or synchronous replication.

How to eliminate wrong answers

Option B is wrong because Amazon DynamoDB is a NoSQL key-value and document database, not a relational database, and global tables provide multi-Region replication, not the Multi-AZ failover required. Option C is wrong because Amazon Redshift is a data warehouse, not a transactional relational database, and cross-Region snapshots are manual or scheduled backups, not automatic failover. Option D is wrong because a single-instance Amazon RDS for MySQL deployment does not provide Multi-AZ redundancy or automatic failover; it runs in a single Availability Zone and requires manual recovery if the instance fails.

Practice this question →

393

MCQmedium

A company is migrating its on-premises MySQL database to Amazon Aurora MySQL. The current database has a table of 500 GB that is accessed by a nightly batch job that updates 80% of the rows. The company wants to minimize downtime during migration. Which migration strategy is MOST appropriate?

A.Use AWS Database Migration Service (DMS) with Aurora as the target.

B.Create an Aurora read replica from the on-premises database.

C.Export the data to Amazon S3 and load it into Aurora using the LOAD DATA FROM S3 command.

D.Use mysqldump to export the database and import it into Aurora.

AnswerA

DMS allows ongoing replication, minimizing downtime.

Why this answer

AWS DMS supports ongoing replication from an on-premises MySQL source to Amazon Aurora MySQL, allowing the nightly batch job to continue running during the initial full load. After the full load completes, DMS captures incremental changes and applies them to Aurora, enabling a cutover with minimal downtime. This approach is ideal for large tables (500 GB) with high update volumes because it avoids a lengthy offline export/import process.

Exam trap

The trap here is that candidates often assume mysqldump or S3 export are faster for large datasets, but they overlook the need for minimal downtime and the ability to keep the batch job running, which DMS’s CDC capability uniquely addresses.

How to eliminate wrong answers

Option B is wrong because Aurora read replicas can only be created from an existing Aurora cluster, not from an on-premises MySQL database; they are a feature within the Aurora ecosystem, not a migration tool. Option C is wrong because exporting the table to Amazon S3 and using LOAD DATA FROM S3 requires the database to be offline during the export, and the batch job would need to be stopped, causing significant downtime. Option D is wrong because mysqldump performs a logical backup that locks tables or requires a read lock, and importing 500 GB would take hours or days, during which the nightly batch job cannot run, leading to unacceptable downtime.

Practice this question →

394

MCQmedium

A data analyst reports that a nightly ETL job to Amazon Redshift is failing with timeout errors shown in the exhibit. The cluster is a dc2.large with 2 nodes. The ETL job inserts large volumes of data. What is the most likely cause?

A.The cluster has reached the maximum number of connections.

B.The workload manager (WLM) queue timeout is too low.

C.The security group is blocking inbound traffic from the ETL server.

D.The cluster has insufficient disk space for the data load.

AnswerD

dc2 nodes use local SSD; full disk causes write failures.

Why this answer

The dc2.large node type has a fixed storage limit of 160 GB per node (320 GB total for 2 nodes). When an ETL job inserts large volumes of data and the cluster runs out of disk space, Redshift cannot write new rows, causing the load to hang and eventually time out. Insufficient disk space is a common cause of timeout errors during bulk inserts because the database cannot complete the write operations.

Exam trap

The trap here is that candidates often attribute timeout errors to network or WLM configuration issues, overlooking the fact that Redshift's fixed storage per node can be silently exhausted during large data loads, leading to apparent timeouts rather than explicit 'disk full' errors.

How to eliminate wrong answers

Option A is wrong because the maximum number of connections for a dc2.large cluster is 500 per node (1,000 total), and connection limits typically produce 'too many connections' errors, not timeout errors during data load. Option B is wrong because WLM queue timeout controls how long a query waits in a queue before being rejected or queued, not the execution timeout of an ongoing INSERT operation; a low WLM timeout would produce a 'queue timeout' error, not a generic timeout during data insertion. Option C is wrong because security group rules blocking inbound traffic would cause connection failures (e.g., 'connection refused' or 'no route to host'), not timeout errors after the ETL job has already started inserting data.

Practice this question →

395

MCQhard

A company runs a document management system using Amazon DocumentDB (with MongoDB compatibility). The application stores large documents (up to 5 MB each) and frequently fetches them by document ID. The team notices increased latency during peak hours. They need to reduce read latency. Which action is MOST effective?

A.Add read replicas to the cluster

B.Shard the collection across multiple DocumentDB clusters

C.Implement Amazon ElastiCache for Redis in front of DocumentDB

D.Increase the instance class of the primary instance

AnswerA

Read replicas offload read traffic and reduce latency.

Why this answer

Adding read replicas to the DocumentDB cluster is the most effective action because it offloads read traffic from the primary instance, directly reducing read latency during peak hours. DocumentDB supports up to 15 read replicas that are kept in sync via the cluster's replication mechanism, and the application's frequent fetches by document ID are read-heavy operations that benefit from distributing the load across multiple replicas.

Exam trap

AWS often tests the misconception that scaling up the primary instance (Option D) is equivalent to scaling out read capacity, but in DocumentDB, read replicas are the correct solution for read-heavy workloads because they provide horizontal read scaling without overloading the primary.

How to eliminate wrong answers

Option B is wrong because sharding across multiple DocumentDB clusters is not a native feature of DocumentDB; DocumentDB does not support horizontal sharding like MongoDB, and managing multiple clusters manually would introduce complexity without reducing read latency for individual document fetches. Option C is wrong because implementing Amazon ElastiCache for Redis in front of DocumentDB adds an additional caching layer that, while potentially beneficial for repeated queries, introduces cache management overhead and does not address the root cause of increased latency during peak hours for direct document ID lookups. Option D is wrong because increasing the instance class of the primary instance only scales the compute and memory resources of a single node, which does not distribute the read load and may still result in latency under high concurrent read traffic.

Practice this question →

396

MCQmedium

A company uses Amazon RDS for Oracle for an OLTP application. The database experiences high CPU utilization during peak hours. The application is read-heavy and can tolerate eventually consistent reads. Which solution reduces CPU load on the primary database with minimal application changes?

A.Implement Amazon ElastiCache to cache frequent queries

B.Upgrade to a larger instance type

C.Create an RDS read replica and direct read traffic to it

D.Use DynamoDB Accelerator (DAX) as a cache layer

AnswerC

Read replicas offload read traffic from the primary, reducing CPU load with minimal application changes.

Why this answer

Creating an RDS Read Replica offloads read traffic from the primary Oracle instance, directly reducing CPU utilization on the primary. Since the application is read-heavy and tolerates eventually consistent reads, the replica’s asynchronous replication lag is acceptable. This solution requires minimal application changes—only modifying the connection string to route SELECT queries to the replica endpoint.

Exam trap

The trap here is that candidates assume caching (ElastiCache or DAX) is the only way to reduce read load, but they overlook that RDS Read Replicas directly offload the database engine’s CPU without requiring application caching logic or a different database service.

How to eliminate wrong answers

Option A is wrong because Amazon ElastiCache caches query results in memory, but it requires application code changes to implement cache-aside or lazy loading patterns, and it does not offload database CPU for queries that miss the cache. Option B is wrong because upgrading to a larger instance type increases capacity but does not reduce CPU load; it only postpones the issue and incurs higher cost without addressing the root cause of read-heavy traffic. Option D is wrong because DynamoDB Accelerator (DAX) is an in-memory cache for Amazon DynamoDB, not for Amazon RDS for Oracle; it cannot be used to cache Oracle queries or reduce CPU on an RDS instance.

Practice this question →

397

Multi-Selecteasy

A company needs to choose a database for a real-time analytics workload that requires sub-second query latency on streaming data. Which TWO AWS services are most suitable?

Select 2 answers

A.Amazon Neptune.

B.Amazon RDS for PostgreSQL with materialized views.

C.Amazon Redshift with streaming ingestion from Kinesis.

D.Amazon Timestream.

E.Amazon DynamoDB Accelerator (DAX).

AnswersC, D

Supports near-real-time analytics.

Why this answer

Amazon Timestream is purpose-built for time-series data and provides sub-second query latency on streaming data via its dedicated query engine and automatic tiering between in-memory and magnetic stores. Amazon Redshift with streaming ingestion from Kinesis enables real-time analytics by directly consuming Kinesis data streams into Redshift materialized views, allowing sub-second queries on fresh data without batch loading.

Exam trap

The trap here is that candidates often confuse low-latency caching services like DAX or traditional databases with materialized views as suitable for real-time streaming analytics, overlooking that only purpose-built time-series databases or services with native streaming ingestion can guarantee sub-second query latency on continuous data streams.

Practice this question →

398

MCQmedium

A database administrator is troubleshooting a slow-performing query on an Amazon RDS for MySQL instance. The slow query log shows the above entry. Based on the exhibit, which index would most improve the query performance?

A.Index on `created_at` only.

B.Index on `status` only.

C.Full-text index on `status` and `created_at`.

D.Composite index on (`status`, `created_at`).

AnswerD

Covers both filter and sort, avoiding a full table scan.

Why this answer

The query filters on `status` and then sorts or filters on `created_at`. A composite index on (`status`, `created_at`) allows MySQL to use the index for both the equality condition on `status` and the range or sort on `created_at`, avoiding a filesort and reducing row scans. This is the most efficient index for this query pattern.

Exam trap

The trap here is that candidates often pick a single-column index on `status` (Option B) thinking it will help the filter, but they overlook the need to also optimize the sort or range on `created_at`, which requires a composite index to avoid a filesort.

How to eliminate wrong answers

Option A is wrong because an index on `created_at` only would not help with the `status` filter, forcing a full table scan or inefficient index scan. Option B is wrong because an index on `status` only would filter by status but then require a separate sort or additional filtering on `created_at`, leading to a filesort and poor performance. Option C is wrong because a full-text index is designed for text search (e.g., MATCH AGAINST) and is not suitable for equality or range comparisons on `status` and `created_at`; it would be ignored by the optimizer for this query.

Practice this question →

399

Multi-Selecthard

A company is migrating a large Oracle database to Amazon Aurora PostgreSQL. They need to minimize downtime and validate data consistency after migration. Which THREE steps should they include in their migration plan? (Choose THREE.)

Select 3 answers

A.Create multiple Aurora Replicas for read scaling during migration.

B.Perform a homogeneous migration directly from Oracle to Aurora.

C.Use AWS Database Migration Service (DMS) with ongoing replication to keep the target in sync.

D.Use AWS DMS data validation to compare source and target data.

E.Use AWS Schema Conversion Tool (SCT) to convert the Oracle schema to PostgreSQL.

AnswersC, D, E

Ongoing replication reduces downtime.

Why this answer

AWS DMS supports ongoing replication (change data capture) from Oracle to Aurora PostgreSQL, allowing the target database to stay synchronized with the source during the migration. This minimizes downtime by enabling a cutover after the initial load, rather than requiring a full outage for the entire migration.

Exam trap

The trap here is that candidates may confuse read replicas (Option A) as a migration tool, or mistakenly think a homogeneous migration (Option B) applies to cross-engine migrations, when in fact heterogeneous migrations require schema conversion and DMS for data transfer.

Practice this question →

400

Multi-Selectmedium

A company is migrating an on-premises MongoDB workload to Amazon DocumentDB. The workload includes aggregation pipelines with $lookup and $group operations. The team wants to ensure minimal performance impact. Which THREE steps should they take?

Select 3 answers

A.Disable journaling to reduce I/O overhead

B.Create appropriate indexes on fields used in $lookup and $group

C.Enable TLS for all connections

D.Use parallel scan operations where possible

E.Choose a larger instance size to accommodate the workload

AnswersB, D, E

Indexes improve aggregation performance significantly.

Why this answer

Creating appropriate indexes on fields used in $lookup (local and foreign fields) and $group (the _id field and any sort fields) allows Amazon DocumentDB to avoid full collection scans, significantly reducing query latency and resource consumption during aggregation pipeline execution.

Exam trap

The trap here is that candidates may confuse security measures (TLS) or storage settings (journaling) with performance optimization, when in fact the correct performance levers are indexing, instance sizing, and parallel execution.

Practice this question →

401

MCQmedium

A social media startup is designing a database for user activity feeds. Each user follows up to 5,000 other users. The feed must show the latest 100 posts from followed users with latency under 200ms. Reads are 10x writes. Which database design best meets these requirements?

A.Use Amazon RDS for PostgreSQL with read replicas and materialized views refreshed every minute

B.Use Amazon ElastiCache for Redis as a primary data store with sorted sets per user

C.Use a single DynamoDB table with a global secondary index on user_id and timestamp

D.Use Amazon DynamoDB with a fan-out on write pattern, storing each user's feed in a separate partition

AnswerD

Fan-out on write ensures feeds are pre-computed for fast reads, meeting latency and throughput requirements.

Why this answer

The fan-out on write pattern with DynamoDB ensures each user's feed is pre-computed and stored in a separate partition, allowing reads to fetch the latest 100 posts with sub-200ms latency by querying a single item collection. This pattern optimizes for the 10:1 read-to-write ratio by shifting work to writes, which are less frequent, and avoids expensive joins or scans at read time.

Exam trap

The trap here is that candidates often choose Option C (GSI on user_id and timestamp) thinking it enables efficient querying, but they overlook the need to query across multiple followed users and merge results, which DynamoDB cannot do without application-level sorting and pagination, violating the 200ms latency SLA.

How to eliminate wrong answers

Option A is wrong because materialized views refreshed every minute cannot meet the 200ms latency requirement for reads, as they introduce up to 60 seconds of staleness, and PostgreSQL read replicas do not reduce write amplification for a high-fan-out social feed. Option B is wrong because using ElastiCache for Redis as a primary data store lacks durability guarantees (no built-in persistence for critical data) and sorted sets per user would require expensive range queries and re-sorting for 5,000 followed users, failing to scale for the 10:1 read ratio. Option C is wrong because a single DynamoDB table with a GSI on user_id and timestamp would require a scan or query across all followed users' posts, leading to high read costs and latency exceeding 200ms due to the need to merge and sort results from multiple partitions.

Practice this question →

402

MCQmedium

A financial services company runs a critical application on Amazon RDS for MySQL that processes transactions. The database must maintain ACID compliance and support point-in-time recovery (PITR) with a recovery point objective (RPO) of 5 seconds and recovery time objective (RTO) of 1 minute. The current setup uses a single db.r5.large instance with automated backups enabled (retention period 7 days) and Multi-AZ deployment. During a recent failover test, the failover took 2 minutes, exceeding the RTO. What should the database specialist recommend to meet the RTO requirement?

A.Remove Multi-AZ and rely on automated backups for recovery.

B.Migrate to a Multi-AZ DB Cluster deployment for RDS for MySQL.

C.Configure a cross-Region read replica and promote it during a failure.

D.Increase the instance size to db.r5.xlarge to improve failover speed.

AnswerB

Multi-AZ DB Cluster provides faster failover (<1 minute).

Why this answer

Amazon RDS Multi-AZ DB Cluster for MySQL provides fast failover (typically under 1 minute) because it uses synchronous replication to two standby instances in different Availability Zones, ensuring automatic failover meets the 1-minute RTO. Option A (Remove Multi-AZ and rely on automated backups) would require restoring from backup, which takes much longer than 1 minute. Option C (Configure a cross-Region read replica and promote it during failure) involves manual promotion and is not automatic, so it cannot guarantee the RTO.

Option D (Increase the instance size to db.r5.xlarge) does not affect failover speed, as failover time is determined by the Multi-AZ configuration, not instance size.

Practice this question →

403

MCQhard

A developer is configuring IAM permissions for a Lambda function that accesses a DynamoDB table named 'Orders'. The policy shown is attached to the Lambda execution role. The function needs to delete items but only if the item contains only 'order_id' and 'status' attributes. Which statement about this policy is correct?

A.The function can delete any item in the Orders table because the condition is on the resource

B.The function cannot delete any items because the DeleteItem action is not allowed

C.The function cannot call Query on the table because it is not listed in the actions

D.The function can only delete items that contain exactly the attributes 'order_id' and 'status'

AnswerD

The condition ensures only items with those attributes can be deleted.

Why this answer

The IAM policy includes a condition key `dynamodb:Attributes` that restricts the `DeleteItem` action to items containing exactly the attributes 'order_id' and 'status'. This condition ensures the function can only delete items that match the specified attribute set, enforcing a fine-grained access control at the item attribute level.

Exam trap

The DBS-C01 exam often tests the misconception that a condition on `dynamodb:Attributes` applies to the resource ARN rather than the item's attributes, leading candidates to incorrectly assume the condition is on the table itself.

How to eliminate wrong answers

Option A is wrong because the condition is on the `dynamodb:Attributes` key, not on the resource; the resource ARN only specifies the table, but the condition restricts which items can be deleted based on their attributes. Option B is wrong because the policy explicitly includes the `DeleteItem` action in the `Action` list, so the action is allowed. Option C is wrong because the policy only grants permissions for `DeleteItem` and `GetItem`, not `Query`; however, the question asks about deleting items, and the policy does not need to include `Query` for the delete operation to work.

Practice this question →

404

MCQeasy

A company is designing a document storage system using Amazon DynamoDB. Each document is up to 400 KB and is identified by a unique 'document_id'. The access pattern is to retrieve a document by its ID. Which DynamoDB table design is MOST efficient?

A.Use 'document_id' as the partition key and create a GSI on 'document_id'.

B.Use 'document_id' as the primary partition key (only).

C.Store documents in Amazon S3 and use DynamoDB to store metadata with a reference to S3.

D.Use a composite key: partition key 'document_id' and sort key 'version'.

AnswerB

Direct GetItem by partition key is most efficient.

Why this answer

DynamoDB can store items up to 400 KB in a single table, and using 'document_id' as the sole partition key directly supports the access pattern of retrieving a document by its ID with a single GetItem call, which is the most efficient operation. No secondary index or composite key is needed, as the primary key alone provides O(1) lookup performance for this use case.

Exam trap

The trap here is that candidates often overcomplicate the design by adding GSIs or composite keys, or default to S3 for large objects, when the item size is within DynamoDB's limit and the access pattern is simple key-value lookup.

How to eliminate wrong answers

Option A is wrong because creating a GSI on 'document_id' is redundant and adds unnecessary cost and complexity; the base table already supports direct access by partition key. Option C is wrong because storing documents in S3 with DynamoDB metadata is a valid pattern for items larger than 400 KB, but the question states each document is up to 400 KB, which fits within DynamoDB's item size limit, making the S3 approach less efficient due to additional latency and management overhead. Option D is wrong because using a composite key with a sort key 'version' is unnecessary when the access pattern only requires retrieval by document ID; it adds complexity without benefit and may lead to unintended multiple items per document_id.

Practice this question →

405

MCQmedium

A company runs an e-commerce application on Amazon RDS for MySQL. The application experiences read-heavy traffic during flash sales. The development team wants to offload read traffic without changing the application code. Which solution should be used?

A.Implement an Amazon ElastiCache cluster and update the application to cache queries.

B.Configure Multi-AZ deployment for the RDS instance.

C.Create an RDS Read Replica and point read traffic to the replica endpoint.

D.Use DynamoDB Accelerator (DAX) in front of the RDS instance.

AnswerC

Read Replicas offload read traffic without application changes.

Why this answer

Creating an RDS Read Replica allows read-heavy traffic to be offloaded from the primary RDS instance without any application code changes. The application simply needs to be configured to use the read replica's endpoint for SELECT queries, while writes continue to the primary instance. This directly addresses the requirement to offload read traffic without modifying the application code.

Exam trap

The trap here is that candidates often confuse Multi-AZ with read scaling, assuming the standby instance can serve reads, but in RDS Multi-AZ the standby is not accessible for read traffic—it only provides failover redundancy.

How to eliminate wrong answers

Option A is wrong because implementing ElastiCache requires updating the application code to cache queries, which violates the requirement of no code changes. Option B is wrong because Multi-AZ deployment provides high availability and automatic failover, but does not offload read traffic; the standby instance cannot serve reads. Option D is wrong because DynamoDB Accelerator (DAX) is an in-memory cache for Amazon DynamoDB, not for RDS for MySQL, and cannot be placed in front of an RDS instance.

Practice this question →

406

MCQeasy

A startup is building a mobile app that requires a scalable NoSQL database. The data model includes user profiles with variable attributes that change over time. The database must support high read throughput and low latency. Which AWS database is best suited?

A.Amazon Neptune

B.Amazon RDS for MySQL

C.Amazon DynamoDB

D.Amazon Redshift

AnswerC

NoSQL, flexible schema, high performance at scale.

Why this answer

Amazon DynamoDB is a fully managed NoSQL key-value and document database that delivers single-digit millisecond latency at any scale. It supports flexible schema with variable attributes, making it ideal for user profiles that change over time, and its provisioned or on-demand capacity modes enable high read throughput with consistent low latency.

Exam trap

The trap here is that candidates may confuse Amazon Neptune's graph capabilities with NoSQL flexibility, or assume a relational database like MySQL can handle variable attributes via JSON columns, overlooking DynamoDB's native schema-less design and guaranteed single-digit millisecond performance at scale.

How to eliminate wrong answers

Option A is wrong because Amazon Neptune is a graph database designed for highly connected data (e.g., social networks, fraud detection), not for general-purpose NoSQL workloads with variable attributes. Option B is wrong because Amazon RDS for MySQL is a relational database with a fixed schema, requiring predefined columns and table alterations for attribute changes, which contradicts the variable-attribute requirement. Option D is wrong because Amazon Redshift is a petabyte-scale data warehouse optimized for analytical queries (OLAP), not for high-throughput, low-latency transactional reads (OLTP) on user profiles.

Practice this question →

407

MCQhard

A financial services company is migrating an on-premises Oracle database to AWS. The database supports an OLTP application with complex joins, stored procedures, and requires high availability within a single Region. The company wants to minimize licensing costs and use a fully managed service. Which AWS database service should they choose?

A.Amazon DynamoDB

B.Amazon RDS for Oracle

C.AWS Database Migration Service (DMS)

D.Amazon Aurora PostgreSQL-Compatible Edition

AnswerD

Aurora PostgreSQL is fully managed, supports complex joins and stored procedures, and provides high availability with Multi-AZ.

Why this answer

Amazon Aurora PostgreSQL-Compatible Edition is the correct choice because it is a fully managed, high-availability database service that supports complex joins, stored procedures, and OLTP workloads while minimizing licensing costs. Aurora provides built-in replication across three Availability Zones, automatic failover, and up to 15 read replicas, meeting the high availability requirement without the licensing overhead of commercial databases like Oracle.

Exam trap

The trap here is that candidates may choose Amazon RDS for Oracle (Option B) because it supports Oracle features directly, overlooking the explicit requirement to minimize licensing costs and the fact that Aurora PostgreSQL can handle complex joins and stored procedures without Oracle licensing fees.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB is a NoSQL key-value and document database that does not support complex joins, stored procedures, or the relational schema required by the existing Oracle OLTP application. Option B is wrong because Amazon RDS for Oracle would require purchasing Oracle licenses (Bring Your Own License or included license), which contradicts the goal of minimizing licensing costs, and it is not the most cost-effective fully managed option for high availability. Option C is wrong because AWS Database Migration Service (DMS) is a migration tool, not a database service; it helps move data to AWS but does not provide the operational database or high availability itself.

Practice this question →

408

Multi-Selecthard

A company runs a web application on Amazon EC2 instances behind an Application Load Balancer. The application uses Amazon RDS for MySQL. Recently, the database CPU utilization spikes to 100% during peak hours. The team observes that the spike is caused by a large number of slow queries. They need to identify and resolve the issue with minimal disruption. Which combination of steps should they take? (Choose two.)

Select 2 answers

A.Enable RDS Performance Insights to identify the slow queries

B.Upgrade to a larger instance type

C.Increase the DB instance storage to improve I/O

D.Create a read replica and direct reporting queries to the replica

E.Implement connection pooling using Amazon RDS Proxy

AnswersA, D

Performance Insights provides a dashboard to analyze database performance and identify problematic queries.

Why this answer

The correct combination is A and D. Option A: Enabling RDS Performance Insights quickly identifies slow queries and their resource consumption, pinpointing the cause of CPU spikes. Option D: Creating a read replica and directing reporting queries to it offloads read traffic from the primary instance, reducing CPU load during peak hours.

Option B is not an identification step and may not address the root cause, while also incurring unnecessary cost. Option C addresses I/O bottlenecks, not CPU spikes from slow queries. Option E helps with connection management but does not identify or directly resolve the slow query issue.

Practice this question →

409

MCQhard

A healthcare company stores patient records in Amazon DynamoDB. Each record includes patient_id (partition key), visit_date (sort key), and a large JSON attribute for medical history. The application frequently queries recent visits for a patient and scans historical data for analytics. The scans on the medical history attribute cause high RCU consumption. The company wants to reduce costs and improve query performance. Which design should be implemented?

A.Compress the medical history attribute using gzip before storing in DynamoDB.

B.Move the medical history attribute to a separate table with patient_id as partition key and visit_date as sort key. Use DynamoDB Streams to keep both tables in sync.

C.Enable DynamoDB Accelerator (DAX) for the table to cache frequent queries.

D.Use Amazon S3 to store the medical history as a separate object and reference it from DynamoDB.

AnswerB

Separating the large attribute reduces RCU consumption for queries that do not need it.

Why this answer

It separates the large, infrequently accessed medical history attribute from the frequently queried core record, reducing the item size for common queries and thus lowering RCU consumption. By using DynamoDB Streams to synchronize the two tables, you maintain data consistency without adding complexity to the application, and queries against the main table become faster and cheaper since they no longer read the large JSON payload.

Exam trap

The trap here is that candidates often choose compression (Option A) thinking it reduces storage and read costs, but DynamoDB does not natively support compression and charges based on the actual stored item size, so compression must be handled at the application layer and does not reduce RCU consumption.

How to eliminate wrong answers

Option A is wrong because compressing the medical history attribute with gzip before storing it in DynamoDB does not reduce RCU consumption; DynamoDB charges for the actual stored size of the item, and compression is not transparent to read operations—the application would still need to read the compressed data and decompress it, and the item size remains the same from DynamoDB's perspective. Option C is wrong because enabling DAX caches query results but does not reduce the RCU cost of the initial scan or query; DAX is a cache layer that speeds up repeated reads but does not change the fact that scanning the large medical history attribute consumes high RCUs per request. Option D is wrong because while storing medical history in S3 and referencing it from DynamoDB is a valid pattern, it introduces latency for retrieving the history and requires additional application logic to fetch the S3 object; more importantly, it does not address the high RCU consumption from scans on the DynamoDB table itself, as the scans would still need to read the reference attribute (which is small) but the question specifically targets the scans on the medical history attribute causing high RCU consumption.

Practice this question →

410

MCQhard

A company runs an OLTP workload on an RDS for MySQL instance. The database has a table with 50 million rows. The application frequently runs queries that join this table with a small lookup table (1000 rows) using a foreign key. The queries are slow. Which design change would most improve performance?

A.Partition the large table by the foreign key column.

B.Scale up the RDS instance to a larger size.

C.Add an index on the foreign key column in the large table.

D.Create a read replica and direct all read queries to it.

AnswerC

An index on the join column allows the database to quickly find matching rows, dramatically improving join performance.

Why this answer

The query joins a large table (50M rows) with a small lookup table (1000 rows) on a foreign key column. Without an index on the foreign key column in the large table, MySQL must perform a full table scan for each join, leading to slow performance. Adding an index on that column allows MySQL to use an index lookup (e.g., B-tree) to quickly locate matching rows, dramatically reducing query time.

Exam trap

The DBS-C01 exam often tests the misconception that partitioning or read replicas can fix join performance issues, but the real bottleneck is typically a missing index on the join column in the large table.

How to eliminate wrong answers

Option A is wrong because partitioning the large table by the foreign key column does not inherently speed up joins; it only splits data into physical segments, and queries still need to scan relevant partitions unless partition pruning is applied, which is not guaranteed for join conditions. Option B is wrong because scaling up the RDS instance increases CPU and memory but does not address the root cause of missing index; the query will still perform full table scans, wasting resources. Option D is wrong because creating a read replica and directing read queries to it does not improve join performance; the replica still lacks the necessary index, so queries remain slow on the replica.

Practice this question →

411

MCQhard

A financial services company runs an Amazon Aurora MySQL database. The application performs complex joins and aggregations on large tables, causing high CPU utilization on the writer instance. The team wants to reduce load without changing the application code. Which solution would best address this issue?

A.Create one or more Aurora Replicas and route read traffic to them.

B.Switch to asynchronous replication to reduce load on the primary.

C.Enable Aurora Auto Scaling to increase storage capacity.

D.Migrate to Aurora Serverless v2 for automatic scaling.

AnswerA

Read replicas offload SELECT queries from the writer.

Why this answer

Creating one or more Aurora Replicas and routing read traffic to them offloads the complex joins and aggregations from the writer instance, reducing CPU utilization without requiring application code changes. Aurora Replicas share the same underlying storage volume as the writer, so they serve read queries with minimal replication lag while the writer focuses on write operations.

Exam trap

The trap here is that candidates may confuse scaling compute capacity (Aurora Serverless v2) with offloading read traffic, but only read replicas directly reduce CPU load on the writer by moving read-heavy operations to separate instances.

How to eliminate wrong answers

Option B is wrong because switching to asynchronous replication does not reduce CPU load on the primary; it only changes how data is replicated to replicas, and Aurora already uses asynchronous replication between the writer and replicas. Option C is wrong because Aurora Auto Scaling for storage capacity increases storage automatically but does not offload compute or reduce CPU utilization on the writer instance. Option D is wrong because migrating to Aurora Serverless v2 provides automatic scaling of compute capacity but does not inherently separate read and write workloads; the writer instance would still handle all complex queries, so CPU load would remain high.

Practice this question →

412

MCQmedium

A company uses Amazon Redshift for data warehousing. They run a query that joins a large fact table (10 billion rows) with a small dimension table (1 million rows). The query is slow. The distribution style of the fact table is AUTO, and the dimension table has DISTSTYLE ALL. The join key is user_id. What is the MOST likely reason for the poor performance?

A.The dimension table does not have a sort key on user_id

B.The fact table's distribution key is not user_id, causing redistribution

C.The dimension table uses DISTSTYLE ALL, which is inefficient for joins

D.The fact table should have column compression disabled for the join key

AnswerB

AUTO may distribute by another key, leading to large data movement during join.

Why this answer

When the fact table uses DISTSTYLE AUTO, Redshift may choose a distribution key that is not user_id. When the fact table is distributed on a different key, joining on user_id requires Redshift to redistribute the fact table rows across nodes to match the dimension table's distribution, causing significant network traffic and slower performance. The dimension table with DISTSTYLE ALL is already replicated to all nodes, so the bottleneck is the fact table's distribution mismatch.

Exam trap

The trap here is that candidates often assume DISTSTYLE ALL is always inefficient for joins, but in this scenario it is actually beneficial, while the real culprit is the fact table's distribution key not matching the join key due to AUTO assignment.

How to eliminate wrong answers

Option A is wrong because sort keys optimize data ordering for range-restricted scans and merging, not for join redistribution; the slow join is due to data movement, not sorting. Option C is wrong because DISTSTYLE ALL is actually efficient for small dimension tables in joins, as it replicates the table to all nodes, avoiding redistribution of the dimension table. Option D is wrong because disabling column compression on the join key would increase I/O and storage costs without addressing the redistribution overhead; compression does not affect join performance in this context.

Practice this question →

413

Multi-Selecthard

A company runs a MySQL-compatible database on Amazon RDS for a mission-critical application. The database experiences high write latency due to frequent index updates. The team wants to redesign the database to reduce write amplification and improve insert performance. Which TWO design changes could help?

Select 2 answers

A.Switch the storage engine from InnoDB to MyISAM

B.Use batch INSERT statements instead of single-row inserts

C.Upgrade to a larger RDS instance class

D.Remove unused or redundant indexes

E.Normalize the database schema to reduce data redundancy

AnswersB, D

Batch inserts reduce transaction overhead and log I/O.

Why this answer

Batch INSERT statements reduce the overhead of per-row index updates by combining multiple rows into a single transaction. This minimizes the number of index tree traversals and log flushes, directly lowering write amplification and improving insert throughput in InnoDB.

Exam trap

The trap here is that candidates often confuse scaling up (Option C) with optimizing write patterns, or assume that removing indexes (Option D) is the only way to reduce write amplification, when batch operations directly address the per-row overhead without sacrificing query performance.

Practice this question →

414

Multi-Selecthard

A company uses Amazon DynamoDB to store order data. The table has a primary key (OrderID) and a Global Secondary Index (GSI) on CustomerID. The application often queries for all orders of a customer sorted by order date. The GSI projects only the keys. The queries are slow. What should the team do to improve query performance? (Choose two.)

Select 2 answers

A.Enable DynamoDB Accelerator (DAX) for the table

B.Increase the read capacity of the GSI

C.Modify the GSI to include OrderDate as a sort key

D.Use a Local Secondary Index (LSI) instead of a GSI

E.Change the GSI projection to include all attributes

AnswersC, E

Adding OrderDate as a sort key allows the GSI to return items sorted by order date without additional processing.

Why this answer

The queries are slow because the GSI projects only keys. When querying the GSI, DynamoDB must fetch the full items from the base table (a 'fetch' operation) for each key, which is inefficient. Option C (modifying the GSI to include OrderDate as a sort key) allows the GSI to sort results by order date natively, improving query performance.

Option E (changing the GSI projection to include all attributes) avoids the extra fetch by storing all attributes in the GSI, eliminating the need to access the base table. Option A (DAX) caches results but doesn't solve the sorting or projection issue. Option B (increasing read capacity) doesn't address the inefficiency of key-only projection.

Option D (using an LSI) is not possible because LSIs require the same partition key as the base table; CustomerID is different from OrderID, so an LSI cannot be used.

Practice this question →

415

MCQeasy

A gaming company runs a leaderboard application on Amazon DynamoDB. The application experiences sudden spikes in read traffic during tournaments. The table uses on-demand capacity and the reads are eventually consistent. However, some users report stale data for several seconds. What is the most likely cause?

A.The application is using eventually consistent reads.

B.The table is using on-demand capacity instead of provisioned capacity.

C.The table has a global secondary index (GSI) that is not updated synchronously.

D.The read capacity units are insufficient for the traffic spikes.

AnswerA

Eventually consistent reads can return stale data within about 1 second.

Why this answer

Eventually consistent reads in DynamoDB can return stale data for up to one second under normal conditions, but during sudden spikes in read traffic, the replication lag can extend to several seconds. The application is using eventually consistent reads, which trade immediate consistency for higher throughput and lower latency, making stale data more likely during high-traffic periods like tournaments.

Exam trap

The trap here is that candidates may confuse eventual consistency with capacity issues, but DynamoDB's on-demand mode eliminates throttling, so stale data points directly to the consistency model rather than resource constraints.

How to eliminate wrong answers

Option B is wrong because on-demand capacity automatically scales to handle traffic spikes without throttling, so it does not cause stale data. Option C is wrong because global secondary indexes (GSIs) are updated synchronously with the base table in DynamoDB, meaning they always reflect the latest write; stale data from a GSI would only occur if the application used eventually consistent reads on the GSI itself. Option D is wrong because read capacity units are not applicable to on-demand capacity mode, which has no fixed capacity limits; insufficient capacity would cause throttling errors (e.g., ProvisionedThroughputExceededException), not stale data.

Practice this question →

416

MCQmedium

A company uses Amazon RDS for Oracle with a Multi-AZ deployment for a critical OLTP application. During a recent failover test, they noticed that the application experienced a two-minute downtime. The team wants to reduce downtime to under 30 seconds during automatic failovers. What should they do?

A.Add a read replica to offload reads

B.Reduce the DNS TTL value to 5 seconds

C.Enable Automatic Failover in the RDS console

D.Migrate to Amazon Aurora with Multi-AZ and use the Aurora auto-failover feature

AnswerD

Aurora failover is typically under 30 seconds, and it provides faster recovery than RDS Multi-AZ.

Why this answer

Amazon Aurora with Multi-AZ provides faster failover than RDS for Oracle because Aurora uses a shared storage architecture and a cluster endpoint that automatically redirects traffic to the replica within 30 seconds, often in as little as 15 seconds. In contrast, RDS for Oracle Multi-AZ relies on DNS record updates and a standby instance that must be promoted, which typically takes 60–120 seconds. Migrating to Aurora eliminates the DNS propagation delay and the need for storage failover, meeting the sub-30-second requirement.

Exam trap

The trap here is that candidates assume reducing DNS TTL (Option B) will solve the problem, but they overlook that the primary bottleneck in RDS for Oracle failover is the database promotion and recovery time, not just DNS caching.

How to eliminate wrong answers

Option A is wrong because adding a read replica offloads read traffic but does not reduce failover time; failover still occurs on the primary instance and requires the same DNS and promotion steps. Option B is wrong because reducing DNS TTL to 5 seconds only minimizes client-side caching delay, but the actual failover process in RDS for Oracle (including storage and instance promotion) still takes 60–120 seconds, so the total downtime remains well over 30 seconds. Option C is wrong because 'Automatic Failover' is already enabled by default in a Multi-AZ deployment; there is no separate toggle to enable it, and the two-minute downtime is inherent to RDS for Oracle's failover mechanism, not a configuration issue.

Practice this question →

417

MCQhard

A gaming company uses Amazon ElastiCache for Redis as a leaderboard for real-time game scores. The leaderboard is updated frequently by millions of users. The application uses sorted sets with player scores. Recently, the leaderboard update latency increased and the cache evictions spiked. The company needs to ensure low-latency updates and high availability. The current setup is a single Redis node. Which design should be implemented?

A.Upgrade to a larger single Redis node instance type to handle the load.

B.Replace Redis with DynamoDB for the leaderboard, using a global secondary index on score.

C.Use a Redis Cluster with multiple shards. Enable AOF persistence and use a read replica for the leaderboard queries.

D.Use ElastiCache for Redis with cluster mode disabled and enable Multi-AZ.

AnswerC

Redis Cluster distributes data across shards, reducing load per node. Read replicas can handle queries, and AOF ensures durability.

Why this answer

Redis Cluster with multiple shards distributes the write load across shards, reducing per-node pressure and evictions. Enabling AOF persistence ensures durability, while using a read replica for leaderboard queries offloads read traffic from the primary shard, maintaining low-latency updates. This design provides both horizontal scaling and high availability, addressing the increased update latency and eviction spikes.

Exam trap

The trap here is that candidates may assume Multi-AZ (Option D) alone solves high availability and performance, but without sharding (cluster mode enabled), a single node remains a bottleneck for write-heavy workloads, and evictions will continue.

How to eliminate wrong answers

Option A is wrong because upgrading to a larger single Redis node instance type only provides vertical scaling, which has a hard ceiling and does not eliminate the single point of failure or the risk of evictions under sustained high write throughput. Option B is wrong because DynamoDB with a global secondary index on score is not optimized for real-time sorted set operations like ZADD and ZRANGE; it lacks the atomic, in-memory sorted set semantics that Redis provides for leaderboards, leading to higher latency and complexity for frequent updates. Option D is wrong because ElastiCache for Redis with cluster mode disabled and Multi-AZ only provides failover redundancy but does not shard data; a single node still handles all writes, so evictions and latency will persist under high load.

Practice this question →

418

MCQhard

A company is designing a social media application that requires storing user relationships (follows) and making graph queries like 'mutual friends.' Which database is most suitable?

A.Amazon ElastiCache for Redis

B.Amazon DynamoDB

C.Amazon Neptune

D.Amazon RDS for MySQL

AnswerC

Neptune is a graph database optimized for highly connected data and graph queries.

Why this answer

Amazon Neptune is a fully managed graph database service optimized for storing and querying highly connected data. It supports both property graph and RDF models, and it uses Gremlin or SPARQL to efficiently traverse relationships like 'mutual friends' in a social media application, making it the ideal choice for graph queries.

Exam trap

The trap here is that candidates often choose DynamoDB for its scalability and low latency, overlooking that graph queries like 'mutual friends' require native graph traversal capabilities that DynamoDB's key-value model cannot efficiently provide.

How to eliminate wrong answers

Option A is wrong because Amazon ElastiCache for Redis is an in-memory key-value store and cache, not a graph database; it lacks native graph traversal capabilities and would require complex application-side logic to compute mutual friends. Option B is wrong because Amazon DynamoDB is a NoSQL key-value and document database that does not support graph queries; it would require multiple queries and client-side joins to resolve relationships, leading to poor performance and scalability for graph workloads. Option D is wrong because Amazon RDS for MySQL is a relational database that uses SQL joins to model relationships, which becomes inefficient and unscalable for deep graph traversals like mutual friends due to the exponential number of join operations required.

Practice this question →

419

MCQhard

A company runs a multi-tenant SaaS application on Amazon DynamoDB. Each tenant's data is stored in a separate table named with a tenant-specific prefix (e.g., tenant1_orders, tenant2_orders). The application uses DynamoDB Streams to replicate data to a central analytics table. Recently, the company added a new large tenant that generates 10x more write traffic than any other tenant. The DynamoDB Streams for the large tenant's table is falling behind by several hours, causing stale data in the analytics table. The company has already increased the write capacity of the large tenant's table to 50,000 WCUs, but the streams lag persists. The analytics table is also in DynamoDB and uses a Global Secondary Index (GSI) for querying. The streams processing Lambda function performs simple transformations and writes to the analytics table. The Lambda function is not throttled. Which action would resolve the streams lag?

A.Enable DynamoDB on-demand mode for the large tenant's table to allow automatic scaling of stream shards.

B.Remove the GSI from the analytics table to reduce write amplification.

C.Increase the Lambda function's reserved concurrency to the maximum.

D.Increase the write capacity of the large tenant's table to 100,000 WCUs.

AnswerA

On-demand mode adjusts the number of stream shards based on write traffic, which can help with lag.

Why this answer

DynamoDB Streams shards are directly tied to the physical partitions of the table. When a table is in provisioned mode, the number of stream shards is fixed and determined by the table's partitions, which cannot scale independently. Enabling on-demand mode allows DynamoDB to automatically split partitions and thus increase the number of stream shards, enabling higher stream throughput to keep up with the large tenant's write volume.

This directly addresses the root cause of the streams lag without requiring manual partition management.

Exam trap

The trap here is that candidates assume increasing write capacity alone will resolve stream lag, but they overlook that stream shard count is tied to physical partitions, which only increase with on-demand mode or by triggering partition splits through sustained high throughput.

How to eliminate wrong answers

Option B is wrong because removing the GSI from the analytics table would reduce write amplification for writes to the analytics table, but the bottleneck is the DynamoDB Streams processing of the large tenant's source table, not the write capacity of the analytics table. Option C is wrong because the Lambda function is not throttled, so increasing reserved concurrency will not help; the issue is that the stream shards cannot process records fast enough due to insufficient shard count. Option D is wrong because increasing write capacity to 100,000 WCUs does not increase the number of stream shards; stream shard count is determined by the number of physical partitions, which only changes when partitions split, and provisioned WCUs alone do not trigger partition splits beyond the initial allocation.

Practice this question →

420

MCQmedium

A company is building a real-time chat application that requires storing messages with a maximum of 10,000 characters per message. The application needs sub-millisecond latency for reads and writes. The data must be durable and replicated across three Availability Zones. The development team wants to minimize operational overhead. Which AWS database service is most appropriate?

A.Amazon ElastiCache for Redis with replication

B.Amazon DynamoDB with DAX

C.Amazon RDS for PostgreSQL with Multi-AZ

D.Amazon Aurora MySQL with Multi-AZ

AnswerB

Serverless, sub-millisecond latency, durable, multi-AZ.

Why this answer

Amazon DynamoDB with DAX is the most appropriate choice because it provides single-digit millisecond latency for reads and writes, supports up to 400 KB per item (easily accommodating 10,000 characters), and offers built-in replication across three Availability Zones for durability. DAX (DynamoDB Accelerator) further reduces read latency to sub-millisecond by serving as an in-memory cache, while DynamoDB itself handles write durability and replication automatically, minimizing operational overhead.

Exam trap

The trap here is that candidates often choose ElastiCache for Redis (Option A) because of its sub-millisecond latency, overlooking the requirement for durable, multi-AZ replicated storage that Redis alone does not provide natively without additional configuration and operational overhead.

How to eliminate wrong answers

Option A is wrong because Amazon ElastiCache for Redis is an in-memory data store that does not provide durable storage by default; while it can be configured with replication, it lacks the native multi-AZ durability guarantees required for persistent message storage and would require additional infrastructure for data persistence. Option C is wrong because Amazon RDS for PostgreSQL with Multi-AZ provides high availability but cannot achieve sub-millisecond latency for both reads and writes due to disk-based storage and synchronous replication overhead, and it requires manual scaling and management. Option D is wrong because Amazon Aurora MySQL with Multi-AZ offers better performance than standard RDS but still cannot guarantee sub-millisecond latency for writes due to its distributed storage architecture and replication across three AZs, and it introduces more operational complexity than a fully managed NoSQL solution like DynamoDB.

Practice this question →

421

MCQeasy

A company needs to store and analyze log data from thousands of servers. The logs are timestamped and rarely updated. Queries are mostly time-range aggregations. Which database service is best suited for this workload?

A.Amazon CloudWatch Logs

B.Amazon ElastiCache for Redis

C.Amazon DynamoDB

D.Amazon RDS for PostgreSQL

AnswerA

CloudWatch Logs is purpose-built for log ingestion, storage, and analysis.

Why this answer

Amazon CloudWatch Logs is purpose-built for ingesting, storing, and analyzing timestamped log data from distributed sources. It supports real-time and historical time-range aggregations via Logs Insights, which uses a query language optimized for pattern matching and aggregation over time windows. The service automatically handles high-throughput ingestion from thousands of servers and is cost-effective for append-only, rarely updated log data.

Exam trap

The trap here is that candidates often choose DynamoDB or RDS because they are familiar with general-purpose databases, but they overlook that CloudWatch Logs is a fully managed, serverless service specifically designed for log ingestion and time-series analysis, eliminating the need for custom schema design, indexing, or scaling logic.

How to eliminate wrong answers

Option B (Amazon ElastiCache for Redis) is wrong because Redis is an in-memory key-value store designed for low-latency caching and real-time data structures, not for persistent storage or time-range aggregation queries over large volumes of log data; it lacks native log analytics capabilities and would require significant custom development. Option C (Amazon DynamoDB) is wrong because DynamoDB is a NoSQL key-value and document database optimized for point lookups and high-throughput transactional workloads, not for time-series aggregations; it does not support native time-range aggregation queries and would require complex application-level logic and secondary indexes to approximate log analysis. Option D (Amazon RDS for PostgreSQL) is wrong because PostgreSQL is a relational database designed for structured, transactional data with complex joins and ACID compliance; it is not optimized for high-ingest, append-only log workloads and would incur high storage costs and performance bottlenecks under the write load from thousands of servers, and its time-range aggregation queries would be slower than a purpose-built log analytics service.

Practice this question →

422

MCQmedium

A company uses Amazon DynamoDB to store IoT sensor data. Each sensor writes a record every second, and the application needs to query the last 24 hours of data for a specific sensor. The query must be very fast. Which table design and query pattern will minimize cost and latency?

A.Use a simple primary key (sensor ID) and scan the table filtering by timestamp

B.Use a composite primary key: partition key = sensor ID, sort key = timestamp

C.Use a composite primary key: partition key = timestamp, sort key = sensor ID

D.Use a simple primary key (sensor ID) and a global secondary index on timestamp

AnswerB

This allows efficient range queries on timestamp for a sensor.

Why this answer

Using a composite primary key with partition key = sensor ID and sort key = timestamp allows DynamoDB to efficiently query all items for a specific sensor in a single partition, using the Query API with a sort key condition on timestamp. This design ensures fast, targeted reads without scanning, minimizing read capacity units and latency.

Exam trap

The trap here is that candidates often choose Option C, mistakenly thinking that timestamp as a partition key provides global time ordering, but this actually scatters sensor data across partitions, making per-sensor queries impossible without a full scan.

How to eliminate wrong answers

Option A is wrong because using a simple primary key (sensor ID) with a scan and filter forces DynamoDB to read every item in the table, consuming excessive read capacity and causing high latency, which violates the requirement for fast queries. Option C is wrong because using timestamp as the partition key would scatter each sensor's data across many partitions, making it impossible to query all data for a single sensor efficiently; instead, you would need to query every partition or use a costly scan. Option D is wrong because while a global secondary index on timestamp could help, the base table still uses a simple primary key (sensor ID), which would require a scan or an inefficient index design; additionally, GSI writes incur extra cost and eventual consistency, and the query pattern would not be as optimal as using a composite key directly.

Practice this question →

423

MCQmedium

A team is migrating an on-premises Microsoft SQL Server database to AWS. The database is used for reporting and analytics, with complex queries that join multiple tables. The team wants to minimize application changes and ensure compatibility. Which AWS service should they use?

A.Amazon RDS for SQL Server

B.Amazon RDS for MySQL

C.Amazon Redshift

D.Amazon DynamoDB

AnswerA

RDS for SQL Server offers native compatibility, minimizing migration effort.

Why this answer

Amazon RDS for SQL Server is the correct choice because it provides a managed SQL Server database engine that is fully compatible with on-premises SQL Server, minimizing application changes. The service supports complex queries with joins and reporting workloads without requiring code modifications, as it uses the same T-SQL dialect and features.

Exam trap

The trap here is that candidates often choose Amazon Redshift for analytics workloads, overlooking that the question emphasizes minimizing application changes and compatibility with an existing SQL Server database, which Redshift cannot provide due to its different SQL dialect and architecture.

How to eliminate wrong answers

Option B is wrong because Amazon RDS for MySQL uses a different SQL dialect and does not support T-SQL-specific features like stored procedures, linked servers, or certain window functions that SQL Server applications may rely on, requiring significant application changes. Option C is wrong because Amazon Redshift is a columnar data warehouse optimized for large-scale analytical queries, not a transactional or relational database; it does not support the same SQL Server syntax, triggers, or stored procedures, and would require rewriting queries and application logic. Option D is wrong because Amazon DynamoDB is a NoSQL key-value and document database that does not support SQL joins, complex queries, or relational schemas, making it incompatible with the existing reporting and analytics workload.

Practice this question →