CCNA Workload-Specific Database Design Questions — Page 5 of 6

301

MCQeasy

A company is using Amazon DynamoDB to store session data for a web application. The session data expires after 24 hours. Which DynamoDB feature should the company use to automatically delete expired items?

A.A retention policy on the DynamoDB table

B.DynamoDB Time to Live (TTL)

C.DynamoDB Streams

D.A scheduled AWS Lambda function that scans and deletes expired items

AnswerB

TTL automatically deletes expired items based on a timestamp attribute.

Why this answer

DynamoDB Time to Live (TTL) is the correct choice because it provides a cost-effective, fully managed mechanism to automatically delete expired items based on a timestamp attribute in the table. TTL works by comparing the current time to the epoch time value stored in the designated TTL attribute; when the value is in the past, DynamoDB marks the item for deletion, typically within 48 hours. This eliminates the need for custom code or additional AWS services, directly addressing the requirement to remove session data after 24 hours.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing a custom Lambda-based approach (Option D) or misidentifying Streams (Option C) as a deletion mechanism, when DynamoDB's native TTL feature is the simplest, most cost-effective, and fully managed answer.

How to eliminate wrong answers

Option A is wrong because DynamoDB does not support a native 'retention policy' on tables; retention policies are a feature of services like Amazon S3 or CloudWatch Logs, not DynamoDB. Option C is wrong because DynamoDB Streams capture item-level changes (inserts, updates, deletes) in near-real-time but do not themselves delete items; they are a notification mechanism, not a data lifecycle management feature. Option D is wrong because while a scheduled Lambda function that scans and deletes expired items could technically work, it is an inefficient, custom solution that consumes read/write capacity and incurs additional cost and complexity, whereas TTL provides the same functionality natively and at no extra cost.

Practice this question →

302

MCQhard

A company is designing a multi-tenant SaaS application using Amazon Aurora PostgreSQL. Each tenant's data must be isolated for security and compliance. The application has a few large tenants and many small tenants. Queries must be able to access data across tenants for reporting, but with strict access controls. Which design best meets these requirements?

A.Use a single Aurora cluster with a separate schema per tenant and implement row-level security policies.

B.Create a separate database per tenant in the same Aurora cluster.

C.Create a separate Aurora cluster per tenant.

D.Use a single Aurora cluster with a single schema but add a tenant_id column to every table.

AnswerA

Schemas provide logical isolation and RLS enforces access controls per tenant.

Why this answer

It uses a single Aurora cluster with a separate schema per tenant and row-level security (RLS) policies. This design provides strong tenant isolation at the schema level while allowing cross-tenant reporting queries with strict access controls enforced by RLS policies, which automatically filter rows based on the current session's tenant context. It balances security, compliance, and operational efficiency for a mix of large and small tenants.

Exam trap

The trap here is that candidates often assume that physical separation (separate clusters or databases) is always required for compliance, but Aurora PostgreSQL's row-level security can provide logical isolation that meets security requirements while enabling efficient cross-tenant reporting.

How to eliminate wrong answers

Option B is wrong because creating a separate database per tenant in the same Aurora cluster does not provide sufficient isolation for security and compliance; databases in the same cluster share the same underlying storage and can be accessed by any user with appropriate privileges, and cross-database queries are cumbersome and less secure. Option C is wrong because creating a separate Aurora cluster per tenant introduces significant operational overhead, cost, and complexity, especially for many small tenants, and makes cross-tenant reporting queries extremely difficult without complex federated query mechanisms. Option D is wrong because using a single schema with a tenant_id column on every table lacks native isolation; it requires application-level filtering that can be bypassed, does not enforce strict access controls at the database level, and makes it harder to manage tenant-specific data lifecycle and compliance requirements.

Practice this question →

303

MCQhard

A company uses Amazon RDS for MySQL with Multi-AZ and read replicas. The database has a table storing user sessions with 50 million rows. The application team reports that queries using 'SELECT * FROM sessions WHERE user_id = ? ORDER BY login_time DESC LIMIT 10' are slow. The EXPLAIN plan shows a full table scan. Which design change would BEST improve query performance?

A.Implement an application-level cache using ElastiCache

B.Create a composite index on (user_id, login_time)

C.Partition the table by user_id

D.Upgrade to a larger instance type with more memory

AnswerB

This index covers both the WHERE and ORDER BY clauses.

Why this answer

The query filters on user_id and orders by login_time, which is a classic case for a composite index. A B-Tree index on (user_id, login_time) allows MySQL to locate all rows for the given user_id via the index's leading column and then retrieve the rows in sorted order using the second column, avoiding a full table scan and a filesort operation. This directly addresses the root cause — the lack of an index to support both the WHERE and ORDER BY clauses efficiently.

Exam trap

The DBS-C01 exam often tests the misconception that adding more resources (Option D) or partitioning (Option C) can substitute for proper indexing, when in fact the most efficient fix for a query with a WHERE and ORDER BY on different columns is a composite index that covers both.

How to eliminate wrong answers

Option A is wrong because an application-level cache would reduce repeated query load but does not fix the underlying full table scan for cache misses; the query would still be slow when the data is not cached. Option C is wrong because partitioning by user_id would not inherently improve query performance without an appropriate index; MySQL would still need to scan all partitions unless a local index is present, and partitioning alone does not provide sorted access. Option D is wrong because upgrading to a larger instance type with more memory only adds resources to handle the full table scan faster but does not eliminate the scan itself; the query would remain inefficient and scale poorly as data grows.

Practice this question →

304

MCQhard

A gaming company uses Amazon DynamoDB to store player scores. The table has a partition key of 'game_id' and a sort key of 'player_id'. They notice that during peak hours, write requests for a popular game 'g123' are throttled, while other games are unaffected. What is the most likely cause and solution?

A.Enable DynamoDB Accelerator (DAX) to cache writes.

B.The write capacity is too low; increase the table's write capacity units.

C.Use a composite partition key with a random suffix to distribute writes.

D.Enable auto-scaling on the table to handle burst write traffic.

AnswerC

Write sharding spreads writes across partitions, avoiding a hot key.

Why this answer

The throttling is caused by a hot partition: all writes for the popular game 'g123' target the same partition key, exceeding the 1,000 WCU per partition limit. Adding a random suffix to the partition key (e.g., 'g123-1', 'g123-2') distributes writes across multiple partitions, eliminating the bottleneck without changing the access pattern.

Exam trap

The trap here is that candidates confuse total table capacity with per-partition capacity, assuming increasing WCU or enabling auto-scaling will fix a hot partition, when the real solution is to redesign the partition key to avoid skew.

How to eliminate wrong answers

Option A is wrong because DAX is a read cache, not a write cache; it does not absorb write throttling. Option B is wrong because increasing the table's total write capacity does not resolve a hot partition; DynamoDB distributes capacity evenly across partitions, so a single partition still caps at 1,000 WCU. Option D is wrong because auto-scaling adjusts total table capacity, not per-partition distribution; it cannot prevent throttling on a single hot key.

Practice this question →

305

Multi-Selecthard

Which TWO are best practices for designing a DynamoDB table for high-traffic e-commerce application? (Select TWO.)

Select 2 answers

A.Create Global Secondary Indexes to support different access patterns.

B.Use a constantly increasing value (e.g., timestamp) as the partition key.

C.Design the table to use scan operations for most queries.

D.Use a composite primary key (partition key and sort key) to organize data.

E.Use a single attribute as the partition key with low cardinality.

AnswersA, D

GSIs allow querying on non-key attributes.

Why this answer

Global Secondary Indexes (GSIs) allow you to support multiple query patterns without duplicating data or redesigning the base table. In a high-traffic e-commerce application, you might need to query orders by customer ID, by status, or by date; GSIs provide alternative access patterns with their own partition and sort keys, enabling efficient queries without full table scans.

Exam trap

The trap here is that candidates often think a monotonically increasing partition key (like a timestamp) is acceptable for time-series data, but in DynamoDB it creates a hot partition, whereas in other databases it might be fine; AWS tests your understanding of DynamoDB's partitioning model and the importance of high-cardinality, evenly distributed partition keys.

Practice this question →

306

Multi-Selecteasy

Which TWO use cases are best suited for Amazon RDS Multi-AZ deployments? (Choose 2.)

Select 2 answers

A.Offloading read traffic from the primary database

B.Disaster recovery across AWS Regions

C.Improving write performance for a write-intensive workload

D.Scaling read capacity for a read-heavy application

E.Ensuring database availability during an Availability Zone outage

AnswersB, E

Correct. Multi-AZ provides automatic failover to a standby in a different AZ, enabling disaster recovery within the same region. Although the option says 'across AWS Regions', the intended use case is disaster recovery at the AZ level.

Why this answer

Amazon RDS Multi-AZ deployments automatically provision and maintain a synchronous standby replica in a different Availability Zone (AZ), ensuring automatic failover and high availability during an AZ outage. Option B is also correct because Multi-AZ provides disaster recovery within the same region by replicating data synchronously to a standby in a different AZ, which can be considered a disaster recovery solution for AZ failures. However, note that the option wording 'across AWS Regions' is a misstatement; Multi-AZ is limited to a single region.

Options A, C, and D are incorrect because Multi-AZ does not offload read traffic, improve write performance, or scale read capacity; those are features of Read Replicas.

Exam trap

Candidates often confuse Multi-AZ (synchronous replication for high availability and disaster recovery within a region) with Read Replicas (asynchronous replication for read scaling and cross-region disaster recovery). Here, option B's 'across AWS Regions' is a trap; the correct disaster recovery role of Multi-AZ is within the same region, not across regions.

Practice this question →

307

Multi-Selecthard

Which TWO techniques can reduce read latency for frequently accessed data in Amazon DynamoDB? (Choose 2.)

Select 2 answers

A.Use strongly consistent reads

B.Increase write capacity units

C.Decrease read capacity units

D.Add Global Secondary Indexes (GSI) for common query patterns

E.Enable DynamoDB Accelerator (DAX)

AnswersD, E

GSIs can provide efficient access to data.

Why this answer

Adding Global Secondary Indexes (GSI) allows you to pre-materialize alternative query patterns, enabling efficient lookups on non-key attributes without scanning the entire table. This reduces read latency for frequently accessed data by providing a pre-sorted and partitioned index that DynamoDB can query directly, avoiding expensive full-table scans.

Exam trap

The trap here is that candidates often confuse strongly consistent reads with performance optimization, not realizing that consistency guarantees come at the cost of higher latency, not lower.

Practice this question →

308

MCQeasy

A company is migrating an on-premises MySQL database to Amazon RDS. The database is used for a critical e-commerce application that requires high availability with automatic failover. Which RDS deployment option should the company choose to meet these requirements?

A.Multi-Region deployment with Read Replicas

B.Single-AZ instance with a standby in the same AZ

C.Multi-AZ deployment with a standby in a different AZ

D.Single-AZ instance with a Read Replica

AnswerC

Multi-AZ provides automatic failover to a standby in a different AZ.

Why this answer

A Multi-AZ deployment for Amazon RDS MySQL automatically provisions and maintains a synchronous standby replica in a different Availability Zone (AZ). In the event of an AZ failure or primary instance failure, Amazon RDS automatically fails over to the standby, providing high availability with minimal downtime. This meets the requirement for automatic failover without manual intervention.

Exam trap

The trap here is that candidates often confuse Multi-AZ with Read Replicas, assuming that a Read Replica can provide automatic failover, but in RDS MySQL, Read Replicas require manual promotion and do not offer synchronous replication or automatic failover.

How to eliminate wrong answers

Option A is wrong because Multi-Region deployment with Read Replicas is designed for disaster recovery across regions and does not provide automatic failover within a single region; failover would require manual promotion of a read replica. Option B is wrong because a Single-AZ instance with a standby in the same AZ is not supported by RDS; Multi-AZ requires the standby to be in a different AZ to protect against AZ-level failures. Option D is wrong because a Single-AZ instance with a Read Replica provides read scaling and can be manually promoted for disaster recovery, but it does not offer automatic failover or synchronous replication, which are required for high availability.

Practice this question →

309

MCQeasy

A company is designing a new application that requires a relational database with strong consistency and support for transactions. The application will be accessed by users worldwide, and the database must provide low-latency reads in multiple regions. The company expects the workload to be unpredictable, with periods of very low activity followed by sudden spikes. They want to minimize operational overhead and only pay for the resources they use. Which AWS database solution should they choose?

A.Amazon Redshift with cross-Region snapshots.

B.Amazon Aurora Serverless v2 with Aurora Global Database.

C.Amazon RDS for PostgreSQL with read replicas in multiple regions.

D.Amazon DynamoDB with Global Tables.

AnswerB

Aurora Serverless v2 automatically scales capacity, supports ACID transactions, and Global Database provides low-latency multi-region reads.

Why this answer

Amazon Aurora Serverless v2 is a good choice for unpredictable workloads because it auto-scales capacity based on demand and you pay only for what you use. It also supports Aurora Global Database for low-latency reads in multiple regions. RDS does not have serverless capability.

DynamoDB is serverless but not relational. Redshift is for analytics. So the best is Aurora Serverless v2 with Global Database.

Practice this question →

310

MCQhard

An IAM policy is attached to a user to restrict access to a DynamoDB table. What does this policy allow the user to do?

A.Read and write items only where the partition key equals 'customer_123'

B.Read and write any item in the Orders table

C.Scan the entire Orders table

D.Perform all DynamoDB actions on the Orders table

AnswerA

The condition restricts operations to items with LeadingKeys 'customer_123'.

Why this answer

The IAM policy uses a condition key `dynamodb:LeadingKeys` with a condition operator `ForAllValues:StringEquals` to restrict access to items where the partition key equals 'customer_123'. This allows the user to perform read and write operations only on items matching that specific partition key value, enforcing fine-grained access control at the item level.

Exam trap

The trap here is that candidates often assume a policy restricting access to a specific partition key still allows a full table Scan, but DynamoDB's fine-grained access control with `dynamodb:LeadingKeys` explicitly denies any operation that does not specify the allowed partition key, including Scans.

How to eliminate wrong answers

Option B is wrong because the policy explicitly restricts access to items with partition key 'customer_123', not any item in the table. Option C is wrong because a Scan operation would access all items in the table, which violates the partition key restriction; the policy does not allow scanning the entire table. Option D is wrong because the policy does not allow all DynamoDB actions; it only allows specific actions (like GetItem, PutItem, UpdateItem, DeleteItem, Query) conditioned on the partition key value, and actions like CreateTable or DeleteTable are not permitted.

Practice this question →

311

MCQhard

A company runs a multi-tenant SaaS application on Amazon RDS for PostgreSQL. Each tenant has an isolated database. Recently, the application experienced a sudden increase in connection errors and slow query performance. Amazon RDS instance metrics show high CPU utilization and a high number of database connections. The application uses connection pooling with PgBouncer running on an EC2 instance. The team suspects the issue is due to a few noisy tenants opening too many connections. The current architecture uses one RDS instance per tenant. The company wants to optimize for workload-specific database design to handle noisy tenants without affecting other tenants. Which design should be implemented to isolate noisy tenants and reduce costs?

A.Use RDS for PostgreSQL with pg_partman to partition data by tenant and implement connection limits per tenant using PostgreSQL advisory locks.

B.Replace RDS with Amazon Aurora PostgreSQL and use Aurora Auto Scaling to handle connection spikes.

C.Move all tenants to a single RDS instance with separate schemas and use RDS Proxy to manage connections.

D.Create separate RDS instances for large tenants and use a single RDS instance for small tenants, with PgBouncer connection pooling per instance.

AnswerD

This isolates noisy tenants on dedicated instances while consolidating small tenants, balancing isolation and cost.

Why this answer

It directly addresses the need to isolate noisy tenants by creating separate RDS instances for large (noisy) tenants while consolidating small tenants onto a single instance, each fronted by its own PgBouncer connection pool. This design prevents a single tenant's connection surge from affecting others, optimizes costs by avoiding over-provisioning for all tenants, and aligns with workload-specific database design principles for multi-tenant SaaS on RDS for PostgreSQL.

Exam trap

The trap here is that candidates may assume a single shared database with connection pooling (Option C) or a fully managed scaling solution (Option B) can solve noisy neighbor problems, but the DBS-C01 exam tests the understanding that workload isolation requires separate database instances or dedicated resources, not just connection management or auto-scaling of a shared cluster.

How to eliminate wrong answers

Option A is wrong because pg_partman is for table partitioning, not connection isolation, and advisory locks do not enforce per-tenant connection limits at the database level—they are application-level coordination mechanisms, not a substitute for connection pooling or instance isolation. Option B is wrong because Aurora Auto Scaling scales the entire cluster, not per-tenant, so a noisy tenant would still consume shared resources and cause contention; it also does not inherently isolate tenants or reduce costs compared to the targeted instance-per-tenant-group approach. Option C is wrong because moving all tenants to a single RDS instance with separate schemas and using RDS Proxy still shares CPU, memory, and I/O across all tenants, so a noisy tenant can degrade performance for others; RDS Proxy manages connections but does not provide workload isolation.

Practice this question →

312

MCQmedium

A company is designing a database for an IoT application that ingests millions of small sensor readings per second. The data is append-only and queries are primarily time-based aggregations with low latency requirements (under 10 ms). Which AWS database service is most suitable for this workload?

A.Amazon DynamoDB

B.Amazon ElastiCache

C.Amazon Aurora

D.Amazon Timestream

AnswerD

Timestream is purpose-built for time-series data with fast ingestion and aggregation.

Why this answer

Amazon Timestream is a purpose-built time-series database designed for IoT and operational applications that ingest high volumes of append-only data. It automatically manages storage tiers (in-memory and magnetic) and provides built-in time-based aggregation functions, enabling queries with sub-10 ms latency for recent data. This makes it the most suitable choice for the described workload of millions of sensor readings per second with low-latency aggregation queries.

Exam trap

The trap here is that candidates often choose Amazon DynamoDB for its low-latency and scalability reputation, overlooking that it lacks native time-series features like automatic retention policies and time-based aggregation functions, which are critical for this specific workload.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB is a key-value and document database optimized for single-digit millisecond latency at any scale, but it lacks native time-series optimizations such as automatic data tiering, time-based partitioning, and built-in aggregation functions, requiring complex application-level sharding and retention management for append-only time-series data. Option B is wrong because Amazon ElastiCache is an in-memory caching service (Redis/Memcached) that can provide sub-millisecond latency but is not designed for persistent, high-ingestion append-only workloads; it would require significant engineering to manage data retention, durability, and time-series queries, and its cost becomes prohibitive for storing millions of events per second. Option C is wrong because Amazon Aurora is a relational database with ACID compliance and high throughput, but it is not optimized for time-series data; its row-based storage and indexing overhead cause write bottlenecks at millions of writes per second, and it lacks native time-based partitioning and aggregation functions, leading to higher latency and cost for this workload.

Practice this question →

313

Multi-Selecteasy

Which TWO AWS services can be used to implement a serverless database architecture for variable workloads?

Select 2 answers

A.Amazon Redshift

B.Amazon Aurora Serverless v2

C.Amazon RDS Proxy

D.Amazon ElastiCache

E.Amazon DynamoDB

AnswersB, E

Aurora Serverless automatically scales capacity.

Why this answer

Amazon Aurora Serverless v2 is correct because it automatically scales database capacity up or down based on application demand, providing a serverless architecture for variable workloads without the need to manage database instances. Amazon DynamoDB is correct because it is a fully managed NoSQL serverless database that automatically scales throughput and storage to handle variable workloads, requiring no server provisioning or management.

Exam trap

The trap here is that candidates often confuse Amazon RDS Proxy (a connection management service) with a serverless database, or assume Amazon Redshift can function as a serverless transactional database, when in fact it is a data warehouse requiring cluster provisioning.

Practice this question →

314

MCQeasy

A startup is building a mobile application that requires a database to store user preferences and session data. The data is accessed by user ID and requires single-digit millisecond latency. The workload is read-heavy with occasional writes. Which database service is MOST cost-effective?

A.Amazon Aurora Serverless

B.Amazon ElastiCache for Memcached

C.Amazon DynamoDB with on-demand capacity

D.Amazon RDS for MySQL with provisioned IOPS

AnswerC

DynamoDB provides single-digit millisecond latency and is cost-effective for variable read-heavy workloads.

Why this answer

Amazon DynamoDB with on-demand capacity is the most cost-effective choice because it provides single-digit millisecond latency for key-value lookups by user ID, scales automatically to handle read-heavy workloads with occasional writes, and charges only for the reads and writes consumed, avoiding the cost of provisioning for peak capacity. The on-demand mode eliminates the need for capacity planning, making it ideal for unpredictable or variable traffic patterns typical of a startup's mobile application.

Exam trap

The trap here is that candidates often choose Amazon ElastiCache for Memcached (Option B) because of its low latency, but they overlook the requirement for a durable database that persists session data, whereas Memcached is a volatile cache with no built-in persistence or replication for data durability.

How to eliminate wrong answers

Option A is wrong because Amazon Aurora Serverless is a relational database designed for transactional workloads with ACID compliance, not optimized for simple key-value lookups with single-digit millisecond latency, and its cold-start latency and higher per-request cost make it less cost-effective for a read-heavy, occasional-write workload. Option B is wrong because Amazon ElastiCache for Memcached is an in-memory cache, not a durable database; it lacks persistence and data durability, making it unsuitable for storing user preferences and session data that must survive restarts. Option D is wrong because Amazon RDS for MySQL with provisioned IOPS incurs fixed costs for provisioned IOPS and instance hours, which is wasteful for a read-heavy workload with occasional writes, and its relational overhead adds unnecessary latency compared to a NoSQL key-value store.

Practice this question →

315

Multi-Selecteasy

Which TWO database design considerations are critical when migrating a high-traffic e-commerce website from Oracle to Amazon Aurora MySQL? (Choose 2.)

Select 2 answers

A.Enable eventual consistency for read replicas to reduce latency

B.Review and adapt application SQL queries for MySQL compatibility

C.Evaluate the impact of Aurora's storage engine on query performance

D.Use Aurora Multi-Master to distribute write load

E.Compress all tables to reduce storage costs

AnswersB, C

Oracle and MySQL differ in SQL syntax.

Why this answer

Oracle and MySQL use different SQL dialects, data types, and functions. Migrating a high-traffic e-commerce application requires reviewing and adapting all SQL queries to ensure compatibility with Aurora MySQL, including handling Oracle-specific features like sequences, hierarchical queries (CONNECT BY), and PL/SQL stored procedures. Failure to do so will cause runtime errors or degraded performance.

Exam trap

The trap here is that candidates often assume Aurora Multi-Master is the best choice for high write loads, but the exam tests understanding that Multi-Master introduces conflict resolution overhead and is typically not recommended for standard e-commerce workloads, where a single writer with read replicas is more appropriate.

Practice this question →

316

MCQeasy

A company is running a MySQL database on Amazon RDS for a web application. The application experiences read-heavy traffic, and the company wants to improve read performance without changing the application code. Which design should the database specialist recommend?

A.Implement an Amazon ElastiCache Redis cluster in front of the database.

B.Create one or more read replicas of the RDS DB instance.

C.Increase the instance size of the RDS DB instance.

D.Enable DynamoDB Accelerator (DAX) for the RDS instance.

AnswerB

Read replicas offload read traffic from the primary instance, improving read performance without application changes.

Why this answer

Amazon RDS read replicas allow you to offload read traffic from the primary DB instance without any application code changes. The application simply connects to the read replica endpoint(s) for SELECT queries, while writes continue to the primary instance. This directly addresses the read-heavy workload by distributing read requests across multiple copies of the database.

Exam trap

The trap here is that candidates may confuse read replicas with caching solutions like ElastiCache, but the key constraint is 'without changing the application code' — read replicas require only a connection string change, whereas caching requires code modifications to implement cache logic.

How to eliminate wrong answers

Option A is wrong because while ElastiCache Redis can improve read performance for cached data, it requires application code changes to implement cache-aside or other caching patterns, and it does not serve as a direct database read endpoint for existing queries. Option C is wrong because scaling up the instance size (vertical scaling) improves both read and write performance but does not specifically address read-heavy traffic in a cost-effective manner; it also does not distribute the read load across multiple nodes. Option D is wrong because DynamoDB Accelerator (DAX) is an in-memory cache for Amazon DynamoDB, not for Amazon RDS MySQL; it is incompatible with RDS and cannot be used to accelerate MySQL queries.

Practice this question →

317

MCQhard

A company uses Amazon Aurora MySQL for a SaaS application. Each tenant has a separate database. The company wants to implement a centralized monitoring solution that collects performance metrics from all tenant databases. The solution should be cost-effective and require minimal overhead. Which approach should be used?

A.Use AWS DMS to continuously replicate metrics to a central RDS instance.

B.Consolidate all tenants into a single RDS MySQL instance and use separate schemas.

C.Run an AWS Lambda function that queries each database's performance_schema every minute and stores results in S3.

D.Use Amazon CloudWatch Agent to collect custom metrics from each Aurora instance and aggregate in CloudWatch.

AnswerD

CloudWatch Agent collects metrics with low overhead.

Why this answer

Amazon CloudWatch Agent can be installed on each Aurora instance to collect custom performance metrics (e.g., from performance_schema) and publish them as CloudWatch custom metrics. This approach is cost-effective because it uses CloudWatch’s pay-per-metric model and eliminates the need for a separate aggregation database or continuous data movement. It also requires minimal overhead as the agent handles collection and aggregation natively, with no additional infrastructure to manage.

Exam trap

The trap here is that candidates often assume a centralized database or Lambda-based polling is required for aggregation, but the CloudWatch Agent’s native custom metrics capability provides a simpler, serverless, and cost-effective solution that aligns with the ‘minimal overhead’ requirement.

How to eliminate wrong answers

Option A is wrong because AWS DMS is designed for database migration and continuous replication of table-level data, not for collecting and aggregating performance metrics; it would introduce unnecessary complexity, cost, and latency. Option B is wrong because consolidating all tenants into a single RDS MySQL instance with separate schemas violates the requirement for separate databases per tenant and introduces cross-tenant performance noise, security risks, and scalability limits. Option C is wrong because running a Lambda function every minute to query each database’s performance_schema would incur significant invocation costs, potential cold-start latency, and network overhead; it also lacks built-in aggregation and retention, requiring additional S3 processing.

Practice this question →

318

MCQhard

A social media analytics company uses Amazon DynamoDB as the primary data store for user session data. Each session record has a partition key of user_id (String) and a sort key of session_start_time (Number, epoch). The application often queries the most recent 10 sessions for a given user. The traffic pattern shows that 90% of reads are for the last 10 sessions, while 10% are for historical sessions. The table has a provisioned read capacity of 5000 RCU and consistently experiences throttled read requests during peak hours. The company wants to optimize read performance without changing the provisioned capacity. Which design change will MOST improve read performance for this workload?

A.Create a Global Secondary Index (GSI) with the same partition key and a sort key of session_start_time, but query with ScanIndexForward=false and Limit=10.

B.Increase the provisioned read capacity to 10000 RCU to handle the peak load.

C.Enable DynamoDB Accelerator (DAX) with default settings to cache the most recent sessions.

D.Configure Amazon ElastiCache for Redis as a read-through cache for session data.

AnswerA

A GSI with the sort key reversed allows efficient retrieval of recent sessions using a single Query with ScanIndexForward=false and Limit=10.

Why this answer

Creating a GSI with the same partition key (user_id) and sort key (session_start_time) allows you to query with ScanIndexForward=false and Limit=10 to efficiently retrieve only the most recent 10 sessions per user. This avoids scanning all sessions for a user, reducing consumed read capacity and eliminating throttling without increasing provisioned RCU. The GSI also supports the 90% workload pattern by providing a targeted index that minimizes read unit consumption.

Exam trap

The trap here is that candidates often assume caching (DAX or ElastiCache) is the best solution for read-heavy workloads, but in this scenario the inefficiency is due to querying the base table without an index that supports efficient retrieval of the last N items, so a GSI with reversed sort order directly reduces read consumption without adding cache management overhead.

How to eliminate wrong answers

Option B is wrong because increasing provisioned read capacity to 10000 RCU does not optimize read performance; it only increases capacity, which contradicts the requirement to not change provisioned capacity and does not address the root cause of inefficient queries. Option C is wrong because enabling DAX with default settings caches hot items but does not reduce the read capacity consumed per query; the underlying table still uses the same number of read units for each query, and DAX does not change the query pattern to avoid full scans. Option D is wrong because configuring ElastiCache for Redis as a read-through cache adds complexity and latency for cache misses, and does not reduce the read capacity consumption on DynamoDB for the frequent last-10-sessions queries; it also does not address the inefficient scan pattern on the base table.

Practice this question →

319

MCQeasy

A developer runs the command `aws rds describe-db-instances --db-instance-identifier mydb` and gets the output containing `Source_Region: us-east-1` and `Replica_Mode: async`. Which conclusion can be drawn about the database configuration?

A.The database is a Multi-AZ read replica

B.The database engine is Aurora MySQL

C.The database is a primary instance in a Multi-AZ deployment

D.The database is a read replica of another instance

AnswerD

ReadReplicaSourceDBInstanceIdentifier indicates it is a replica.

Why this answer

The output from the describe-db-instances command indicates that this database is configured as a read replica. Read replicas in Amazon RDS are identified by the presence of a source region and asynchronous replication mode, which are characteristic of read replica configurations. Multi-AZ deployments use synchronous replication and do not expose these fields, making option D the only viable conclusion.

Exam trap

The trap here is that candidates confuse Multi-AZ standby instances with read replicas, but Multi-AZ uses synchronous replication and does not expose `Source_Region` or `Replica_Mode`, whereas read replicas use asynchronous replication and always show these fields.

How to eliminate wrong answers

Option A is wrong because Multi-AZ read replicas do not exist; Multi-AZ is a high-availability feature for primary instances, not a replica configuration. Option B is wrong because the output does not show any Aurora-specific fields such as `DBClusterIdentifier` or `Engine: aurora-mysql`, and the presence of `Replica_Mode: async` is common to both RDS MySQL and Aurora read replicas, but the lack of cluster context makes Aurora unlikely. Option C is wrong because a primary instance in a Multi-AZ deployment would not have `Source_Region` or `Replica_Mode` fields; those are exclusive to read replicas.

Practice this question →

320

MCQmedium

A media company stores video metadata in Amazon DynamoDB. Each record has a partition key of video_id and a sort key of uploaded_timestamp. The application frequently queries videos by genre and upload date. The access pattern is read-heavy with occasional writes. The table is provisioned with 3000 RCUs and 1000 WCUs. The company notices that queries by genre are slow and consume many RCUs. Which design change should be made to optimize for this workload?

A.Use DynamoDB Accelerator (DAX) to cache query results.

B.Create a local secondary index (LSI) with genre as sort key and uploaded_timestamp as partition key.

C.Increase the provisioned RCUs to 6000.

D.Create a global secondary index (GSI) with genre as partition key and uploaded_timestamp as sort key.

AnswerD

A GSI with genre as partition key allows efficient queries by genre and date.

Why this answer

Creating a Global Secondary Index (GSI) with genre as the partition key and uploaded_timestamp as the sort key allows efficient querying by genre and date without scanning the entire table. This directly supports the access pattern, reducing RCU consumption by using index key lookups instead of full table scans. The GSI is ideal for read-heavy workloads with occasional writes, as it offloads query traffic from the main table.

Exam trap

The trap here is that candidates may confuse LSIs and GSIs, incorrectly assuming an LSI can change the partition key, when in fact LSIs must share the main table's partition key, making them unsuitable for querying by a different attribute like genre.

How to eliminate wrong answers

Option A is wrong because DAX caches query results to reduce latency and RCU consumption, but it does not address the root cause of slow queries by genre—the lack of an appropriate index for that access pattern; DAX would still require expensive scans on cache misses. Option B is wrong because a Local Secondary Index (LSI) must have the same partition key as the main table (video_id), so it cannot support queries by genre as the partition key; using genre as sort key with video_id as partition key would not enable efficient genre-based queries. Option C is wrong because increasing RCUs to 6000 only adds more read capacity without fixing the inefficient query pattern; it would increase cost without resolving the underlying design issue of scanning the entire table for genre queries.

Practice this question →

321

Multi-Selecteasy

A company wants to store session state for a web application that runs on Amazon EC2 instances behind an Application Load Balancer. The session data is ephemeral and must be highly available. Which two AWS services are suitable for this use case? (Choose two.)

Select 2 answers

A.Amazon DynamoDB

B.Amazon ElastiCache for Redis with replication

C.Amazon Redshift

D.Amazon S3

E.Amazon RDS for MySQL

AnswersA, B

Fast, scalable, and highly available key-value store.

Why this answer

Amazon DynamoDB is a fully managed, serverless NoSQL key-value and document database that offers single-digit millisecond latency at any scale. It is ideal for storing ephemeral session state because it provides built-in high availability and durability by replicating data across multiple Availability Zones (AZs) automatically, without requiring manual failover or replication configuration.

Exam trap

The trap here is that candidates often choose Amazon S3 for its durability and low cost, overlooking its eventual consistency model and higher latency, which are unsuitable for real-time session state; or they pick Amazon RDS for MySQL assuming relational databases are always the safest choice, ignoring the overhead and lack of native TTL/expiration features for ephemeral data.

Practice this question →

322

MCQmedium

A company needs to store and manage user sessions for a web application. The application runs on multiple EC2 instances, and sessions must be accessible from any instance. The team wants a fully managed, highly available, and low-latency solution. Which AWS service should they use?

A.Amazon RDS for MySQL

B.Amazon ElastiCache for Redis

C.Amazon DynamoDB

D.Amazon S3

AnswerB

Redis is ideal for session storage with low latency and high availability.

Why this answer

Amazon ElastiCache for Redis is the correct choice because it provides a fully managed, in-memory data store with sub-millisecond latency, making it ideal for storing user session data that must be accessed from any EC2 instance. Redis supports atomic operations and data structures (e.g., TTL-based key expiration) that are well-suited for session management, and its replication and Multi-AZ failover ensure high availability. This meets the requirement for a fully managed, highly available, and low-latency solution without the overhead of managing a database cluster.

Exam trap

The trap here is that candidates often choose Amazon DynamoDB because it is fully managed and highly available, but they overlook the specific requirement for 'low-latency' (sub-millisecond) that only an in-memory cache like ElastiCache for Redis can provide, and they miss that DynamoDB's latency is higher due to disk I/O and consistency models.

How to eliminate wrong answers

Option A is wrong because Amazon RDS for MySQL is a relational database with disk-based storage, which introduces higher latency for session lookups compared to an in-memory store, and it requires more operational overhead for scaling and failover. Option C is wrong because Amazon DynamoDB is a NoSQL database that, while fully managed and highly available, has higher read/write latency (typically single-digit milliseconds) compared to ElastiCache for Redis (sub-millisecond), and it is not optimized for ephemeral session data with automatic TTL expiration as efficiently as Redis. Option D is wrong because Amazon S3 is an object storage service with high latency (often tens to hundreds of milliseconds) and is not designed for frequent, low-latency read/write operations required for user sessions; it also lacks native session management features like atomic operations or TTL.

Practice this question →

323

MCQmedium

A company is migrating an on-premises PostgreSQL database to Amazon RDS for PostgreSQL. The database currently uses a custom extension that is not supported by RDS. The application relies heavily on this extension for advanced statistical analysis. Which design approach should the company take to minimize application changes?

A.Migrate to PostgreSQL on Amazon EC2 and install the custom extension.

B.Migrate to Amazon DynamoDB and implement statistical analysis using DynamoDB streams and Lambda.

C.Migrate to Amazon RDS for PostgreSQL and install the custom extension on the RDS instance.

D.Migrate to Amazon RDS for PostgreSQL and implement the extension's functionality using AWS Lambda functions called via triggers.

AnswerD

Lambda can replicate the extension's behavior without modifying the application.

Why this answer

It allows the company to offload the unsupported custom extension's statistical analysis logic to AWS Lambda functions, which can be invoked via RDS PostgreSQL triggers. This approach minimizes application changes by keeping the database schema and query patterns largely intact, while the Lambda functions handle the advanced computations externally. RDS does not allow custom extensions, so this pattern leverages RDS for PostgreSQL's native trigger support to integrate with Lambda without modifying the application's core database interactions.

Exam trap

The trap here is that candidates assume RDS for PostgreSQL supports all PostgreSQL extensions, but AWS explicitly restricts custom extensions, making Option C a common distractor that seems plausible but is technically impossible.

How to eliminate wrong answers

Option A is wrong because migrating to PostgreSQL on Amazon EC2, while allowing custom extensions, requires significant operational overhead for patching, backups, and high availability, and does not minimize application changes more than the trigger-based approach. Option B is wrong because migrating to Amazon DynamoDB would require a complete rewrite of the application's data access layer and statistical analysis logic, as DynamoDB is a NoSQL key-value and document database with a different query model and no native support for PostgreSQL extensions. Option C is wrong because Amazon RDS for PostgreSQL does not allow installation of custom extensions; only AWS-provided extensions are supported, so this option is technically infeasible.

Practice this question →

324

Multi-Selecthard

A company is moving a large-scale time-series application from Cassandra to a managed AWS service. The workload involves high-frequency writes (millions per second) and queries that aggregate data over time windows. Which THREE AWS services are suitable for this time-series workload?

Select 3 answers

A.Amazon OpenSearch Service

B.Amazon Aurora

C.Amazon DynamoDB

D.Amazon Timestream

E.Amazon Redshift

AnswersA, C, D

Supports time-series ingestion and aggregation.

Why this answer

Amazon OpenSearch Service is suitable because it supports high-frequency writes via bulk indexing and provides powerful aggregation queries (e.g., date histograms, percentiles) over time windows, making it ideal for time-series analytics. It can ingest millions of events per second when properly scaled with optimized shard strategies and using the OpenSearch ingest pipeline.

Exam trap

The trap here is that candidates often choose Amazon Redshift for time-series analytics due to its columnar storage, overlooking its high write latency and lack of support for real-time, high-frequency ingestion at millions of writes per second.

Practice this question →

325

Multi-Selecthard

Which THREE design patterns can improve the performance of a write-heavy application using Amazon DynamoDB?

Select 3 answers

A.Write sharding by using a composite key with a random suffix to distribute writes across partitions.

B.Enable DynamoDB adaptive capacity to allow a single partition to use more throughput.

C.Create local secondary indexes (LSIs) for all query patterns.

D.Use DynamoDB Accelerator (DAX) to offload read traffic.

E.Increase provisioned write capacity units (WCUs) to the maximum allowed.

AnswersA, B, D

Prevents hot partitions by evenly distributing write traffic.

Why this answer

Write sharding with a random suffix on the partition key distributes writes evenly across multiple partitions, preventing hot partitions. This pattern avoids throttling by ensuring no single partition exceeds its write capacity limit, which is critical for write-heavy workloads in DynamoDB.

Exam trap

The trap here is that candidates may confuse local secondary indexes (LSIs) with global secondary indexes (GSIs) or assume that increasing WCUs alone resolves hot partitions, ignoring DynamoDB's per-partition throughput limits.

Practice this question →

326

MCQhard

An IAM policy is attached to a user to allow read access to the Orders table in DynamoDB. The user reports that a GetItem call for an order returns an 'AccessDeniedException'. What is the likely cause?

A.The user must specify a projection expression in the GetItem request to include only 'order_id' and 'status' attributes.

B.The user does not have permissions to perform GetItem on the Orders table.

C.The resource ARN is incorrect; it should include the wildcard for the table.

D.The condition key 'dynamodb:Attributes' restricts access to only two attributes, but the user can still get all attributes.

AnswerA

The condition requires that only these attributes be returned, so the request must explicitly project them.

Why this answer

When an IAM policy uses the `dynamodb:Attributes` condition key to restrict access to specific attributes (e.g., `order_id` and `status`), the user must include a `ProjectionExpression` in the `GetItem` request that explicitly lists only those allowed attributes. Without the projection expression, DynamoDB attempts to return all attributes, which triggers an `AccessDeniedException` because the policy denies access to attributes not listed in the condition.

Exam trap

AWS often tests the misconception that a table-level permission error is the cause, when in reality the issue is a missing `ProjectionExpression` due to attribute-level restrictions in the IAM policy.

How to eliminate wrong answers

Option B is wrong because the user does have permissions to perform GetItem on the Orders table; the error is caused by attribute-level restrictions, not a lack of table-level permission. Option C is wrong because the resource ARN in the policy is correct; including a wildcard for the table would not resolve the attribute-level restriction issue. Option D is wrong because the condition key `dynamodb:Attributes` does restrict access to only two attributes, and the user cannot get all attributes; the GetItem call must use a projection expression to limit the returned attributes to those allowed.

Practice this question →

327

MCQhard

A company runs a global e-commerce platform with a relational database. They need to reduce read latency for users in Europe and Asia. The primary database is in us-west-2. Which solution provides the LOWEST read latency for global users while maintaining data consistency?

A.Deploy Amazon ElastiCache clusters in each region and cache database queries

B.Use Amazon Aurora Global Database with reader instances in Europe and Asia

C.Migrate to Amazon DynamoDB global tables

D.Configure Amazon RDS cross-region read replicas

AnswerB

Aurora Global Database provides cross-region read replicas with <1 second latency, enabling low-latency local reads.

Why this answer

Amazon Aurora Global Database is designed for low-latency global reads by replicating data to up to five secondary regions with dedicated reader instances. It uses storage-based replication that typically adds less than one second of lag, ensuring strong consistency while providing local read access for users in Europe and Asia. This architecture directly addresses the requirement for the lowest read latency without compromising data consistency.

Exam trap

The trap here is that candidates often choose ElastiCache (Option A) thinking caching always provides the lowest latency, but they overlook the requirement for data consistency and the fact that caching does not replicate the full database state across regions.

How to eliminate wrong answers

Option A is wrong because ElastiCache caches database queries but does not replicate the underlying relational data; it introduces eventual consistency and cache staleness, and does not provide the same consistency guarantees as Aurora Global Database. Option C is wrong because DynamoDB global tables are a NoSQL solution, not a relational database, and the company specifically requires a relational database for its e-commerce platform. Option D is wrong because Amazon RDS cross-region read replicas use asynchronous replication with potentially higher lag than Aurora Global Database, and they do not offer the same low-latency global read architecture with dedicated reader instances in each region.

Practice this question →

328

Multi-Selectmedium

A company is using Amazon DynamoDB for a shopping cart application. The table has a partition key of `user_id` and a sort key of `item_id`. The application performs frequent updates to the `quantity` attribute. The company notices that write requests are being throttled during peak hours. Which TWO actions would help reduce throttling? (Choose two.)

Select 2 answers

A.Increase the provisioned write capacity for the table.

B.Use conditional writes to prevent overwrites.

C.Implement a write sharding pattern using a random suffix on the partition key.

D.Enable DynamoDB Streams to process writes asynchronously.

E.Enable DynamoDB Accelerator (DAX) for the table.

AnswersA, C

Increasing write capacity directly reduces throttling.

Why this answer

Increasing the provisioned write capacity directly raises the number of write capacity units (WCUs) available per second, allowing more write requests to succeed without being throttled. Since the application performs frequent updates to the `quantity` attribute, which consumes write capacity, adding more capacity alleviates throttling during peak hours.

Exam trap

The trap here is that candidates often confuse read-side solutions (like DAX or Streams) with write-side throttling, or they mistakenly think conditional writes reduce capacity consumption, when in fact they do not address the root cause of insufficient write capacity or hot partitions.

Practice this question →

329

MCQeasy

A gaming company wants to store player profiles and game state data with low-latency access for millions of concurrent users. The data is accessed via a REST API and requires high scalability with minimal operational overhead. Which database service is MOST suitable?

A.Amazon RDS for MySQL with read replicas

B.Amazon DynamoDB

C.Amazon Neptune

D.Amazon ElastiCache for Redis

AnswerB

DynamoDB is serverless, scales automatically, and provides low-latency access.

Why this answer

Amazon DynamoDB is the most suitable choice because it is a fully managed NoSQL key-value and document database that delivers single-digit millisecond latency at any scale, making it ideal for storing player profiles and game state data for millions of concurrent users. It supports high throughput with auto-scaling, integrates seamlessly with REST APIs via AWS SDKs, and requires minimal operational overhead due to its serverless nature.

Exam trap

The trap here is that candidates often confuse ElastiCache for Redis as a primary database due to its low latency, but it is an in-memory cache that does not provide the durability and persistence guarantees required for authoritative game state data, whereas DynamoDB is designed as a fully managed, durable, and scalable NoSQL database for exactly this use case.

How to eliminate wrong answers

Option A is wrong because Amazon RDS for MySQL with read replicas is a relational database that introduces write bottlenecks and requires manual scaling, schema management, and operational overhead, making it unsuitable for the high-velocity, schema-flexible game state data and millions of concurrent writes. Option C is wrong because Amazon Neptune is a graph database optimized for highly connected data like social networks or recommendation engines, not for simple key-value lookups of player profiles and game state, and it adds unnecessary complexity and cost. Option D is wrong because Amazon ElastiCache for Redis is an in-memory cache, not a durable primary database; while it provides low latency, it lacks persistence guarantees and is typically used as a caching layer, not for storing authoritative game state data that must survive restarts.

Practice this question →

330

MCQhard

A company is building a real-time leaderboard for a gaming application. The leaderboard must update scores within seconds and support queries for top players and individual ranks. Which database design is most appropriate?

A.Amazon S3 with Range GET requests

B.Amazon ElastiCache for Redis with sorted sets

C.Amazon DynamoDB with a global secondary index on score

D.Amazon RDS for PostgreSQL with ORDER BY and LIMIT

AnswerC

DynamoDB GSI enables efficient querying of top scores and rank lookups.

Why this answer

Amazon DynamoDB with a global secondary index (GSI) on score is the most appropriate design because it supports real-time updates and low-latency queries for both top players (via query on the GSI with ScanIndexForward=false and Limit) and individual ranks (via efficient key lookups). DynamoDB's fully managed, serverless architecture ensures sub-second response times at any scale, which is critical for a gaming leaderboard that must update scores within seconds.

Exam trap

Candidates might gravitate toward Redis (Option B) because of its native sorted set support, which is highly efficient for leaderboards. However, DynamoDB can also serve this use case with a global secondary index on score, allowing queries for top players and individual ranks with low latency, and it offers a fully managed serverless experience that scales automatically.

How to eliminate wrong answers

Option A is wrong because Amazon S3 is an object storage service, not a database; it lacks the ability to perform real-time updates or sorted queries, and Range GET requests are for retrieving byte ranges of an object, not for leaderboard operations. Option B is wrong because while ElastiCache for Redis with sorted sets can efficiently maintain a leaderboard in memory, it is not a durable, persistent database by default and would require additional configuration for data persistence and failover, making it less suitable as the primary database for a production gaming application that needs durability and consistency. Option D is wrong because Amazon RDS for PostgreSQL with ORDER BY and LIMIT can support leaderboard queries, but it is not optimized for real-time, high-frequency updates and queries at the scale of a gaming application; it would introduce latency due to disk-based storage and lack of native in-memory sorted set operations, and it requires manual scaling and management.

Practice this question →

331

MCQhard

A company uses Amazon DynamoDB to store IoT sensor data. Each sensor sends data every second, and the application needs to query the latest reading from each sensor. The sensor ID is the partition key, and the timestamp is the sort key. The table has millions of sensors. Which query pattern is most efficient to get the latest reading for a specific sensor?

A.Use BatchGetItem with the sensor ID and multiple timestamps

B.Use Scan with FilterExpression on sensor ID

C.Use GetItem with the sensor ID and the current timestamp

D.Use Query with KeyConditionExpression on sensor ID, ScanIndexForward=false, Limit=1

AnswerD

This retrieves the most recent item for that sensor efficiently.

Why this answer

Query with ScanIndexForward=false and Limit=1 retrieves only the most recent item for a given partition key (sensor ID) by reading items in descending sort key (timestamp) order and stopping after one item. This is the most efficient pattern as it uses the primary key index directly, avoids scanning, and minimizes read capacity consumption.

Exam trap

The DBS-C01 exam often tests the misconception that GetItem can be used with a partial key or that Scan with a filter is acceptable for single-item retrieval, but the trap here is that candidates overlook the efficiency of using Query with sort key ordering and limit to fetch the most recent item without scanning or guessing timestamps.

How to eliminate wrong answers

Option A is wrong because BatchGetItem requires exact primary keys (partition key and sort key) and cannot retrieve the latest item without knowing the exact timestamp; it also consumes read capacity for each requested item, making it inefficient for this use case. Option B is wrong because Scan reads every item in the table, which is extremely expensive and slow for millions of sensors, and FilterExpression is applied after the scan, not reducing the read capacity consumed. Option C is wrong because GetItem requires the exact primary key (sensor ID and timestamp), and using the current timestamp assumes the latest reading occurs exactly at that moment, which is almost never true for real-time sensor data.

Practice this question →

332

MCQmedium

A healthcare application stores patient records in Amazon DynamoDB. Each record has a unique patient ID and contains sensitive health information. The application must encrypt data at rest and ensure that only authorized services can access the data. Which combination of design choices meets these requirements?

A.Implement client-side encryption and use Lambda to validate access.

B.Enable S3 server-side encryption with AWS KMS and use bucket policies.

C.Enable DynamoDB encryption at rest using AWS KMS and use IAM policies to restrict access.

D.Use AWS CloudHSM for key storage and VPC endpoints for access control.

AnswerC

DynamoDB integrates with KMS for encryption and IAM for access control.

Why this answer

DynamoDB encryption at rest using AWS KMS provides server-side encryption for sensitive patient data, while IAM policies allow fine-grained access control to ensure only authorized services can access the table. This combination directly meets both the encryption and access control requirements without unnecessary complexity or service mismatches.

Exam trap

The trap here is that candidates may confuse encryption mechanisms across services (e.g., applying S3 encryption to DynamoDB) or assume that network controls like VPC endpoints replace the need for IAM-based authorization.

How to eliminate wrong answers

Option A is wrong because client-side encryption does not protect data at rest within DynamoDB (the application must manage keys and encryption logic), and Lambda validation is not a native access control mechanism for DynamoDB—IAM policies are required. Option B is wrong because S3 server-side encryption and bucket policies apply to Amazon S3, not DynamoDB; DynamoDB does not use S3 for primary storage or bucket policies for access control. Option D is wrong because AWS CloudHSM is a hardware security module for key storage but does not directly integrate with DynamoDB encryption at rest (DynamoDB uses AWS KMS, not CloudHSM), and VPC endpoints control network access but not authorization—IAM policies are still needed.

Practice this question →

333

MCQmedium

A financial services company uses Amazon Redshift for analytics. The workload consists of a mix of short-running queries from dashboards and long-running ETL jobs. The company notices that during peak hours, short queries experience high latency due to queueing behind ETL jobs. How can the company reduce the impact of ETL jobs on dashboard queries?

A.Configure workload management (WLM) queues to separate ETL and dashboard queries, and assign different concurrency levels.

B.Enable concurrency scaling to handle bursts of queries.

C.Enable short query acceleration (SQA) to prioritize queries that run under a certain time threshold.

D.Increase the number of nodes in the Redshift cluster.

AnswerA

WLM allows resource allocation per queue, ensuring dashboard queries have dedicated resources.

Why this answer

Amazon Redshift's Workload Management (WLM) allows you to create separate queues for different query types, such as ETL jobs and dashboard queries. By assigning different concurrency levels to each queue, you prevent long-running ETL jobs from consuming all available slots and blocking short dashboard queries, thereby reducing latency during peak hours.

Exam trap

The trap here is that candidates often confuse concurrency scaling or SQA as solutions for queueing, but these features do not isolate workloads; they only add capacity or prioritize within a single queue, whereas WLM queue separation directly addresses the root cause by dedicating resources per workload type.

How to eliminate wrong answers

Option B is wrong because concurrency scaling is designed to handle bursts of read queries by adding transient clusters, but it does not prioritize or isolate queries within the same cluster; it simply adds more capacity, which may not address the queueing issue if ETL jobs still consume all slots. Option C is wrong because Short Query Acceleration (SQA) prioritizes short-running queries within a single WLM queue by predicting their runtime, but it does not isolate ETL jobs from dashboard queries; if the queue is full of ETL jobs, SQA cannot bypass the queue entirely. Option D is wrong because increasing the number of nodes adds more compute capacity but does not change the queueing behavior; without WLM queue separation, ETL jobs can still fill all available slots and cause latency for short queries.

Practice this question →

334

MCQmedium

A company needs to implement a database solution for a global e-commerce platform that requires strongly consistent reads and writes with automatic failover across AWS Regions. Which service should be used?

A.Amazon DynamoDB global tables.

B.Amazon RDS for MySQL with Multi-AZ and cross-Region read replicas.

C.Amazon ElastiCache for Redis with Global Datastore.

D.Amazon Aurora Global Database.

AnswerD

Provides cross-Region replication and failover with strong consistency.

Why this answer

Amazon Aurora Global Database is the correct choice because it provides strongly consistent reads and writes across multiple AWS Regions with automatic failover. It uses a primary cluster in one Region and up to five secondary read-only clusters in other Regions, with replication typically under one second. Failover to a secondary Region can be promoted in as little as one minute, meeting the requirements for a global e-commerce platform.

Exam trap

The trap here is that candidates often confuse DynamoDB global tables' eventual consistency with strong consistency, or assume Multi-AZ RDS provides cross-Region failover, when in fact Multi-AZ is limited to a single Region and cross-Region replicas require manual intervention.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB global tables offer multi-Region replication but provide eventual consistency for reads by default, not strong consistency, and writes are only strongly consistent within a single Region. Option B is wrong because Amazon RDS for MySQL with Multi-AZ and cross-Region read replicas does not support automatic failover across Regions; Multi-AZ failover is within a single Region, and cross-Region replicas require manual promotion. Option C is wrong because Amazon ElastiCache for Redis with Global Datastore is an in-memory cache, not a durable database, and it does not guarantee strong consistency for writes across Regions.

Practice this question →

335

Multi-Selecteasy

Which TWO AWS services can be used to cache database query results to improve read performance? (Select TWO.)

Select 2 answers

A.Amazon DynamoDB Accelerator (DAX)

B.Amazon ElastiCache for Redis

C.Amazon CloudFront

D.Amazon ElastiCache for Memcached

E.Amazon RDS read replica

AnswersB, D

In-memory cache for query results.

Why this answer

Amazon ElastiCache for Redis and Amazon ElastiCache for Memcached are in-memory caching services that can store the results of database queries, allowing subsequent identical queries to be served from the cache instead of hitting the database. This reduces latency and improves read performance by offloading read traffic from the primary database.

Exam trap

The trap here is that candidates often confuse read replicas with caching, but read replicas are full database copies that still execute queries, whereas ElastiCache stores pre-computed results in memory for near-instant retrieval.

Practice this question →

336

MCQeasy

A company needs to migrate an on-premises PostgreSQL database to Amazon Aurora PostgreSQL. The database is 2 TB in size and has a 24/7 uptime requirement. Which AWS service should be used to perform the migration with minimal downtime?

A.AWS Schema Conversion Tool (SCT)

B.AWS S3

C.pg_dump and pg_restore

D.AWS Database Migration Service (DMS)

AnswerD

DMS supports live migration with CDC.

Why this answer

AWS Database Migration Service (DMS) is the correct choice because it supports ongoing replication from an on-premises PostgreSQL source to Amazon Aurora PostgreSQL, enabling a migration with minimal downtime. DMS can perform a full load of the 2 TB database and then continuously replicate changes using PostgreSQL's logical replication (via the pglogical extension or native slot-based replication) until the cutover, keeping the source available throughout the process.

Exam trap

The trap here is that candidates often choose pg_dump and pg_restore (Option C) because they are familiar PostgreSQL tools, but they overlook the 24/7 uptime requirement and the fact that pg_dump requires a consistent snapshot, which for a 2 TB database would cause hours of downtime during the dump and restore process.

How to eliminate wrong answers

Option A is wrong because AWS Schema Conversion Tool (SCT) is used for converting database schemas and code when migrating between different database engines (e.g., Oracle to Aurora PostgreSQL), not for migrating data with minimal downtime; it does not handle ongoing replication. Option B is wrong because AWS S3 is an object storage service and cannot directly migrate or replicate a live PostgreSQL database; it could be used as an intermediate staging area for exported data but would require manual export/import steps that cause significant downtime. Option C is wrong because pg_dump and pg_restore are native PostgreSQL utilities that perform a logical backup and restore, which requires the source database to be quiesced or locked during the dump to ensure consistency, resulting in substantial downtime for a 2 TB database.

Practice this question →

337

MCQhard

A gaming company uses Amazon RDS for PostgreSQL to store player profiles and game state. They report slow queries during peak hours. The DB instance is a db.r5.2xlarge with 500 GB gp2 storage. Which design change would MOST improve read performance for the most frequently accessed player profiles?

A.Implement application-level sharding by player ID

B.Increase provisioned IOPS on the existing volume

C.Upgrade to a db.r5.4xlarge instance

D.Add a read replica in the same AZ

AnswerD

Read replicas offload read traffic from the primary, improving performance for read-heavy workloads.

Why this answer

Adding a read replica in the same Availability Zone (AZ) offloads read traffic from the primary RDS for PostgreSQL instance, directly improving read performance for frequently accessed player profiles during peak hours. Read replicas asynchronously replicate data using PostgreSQL's streaming replication and can serve SELECT queries without impacting the primary instance's write workload or connection limits.

Exam trap

The trap here is that candidates confuse increasing instance size (Option C) or IOPS (Option B) as the only way to fix slow queries, when the real solution is to offload read traffic to a read replica, which is a common AWS exam pattern for read-heavy workloads on RDS.

How to eliminate wrong answers

Option A is wrong because application-level sharding by player ID distributes write and read load across multiple databases, but it requires significant application changes and does not directly address read performance on the existing single RDS instance; it is an architectural redesign, not a quick design change. Option B is wrong because increasing provisioned IOPS on the existing gp2 volume improves I/O throughput for write-heavy or latency-sensitive operations, but the bottleneck described is read performance during peak hours, and gp2 already provides baseline IOPS proportional to size (1500 IOPS for 500 GB) with burst credits; the issue is likely CPU or connection saturation, not storage I/O. Option C is wrong because upgrading to a db.r5.4xlarge instance doubles the compute and memory resources, which can improve overall performance, but it does not isolate read traffic from write traffic; the primary instance still handles all reads and writes, so read performance gains are limited by the same contention and replication lag is not addressed.

Practice this question →

338

MCQeasy

A company is migrating a MySQL database to Amazon Aurora MySQL. The current database uses multi-statement transactions with read committed isolation level. The application frequently encounters deadlocks on the source database. Which Aurora MySQL feature can help reduce deadlocks without application changes?

A.Use Amazon Aurora Auto Scaling to automatically adjust the number of replicas.

B.Use Amazon Aurora Global Database to replicate data to multiple regions.

C.Use Amazon RDS Proxy to pool and share database connections.

D.Use Amazon Aurora Backtrack to quickly revert transactions.

AnswerC

RDS Proxy reduces connection contention and can help reduce deadlocks.

Why this answer

RDS Proxy helps reduce deadlocks by pooling and reusing database connections, which minimizes the overhead of establishing new connections and reduces contention on database resources. In MySQL, deadlocks often occur when multiple transactions compete for the same resources under high connection churn; by maintaining a stable pool of connections, RDS Proxy lowers the probability of concurrent conflicting locks. Since the proxy is transparent to the application, no code changes are required to benefit from this behavior.

Exam trap

The trap here is that candidates confuse deadlock reduction with high-availability or disaster-recovery features, mistakenly thinking that scaling replicas (Auto Scaling) or global replication (Global Database) can resolve concurrency conflicts, when in fact the key is connection management and reducing lock contention.

How to eliminate wrong answers

Option A is wrong because Aurora Auto Scaling adjusts the number of read replicas based on load, which does not address deadlock reduction—deadlocks are a concurrency and locking issue, not a capacity issue. Option B is wrong because Aurora Global Database replicates data across regions for disaster recovery and low-latency reads, but it does not reduce deadlocks on the primary instance; in fact, it can introduce additional replication-related locks. Option D is wrong because Aurora Backtrack allows reverting transactions to a point in time, which is a recovery feature, not a prevention mechanism—it does not reduce the occurrence of deadlocks during normal operation.

Practice this question →

339

Multi-Selectmedium

A company is designing a database for a global e-commerce platform. The application requires single-digit millisecond read and write latency for user sessions, and must handle millions of requests per second. The data is key-value in nature. Which TWO AWS services should the company consider? (Choose two.)

Select 2 answers

A.Amazon DynamoDB

B.Amazon ElastiCache for Redis

C.Amazon Neptune

D.Amazon Redshift

E.Amazon RDS for MySQL

AnswersA, B

Key-value NoSQL database with single-digit millisecond latency.

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 is designed for high-traffic applications requiring millions of requests per second, making it ideal for the global e-commerce platform's user session data.

Exam trap

The trap here is that candidates may choose Amazon RDS for MySQL or Amazon Neptune because they are familiar with SQL or graph databases, but they fail to recognize that key-value workloads with extreme throughput and latency requirements are a core use case for DynamoDB and ElastiCache, not relational or graph databases.

Practice this question →

340

Multi-Selecthard

A company is designing a multi-tenant SaaS application on Amazon Aurora MySQL. Each tenant has its own database, but some tenants are very large and generate high write traffic. The company wants to isolate tenant workloads to prevent a noisy neighbor from affecting other tenants. Which TWO design strategies should the database specialist recommend?

Select 2 answers

A.Use Aurora Serverless for tenants with variable workloads

B.Use a single Aurora cluster with read replicas for each tenant

C.Migrate all tenants to Amazon DynamoDB and use DynamoDB Accelerator (DAX) for caching

D.Use Amazon RDS Proxy to pool connections and limit throughput per tenant

E.Use separate Aurora clusters for high-traffic tenants

AnswersA, E

Aurora Serverless automatically scales compute capacity based on workload, minimizing impact on other tenants.

Why this answer

Aurora Serverless automatically scales compute capacity based on application demand, which is ideal for tenants with variable workloads. This prevents a noisy neighbor scenario by ensuring that a tenant's burst of write traffic does not consume shared resources that would degrade performance for other tenants.

Exam trap

The trap here is that candidates often confuse connection pooling (RDS Proxy) with resource isolation, not realizing that RDS Proxy only manages connections and does not prevent a noisy neighbor from exhausting the cluster's shared I/O or CPU capacity.

Practice this question →

341

MCQeasy

A retail company uses Amazon DynamoDB to store shopping cart data. The cart items are frequently updated as users add or remove products. The application reads the entire cart each time the user views it. The cart size averages 50 KB but can reach up to 400 KB. The company wants to reduce read costs and improve performance. Which design change would be most effective?

A.Switch to larger DynamoDB instance types to handle larger items.

B.Use DynamoDB Accelerator (DAX) to cache the cart data.

C.Compress the cart items before storing them in DynamoDB and decompress on read.

D.Normalize the cart data into separate tables for cart headers and line items.

AnswerC

Compression reduces the item size, lowering RCU consumption and cost.

Why this answer

Compressing cart items before storing them in DynamoDB reduces the item size, which directly lowers read capacity unit (RCU) consumption since DynamoDB charges based on read item size rounded up to 4 KB increments. For a 400 KB item, compression can shrink it significantly, reducing the number of 4 KB blocks read and thus cutting costs. Decompression on read adds minimal CPU overhead but yields substantial performance gains by reducing network transfer time and read latency.

Exam trap

The trap here is that candidates often assume caching (DAX) is the universal performance fix, but the question specifically targets reducing read costs, not just latency, and DAX does not eliminate the underlying cost of reading large items from DynamoDB.

How to eliminate wrong answers

Option A is wrong because DynamoDB is a serverless, fully managed service and does not use instance types; the concept of 'larger instances' applies to relational databases like Amazon RDS, not DynamoDB. Option B is wrong because DAX caches frequently accessed data to reduce read latency, but it does not reduce the read cost per item; you still pay for the underlying DynamoDB reads when the cache is populated or on cache misses, and the large item size still incurs high RCU consumption. Option D is wrong because normalizing cart data into separate tables (e.g., headers and line items) would require multiple read operations to reconstruct the cart, increasing read costs and latency, and DynamoDB is optimized for denormalized, single-table designs with large items.

Practice this question →

342

MCQmedium

A company is designing a database for an e-commerce platform that requires ACID transactions for order processing, complex joins for inventory reporting, and the ability to scale read replicas across multiple AWS regions. Which database service best meets these requirements?

A.Amazon Aurora

B.Amazon DynamoDB

C.Amazon RDS for SQL Server

D.Amazon Redshift

AnswerA

Aurora offers ACID transactions, complex joins, and cross-region read replicas.

Why this answer

Amazon Aurora is the correct choice because it provides full ACID compliance for transactional workloads, supports complex joins via its MySQL/PostgreSQL-compatible relational engine, and offers up to 15 low-latency read replicas that can be placed in multiple AWS Regions using Aurora Global Database. This combination of strong consistency, relational query capabilities, and cross-region read scaling directly matches the e-commerce platform's requirements.

Exam trap

The trap here is that candidates often choose DynamoDB for its scalability but overlook the explicit requirement for complex joins, which DynamoDB cannot perform natively, or they choose RDS for SQL Server without realizing its strict limit on read replicas and lack of native cross-region replication.

How to eliminate wrong answers

Option B (Amazon DynamoDB) is wrong because it is a NoSQL key-value/document database that does not support complex joins natively and provides only eventual consistency by default, not full ACID transactions across multiple items without additional client-side logic. Option C (Amazon RDS for SQL Server) is wrong because while it supports ACID transactions and joins, it is limited to a maximum of 5 read replicas and does not support cross-region read replicas natively, making it unsuitable for multi-region read scaling. Option D (Amazon Redshift) is wrong because it is a columnar data warehouse optimized for analytical queries, not transactional workloads, and does not support ACID transactions for OLTP order processing or real-time complex joins for inventory reporting.

Practice this question →

343

Multi-Selecteasy

A company is designing a database for a global application that requires low-latency reads and writes across multiple AWS regions. The application data is key-value and does not require complex queries. The team needs strong consistency for critical data. Which TWO services should they consider? (Choose TWO.)

Select 2 answers

A.Amazon DynamoDB Global Tables

B.Amazon S3 with cross-region replication

C.Amazon ElastiCache for Redis with global datastore

D.Amazon Aurora Global Database

E.Amazon RDS for PostgreSQL with cross-region read replicas

AnswersA, D

DynamoDB Global Tables replicate data across regions and support strong consistency.

Why this answer

Amazon DynamoDB Global Tables is correct because it provides a fully managed, multi-region, multi-active database solution that replicates data across AWS Regions with low-latency reads and writes. It supports strongly consistent reads for critical data when using the `ConsistentRead` parameter, which returns the most up-to-date data from the source region. This makes it ideal for key-value workloads requiring global scalability and strong consistency.

Exam trap

The trap here is that candidates often confuse 'global datastore' (ElastiCache for Redis) with a fully managed multi-region database, not realizing it provides only eventual consistency and is not designed for durable, strongly consistent critical data.

Practice this question →

344

MCQeasy

A startup is building a social media application that stores user posts in Amazon DynamoDB. The access pattern is to retrieve posts by user_id (partition key) sorted by post_timestamp (sort key) in descending order. The table has a global secondary index (GSI) with the same key structure but with different projection. The application reads from the GSI. Recently, the team noticed that writes to the base table are throttled during peak hours. The write capacity is balanced across partitions. Which design change should be made to reduce write throttling?

A.Use DynamoDB Accelerator (DAX) for writes.

B.Increase the write capacity units (WCUs) on the base table.

C.Switch to on-demand capacity mode.

D.Add a write sharding pattern by appending a random suffix to the partition key.

AnswerD

Sharding distributes writes across partitions, reducing hot spots.

Why this answer

The write throttling is caused by a hot partition, where a single partition key (user_id) receives a disproportionate number of writes. By appending a random suffix to the partition key, the writes are distributed evenly across multiple partitions, eliminating the hot spot. This is a well-known sharding pattern for DynamoDB when access patterns create uneven write traffic, and it does not require changing the read logic because the GSI can be queried with a sort key condition on post_timestamp.

Exam trap

The trap here is that candidates often assume increasing capacity or switching to on-demand mode will solve all throttling issues, but they overlook the fundamental partition-level throughput limits that cause hot partition throttling.

How to eliminate wrong answers

Option A is wrong because DAX is an in-memory cache for reads, not writes; it does not increase write capacity or reduce write throttling. Option B is wrong because increasing WCUs on the base table would not resolve the underlying hot partition issue; throttling occurs at the partition level, and if one partition is overloaded, adding more capacity to the table does not help because the partition's throughput limit is fixed. Option C is wrong because switching to on-demand capacity mode would only handle unpredictable traffic patterns, but it does not solve the hot partition problem; on-demand still has per-partition throughput limits (3,000 RCU or 1,000 WCU per partition), and a single hot partition can still throttle writes.

Practice this question →

345

MCQeasy

A social media company stores user posts in a database. Each post has a unique ID, content, and timestamp. The application frequently queries posts by user ID and also needs to support a global feed sorted by timestamp. Which database design is most efficient?

A.Amazon DynamoDB with a single table and scan operation for the global feed

B.Amazon S3 with a metadata index in DynamoDB

C.Amazon DynamoDB with user_id as partition key and timestamp as sort key, plus a GSI on timestamp

D.Amazon RDS for PostgreSQL with indexes on user_id and timestamp

AnswerC

This design efficiently supports both query patterns.

Why this answer

It uses user_id as the partition key and timestamp as the sort key for efficient per-user queries, while the Global Secondary Index (GSI) on timestamp allows the global feed to be sorted by timestamp without a costly scan. This design leverages DynamoDB's key-value and query capabilities to support both access patterns with low latency and minimal read capacity consumption.

Exam trap

The trap here is that candidates often assume a relational database with indexes is always the best for sorted queries, but DynamoDB's GSI and sort key design can handle both access patterns more efficiently at scale, and the exam tests understanding of when to use NoSQL over SQL for high-throughput workloads.

How to eliminate wrong answers

Option A is wrong because a Scan operation on a single DynamoDB table reads every item, which is inefficient, expensive, and does not scale for a global feed sorted by timestamp; DynamoDB is designed for query-based access, not full-table scans. Option B is wrong because storing posts in S3 with a DynamoDB metadata index adds unnecessary complexity and latency for frequent queries, as each post retrieval requires two round trips (one to DynamoDB for metadata, one to S3 for content), and it does not natively support sorted global feeds without additional processing. Option D is wrong because while PostgreSQL with indexes can support both queries, it is a relational database that may introduce overhead for a social media workload with high write throughput and requires manual scaling, whereas DynamoDB provides managed, auto-scaling NoSQL performance better suited for this use case.

Practice this question →

346

MCQhard

A gaming company uses Amazon DynamoDB as the primary data store for player profiles and game state. The application experiences sudden spikes in traffic during new game launches, causing throttling on write requests. The current table has on-demand capacity mode. The table's partition key is 'player_id' (high cardinality). The read/write patterns are evenly distributed. Despite on-demand mode, throttling occurs because the per-partition throughput limit is being reached. The company wants to eliminate throttling without changing the partition key. Which solution should be recommended?

A.Implement Amazon DynamoDB Accelerator (DAX) to offload read traffic.

B.Use DynamoDB auto scaling with provisioned capacity.

C.Enable DynamoDB adaptive capacity and implement write sharding using a random suffix.

D.Switch to provisioned capacity mode and increase write capacity units.

AnswerC

Adaptive capacity helps distribute load; write sharding further spreads writes across partitions.

Why this answer

On-demand capacity mode already scales automatically, but per-partition throughput limits can still be reached if a single partition receives too many writes. Adaptive capacity (enabled by default) helps by dynamically adjusting per-partition throughput based on traffic patterns. However, if a specific partition key value experiences hot-spotting, write sharding—adding a random suffix to the partition key—further distributes writes across multiple partitions, increasing overall write capacity.

Option A (DAX) caches reads, not writes. Option B (auto scaling with provisioned) does not solve per-partition limits; it adjusts table-level capacity. Option D (provisioned with increased WCU) also addresses table-level capacity, not per-partition limits.

Practice this question →

347

MCQmedium

A company is running a critical application on Amazon RDS for Oracle. They need to ensure high availability with automatic failover in case of a database failure. The database size is 500 GB. Which solution should they implement?

A.Create a cross-Region read replica

B.Migrate to Amazon DynamoDB Global Tables

C.Take regular snapshots and restore in a different Availability Zone

D.Enable Multi-AZ deployment

AnswerD

Multi-AZ automatically fails over to a standby instance.

Why this answer

Multi-AZ deployment for Amazon RDS for Oracle provides synchronous replication to a standby instance in a different Availability Zone, with automatic failover in the event of a database failure. This ensures high availability without manual intervention, meeting the requirement for automatic failover for a 500 GB Oracle database.

Exam trap

The trap here is that candidates may confuse cross-Region read replicas or snapshot-based recovery with automatic failover, but only Multi-AZ provides synchronous replication and automatic failover without manual intervention for RDS databases.

How to eliminate wrong answers

Option A is wrong because cross-Region read replicas are designed for disaster recovery and read scaling, not automatic failover within the same region; they require manual promotion and do not provide synchronous replication. Option B is wrong because DynamoDB Global Tables are for NoSQL workloads, not Oracle relational databases, and migrating would require significant application changes. Option C is wrong because taking regular snapshots and restoring in a different Availability Zone is a manual process that does not provide automatic failover; it results in data loss from the last snapshot and downtime during restore.

Practice this question →

348

Multi-Selectmedium

Which TWO of the following are advantages of using Amazon Aurora over standard RDS for MySQL?

Select 2 answers

A.Aurora automatically fails over to a read replica in case of primary failure.

B.Aurora is compatible with PostgreSQL, so you can migrate from SQL Server easily.

C.Aurora can deliver up to 5x the throughput of standard MySQL on the same hardware.

D.Aurora supports up to 15 read replicas, while RDS for MySQL only supports 5.

E.Aurora provides higher durability with 6 copies of data across 3 AZs.

AnswersC, E

Aurora's architecture provides significant performance improvements.

Why this answer

Amazon Aurora uses a distributed, SSD-backed storage subsystem that separates compute from storage, enabling it to deliver up to 5x the throughput of standard MySQL running on the same hardware. This performance gain comes from the Aurora storage engine's ability to reduce I/O operations and parallelize writes across multiple storage nodes.

Exam trap

The trap here is that candidates may confuse the number of read replicas supported by RDS for MySQL (which is 15, not 5) and assume Aurora's higher replica count is a unique advantage, while in fact both services support the same limit.

Practice this question →

349

MCQhard

A gaming company uses Amazon DynamoDB with global tables across two regions. They notice increased write latency and throttling during peak hours. The access pattern is mostly writes to a small set of hot partitions. Which design change would best address this?

A.Implement write sharding using a random suffix on the partition key

B.Enable DynamoDB Accelerator (DAX)

C.Switch to DynamoDB on-demand capacity mode

D.Increase write capacity using auto scaling

AnswerA

Write sharding distributes writes evenly across partitions.

Why this answer

The issue is hot partitions caused by a small set of partition keys receiving the majority of writes. By implementing write sharding with a random suffix on the partition key, you distribute writes across multiple partitions, reducing throttling and write latency. This directly addresses the root cause of uneven access patterns, unlike the other options that either cache reads, adjust capacity mode, or scale capacity without solving the partition-level bottleneck.

Exam trap

The trap here is that candidates often confuse throughput scaling (options C and D) with partition-level distribution, failing to recognize that hot partitions require a key design change, not just capacity adjustments.

How to eliminate wrong answers

Option B is wrong because DynamoDB Accelerator (DAX) is an in-memory cache that primarily improves read performance, not write latency or throttling on hot partitions. Option C is wrong because switching to on-demand capacity mode handles traffic spikes but does not resolve the underlying hot partition issue; throttling can still occur at the partition level if a single partition exceeds its throughput limit. Option D is wrong because increasing write capacity with auto scaling only raises the table-level throughput, but if writes are concentrated on a few partitions, those partitions will still hit their individual limits and cause throttling.

Practice this question →

350

MCQhard

An application using the above IAM policy is trying to perform a Scan operation on the 'Orders' table. What will happen?

A.The Scan operation will succeed because the Deny is on all resources but the Allow is specific to the table.

B.The Scan operation will succeed because the policy allows other operations on the table.

C.The Scan operation will fail because the policy does not explicitly allow Scan.

D.The Scan operation will fail because the explicit Deny on dynamodb:Scan overrides the Allow.

AnswerD

Explicit Deny always overrides Allow.

Why this answer

D is correct because IAM policy evaluation follows an explicit deny override: any explicit Deny statement for an action overrides any Allow for that same action, regardless of resource specificity. Since the policy includes an explicit Deny on dynamodb:Scan for all resources, the Scan operation on the 'Orders' table will be denied, even though an Allow statement grants other DynamoDB actions on that table.

Exam trap

The trap here is that candidates assume a resource-specific Allow (e.g., on the 'Orders' table) will override a broad Deny on all resources, but AWS IAM's explicit deny always wins, regardless of resource specificity.

How to eliminate wrong answers

Option A is wrong because an explicit Deny on all resources overrides a resource-specific Allow for the same action; AWS IAM evaluates Deny statements before Allow statements, so the Deny on dynamodb:Scan blocks the operation. Option B is wrong because allowing other operations (e.g., GetItem, PutItem) does not imply Scan is allowed; each action must be explicitly permitted unless a wildcard is used, and the explicit Deny on Scan overrides any implicit or explicit Allow. Option C is wrong because the failure is not due to a missing explicit Allow for Scan—it is due to the explicit Deny on Scan, which takes precedence over any Allow.

Practice this question →

351

MCQhard

A social media application uses Amazon DynamoDB with a table that has a partition key of 'user_id' and a sort key of 'post_timestamp'. The application frequently queries for the 10 most recent posts by a specific user. The query pattern uses a 'begins_with' condition on the sort key with a timestamp prefix. Recently, the query latency has increased significantly for users with many posts. Which design change would improve query performance?

A.Create a local secondary index (LSI) with 'user_id' as partition key and 'post_timestamp' as sort key, and query using reverse order with a limit of 10.

B.Enable DynamoDB Accelerator (DAX) to cache the query results.

C.Create a global secondary index (GSI) with 'post_timestamp' as partition key and 'user_id' as sort key.

D.Change the table's partition key to 'post_id' to distribute data more evenly.

AnswerA

Creating an LSI with 'user_id' as partition key and 'post_timestamp' as sort key allows querying in reverse order with a limit of 10, efficiently retrieving the most recent posts for a user.

Why this answer

The optimal approach to retrieve the 10 most recent posts for a user is to query the table or an index with the partition key 'user_id' and use ScanIndexForward=false with a Limit of 10. Option A achieves this by creating a Local Secondary Index (LSI) with the same partition key and sort key as the base table. While the base table itself can be queried in reverse order, creating an LSI dedicated to this query pattern can improve performance by offloading reads from the base table index, reducing contention and ensuring fast consistent reads.

The LSI can be provisioned with its own read capacity to handle the frequent queries for the most recent posts per user, thus improving overall query performance. Options B, C, and D do not effectively address the specific requirement of per-user recent posts. Option B (DAX) may reduce latency but does not fix the underlying inefficient query pattern (scanning many items per user).

Option C (GSI with timestamp as partition key) would allow querying posts globally by time, not per user. Option D (changing partition key to post_id) would break the ability to query all posts by a user. Therefore, Option A is the correct design change.

Exam trap

A common trap is to think that a Local Secondary Index must have a different sort key than the base table. However, DynamoDB allows creating an LSI with the same sort key as the base table; this can be used to provision separate capacity for specific query patterns. Another trap is overlooking that the base table already supports reverse-order queries with ScanIndexForward=false, but creating an LSI can still be beneficial for workload isolation.

How to eliminate wrong answers

Option B is wrong because DynamoDB Accelerator (DAX) caches query results to reduce latency for repeated queries, but it does not address the underlying issue of inefficient scanning caused by the 'begins_with' condition on a large number of items per partition; DAX would only help if the same query is repeated frequently, not for the general query pattern. Option C is wrong because a GSI with 'post_timestamp' as partition key and 'user_id' as sort key would not efficiently retrieve the 10 most recent posts for a specific user, as the partition key is timestamp-based, requiring a scan across all partitions to filter by user_id. Option D is wrong because changing the partition key to 'post_id' would break the existing query pattern that relies on user_id to find posts for a specific user, and it would not improve performance for the 'most recent posts by user' query.

Practice this question →

352

Multi-Selecteasy

Which TWO of the following are advantages of using Amazon DynamoDB over Amazon RDS for MySQL for a workload that requires high scalability and low maintenance? (Select TWO.)

Select 2 answers

A.Strong consistency by default

B.Support for complex joins and transactions

C.No need to manage database servers or patches

D.Built-in read replicas for scaling reads

E.Automatic scaling of read/write capacity

AnswersC, E

DynamoDB is serverless and fully managed.

Why this answer

Amazon DynamoDB is a fully managed NoSQL database service that eliminates the need for server provisioning, patching, or maintenance. Unlike Amazon RDS for MySQL, where you are responsible for managing the underlying DB instance (including OS and database engine patches), DynamoDB abstracts all infrastructure management, allowing you to focus solely on data access patterns.

Exam trap

The trap here is that candidates often confuse DynamoDB’s optional strong consistency with a default setting, or they assume that a NoSQL database like DynamoDB supports SQL-style joins, leading them to select options A or B despite those being features of relational databases like RDS for MySQL.

Practice this question →

353

Multi-Selectmedium

A company is designing a database for an e-commerce platform that needs to store product catalog data. The data is highly relational with many-to-many relationships between products, categories, and suppliers. The platform requires ACID transactions and complex joins. Which TWO AWS database solutions are suitable for this workload? (Choose TWO.)

Select 2 answers

A.Amazon Aurora MySQL

B.Amazon RDS for PostgreSQL

C.Amazon ElastiCache for Redis

D.Amazon Neptune

E.Amazon DynamoDB

AnswersA, B

Aurora is a relational database with ACID support and complex join capabilities.

Why this answer

Amazon Aurora MySQL is a fully ACID-compliant relational database that supports complex joins and many-to-many relationships through foreign keys and junction tables. It is optimized for high-throughput e-commerce workloads with features like auto-scaling storage and up to 15 low-latency read replicas, making it suitable for product catalog data that requires transactional consistency.

Exam trap

The trap here is that candidates often choose DynamoDB for its scalability, overlooking that it cannot handle complex joins and many-to-many relational structures, or they select Neptune thinking it is suitable for any connected data, but it lacks SQL-based ACID transactions and relational integrity needed for product catalogs.

Practice this question →

354

MCQhard

A company is designing a document management system using Amazon DocumentDB. Each document is up to 10 MB. The application needs to retrieve multiple documents by their IDs in a single request. The IDs are known at query time. Which query pattern is most efficient?

A.Use a find operation with the $or operator on the _id field.

B.Use a scan operation with a filter on the _id field.

C.Use a find operation with the $in operator on the _id field.

D.Issue multiple get operations in parallel.

AnswerC

Uses index on _id efficiently.

Why this answer

The `$in` operator on the `_id` field allows DocumentDB to use the primary key index directly, retrieving multiple documents in a single round trip with minimal overhead. This is the most efficient pattern because it leverages the clustered index on `_id` and avoids the performance penalty of multiple queries or full scans.

Exam trap

The trap here is that candidates often assume parallel `get` operations (Option D) are fastest because they think concurrency equals speed, but they overlook the overhead of multiple network round trips and the fact that DocumentDB's `$in` operator performs a single index seek for all IDs, which is far more efficient under load.

How to eliminate wrong answers

Option A is wrong because the `$or` operator on `_id` forces DocumentDB to evaluate each condition separately, often resulting in an index scan or a collection scan rather than a single index seek, which is less efficient than `$in`. Option B is wrong because a scan operation with a filter on `_id` ignores the primary key index entirely, reading every document in the collection and then filtering, which is extremely inefficient for large collections. Option D is wrong because issuing multiple `get` operations in parallel increases network round trips and connection overhead, and DocumentDB does not benefit from parallel single-document lookups as much as a batched index seek via `$in`.

Practice this question →

355

MCQeasy

A startup needs a fully managed relational database with automated backups and scaling. They expect unpredictable workloads. Which AWS service meets these requirements?

A.Amazon DynamoDB

B.Amazon Redshift

C.Amazon Aurora Serverless

D.Amazon ElastiCache

AnswerC

Fully managed relational database with auto-scaling and backups.

Why this answer

Amazon Aurora Serverless is a fully managed relational database that automatically scales capacity up or down based on application demand, making it ideal for unpredictable workloads. It also provides automated backups, continuous backups to Amazon S3, and point-in-time recovery, meeting all stated requirements.

Exam trap

The trap here is that candidates often confuse DynamoDB's on-demand scaling with relational database requirements, overlooking that DynamoDB is NoSQL and not relational, or they mistakenly think Redshift's scaling capabilities apply to transactional workloads.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB is a NoSQL key-value and document database, not a relational database, so it does not meet the requirement for a relational database. Option B is wrong because Amazon Redshift is a petabyte-scale data warehouse optimized for analytical workloads, not a transactional relational database, and it does not automatically scale for unpredictable transactional workloads. Option D is wrong because Amazon ElastiCache is an in-memory caching service (supporting Redis or Memcached), not a relational database, and it does not provide automated backups or scaling for persistent relational data.

Practice this question →

356

MCQmedium

A company uses Amazon DynamoDB to store session data for a web application. During peak hours, they experience occasional ProvisionedThroughputExceededException errors. The table has a read capacity of 1000 RCU and a write capacity of 500 WCU. The application uses strongly consistent reads. The traffic pattern shows short bursts of reads exceeding 1000 RCU. What is the MOST cost-effective way to handle these bursts without changing the application?

A.Enable DynamoDB Auto Scaling to adjust RCU dynamically

B.Increase RCU to 2000 and enable Auto Scaling

C.Switch to eventually consistent reads

D.Use DynamoDB Accelerator (DAX) for caching reads

AnswerA

Correct. Auto Scaling dynamically adjusts RCU based on demand, handling bursts cost-effectively without application changes.

Why this answer

Enabling DynamoDB Auto Scaling (Option A) is the most cost-effective solution because it automatically adjusts read capacity in response to traffic patterns, handling short bursts without manual intervention or over-provisioning. It does not require application changes. Option B is more expensive due to higher static capacity.

Option C requires switching to eventually consistent reads, which would change application behavior and may not be acceptable for session data requiring strong consistency. Option D adds cost and complexity with DAX without addressing read capacity limits directly.

Practice this question →

357

MCQeasy

A company uses Amazon DynamoDB for a session management store. The application writes and reads session data frequently. The team notices that write requests occasionally fail with ProvisionedThroughputExceededException. They want a cost-effective solution to handle these bursts. What should they do?

A.Increase the provisioned write capacity to a higher fixed value

B.Use DynamoDB Accelerator (DAX) to cache writes

C.Implement an Amazon SQS queue to buffer writes

D.Enable DynamoDB Auto Scaling for the table

AnswerD

Auto Scaling adjusts capacity based on actual usage, handling bursts cost-effectively.

Why this answer

DynamoDB Auto Scaling dynamically adjusts the provisioned write capacity based on actual traffic patterns, handling bursts cost-effectively by scaling up during spikes and down during lulls. This avoids the fixed-cost overhead of a higher provisioned value (Option A) and directly addresses the ProvisionedThroughputExceededException by ensuring sufficient capacity during bursts.

Exam trap

The trap here is that candidates often confuse DAX (a read cache) with a write buffer, or assume that a higher fixed capacity is the only way to handle bursts, ignoring the cost-efficiency requirement that points to Auto Scaling.

How to eliminate wrong answers

Option A is wrong because increasing provisioned write capacity to a higher fixed value would eliminate the bursts but at a constant higher cost, which is not cost-effective for variable workloads. Option B is wrong because DynamoDB Accelerator (DAX) is an in-memory cache for reads, not writes; it cannot buffer or absorb write bursts or prevent ProvisionedThroughputExceededException on write operations. Option C is wrong because while an SQS queue can buffer write requests, it introduces asynchronous processing and latency, which is unsuitable for a session management store that requires immediate, synchronous writes to maintain session consistency.

Practice this question →

358

Multi-Selecthard

Which TWO design patterns help meet ACID compliance requirements in a distributed database environment while maintaining high availability?

Select 2 answers

A.Use an eventually consistent read model to improve performance.

B.Implement Amazon Aurora Global Database for cross-Region ACID transactions.

C.Adopt a saga pattern to manage distributed transactions.

D.Use Amazon DynamoDB Transactions for multi-item ACID operations.

E.Implement DynamoDB Streams to capture changes for audit.

AnswersB, D

Aurora Global Database provides ACID within each region.

Why this answer

Amazon Aurora Global Database is designed to support cross-Region ACID transactions by using a primary cluster in one AWS Region and up to five secondary read-only clusters in other Regions. It replicates data asynchronously from the primary to the secondary Regions, but each secondary cluster can be promoted to a primary in under a minute, ensuring high availability while maintaining ACID compliance for transactions that span multiple Regions.

Exam trap

The DBS-C01 exam often tests the distinction between ACID-compliant distributed transactions and patterns that provide only eventual consistency or compensation-based semantics, leading candidates to select the saga pattern or eventually consistent models as valid ACID solutions.

Practice this question →

359

MCQeasy

A gaming company uses Amazon DynamoDB as the database for user profiles and game state. The application requires strongly consistent reads for the user's own profile, but eventually consistent reads for leaderboard queries. How should the company design the table and queries?

A.Create two separate tables: one for strong consistency and one for eventual consistency.

B.Use the ConsistentRead parameter set to true for profile queries and false for leaderboard queries.

C.Enable DynamoDB Accelerator (DAX) for strong consistency on all reads.

D.Configure DynamoDB Streams to replicate data to a second table for strong consistency.

AnswerB

This allows per-request consistency control.

Why this answer

DynamoDB supports both strongly consistent reads and eventually consistent reads on the same table, controlled by the `ConsistentRead` parameter in the `GetItem`, `Query`, or `Scan` API calls. Setting `ConsistentRead=true` for profile queries ensures the most up-to-date data, while `ConsistentRead=false` (the default) for leaderboard queries provides lower latency and higher throughput, which is ideal for read-heavy, non-critical data. This design avoids the cost and complexity of multiple tables or additional services.

Exam trap

The trap here is that candidates often assume strong consistency requires a separate table or a caching layer like DAX, but DynamoDB natively supports both consistency models on the same table via a simple API parameter, making the other options over-engineered or incorrect.

How to eliminate wrong answers

Option A is wrong because creating two separate tables for consistency levels is unnecessary and wasteful; DynamoDB supports both consistency models on a single table via the `ConsistentRead` parameter. Option C is wrong because DAX is a caching layer that provides eventually consistent reads by default and does not guarantee strongly consistent reads; it is designed for read-heavy workloads with relaxed consistency, not for enforcing strong consistency. Option D is wrong because DynamoDB Streams is used for change data capture and replication, not for serving strongly consistent reads; replicating to a second table would introduce eventual consistency between tables and add latency and cost without solving the requirement.

Practice this question →

360

MCQmedium

A company is migrating an on-premises Oracle OLTP database to Amazon Aurora PostgreSQL. The database has a complex schema with stored procedures, triggers, and sequences. During the migration, the team notices that the conversion tool reports several incompatibilities. Which strategy should the team use to handle the database schema changes with minimal downtime?

A.Deploy Amazon RDS for PostgreSQL with Babelfish to run Oracle PL/SQL code natively.

B.Use AWS Database Migration Service (DMS) with the AWS Schema Conversion Tool (SCT) to convert the schema and migrate data, then handle remaining incompatibilities during a cutover window.

C.Use pg_dump and pg_restore to migrate the schema, and then test and fix any errors.

D.Manually rewrite all stored procedures and triggers to PostgreSQL syntax before migration.

AnswerB

SCT automates schema conversion, and DMS supports minimal downtime via ongoing replication.

Why this answer

AWS DMS with SCT is the recommended approach for heterogeneous migrations like Oracle to Aurora PostgreSQL. SCT converts the schema (including stored procedures, triggers, and sequences) and identifies incompatibilities, while DMS handles ongoing replication to minimize downtime. The remaining incompatibilities can be resolved during a planned cutover window, which is the standard strategy for complex schema migrations with minimal downtime.

Exam trap

The trap here is that candidates may assume Babelfish can handle Oracle PL/SQL because it supports SQL Server T-SQL, but Babelfish is specifically for SQL Server compatibility, not Oracle.

How to eliminate wrong answers

Option A is wrong because Babelfish is designed for SQL Server T-SQL compatibility, not Oracle PL/SQL; it cannot run Oracle PL/SQL code natively. Option C is wrong because pg_dump and pg_restore are used for PostgreSQL-to-PostgreSQL migrations, not for converting Oracle schemas; they would fail on Oracle-specific syntax and do not handle schema conversion. Option D is wrong because manually rewriting all stored procedures and triggers before migration would cause significant downtime and is not a minimal-downtime strategy; SCT automates most of the conversion, and manual fixes are better handled during cutover.

Practice this question →

361

MCQhard

A financial services company uses Amazon DynamoDB to store transaction records. The table has a partition key of 'account_id' and a sort key of 'transaction_time'. Recent queries for a specific account's transactions within a time range are experiencing high latency. The table has read capacity units set to auto-scaling. Which design change would most improve query performance?

A.Change the sort key to a composite attribute for better filtering.

B.Enable DynamoDB Accelerator (DAX) for the table.

C.Increase the read capacity units for the table.

D.Create a global secondary index with a different partition key.

AnswerD

GSI with a different key distributes reads across partitions.

Why this answer

Creating a global secondary index (GSI) with a different partition key can distribute read traffic across multiple partitions, avoiding hot partitions caused by frequent access to the same account_id. This improves query performance for time-range queries on a specific account. Option A (changing sort key) would not help if the partition itself is overloaded.

Option B (DAX) caches results but does not address hot partitions, and may not help if the queries are not cacheable. Option C (increasing RCUs) may not help if the existing partition is hot due to throttling at the partition level.

Practice this question →

362

Multi-Selectmedium

A company is designing a new application that requires a relational database with read replicas for reporting. The application has unpredictable traffic patterns. The company wants to minimize operational overhead and automatically scale compute capacity. Which TWO services should the company consider?

Select 2 answers

A.Amazon DynamoDB Accelerator (DAX)

B.Amazon RDS for MySQL with Multi-AZ

C.Amazon RDS for PostgreSQL with read replicas

D.Amazon Aurora Serverless v2

E.Amazon RDS Proxy

AnswersD, E

Amazon Aurora Serverless v2 automatically scales compute capacity, supports read replicas for reporting, and minimizes operational overhead, making it a correct choice.

Why this answer

The company requires a relational database with read replicas for reporting, minimal operational overhead, and automatic scaling of compute capacity. Amazon Aurora Serverless v2 (D) meets all these requirements: it is a relational database compatible with PostgreSQL and MySQL, automatically scales compute capacity based on demand, and supports up to 15 read replicas for reporting workloads. Amazon RDS Proxy (E) provides connection pooling to handle unpredictable traffic patterns efficiently, reducing overhead and improving scalability.

Together, these two services fulfill the requirements without the need for an additional database instance, making option C unnecessary.

Exam trap

The trap here is that candidates may think they need a separate database service like RDS for PostgreSQL to get read replicas, not realizing that Aurora Serverless v2 already supports read replicas with automatic scaling. They might also overlook the role of RDS Proxy in managing unpredictable traffic.

Practice this question →

363

MCQmedium

Refer to the exhibit. A company uses this DynamoDB table to store user session data. The application frequently queries by user_id alone to get all sessions for a user. However, the query is slow. What is the most likely cause?

A.The table's partition key is session_id, not user_id, so querying by user_id requires a scan.

B.The table has no sort key on user_id.

C.The table has too many items, causing slow scans.

D.The provisioned read capacity is too low.

AnswerA

Without a GSI on user_id, queries on user_id are scans.

Why this answer

The table's primary key is session_id, not user_id. Querying by user_id without a secondary index forces DynamoDB to perform a full table scan, which reads every item and is significantly slower than a query operation. This is the most likely cause of the slow performance.

Exam trap

The trap here is that candidates often assume any attribute can be queried efficiently, failing to recognize that DynamoDB requires a primary key or index for efficient lookups, and that a scan is the fallback for non-key attributes.

How to eliminate wrong answers

Option B is wrong because a sort key on user_id would not help; the table already has a sort key (timestamp), but the issue is that user_id is not the partition key, so queries by user_id still require a scan. Option C is wrong because while a large number of items can slow scans, the fundamental problem is the access pattern mismatch (scan vs. query), not just item count. Option D is wrong because low provisioned read capacity would cause throttling (ProvisionedThroughputExceededException), not inherently slow queries; the described slowness is due to scanning, not capacity limits.

Practice this question →

364

Multi-Selecteasy

A company is designing a database for a social media application that requires storing user profiles, posts, and follower relationships. The application needs low-latency queries for user timelines and social graph traversals. Which TWO AWS database services should the database specialist consider? (Choose TWO.)

Select 2 answers

A.Amazon Timestream

B.Amazon Neptune

C.Amazon Redshift

D.Amazon RDS for MySQL

E.Amazon DynamoDB

AnswersB, E

Neptune is a graph database purpose-built for social graph traversals.

Why this answer

Amazon Neptune is a fully managed graph database service optimized for storing and querying highly connected data, such as social graphs. It supports property graph and RDF models, enabling low-latency traversals of follower relationships and user timelines using Gremlin or SPARQL queries.

Exam trap

The trap here is that candidates may choose Amazon RDS for MySQL (Option D) thinking relational databases can handle graph queries with joins, but they fail to recognize that Neptune provides native graph traversal performance that relational databases cannot match for deeply connected data.

Practice this question →

365

Multi-Selectmedium

A company is designing a database for a global e-commerce platform with strong consistency requirements. The database must support cross-region disaster recovery with RPO < 1 second and RTO < 1 minute. Which TWO AWS database services meet these requirements?

Select 2 answers

A.Amazon Aurora Global Database

B.Amazon RDS Multi-AZ

C.Amazon Redshift with cross-region snapshot copy

D.Amazon ElastiCache for Redis with Global Datastore

E.Amazon DynamoDB Global Tables

AnswersA, E

Aurora Global Database replicates across regions with RPO of 1 second and RTO of 1 minute.

Why this answer

Amazon Aurora Global Database uses storage-based replication with a typical latency of under 1 second, supporting cross-region disaster recovery with an RPO of less than 1 second and an RTO of less than 1 minute by promoting a secondary region to primary. Amazon DynamoDB Global Tables provide multi-region, fully replicated tables with strong consistency and automatic failover, achieving RPO of less than 1 second and RTO of less than 1 minute through active-active replication.

Exam trap

The trap here is that candidates confuse Multi-AZ (single-region HA) with cross-region DR, or assume that snapshot-based replication (like Redshift) can meet sub-second RPO, when in reality only continuous replication services like Aurora Global Database and DynamoDB Global Tables can achieve such low RPO and RTO.

Practice this question →

366

MCQhard

A company uses Amazon DynamoDB for a shopping cart application. During a flash sale, write requests are throttled due to hot partitions. The access pattern is evenly distributed across items, but the partition key is the customer ID. Which design change would best mitigate throttling?

A.Enable DynamoDB adaptive capacity.

B.Change the partition key to a single value for all items.

C.Increase the provisioned write capacity to a higher fixed value.

D.Add a DAX cluster in front of DynamoDB.

AnswerA

Adaptive capacity rebalances throughput across partitions.

Why this answer

DynamoDB adaptive capacity automatically adjusts throughput capacity based on traffic patterns, which helps mitigate hot partitions by redistributing unused capacity from less-accessed partitions to heavily accessed ones. This is ideal for the flash sale scenario where write requests are throttled due to uneven access across customer ID partitions, even though the overall access pattern is evenly distributed.

Exam trap

The trap here is that candidates may think increasing provisioned capacity (Option C) is the straightforward fix for throttling, but they overlook that hot partitions require a design-level solution like adaptive capacity or partition key redesign to distribute writes evenly.

How to eliminate wrong answers

Option B is wrong because changing the partition key to a single value for all items would create an extreme hot partition, causing all writes to target one partition and severely throttling the entire table. Option C is wrong because increasing provisioned write capacity to a higher fixed value does not address the root cause of hot partitions; it only increases overall throughput but still allows throttling on individual partitions if the access pattern is skewed. Option D is wrong because adding a DAX cluster in front of DynamoDB is a caching layer that primarily improves read performance and reduces read latency, but it does not mitigate write throttling or hot partition issues on the write path.

Practice this question →

367

MCQhard

A company runs a critical Oracle database on Amazon RDS. The database has a large table that is frequently accessed by multiple applications. The team wants to implement caching to reduce the load on the database. The cached data must be strongly consistent with the database. Which caching strategy should they use?

A.Eventual consistency with DynamoDB Accelerator (DAX)

B.Read-only cache with Amazon ElastiCache

C.Write-through cache using Amazon ElastiCache

D.Lazy loading with cache-aside pattern

AnswerC

Write-through ensures data is written to cache and DB together, maintaining strong consistency.

Why this answer

The write-through cache strategy ensures that every write to the database also updates the cache synchronously, so the cached data is always strongly consistent with the database. This is critical for the Oracle RDS workload where multiple applications require immediate consistency. Amazon ElastiCache (Redis or Memcached) supports write-through by updating the cache on every write operation, preventing stale reads.

Exam trap

The trap here is that candidates often confuse 'read-only cache' or 'lazy loading' with strong consistency, not realizing that only write-through synchronously updates the cache on every write, making it the only option that guarantees the cached data is always identical to the database.

How to eliminate wrong answers

Option A is wrong because DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB, not for Amazon RDS Oracle, and eventual consistency does not meet the strong consistency requirement. Option B is wrong because a read-only cache only caches data that is read, not written, so it cannot ensure strong consistency for data that is updated; it would serve stale data until the cache is invalidated or refreshed. Option D is wrong because lazy loading (cache-aside) loads data into the cache only on a cache miss, which can lead to stale data if the database is updated before the cache is refreshed; it does not guarantee strong consistency.

Practice this question →

368

MCQmedium

A company is designing a database for a social media application that stores user posts. Each post can have multiple tags. The workload requires low-latency queries to find all posts with a specific tag. Which database design is most suitable?

A.Amazon ElastiCache for Memcached storing posts and tags as key-value pairs.

B.Amazon DynamoDB with a Global Secondary Index on the tag attribute.

C.Amazon RDS for MySQL with a normalized schema and JOIN queries.

D.Amazon Neptune with a graph model for tags and posts.

AnswerB

GSI provides fast query by tag.

Why this answer

Amazon DynamoDB with a Global Secondary Index (GSI) on the tag attribute is the most suitable design because it allows low-latency queries to find all posts with a specific tag without scanning the entire table. The GSI enables efficient querying by tag as a partition key, supporting the required access pattern with consistent single-digit millisecond performance at any scale.

Exam trap

The trap here is that candidates may choose Amazon RDS for MySQL (Option C) due to familiarity with normalized relational designs, overlooking that DynamoDB's GSI provides superior performance and scalability for high-velocity, low-latency tag-based queries without the overhead of JOINs.

How to eliminate wrong answers

Option A is wrong because Amazon ElastiCache for Memcached is an in-memory cache, not a persistent database; it lacks native indexing for tag-based queries and would require application-level logic to maintain and query tag-to-post mappings, leading to data loss on cache eviction or failure. Option C is wrong because Amazon RDS for MySQL with a normalized schema and JOIN queries introduces relational overhead and potential performance bottlenecks at scale, as JOINs on large tables with many-to-many relationships (posts and tags) cannot match the low-latency, single-query access provided by DynamoDB's GSI. Option D is wrong because Amazon Neptune, while capable of modeling tags and posts as a graph, is overkill for this simple key-value access pattern and incurs higher latency and cost compared to DynamoDB's direct index lookup.

Practice this question →

369

MCQmedium

A company runs an e-commerce platform on Amazon RDS for PostgreSQL. During a flash sale, the database experiences high write load and read replicas lag significantly. The application uses read replicas for reporting queries. Which design change would most effectively reduce replica lag without compromising write performance?

A.Increase the instance size of the primary database.

B.Add more read replicas to distribute the reporting load.

C.Migrate to Amazon Aurora with read replicas.

D.Convert the RDS instance to a Multi-AZ deployment.

AnswerC

Aurora has faster replication (typically <100ms) and is designed to handle high write loads with minimal replica lag.

Why this answer

Amazon Aurora's distributed storage architecture decouples compute from storage, allowing replicas to apply redo logs with minimal overhead compared to RDS for PostgreSQL's physical replication. Aurora's replicas share the same underlying storage volume, so replica lag is significantly reduced even under heavy write loads, while write performance on the primary remains unaffected due to the asynchronous, log-based replication mechanism.

Exam trap

The trap here is that candidates assume adding more replicas or scaling the primary will solve replication lag, but they fail to recognize that the fundamental replication mechanism in RDS for PostgreSQL (streaming WAL) is the bottleneck, whereas Aurora's shared-storage architecture inherently minimizes lag.

How to eliminate wrong answers

Option A is wrong because increasing the primary instance size may improve write throughput but does not address the root cause of replica lag, which is the replication bottleneck in RDS for PostgreSQL's streaming replication; the primary's larger size does not speed up log shipping or apply on replicas. Option B is wrong because adding more read replicas does not reduce lag on existing replicas; it may even increase replication overhead on the primary, potentially worsening lag for all replicas under high write load. Option D is wrong because Multi-AZ deployment provides high availability with synchronous replication to a standby instance, but it does not create read replicas or reduce lag for reporting queries; the standby is not used for reads and does not alleviate replica lag.

Practice this question →

370

MCQmedium

A company uses Amazon DynamoDB for a time-series IoT application. Each device sends a data point every second. The application queries data by device ID and timestamp range. Which table design is most efficient?

A.Use a composite key of device ID and timestamp as the partition key.

B.Use device ID as the partition key and a random suffix as the sort key.

C.Use timestamp as the partition key and device ID as the sort key.

D.Use device ID as the partition key and timestamp as the sort key.

AnswerD

Allows efficient range queries on timestamp per device.

Why this answer

It models the access pattern directly: using device ID as the partition key ensures all data for a device is co-located, and timestamp as the sort key enables efficient range queries (e.g., Query with KeyConditionExpression on timestamp between start and end). This design avoids hot partitions and allows DynamoDB to retrieve the exact time-series slice without scanning.

Exam trap

AWS often tests the misconception that a composite partition key (device ID + timestamp) is needed for uniqueness, but the trap here is that candidates forget the sort key's role in enabling range queries and instead try to force uniqueness into the partition key, which breaks the access pattern.

How to eliminate wrong answers

Option A is wrong because using a composite key of device ID and timestamp as the partition key would create a unique partition for each data point, making it impossible to query all data for a device across a time range without a full scan. Option B is wrong because using a random suffix as the sort key destroys the natural ordering of timestamps, preventing efficient range queries and forcing a scan to filter by time. Option C is wrong because using timestamp as the partition key leads to a single hot partition for each second (or time granularity), causing throttling and poor distribution, and querying by device ID would require a scan across all partitions.

Practice this question →

371

MCQeasy

A financial services company needs a relational database with high availability and automatic failover across three Availability Zones in us-east-1. The workload consists of OLTP transactions with occasional analytic queries. Which database solution meets these requirements?

A.Amazon RDS for MySQL with Multi-AZ (2 AZs)

B.Amazon DynamoDB global tables

C.Amazon Aurora MySQL with Multi-AZ deployment across 3 AZs

D.Amazon Redshift with cross-region snapshots

AnswerC

Aurora provides automatic failover across 3 AZs and supports OLTP and analytics.

Why this answer

Amazon Aurora MySQL with Multi-AZ deployment across 3 AZs meets the requirements because Aurora automatically replicates your data six ways across three Availability Zones, with a primary DB instance in one AZ and two read replicas in the other two AZs. In the event of a failure, Aurora automatically fails over to a read replica in under 30 seconds without data loss, providing high availability and automatic failover across three AZs. Aurora also supports both OLTP transactions and can handle occasional analytic queries via Aurora Replicas or Aurora Global Database for read scaling.

Exam trap

The trap here is that candidates often confuse RDS Multi-AZ (which only supports 2 AZs) with Aurora's native multi-AZ replication across 3 AZs, or they mistakenly think DynamoDB global tables (a NoSQL service) can replace a relational database for OLTP workloads requiring ACID transactions.

How to eliminate wrong answers

Option A is wrong because Amazon RDS for MySQL with Multi-AZ (2 AZs) only supports a standby replica in a single secondary AZ, not across three AZs, and failover is limited to two AZs, failing the requirement for three Availability Zones. Option B is wrong because Amazon DynamoDB global tables is a NoSQL key-value and document database, not a relational database, and while it provides multi-region replication, it does not support relational queries or ACID transactions in the same way as a relational database, and it does not offer automatic failover across three AZs in a single region. Option D is wrong because Amazon Redshift is a data warehouse optimized for analytic queries, not OLTP transactions, and cross-region snapshots provide disaster recovery but not automatic failover across three AZs for high availability.

Practice this question →

372

MCQhard

A company is running a production Amazon DynamoDB table that supports a gaming application with millions of concurrent users. The table uses on-demand capacity mode. Recently, the application started experiencing throttling (ProvisionedThroughputExceededException) during peak hours. The company wants to resolve this with minimal operational overhead. What should the company do?

A.Enable DynamoDB Accelerator (DAX) to cache reads

B.Partition the table across multiple tables and use application-level sharding

C.Request a service quota increase for the on-demand table's maximum throughput

D.Switch to provisioned capacity mode with auto scaling

AnswerC

On-demand tables have default throughput limits that can be increased.

Why this answer

On-demand capacity mode in DynamoDB has a default throughput quota (typically 40,000 read/write request units per second per table, though this can vary by region and account). When traffic exceeds this soft limit, DynamoDB returns ProvisionedThroughputExceededException. Requesting a service quota increase raises this ceiling, allowing the table to handle higher bursts without throttling, and requires no architectural changes or capacity management—minimizing operational overhead.

Exam trap

The trap here is that candidates assume on-demand capacity is unlimited and never throttles, but AWS imposes a default throughput quota per table that must be explicitly raised for sustained high-traffic workloads.

How to eliminate wrong answers

Option A is wrong because DAX is an in-memory cache that reduces read latency and offloads read traffic, but it does not increase the table's write throughput quota; throttling on writes or high-volume reads that bypass DAX would still occur. Option B is wrong because application-level sharding across multiple tables adds significant operational complexity (routing logic, cross-table consistency, management overhead) and is unnecessary when a simple quota increase can resolve the throttling. Option D is wrong because switching to provisioned capacity with auto scaling introduces capacity planning and scaling lag, increasing operational overhead compared to simply raising the on-demand quota; on-demand already scales instantly within its quota limits.

Practice this question →

373

MCQhard

A company runs a customer-facing application on Amazon RDS for MySQL. The application experiences frequent read replicas lagging behind the primary due to long-running analytics queries. The analytics team runs complex SELECT queries that scan large tables. Which design change would minimize replica lag without affecting production writes?

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

B.Increase the instance size of the primary and all read replicas.

C.Enable Multi-AZ on the primary instance.

D.Create a cross-Region read replica for analytics queries.

AnswerD

Offloads analytics to a separate replica, reducing lag.

Why this answer

Creating a cross-Region read replica for analytics queries offloads the long-running SELECT statements to a separate read replica in a different AWS Region, isolating the analytics workload from the primary instance and its in-Region replicas. This prevents the analytics queries from competing for I/O and CPU resources on the primary or its local replicas, thereby minimizing replica lag without affecting production writes. Cross-Region replicas use asynchronous replication, so they can handle heavy read traffic without impacting the primary's write performance.

Exam trap

The trap here is that candidates often assume increasing instance size (Option B) or enabling Multi-AZ (Option C) will solve replica lag, but they fail to recognize that the lag is caused by resource contention from analytics queries on the same replicas, not by insufficient hardware or lack of high availability.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB, not for RDS for MySQL, and it does not address replica lag caused by long-running analytics queries on RDS. Option B is wrong because increasing the instance size of the primary and all read replicas may improve performance but does not isolate the analytics workload; the long-running queries on the replicas will still consume resources and cause lag, and it does not prevent the analytics queries from affecting the primary's write performance. Option C is wrong because enabling Multi-AZ on the primary instance provides high availability with a standby replica that cannot be used for reads (it is not a read replica), so it does not offload analytics queries or reduce replica lag.

Practice this question →

374

MCQmedium

A company uses Amazon RDS for PostgreSQL for its e-commerce platform. The application team reports increasing read latency on the primary instance during sales events. Which action should be taken to reduce read load on the primary?

A.Enable Multi-AZ deployment

B.Migrate to Amazon DynamoDB

C.Create one or more read replicas

D.Increase the instance size of the primary

AnswerC

Read replicas offload read queries from primary.

Why this answer

Creating one or more read replicas offloads read traffic from the primary RDS for PostgreSQL instance, directly addressing the increased read latency during sales events. Read replicas are asynchronous replicas that can serve SELECT queries, reducing the load on the primary without requiring application changes to the write path. This is the standard AWS solution for scaling read-heavy workloads in RDS.

Exam trap

The trap here is that candidates often confuse Multi-AZ with read replicas, assuming the standby in a Multi-AZ deployment can serve reads, but in RDS for PostgreSQL the standby is not accessible for read traffic—only Oracle and SQL Server Multi-AZ deployments offer readable standbys under specific configurations.

How to eliminate wrong answers

Option A is wrong because Multi-AZ deployment provides high availability and automatic failover via synchronous standby replication, but it does not offload read traffic—the standby is not accessible for reads in RDS for PostgreSQL. Option B is wrong because migrating to DynamoDB is a complete architectural change that is unnecessary for simply reducing read load on an existing PostgreSQL database; it would require rewriting application queries and data modeling, and it does not address the immediate symptom of read latency on the primary. Option D is wrong because increasing the instance size of the primary only vertically scales the server, which can help but is less cost-effective and does not distribute read load; it also does not leverage the horizontal read scaling that read replicas provide.

Practice this question →

375

MCQeasy

Refer to the exhibit. A developer created a DynamoDB table 'UserSessions' with a simple primary key. The application needs to query by user_id as well. What design change should the developer make to support this query efficiently?

A.Use a Scan operation with a filter

B.Add a sort key to the table

C.Create a Local Secondary Index on user_id

D.Create a Global Secondary Index on user_id

AnswerD

A GSI enables efficient querying on user_id.

Why this answer

A Global Secondary Index (GSI) on user_id allows efficient querying by user_id without altering the base table's primary key structure. The base table uses a simple primary key (likely session_id), and a GSI provides a separate index with its own partition key (user_id) to support non-key attribute queries with eventual consistency, enabling the application to query by user_id efficiently without scanning the entire table.

Exam trap

AWS often tests the misconception that a Local Secondary Index can be used to query on any attribute, but the trap here is that an LSI requires the same partition key as the base table, so it cannot index user_id as a partition key unless user_id is already the base table's partition key.

How to eliminate wrong answers

Option A is wrong because a Scan operation with a filter reads every item in the table, incurring high read capacity consumption and latency, which is inefficient for frequent queries. Option B is wrong because adding a sort key to the table would change the primary key structure, requiring a new table or migration, and does not directly support querying by user_id unless user_id is already the partition key. Option C 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; if the base table's partition key is not user_id, an LSI cannot index user_id as a partition key, making it unsuitable for this use case.

Practice this question →