CCNA Workload-Specific Database Design Questions

75 of 444 questions · Page 4/6 · Workload-Specific Database Design · Answers revealed

226
MCQmedium

An IoT company ingests sensor data into Amazon DynamoDB. The data has a partition key of device_id and sort key of timestamp. Queries often filter by device_id and a date range. Which design pattern improves query performance and reduces cost?

A.Use DynamoDB Time to Live (TTL) to expire old data
B.Create a local secondary index on device_id and timestamp
C.Enable DynamoDB Accelerator (DAX)
D.Create a global secondary index on timestamp
AnswerB

LSI allows efficient querying by device_id and sort key.

Why this answer

Option B is correct because a local secondary index (LSI) on device_id and timestamp allows efficient querying by device_id and a date range without scanning the entire table. Since the base table already uses device_id as the partition key, the LSI shares the same partition key but provides an alternate sort key (timestamp), enabling range queries on timestamp for each device_id. This reduces read capacity consumption and improves latency by avoiding full table scans or expensive filter expressions.

Exam trap

The trap here is that candidates often confuse local secondary indexes (LSI) with global secondary indexes (GSI), assuming a GSI on timestamp alone is sufficient, but without device_id as a partition key in the index, the query cannot efficiently isolate a single device's data.

How to eliminate wrong answers

Option A is wrong because DynamoDB TTL only expires old data automatically to reduce storage costs, but it does not improve query performance for filtering by device_id and date range. Option C is wrong because DynamoDB Accelerator (DAX) is an in-memory cache that speeds up read-heavy workloads, but it does not change the underlying query pattern or indexing; queries still require a full scan if no appropriate index exists. Option D is wrong because a global secondary index (GSI) on timestamp alone would not allow efficient filtering by device_id, as the GSI's partition key would be timestamp, forcing a scan across all devices to find a specific device_id.

227
MCQhard

A company runs a time-series application on Amazon RDS for PostgreSQL. The table 'events' has 500 million rows and is queried by event_time and event_type. Queries for the last hour are slow despite indexing. Which design change would most improve query performance?

A.Add a composite index on (event_type, event_time)
B.Partition the table by month using PostgreSQL declarative partitioning
C.Migrate to Amazon DynamoDB with TTL
D.Upgrade to a larger RDS instance
AnswerB

Partition pruning limits scans to relevant partitions.

Why this answer

Option B is correct because partitioning the 'events' table by month using PostgreSQL declarative partitioning allows the query planner to prune partitions that do not contain data for the last hour. This dramatically reduces the number of rows scanned, even with a large table of 500 million rows, and directly addresses the slow query performance for time-range queries. Indexing alone cannot overcome the overhead of scanning a massive monolithic table for a narrow time window.

Exam trap

The trap here is that candidates often assume adding a composite index is sufficient for all query patterns, but for time-series data with a large table and narrow time-range queries, partition pruning provides a far more significant reduction in scanned data than any index can achieve.

How to eliminate wrong answers

Option A is wrong because adding a composite index on (event_type, event_time) may improve some queries but does not solve the fundamental problem of scanning a 500-million-row table for a one-hour time range; the index still has to traverse a large B-tree and fetch rows from the heap, leading to significant I/O. Option C is wrong because migrating to DynamoDB with TTL is designed for automatic item expiration, not for improving query performance on time-series data; DynamoDB lacks native time-range query optimization like partition pruning and would require careful design of partition keys and secondary indexes to avoid hot partitions. Option D is wrong because upgrading to a larger RDS instance provides more CPU and memory but does not change the fact that queries must scan the entire table or a large index; it is a vertical scaling approach that does not address the architectural inefficiency of a monolithic table for time-based queries.

228
MCQmedium

A company runs an Oracle database on Amazon RDS. The database is used by multiple applications, and the company needs to capture all data modification language (DML) changes for auditing. Which solution should be used?

A.Use AWS CloudTrail to capture database events.
B.Enable Oracle Flashback and store the flashback logs.
C.Install Oracle Audit Vault on the RDS instance.
D.Use AWS DMS with change data capture (CDC) to stream changes to Amazon S3.
AnswerD

DMS CDC captures DML changes and can write to S3.

Why this answer

Option D is correct because AWS DMS with CDC and stream to S3 allows capturing DML changes and storing them for auditing. Option A is wrong because RDS does not support Oracle Flashback. Option B is wrong because RDS does not support Oracle Audit Vault.

Option C is wrong because CloudTrail does not capture database-level DML.

229
Multi-Selecthard

A company runs a critical Oracle database on Amazon RDS. They need to implement a disaster recovery strategy that provides the lowest possible recovery point objective (RPO) and recovery time objective (RTO) across AWS Regions. Which TWO actions should they take? (Choose two.)

Select 2 answers
A.Configure cross-Region automated backups to copy backups to another Region.
B.Configure an AWS DMS task to replicate data from the primary RDS Oracle instance to an RDS Oracle instance in another Region.
C.Enable Multi-AZ on the primary RDS instance.
D.Create a cross-Region read replica of the Oracle DB instance.
E.Use Amazon Aurora Global Database to replicate data across Regions.
AnswersA, B

Cross-Region automated backups provide an RPO of a few minutes and allow restore in the secondary Region.

Why this answer

To achieve cross-Region DR with low RPO/RTO, you can use an AWS DMS task with ongoing replication to an RDS instance in another Region. Additionally, you can enable Multi-AZ in the primary Region for high availability, but that doesn't provide cross-Region DR. Option C (cross-Region read replica) is not supported for Oracle.

Option D (Cross-Region automated backups) is supported and provides RPO of a few minutes. Option E (Aurora Global Database) is for Aurora, not Oracle. The correct combination is: Option A (DMS) and Option D (Cross-Region backup restore).

However, DMS provides continuous replication (low RPO) and Option D provides automated backups that can be restored in another Region (low RTO if restored). But Option A alone is not sufficient for RTO; you need a standby instance. The best answer is to use DMS for replication to a standby RDS instance in the secondary Region and use Cross-Region automated backups for additional protection.

But the question asks for TWO actions. Option A + Option D is valid. Option B (Multi-AZ) is for HA within a Region.

Option C is not supported. Option E is for Aurora. So A and D.

230
MCQhard

A company is designing a multi-region active-active application that requires low-latency reads and writes across regions. The database must support conflict resolution. Which database should be used?

A.Amazon RDS Multi-AZ
B.Amazon DynamoDB Global Tables
C.Amazon Redshift
D.Amazon Aurora Global Database
AnswerB

DynamoDB global tables offer active-active replication with eventual consistency and conflict resolution.

Why this answer

Amazon DynamoDB Global Tables is the correct choice because it provides a fully managed, multi-region, multi-active database that replicates data across regions with eventual consistency, supporting low-latency reads and writes. It includes built-in conflict resolution using a last-writer-wins (LWW) mechanism based on timestamps, which meets the requirement for conflict resolution in an active-active architecture.

Exam trap

The trap here is that candidates often confuse Amazon Aurora Global Database with an active-active solution, but it is actually active-passive with a single write region, whereas DynamoDB Global Tables supports multi-region writes with automatic conflict resolution.

How to eliminate wrong answers

Option A is wrong because Amazon RDS Multi-AZ is a single-region, high-availability feature that provides a standby replica in a different Availability Zone, not multi-region active-active capability, and it does not support conflict resolution. Option C is wrong because Amazon Redshift is a data warehouse optimized for analytical queries, not low-latency transactional reads and writes across regions, and it lacks conflict resolution mechanisms. Option D is wrong because Amazon Aurora Global Database is designed for cross-region replication but supports only one primary region for writes (active-passive), not active-active, and it does not provide built-in conflict resolution for concurrent writes.

231
MCQhard

A company runs an e-commerce platform on Amazon RDS for MySQL with a Multi-AZ deployment. The database has a table 'orders' with 50 million rows. During Black Friday sales, the application experiences severe slowdowns. Analysis shows that the CPU utilization is at 90% and there are many slow queries that perform full table scans on the 'orders' table. The development team has already added indexes on the most queried columns, but the problem persists. The database specialist suspects that the issue is not solely due to missing indexes. They notice that the queries often filter on a combination of 'order_date', 'customer_id', and 'status', and that the data distribution is heavily skewed: 80% of orders are 'completed' status. The 'order_date' range is typically the last 30 days. What should the database specialist do to improve query performance?

A.Partition the 'orders' table by 'status' and 'order_date' and create covering indexes on common query patterns.
B.Create multiple read replicas and distribute read traffic.
C.Implement an in-memory caching layer using Amazon ElastiCache for frequently accessed data.
D.Upgrade the RDS instance to a larger instance class with more vCPUs and memory.
AnswerA

Partitioning reduces the data scanned, and covering indexes speed up queries without accessing the table.

Why this answer

Option D is correct because partitioning the table by 'status' and 'order_date' can significantly reduce the amount of data scanned, as queries often filter on these columns. In addition, using a covering index can avoid lookups. Option A (vertical scaling) provides temporary relief but does not address the root cause.

Option B (read replicas) offloads read traffic but does not fix the slow queries themselves. Option C (cache layer) can help with repeated queries but not with ad-hoc analytical queries that still scan large datasets.

232
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'. The application needs to retrieve the top 10 players for a given game_id based on score (stored as an attribute). The game_id has high cardinality. The team wants to avoid full table scans. Which design pattern is MOST efficient?

A.Query the table by game_id and sort the results in the application
B.Use a Scan operation with a filter expression and limit 10
C.Create a local secondary index with partition key game_id and sort key score
D.Create a global secondary index with partition key game_id and sort key score
AnswerD

Query the GSI with ScanIndexForward=false and limit 10 for fast retrieval.

Why this answer

DynamoDB does not support ORDER BY on non-key attributes. To efficiently retrieve top scores, a global secondary index (GSI) with game_id as partition key and score as sort key allows descending queries. Option B is wrong because using scan with limit is inefficient.

Option C is wrong because reading all items in the game partition and sorting in application is costly. Option D is wrong because a local secondary index (LSI) would require the same partition key but cannot have a different sort key if the table's sort key is player_id; also LSIs have size limits.

233
Multi-Selecthard

Which THREE design patterns are commonly used to optimize DynamoDB performance for write-heavy workloads?

Select 3 answers
A.Using DynamoDB adaptive capacity to handle unbalanced access patterns.
B.Using sparse indexes on rarely accessed attributes.
C.Batch writes using BatchWriteItem.
D.Write sharding using a random suffix on the partition key.
E.Using global tables to distribute writes across regions.
AnswersA, C, D

Adaptive capacity automatically rebalances partitions to handle hot spots.

Why this answer

Option A is correct because write sharding distributes writes evenly. Option C is correct because batching reduces API calls. Option E is correct because adaptive capacity helps handle uneven access patterns.

Option B is wrong because global tables are for multi-region replication, not write optimization. Option D is wrong because sparse indexes are for read optimization.

234
MCQeasy

What is the purpose of the 'TimeToLiveSpecification' in this template?

A.It enables DynamoDB to automatically delete items after the specified timestamp
B.It enforces that the 'expire_time' attribute must be unique
C.It automatically updates the 'expire_time' attribute when an item is read
D.It creates a backup of items that have expired
AnswerA

TTL deletes items when the timestamp is reached.

Why this answer

The 'TimeToLiveSpecification' in an AWS DynamoDB CloudFormation template enables DynamoDB's Time to Live (TTL) feature, which automatically deletes items when the current time exceeds the epoch timestamp value stored in the specified attribute (e.g., 'expire_time'). This is a cost-effective way to manage data retention without requiring custom delete logic or additional write capacity.

Exam trap

The trap here is that candidates confuse TTL with a feature that actively manages or updates timestamps, when in reality TTL is a passive, background deletion mechanism that only reads the existing attribute value and never modifies it.

How to eliminate wrong answers

Option B is wrong because TTL does not enforce uniqueness on the 'expire_time' attribute; DynamoDB only uses the attribute's value to determine expiration, and multiple items can share the same timestamp. Option C is wrong because TTL never automatically updates the 'expire_time' attribute when an item is read; it is a passive deletion mechanism based solely on the stored timestamp. Option D is wrong because TTL does not create backups of expired items; expired items are permanently deleted within 48 hours of expiration, and you must use DynamoDB Streams or separate backup mechanisms to capture them before deletion.

235
MCQmedium

A company is migrating an on-premises MongoDB database to AWS. The database stores JSON documents for a content management system. The workload requires read-after-write consistency and automatic scaling. Which AWS database service is MOST appropriate?

A.Amazon ElastiCache for Redis
B.Amazon DynamoDB
C.Amazon RDS for PostgreSQL
D.Amazon DocumentDB
AnswerD

DocumentDB is MongoDB-compatible, provides read-after-write consistency, and scales automatically.

Why this answer

Amazon DocumentDB is the most appropriate choice because it is a fully managed, MongoDB-compatible document database that natively stores JSON documents, supports read-after-write consistency via its default session consistency model, and provides automatic scaling of storage (up to 64 TB) and compute resources. It directly replaces on-premises MongoDB workloads without requiring schema changes or application rewrites, making it ideal for a content management system.

Exam trap

The trap here is that candidates often choose DynamoDB (Option B) because it is a NoSQL document database with automatic scaling, but they overlook the requirement for MongoDB compatibility and read-after-write consistency, which DynamoDB does not provide by default and requires additional configuration, whereas DocumentDB is purpose-built for MongoDB workloads with strong consistency out of the box.

How to eliminate wrong answers

Option A is wrong because Amazon ElastiCache for Redis is an in-memory key-value store, not a document database; it does not natively support JSON document storage with MongoDB-compatible querying, and its eventual consistency model (with optional strong consistency via WAIT command) is not designed for persistent, read-after-write consistent document workloads. Option B is wrong because Amazon DynamoDB is a key-value and document database but uses a different API and consistency model (eventually consistent reads by default, with strongly consistent reads available at additional cost); it lacks MongoDB wire protocol compatibility, requiring application refactoring. Option C is wrong because Amazon RDS for PostgreSQL is a relational database that stores data in tables with a fixed schema, not as JSON documents; while it supports JSONB, it does not provide MongoDB-compatible APIs or automatic scaling of storage without manual intervention, and it requires schema migration from MongoDB's document model.

236
MCQmedium

A company is running a MongoDB-compatible workload on Amazon DocumentDB. They are experiencing high write latency during peak hours. The current cluster has one instance (db.r5.large) with 100 GB storage. Which change is most likely to improve write performance?

A.Increase storage to 500 GB
B.Enable Multi-AZ deployment
C.Increase the instance size to db.r5.xlarge
D.Add a read replica in a different Availability Zone
AnswerC

A larger instance provides more CPU and memory, which can improve write performance.

Why this answer

DocumentDB writes are handled by the primary instance. Since the instance is r5.large, increasing instance size provides more CPU and memory, improving write throughput. Adding read replicas does not help writes.

Scaling storage does not directly improve write latency. Enabling Multi-AZ adds a standby but does not improve write performance.

237
MCQeasy

A startup is building a social media application that needs to store user profiles, posts, comments, and likes. The data is highly interconnected, and the team wants to query relationships efficiently, such as 'find all friends of a user who liked a post'. Which database service is best suited for this workload?

A.Amazon ElastiCache for Redis
B.Amazon DynamoDB
C.Amazon RDS for PostgreSQL
D.Amazon Neptune
AnswerD

Neptune is a graph database built for relationship queries.

Why this answer

Amazon Neptune is a graph database designed for highly connected data, making it ideal for social graphs. Option A (DynamoDB) is wrong because it is a key-value/document database that requires additional application logic for graph queries. Option B (RDS) is wrong because relational databases can model graphs but are less efficient for deep relationship queries.

Option D (ElastiCache) is wrong because it is a cache, not a primary database.

238
MCQmedium

A company is designing a database for an e-commerce platform that stores product catalog data. The catalog has frequent reads and occasional writes. The data is highly relational but the team wants the lowest possible latency for read queries. Which database service should they choose?

A.Amazon DocumentDB
B.Amazon RDS for PostgreSQL with read replicas
C.Amazon DynamoDB with DAX
D.Amazon ElastiCache for Redis
AnswerC

DAX provides in-memory acceleration for DynamoDB, delivering microsecond read latency.

Why this answer

DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB that provides microsecond read latency. While DynamoDB itself is NoSQL, DAX is used to speed up reads. RDS with read replicas can improve read performance but not to microsecond level.

ElastiCache could be used but requires more application logic. DocumentDB is a document database not optimized for microsecond reads.

239
Multi-Selectmedium

A company is migrating an on-premises MongoDB database to Amazon DocumentDB. The database stores IoT sensor data with time-series characteristics. The application performs range queries on timestamp fields and updates recent documents frequently. Which THREE aspects of DocumentDB should the company consider to optimize performance for this workload? (Choose three.)

Select 3 answers
A.Use global secondary indexes to speed up queries on the timestamp field.
B.Implement sharding to distribute write load across multiple instances.
C.Enable a TTL index on the timestamp field to automatically delete old data.
D.Create a compound index on (device_id, timestamp) to support range queries.
E.Use a single large instance class to avoid sharding complexity.
AnswersB, C, D

Sharding helps scale writes by distributing data across shards.

Why this answer

Option B is correct because DocumentDB does not support native sharding like MongoDB; however, for workloads with high write throughput, you can distribute writes by using multiple DocumentDB instances and routing writes based on a shard key in the application layer. This helps avoid write bottlenecks on a single instance and scales write capacity horizontally.

Exam trap

The trap here is that candidates may assume DocumentDB supports sharding natively like MongoDB, but DocumentDB does not have built-in sharding; instead, you must implement application-level sharding or use multiple clusters to distribute write load.

240
MCQmedium

Refer to the exhibit. An IAM policy is attached to an IAM role used by a Lambda function that writes to a DynamoDB table. The function also needs to read items from the table. What is the outcome of this policy?

A.The policy is invalid because it contains both Allow and Deny for the same table
B.The Lambda function can both read and write items
C.The Lambda function can write items but cannot read items
D.The Lambda function cannot perform any operations on the table
AnswerC

The Deny for GetItem overrides the Allow, so reads fail.

Why this answer

The IAM policy includes an explicit Deny for the `dynamodb:GetItem` action on the table, which overrides any Allow statements due to the explicit deny evaluation logic in AWS IAM. Since the Lambda function assumes a role with this policy, it is denied read access while the Allow for `dynamodb:PutItem` permits write operations. Therefore, the function can write but cannot read items from the DynamoDB table.

Exam trap

The trap here is that candidates often assume a single Allow statement grants all actions on a resource, overlooking that an explicit Deny for a specific action will block that action even if other actions are allowed.

How to eliminate wrong answers

Option A is wrong because a policy can contain both Allow and Deny for the same resource; this is valid and results in the Deny taking precedence. Option B is wrong because the explicit Deny on `dynamodb:GetItem` prevents read operations, so the function cannot both read and write. Option D is wrong because the Allow for `dynamodb:PutItem` is not overridden by any Deny, so write operations are permitted.

241
MCQhard

A media company stores video metadata in Amazon DynamoDB. The table has partition key 'video_id' and sort key 'upload_date'. The application frequently queries videos by 'category' and 'status'. The access pattern changes over time. Which design minimizes cost and maximizes query flexibility?

A.Create a single GSI with partition key 'category' and sort key 'status'
B.Create multiple GSIs with different partition keys to support various query patterns
C.Use DynamoDB Streams to replicate data to Amazon Elasticsearch Service
D.Redesign to a single DynamoDB table that aggregates all attributes into the partition key
AnswerB

Multiple GSIs provide query flexibility at the cost of additional storage, but DynamoDB allows up to 20 GSIs.

Why this answer

Option D is correct because DynamoDB supports multiple GSIs per table, allowing different access patterns. Option A (single GSI) is less flexible. Option B (stream to Elasticsearch) adds complexity and cost.

Option C (single table design) may not fit all patterns.

242
MCQhard

A company runs a critical OLTP workload on Amazon RDS for PostgreSQL. The database size is 2 TB and growing. To reduce storage costs, the company wants to archive old data that is rarely accessed. Which approach is most cost-effective and minimally impacts performance?

A.Move the database to Amazon Aurora PostgreSQL with storage auto-scaling.
B.Migrate the entire database to Amazon DynamoDB.
C.Implement table partitioning and use S3 as an external table for old partitions.
D.Delete old rows and run VACUUM FULL to reclaim space.
AnswerC

Reduces primary storage cost while preserving data access.

Why this answer

Option C is correct because it uses PostgreSQL table partitioning (e.g., range partitioning by date) combined with the `postgres_fdw` or `pg_parquet` extension to treat old partitions as foreign tables stored in Amazon S3. This keeps the hot data in RDS for fast OLTP access while offloading cold data to low-cost S3 storage, minimizing performance impact and reducing storage costs without requiring a full migration or schema redesign.

Exam trap

The trap here is that candidates assume deleting rows and running VACUUM FULL (Option D) reduces storage costs, but RDS bills for allocated storage, not used space, so reclaiming space does not lower the bill and VACUUM FULL can cause significant performance disruption.

How to eliminate wrong answers

Option A is wrong because moving to Aurora PostgreSQL with storage auto-scaling does not reduce storage costs for rarely accessed data; it only automates scaling and still incurs Aurora storage costs for all data. Option B is wrong because migrating an entire 2 TB OLTP workload to DynamoDB would require a complete application rewrite to fit the NoSQL model, and DynamoDB is not optimized for complex relational queries or large-volume archival patterns. Option D is wrong because deleting old rows and running VACUUM FULL reclaims space but does not reduce storage costs long-term (RDS bills for allocated storage, not used space) and VACUUM FULL causes table bloat, performance degradation, and downtime.

243
Multi-Selecteasy

Which TWO of the following are valid considerations when designing a database for an e-commerce application with high read traffic and low write latency requirements?

Select 2 answers
A.Use Amazon DynamoDB Accelerator (DAX) to improve read performance.
B.Store session data in Amazon S3 for fast access.
C.Use Amazon Redshift to serve read traffic directly.
D.Use Amazon ElastiCache to cache frequently accessed data.
E.Deploy Amazon RDS for MySQL with Multi-AZ for read scaling.
AnswersA, D

DAX is a caching layer for DynamoDB.

Why this answer

Option A and D are correct. Amazon ElastiCache is a caching layer that reduces read load on the database. Amazon DynamoDB Accelerator (DAX) provides in-memory caching for DynamoDB, reducing read latency.

Option B (Amazon Redshift) is a data warehouse for analytics, not for low-latency transactional reads. Option C (Amazon RDS for MySQL with Multi-AZ) provides high availability but does not primarily address high read traffic. Option E (Amazon S3) is object storage, not a transactional database.

244
Multi-Selectmedium

Which TWO of the following are best practices for designing a DynamoDB table for high traffic? (Choose 2)

Select 2 answers
A.Store large items to reduce the number of items
B.Use normalized tables and perform joins in application
C.Use global secondary indexes for alternate access patterns
D.Always use strongly consistent reads for best performance
E.Use partition keys with high cardinality
AnswersC, E

GSIs allow efficient queries on non-key attributes.

Why this answer

Global secondary indexes (GSIs) allow you to define alternate partition and sort keys to support different query patterns without duplicating data. This is a best practice for high-traffic workloads because it enables efficient access to data using multiple access patterns while maintaining a single base table, reducing the need for expensive scans or application-level joins.

Exam trap

AWS often tests the misconception that strongly consistent reads always provide better performance, when in fact they are more expensive and slower than eventually consistent reads, and should only be used when strict read-after-write consistency is required.

245
MCQmedium

A company uses Amazon RDS for PostgreSQL to run a reporting application. The reporting queries are complex and take several minutes to complete, causing performance impact on the primary instance. The company wants to isolate the reporting workload without data staleness. Which solution should they implement?

A.Implement an Amazon ElastiCache cluster to cache query results.
B.Enable Multi-AZ and use the standby instance for reporting.
C.Take a manual snapshot of the database and restore it for reporting.
D.Create a read replica and direct reporting queries to it.
AnswerD

Read replicas offload read traffic and are updated asynchronously.

Why this answer

Option D is correct because creating a read replica of the Amazon RDS for PostgreSQL primary instance allows you to offload complex reporting queries to the replica without impacting the primary. Read replicas use asynchronous replication (based on PostgreSQL streaming replication), which provides near-real-time data with minimal staleness, satisfying the requirement to isolate the reporting workload without significant data staleness.

Exam trap

The trap here is that candidates often confuse the Multi-AZ standby instance as usable for read traffic, but AWS explicitly prevents read access to the standby to maintain crash recovery consistency, whereas a read replica is purpose-built for offloading read workloads.

How to eliminate wrong answers

Option A is wrong because Amazon ElastiCache caches query results, not the underlying data; it would serve stale results until the cache is invalidated, and complex queries that take minutes to run would not benefit from caching if the underlying data changes frequently. Option B is wrong because the Multi-AZ standby instance is not directly accessible for read or write operations; it is only used for automatic failover and cannot serve reporting traffic. Option C is wrong because taking a manual snapshot and restoring it creates a point-in-time copy that is static; any subsequent changes to the primary database would not be reflected, leading to data staleness, and the restore process is time-consuming.

246
MCQeasy

A company needs to store session data for millions of users with sub-millisecond latency. The data is key-value in nature and can tolerate eventual consistency. Which database service is best suited?

A.Amazon Redshift
B.Amazon Neptune
C.Amazon RDS for MySQL
D.Amazon DynamoDB
AnswerD

Low-latency, scalable key-value store.

Why this answer

Amazon DynamoDB is the best choice because it is a fully managed NoSQL key-value and document database designed for single-digit millisecond latency at any scale, making it ideal for session data storage. It supports eventual consistency, which is acceptable for this use case, and can handle millions of users with sub-millisecond read and write performance using its SSD-backed storage and distributed architecture.

Exam trap

The trap here is that candidates may choose Amazon RDS for MySQL (Option C) because they associate MySQL with web applications and session storage, but they overlook the strict latency and scalability requirements that DynamoDB's distributed NoSQL architecture uniquely satisfies.

How to eliminate wrong answers

Option A is wrong because Amazon Redshift is a petabyte-scale data warehouse optimized for complex analytical queries using SQL, not for low-latency key-value lookups or session storage. Option B is wrong because Amazon Neptune is a graph database designed for highly connected data (e.g., social networks, recommendation engines) and is not optimized for simple key-value access patterns with sub-millisecond latency. Option C is wrong because Amazon RDS for MySQL is a relational database that, while capable of key-value operations, introduces overhead from SQL parsing, indexing, and ACID compliance that prevents consistent sub-millisecond latency at the scale of millions of concurrent users, and it does not natively support eventual consistency as a tunable feature.

247
MCQmedium

A company uses the IAM policy shown in the exhibit to control access to a DynamoDB table. The table has a partition key user_id and a sort key timestamp. The application uses the AWS SDK to query items. When a user tries to query items with a filter condition, they receive an AccessDeniedException. What is the most likely cause?

A.The aws:userid variable is not being resolved correctly.
B.The query does not specify a partition key that matches the user's LeadingKeys condition.
C.The policy is missing a Condition element with dynamodb:Select.
D.The policy does not allow the Query action.
AnswerB

The condition restricts access to items with a partition key equal to the user's ID; if the query does not use that partition key, access is denied.

Why this answer

The IAM policy uses a `Condition` block with `ForAllValues:StringEquals` on `dynamodb:LeadingKeys` to restrict access to items where the partition key (`user_id`) matches the caller's IAM user ID (`${aws:userid}`). When a query does not specify a partition key that satisfies this condition, the request fails with an `AccessDeniedException`. The error occurs because the query must include a partition key equal to the user's ID to pass the leading keys restriction.

Exam trap

The trap here is that candidates may overlook the `LeadingKeys` condition and assume the error is due to a missing action or a policy syntax issue, rather than recognizing that the query must include a partition key matching the condition value.

How to eliminate wrong answers

Option A is wrong because the `aws:userid` variable is resolved correctly at runtime to the IAM user's unique ID; the issue is not with variable resolution but with the query not including a matching partition key. Option C is wrong because `dynamodb:Select` is not a valid condition key for DynamoDB IAM policies; the policy does not need a `Condition` element for `Select`. Option D is wrong because the policy explicitly allows the `Query` action on the table; the denial is due to the condition on the partition key, not the action itself.

248
MCQhard

A company has a critical application that uses Amazon RDS for MySQL with Multi-AZ deployment. During a recent failure, the automatic failover took 2 minutes, causing application timeout. The company needs to reduce failover time to under 30 seconds. Which solution should the database specialist recommend?

A.Migrate the database to Amazon Aurora MySQL.
B.Create a read replica and promote it during failover.
C.Increase the DB instance class to a larger size.
D.Implement Amazon RDS Proxy to handle connection draining.
AnswerA

Aurora has a distributed storage layer that allows faster failover.

Why this answer

Amazon Aurora MySQL is designed to reduce failover time significantly compared to standard RDS MySQL Multi-AZ. Aurora typically completes failover in under 30 seconds by using a shared distributed storage volume across multiple Availability Zones, allowing the primary instance to fail over to a read replica without the need to replay redo logs or perform crash recovery. This meets the requirement of reducing failover time to under 30 seconds.

Exam trap

The trap here is that candidates may think increasing instance size or using RDS Proxy directly reduces failover time, but failover time is dominated by crash recovery and log replay, not compute or connection management.

How to eliminate wrong answers

Option B is wrong because creating a read replica and promoting it during failover is a manual process that can take several minutes, not under 30 seconds, and does not provide automatic failover with the same consistency guarantees as Multi-AZ or Aurora. Option C is wrong because increasing the DB instance class does not reduce failover time; failover time is dominated by crash recovery and redo log replay, which are independent of instance size. Option D is wrong because Amazon RDS Proxy manages connection pooling and draining but does not affect the underlying database failover time; it only helps with application connection handling during a failover event.

249
MCQmedium

A social media application stores user posts in a DynamoDB table with a partition key of user_id and a sort key of timestamp. The most frequent query is to retrieve the 10 most recent posts for a given user. Which secondary index design would optimize this query?

A.Create a GSI with user_id as the partition key and timestamp as the sort key.
B.Use DynamoDB Streams to populate an Amazon Elasticsearch cluster for search queries.
C.Create an LSI with user_id as the partition key and timestamp as the sort key.
D.Query the base table using the sort key timestamp with a limit of 10.
AnswerC

An LSI uses the same partition key and a different sort key, enabling efficient range queries.

Why this answer

Option B is correct because a local secondary index (LSI) with the same partition key but a different sort key allows efficient retrieval of recent posts per user. Option A is wrong because a global secondary index (GSI) would require additional provisioned throughput and is unnecessary. Option C is wrong because using the sort key directly without an index still requires a scan.

Option D is wrong because Elasticsearch adds operational complexity and cost for this simple query pattern.

250
MCQhard

A company is designing a new e-commerce platform using Amazon DynamoDB. The workload requires single-digit millisecond latency for user session data, which is accessed by session token. The session data is temporary and should be automatically deleted after 24 hours. Which DynamoDB design should the database specialist recommend?

A.Create an AWS Lambda function that runs every hour and deletes expired session data
B.Store session data in Amazon S3 with a lifecycle policy to delete objects after 24 hours
C.Use DynamoDB Accelerator (DAX) to cache session data and set a 24-hour TTL on the cache
D.Enable DynamoDB Time to Live (TTL) on the session token attribute
AnswerD

TTL automatically deletes items after a specified expiry timestamp, meeting the 24-hour deletion requirement.

Why this answer

DynamoDB Time to Live (TTL) automatically deletes expired items after a specified timestamp, making it ideal for session data that must be removed after 24 hours. This approach requires no additional infrastructure, meets the single-digit millisecond latency requirement by using the session token as the primary key, and ensures automatic cleanup without manual intervention or added cost.

Exam trap

The trap here is that candidates may confuse DynamoDB TTL with a feature that provides real-time or immediate deletion, when in fact TTL deletes items asynchronously in the background, typically within a few minutes to 48 hours, which is acceptable for temporary session data but not for compliance-driven immediate removal.

How to eliminate wrong answers

Option A is wrong because using a Lambda function to delete expired data adds operational complexity, potential cost, and latency, and does not guarantee immediate deletion at the exact 24-hour mark, whereas DynamoDB TTL provides a native, serverless solution. Option B is wrong because Amazon S3 does not support single-digit millisecond latency for session data access and is not designed for real-time key-value lookups required by session token access. Option C is wrong because DAX is a caching layer that improves read performance but does not provide automatic deletion of expired data; setting a TTL on the cache only evicts items from the cache, not from the underlying DynamoDB table, leaving stale data in the table.

251
MCQhard

A gaming company uses Amazon DynamoDB for player session data. Each session has a partition key of `game_id` and a sort key of `session_id`. The table has a global secondary index (GSI) on `player_id` for leaderboard queries. Recently, the company noticed that write traffic to the GSI is causing throttling on the base table, even though the base table's write capacity is not fully utilized. What is the MOST likely cause?

A.The application is using strongly consistent reads on the GSI, which consumes double the read capacity.
B.The GSI is not designed with a high-cardinality partition key, causing write hot spots on the GSI.
C.Point-in-time recovery (PITR) is enabled, consuming extra write capacity.
D.The table's auto-scaling settings are not configured correctly for the GSI.
AnswerB

A hot GSI partition can throttle writes, affecting the base table writes.

Why this answer

The correct answer is B. A global secondary index (GSI) has its own provisioned read and write capacity, separate from the base table. If the GSI's partition key (player_id) has low cardinality (e.g., only a few distinct player_id values), writes to the base table will concentrate on a small number of GSI partitions, causing throttling on the GSI.

This throttling on the GSI then back-pressures the base table, resulting in write throttling on the base table even if its own write capacity is underutilized.

Exam trap

The trap here is that candidates often assume throttling on the base table is always caused by the base table's own capacity settings, overlooking that GSIs have independent capacity and can cause back-pressure on the base table when their partition key design leads to hot spots.

How to eliminate wrong answers

Option A is wrong because strongly consistent reads are not supported on GSIs in DynamoDB; GSIs only support eventually consistent reads, so this option describes an impossible scenario. Option C is wrong because point-in-time recovery (PITR) does not consume write capacity; it uses separate backup storage and does not affect the table's provisioned write throughput. Option D is wrong because auto-scaling settings for the GSI are independent of the base table; misconfigured auto-scaling could cause throttling on the GSI itself, but the question states the base table's write capacity is not fully utilized, and the core issue is the GSI's partition key cardinality causing hot spots, not auto-scaling misconfiguration.

252
MCQmedium

A company is migrating an on-premises Oracle database to Amazon Aurora PostgreSQL. The database is 2 TB and has a daily change rate of 10%. They have a 1 Gbps network connection to AWS. They want to minimize downtime during the migration. Which migration approach should they use?

A.Use AWS Schema Conversion Tool (SCT) to convert schema, then import data
B.Use AWS Database Migration Service (DMS) with ongoing replication
C.Use pg_dump to export the database and pg_restore to import
D.Create an Aurora read replica from the Oracle database
AnswerB

DMS supports continuous change data capture (CDC) to minimize downtime.

Why this answer

AWS DMS can perform continuous replication from Oracle to Aurora PostgreSQL with minimal downtime. Option A is wrong because pg_dump/restore would require a long downtime for the initial load and catch-up. Option B is wrong because an Aurora read replica cannot be created from an external Oracle database.

Option D is wrong because the Schema Conversion Tool (SCT) is for schema conversion, not data migration.

253
MCQeasy

A company needs a database for a serverless web application that stores user sessions. The sessions expire after 24 hours. The database must be highly available and require no server management. Which AWS service is most appropriate?

A.Amazon ElastiCache for Redis with cluster mode.
B.Amazon DynamoDB with TTL.
C.Amazon RDS for PostgreSQL with Multi-AZ.
D.Amazon S3 with lifecycle policies.
AnswerB

DynamoDB is serverless, highly available, and supports TTL.

Why this answer

Amazon DynamoDB with TTL is the most appropriate choice because it provides a fully managed, serverless, highly available NoSQL database that can automatically expire user sessions after 24 hours using the Time to Live (TTL) feature. DynamoDB's on-demand capacity mode eliminates server management, and its built-in replication across multiple Availability Zones ensures high availability without any manual intervention.

Exam trap

The trap here is that candidates often confuse ElastiCache for Redis as a 'database' for sessions, but the question explicitly requires 'no server management' and 'highly available' — DynamoDB is the only fully serverless, managed database option that meets all criteria, while ElastiCache still requires cluster management and is not serverless.

How to eliminate wrong answers

Option A is wrong because Amazon ElastiCache for Redis with cluster mode is an in-memory cache, not a durable database; while it can store sessions with TTL, it requires server management (e.g., node sizing, patching) and is not serverless. Option C is wrong because Amazon RDS for PostgreSQL with Multi-AZ requires server management (e.g., patching, scaling) and is not serverless; it also lacks a native TTL feature for automatic session expiration. Option D is wrong because Amazon S3 with lifecycle policies is an object storage service, not a database; it cannot efficiently handle high-frequency read/write operations for user sessions and lacks the low-latency query capabilities needed for session management.

254
MCQhard

Refer to the exhibit. The exhibit shows CloudWatch metrics from an Amazon RDS for PostgreSQL instance. The application is experiencing slow query performance. Which is the most likely cause?

A.High storage latency due to provisioned IOPS being fully utilized or EBS volume contention
B.High CPU utilization due to complex queries
C.Too many database connections causing context switching
D.Insufficient memory causing disk swaps
AnswerA

Read/Write latency significantly above expected values for provisioned IOPS storage.

Why this answer

Option A is correct because ReadLatency of 2.5 ms is high for a database with 5000 provisioned IOPS; typically sub-millisecond is expected. WriteLatency of 5 ms is also high. Memory usage is 450 MB out of 16 GB, so memory is fine.

Connections (100) are moderate. IOPS (5000 read, 2000 write) are within limits but latency is high, indicating potential throttling or contention. Option B: connections are not high.

Option C: memory is not pressured. Option D: CPU is not mentioned; high latency is often storage-related.

255
MCQmedium

A company is designing a database for a global application that requires active-active replication across two AWS Regions. The database must support multi-master writes with conflict resolution. Which AWS database service should they use?

A.Amazon Aurora Global Database
B.Amazon DynamoDB Global Tables
C.Amazon Redshift
D.Amazon RDS for MySQL with Multi-AZ
AnswerB

DynamoDB Global Tables provide multi-master active-active replication with conflict resolution.

Why this answer

Amazon DynamoDB Global Tables provide multi-Region, multi-master replication with conflict resolution based on last writer wins. Aurora Global Database supports replication but is primary-secondary (single master for writes). RDS Multi-AZ is multi-AZ, not multi-Region.

Redshift is not designed for this.

256
Multi-Selecthard

Which THREE factors should be considered when choosing between Amazon RDS Multi-AZ and Amazon Aurora for high availability? (Choose 3)

Select 3 answers
A.Aurora provides faster failover (typically under 30 seconds)
B.RDS Multi-AZ provides automatic scaling of storage
C.RDS Multi-AZ supports encryption at rest
D.Aurora automatically scales storage up to 128 TB per instance
E.Aurora supports up to 15 read replicas, while RDS Multi-AZ supports only 1 standby
AnswersA, D, E

Aurora failover is faster than RDS Multi-AZ.

Why this answer

Aurora's distributed storage architecture enables failover in under 30 seconds typically, because the storage layer is shared across all instances in the cluster. When the primary instance fails, Aurora simply promotes one of the existing read replicas to primary, without needing to remap storage volumes. This is significantly faster than RDS Multi-AZ, which requires a DNS change and a synchronous block-level replication failover that can take 60-120 seconds.

Exam trap

The trap here is that candidates confuse RDS Multi-AZ's synchronous replication with Aurora's shared storage architecture, assuming both have similar failover times, but Aurora's failover is consistently faster due to its distributed storage layer.

257
MCQhard

Refer to the exhibit. A developer runs a DynamoDB query against a global secondary index. The index's partition key is 'status' and sort key is 'created_at'. There are many items with status 'PENDING' in the table. Why does the query return zero items?

A.The query is incorrectly targeting the base table instead of the index.
B.The query must include a condition on the sort key to return results.
C.The key-condition-expression uses the wrong attribute name placeholder.
D.The global secondary index is not yet backfilled with data from the base table.
AnswerD

If the index was recently created, it may still be in the process of backfilling, so items are not yet available.

Why this answer

The query uses the index's partition key 'status' but does not specify a sort key condition. The index's sort key is 'created_at'. The query should return items with status 'PENDING' sorted by 'created_at'.

However, the response shows 0 items but consumed 0.5 capacity units, indicating the index exists but no items matched. This could happen if the index is not yet backfilled (if recently created) or if the index's partition key attribute is missing in the items. In DynamoDB, GSI items are only written if the attribute exists.

If items have a 'status' attribute set to 'PENDING', they should appear. The most likely cause is that the index is not fully populated yet (if recently created) or the 'status' attribute is missing in the items. The query syntax looks correct.

Option A (incorrect expression) is unlikely. Option B (missing sort key) is not required for query on partition key only. Option C (index not yet backfilled) is plausible.

Option D (using table name instead of index name) is incorrect because the query specifies --index-name. So C is correct.

258
MCQmedium

A healthcare application requires storing patient records that include structured data (e.g., name, age) and unstructured data (e.g., medical images). The application needs to query structured data with SQL and serve images via HTTPS. Which combination of AWS services provides the MOST efficient design?

A.Amazon DynamoDB for structured data and Amazon S3 for images with DynamoDB Accelerator (DAX)
B.Amazon RDS for MySQL for structured data and Amazon EFS for images
C.Amazon RDS for PostgreSQL for structured data and Amazon S3 for images with Amazon CloudFront
D.Amazon Redshift for structured data and Amazon S3 for images
AnswerC

RDS provides SQL; S3 and CloudFront serve images efficiently.

Why this answer

Option B is correct: RDS stores structured data with SQL, S3 stores images, and CloudFront caches images for low-latency access. Option A is wrong because DynamoDB does not support SQL. Option C is wrong because EFS is a file system, not optimized for image serving.

Option D is wrong because Redshift is a data warehouse, not suitable for transactional queries.

259
MCQmedium

A company is designing a database for a social media application that requires low-latency access to user profiles and support for complex graph queries. Which AWS database service is most suitable for this workload?

A.Amazon DynamoDB
B.Amazon ElastiCache for Redis
C.Amazon Neptune
D.Amazon RDS for MySQL
AnswerC

Neptune is a graph database with support for graph queries.

Why this answer

Amazon Neptune is a fully managed graph database service optimized for storing and querying highly connected data. It supports both property graph (Apache TinkerPop/Gremlin) and RDF (SPARQL) models, making it the ideal choice for social media applications that require low-latency traversal of complex relationships, such as friend-of-friend recommendations or influence paths.

Exam trap

The trap here is that candidates often mistake DynamoDB's low-latency key-value lookups as sufficient for graph queries, overlooking that DynamoDB cannot perform multi-step traversals without multiple round trips and client-side joins, which destroys performance for complex relationship queries.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB is a key-value and document database that excels at high-throughput, low-latency lookups by primary key but lacks native support for graph traversal queries (e.g., multi-hop joins or pathfinding) required for complex graph workloads. Option B is wrong because Amazon ElastiCache for Redis is an in-memory data store primarily used for caching, session management, and real-time analytics; it does not provide a graph query engine (like Gremlin or SPARQL) and cannot efficiently execute complex graph traversals across deeply connected data. Option D is wrong because Amazon RDS for MySQL is a relational database that uses SQL joins and recursive CTEs to model graphs, but these operations become exponentially slower as graph depth increases, failing to meet the low-latency requirements for complex graph queries at scale.

260
MCQhard

A company uses Amazon RDS for Oracle with a custom application that generates complex hierarchical queries using CONNECT BY. They want to migrate to Amazon Aurora to reduce licensing costs. Which migration strategy requires the fewest application changes?

A.Use AWS Database Migration Service (DMS) to migrate directly to Aurora with no application changes.
B.Migrate to Amazon Aurora MySQL and use its hierarchical query features.
C.Migrate to Amazon Aurora PostgreSQL and rewrite hierarchical queries to use recursive CTEs.
D.Migrate to Amazon RDS for SQL Server and use its recursive CTEs.
AnswerC

PostgreSQL supports recursive CTEs, which are equivalent to CONNECT BY.

Why this answer

Option C is correct because Aurora PostgreSQL supports recursive Common Table Expressions (CTEs) via the WITH RECURSIVE clause, which can be used to rewrite Oracle's CONNECT BY hierarchical queries with minimal application changes. This approach avoids the licensing costs of Oracle while preserving the hierarchical query logic, requiring only a syntax rewrite rather than a complete redesign. Aurora MySQL does not support CONNECT BY or recursive CTEs, making PostgreSQL the only Aurora engine that can handle this workload without significant application restructuring.

Exam trap

The trap here is that candidates assume Aurora MySQL can handle hierarchical queries because it is often marketed as Oracle-compatible, but it lacks CONNECT BY and recursive CTEs, making PostgreSQL the only Aurora engine that can natively support hierarchical queries with a straightforward rewrite.

How to eliminate wrong answers

Option A is wrong because AWS DMS cannot translate Oracle-specific CONNECT BY syntax into an equivalent Aurora MySQL or PostgreSQL query; it only migrates data, not query logic, so the application would break without changes. Option B is wrong because Amazon Aurora MySQL does not support CONNECT BY or recursive CTEs, so hierarchical queries would require a complete rewrite using alternative methods like nested sets or adjacency lists, which is far more complex than a simple CTE rewrite. Option D is wrong because migrating to Amazon RDS for SQL Server does not reduce licensing costs (SQL Server requires its own licenses) and still requires rewriting queries to use recursive CTEs, offering no advantage over PostgreSQL in this scenario.

261
Multi-Selecteasy

Which THREE are factors to consider when choosing between Amazon RDS and Amazon DynamoDB? (Select THREE.)

Select 3 answers
A.Serverless capacity management
B.ACID transaction support across multiple tables
C.Need for complex joins and relationships
D.Encryption at rest requirements
E.Need for in-memory caching
AnswersA, B, C

DynamoDB is serverless; RDS requires provisioning.

Why this answer

Option A is correct because Amazon RDS requires manual or auto-scaling of compute and storage capacity, while DynamoDB offers serverless capacity management with on-demand mode that automatically scales throughput based on traffic. This is a key differentiator when deciding between provisioned capacity (RDS) and fully managed, pay-per-request scaling (DynamoDB).

Exam trap

The trap here is that candidates may think encryption at rest or in-memory caching are exclusive to one service, but AWS offers these features across both RDS and DynamoDB, making them irrelevant for choosing between the two.

262
MCQeasy

A company is designing a database for an e-commerce application that requires high availability and automatic failover. The application performs mainly read-heavy workloads with occasional write spikes during flash sales. Which AWS database service is most suitable for this workload?

A.Amazon DynamoDB with global tables
B.Amazon Aurora MySQL
C.Amazon ElastiCache for Redis
D.Amazon RDS for MySQL with Multi-AZ
AnswerB

High availability and read replicas for read-heavy workloads.

Why this answer

Amazon Aurora MySQL is the most suitable choice because it is designed for high availability with automatic failover (typically under 30 seconds) and provides up to 15 low-latency read replicas that can handle read-heavy workloads. During write spikes like flash sales, Aurora's distributed storage subsystem automatically scales I/O capacity without manual intervention, and its Multi-AZ deployment ensures continuous availability even if the primary instance fails.

Exam trap

The trap here is that candidates often confuse Multi-AZ with high availability and choose RDS MySQL Multi-AZ (Option D), overlooking that Aurora provides the same failover capability with superior read scaling and write performance for bursty workloads.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB with global tables is optimized for multi-region active-active workloads and eventual consistency, not for a single-region read-heavy relational workload with occasional write spikes; it lacks the native SQL join capabilities and relational schema that an e-commerce application typically requires. Option C is wrong because Amazon ElastiCache for Redis is an in-memory caching layer, not a primary database; it cannot serve as the durable, ACID-compliant database for transactional data like orders and inventory. Option D is wrong because Amazon RDS for MySQL with Multi-AZ provides automatic failover but only supports up to 5 read replicas (with asynchronous replication) and does not offer the same write throughput scalability or storage auto-scaling as Aurora, making it less suitable for write spikes during flash sales.

263
MCQmedium

A company needs to store and query JSON documents that vary in structure. The application requires flexible schema, automatic indexing, and the ability to run complex aggregation pipelines. Which AWS database service should be used?

A.Amazon DynamoDB
B.Amazon DocumentDB (with MongoDB compatibility)
C.Amazon ElastiCache for Redis
D.Amazon RDS for PostgreSQL
AnswerB

DocumentDB supports flexible schema, automatic indexing, and aggregation pipelines.

Why this answer

Amazon DocumentDB (with MongoDB compatibility) is the correct choice because it is purpose-built for storing and querying JSON-like documents with flexible schemas, automatically indexes fields, and supports MongoDB's aggregation pipeline for complex data transformations. This aligns directly with the requirements for varying document structures, automatic indexing, and aggregation capabilities.

Exam trap

The trap here is that candidates often confuse DynamoDB's flexible schema and JSON support with full aggregation pipeline capabilities, overlooking that DynamoDB lacks complex multi-stage aggregations like MongoDB's $lookup or $unwind, which are essential for the stated requirement.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB is a key-value and document database that does not support complex aggregation pipelines like MongoDB's $lookup or $group stages; it uses limited query patterns and requires manual secondary index management. Option C is wrong because Amazon ElastiCache for Redis is an in-memory cache, not a persistent document store, and lacks support for aggregation pipelines or automatic indexing of JSON documents. Option D is wrong because Amazon RDS for PostgreSQL requires a predefined schema and does not natively support automatic indexing of varying JSON structures or MongoDB-style aggregation pipelines, though it can store JSON via JSONB, it lacks the flexible schema and pipeline capabilities needed.

264
MCQeasy

A company is migrating an on-premises MongoDB database to AWS. Which AWS database service is most compatible and requires minimal application changes?

A.Amazon DynamoDB.
B.Amazon DocumentDB (with MongoDB compatibility).
C.Amazon Neptune.
D.Amazon RDS for MySQL.
AnswerB

MongoDB-compatible document database.

Why this answer

Amazon DocumentDB (with MongoDB compatibility) is the most compatible AWS database service for migrating an on-premises MongoDB database because it is purpose-built to emulate the MongoDB wire protocol and data model, allowing existing MongoDB drivers and tools to connect with minimal or no application code changes. This makes it the ideal choice for a lift-and-shift migration that preserves the document-oriented structure and query patterns of MongoDB.

Exam trap

The trap here is that candidates may assume DynamoDB is a suitable document database for MongoDB migration because both are NoSQL, overlooking the critical fact that DynamoDB uses a completely different API and data model, which would require a full application rewrite rather than minimal changes.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB is a key-value and document database that uses a proprietary API and data model, requiring significant application rewrites to adapt from MongoDB's query language and indexing. Option C is wrong because Amazon Neptune is a graph database designed for highly connected data (e.g., social networks, fraud detection) and does not support MongoDB's document model or wire protocol, making it incompatible for a direct migration. Option D is wrong because Amazon RDS for MySQL is a relational database that enforces a fixed schema and SQL-based access, which would require extensive application changes to map MongoDB's flexible documents to tables and rows.

265
MCQhard

A company uses Amazon RDS for MySQL with Multi-AZ. During a recent failover test, the database experienced a 5-minute write outage. The application can tolerate up to 1 minute of downtime. Which solution should be used to reduce the failover time?

A.Migrate to Amazon Aurora MySQL.
B.Use Amazon RDS Proxy between the application and the database.
C.Enable automatic failover on the Multi-AZ deployment.
D.Decrease the DNS TTL on the RDS endpoint.
AnswerA

Aurora failover is typically under 30 seconds.

Why this answer

Option D is correct because Amazon Aurora MySQL provides faster failover (typically under 30 seconds) due to its shared storage architecture. Option A is wrong because modifying the DNS TTL may help but does not reduce the failover time significantly. Option B is wrong because RDS Proxy helps with connection pooling, not failover speed.

Option C is wrong because Multi-AZ already provides automatic failover, but failover time is typically 1-2 minutes for RDS.

266
MCQmedium

An e-commerce application uses Amazon DynamoDB as its primary database. The table stores order data with a partition key of 'OrderID' and a sort key of 'OrderDate'. The application frequently queries orders by customer ID (which is not a key attribute). What design change would improve query performance?

A.Enable DynamoDB Streams and export to Amazon Elasticsearch Service
B.Use DynamoDB Accelerator (DAX) to cache queries
C.Create a Global Secondary Index on CustomerID
D.Create a Local Secondary Index on CustomerID
AnswerC

GSI allows querying by CustomerID efficiently.

Why this answer

Option C is correct because creating a Global Secondary Index (GSI) on CustomerID allows efficient querying by that attribute without scanning the entire table. A GSI has its own partition and sort keys, enabling fast lookups on non-key attributes. This directly addresses the performance issue of frequent queries by CustomerID, which otherwise would require a full table scan.

Exam trap

The trap here is that candidates often confuse Local Secondary Indexes (LSIs) with Global Secondary Indexes (GSIs), assuming an LSI can be used to query by a non-key attribute without the partition key, but LSIs require the same partition key as the base table and cannot be added after table creation.

How to eliminate wrong answers

Option A is wrong because DynamoDB Streams and exporting to Amazon Elasticsearch Service are designed for search and analytics, not for improving point-query performance on a specific attribute like CustomerID; this adds complexity and latency without solving the core access pattern. Option B is wrong because DynamoDB Accelerator (DAX) is an in-memory cache that speeds up repeated queries on existing keys, but it does not enable querying by a non-key attribute like CustomerID; it cannot create new access patterns. Option D is wrong because a Local Secondary Index (LSI) can only be created at table creation time and must use the same partition key as the base table (OrderID), so it cannot index by CustomerID alone; it would still require the partition key to be specified in queries.

267
MCQeasy

A mobile gaming application uses Amazon DynamoDB to store player profiles and game state. The write throughput is high during events, but low otherwise. The company wants to minimize costs while maintaining performance. Which capacity mode should they use?

A.Reserved capacity
B.On-Demand capacity mode
C.Provisioned capacity without auto scaling
D.Provisioned capacity with auto scaling
AnswerB

Automatically handles spikes and charges per request, minimizing cost during low traffic.

Why this answer

On-Demand capacity mode is ideal for this workload because it automatically scales to handle high write throughput during events and scales down to zero when idle, eliminating the need for capacity planning. This minimizes costs by charging only for actual reads and writes, without requiring any provisioning or management of throughput limits.

Exam trap

AWS often tests the misconception that Provisioned capacity with auto scaling is always the most cost-effective option, but for unpredictable, spiky workloads like gaming events, On-Demand avoids the fixed costs of minimum provisioned capacity and the risk of throttling during rapid traffic surges.

How to eliminate wrong answers

Option A is wrong because Reserved capacity is not a DynamoDB capacity mode; it is a pricing model for EC2 and RDS, not applicable to DynamoDB. Option C is wrong because Provisioned capacity without auto scaling would require manual adjustments to handle event-driven spikes, risking throttling or over-provisioning costs. Option D is wrong because Provisioned capacity with auto scaling still requires setting a minimum provisioned capacity, which incurs costs even during low-usage periods, making it less cost-effective than On-Demand for unpredictable, spiky workloads.

268
MCQmedium

A company is designing a database for an IoT application that ingests millions of sensor readings per second. Each reading is a small JSON document (less than 1 KB) and must be stored with low latency. Queries are primarily by device ID and timestamp range. The team expects to rarely update or delete old data. Which AWS database solution is MOST cost-effective and performant?

A.Amazon S3 with a partition prefix of device_id/timestamp/
B.Amazon Redshift with distribution key on device_id
C.Amazon DynamoDB with a composite primary key (device_id, timestamp)
D.Amazon RDS for MySQL with multiple read replicas
AnswerC

DynamoDB provides low-latency, high-throughput ingestion and efficient querying by device and time.

Why this answer

Amazon DynamoDB is a NoSQL key-value and document database that provides single-digit millisecond latency at any scale. It is ideal for high-throughput ingestion of small items with simple access patterns (device ID + timestamp). Option A is wrong because Amazon RDS for MySQL is relational and would require scaling a single master, leading to bottlenecks.

Option C is wrong because Amazon Redshift is a data warehouse optimized for analytics, not real-time ingestion. Option D is wrong because Amazon S3 is an object store with higher latency for individual small writes.

269
MCQmedium

A developer is designing a DynamoDB table for an order management system using the above CloudFormation template. The application needs to query orders by CustomerID. The current design has a GSI on CustomerID. However, the developer notices that the GSI has low write throughput and often throttles. What is the most cost-effective way to improve write throughput on the GSI?

A.Change the ProjectionType of the GSI to KEYS_ONLY.
B.Use Amazon SQS to buffer writes to the table.
C.Increase the WriteCapacityUnits of the table.
D.Increase the WriteCapacityUnits of the GSI from 5 to a higher value.
AnswerD

GSI has its own provisioned throughput; increasing it alleviates throttling.

Why this answer

Option A is correct because increasing the GSI's write capacity directly addresses the throttling. Option B is wrong because increasing table write capacity does not affect GSI capacity; GSI has its own. Option C is wrong because changing projection to KEYS_ONLY reduces storage but not write throughput.

Option D is wrong because SQS does not help with DynamoDB write throughput.

270
Multi-Selectmedium

A company is migrating an on-premises MongoDB database to Amazon DocumentDB. The current MongoDB workload uses aggregation pipelines with the $lookup stage and geospatial queries. The migration tool reports that some aggregation stages are not supported. Which THREE actions should the company take to address the incompatibilities?

Select 3 answers
A.Replace $lookup with $geoWithin for location-based queries.
B.Use $geoNear for geospatial queries as it is supported in DocumentDB.
C.Convert $graphLookup to use recursive queries in DocumentDB.
D.Denormalize the data to avoid $lookup by embedding related documents.
E.Rewrite $lookup stages as application-side joins or use references.
AnswersB, D, E

DocumentDB supports $geoNear.

Why this answer

Option A (rewrite $lookup as application-side joins) is correct because DocumentDB does not support $lookup. Option B (use $geoWithin operator) is correct because DocumentDB supports it. Option C (use $geoNear for geospatial) is correct because DocumentDB supports $geoNear.

Option D is wrong because $graphLookup is not supported. Option E is wrong because storing pre-joined documents can be an alternative for $lookup but is not a direct action for unsupported stages.

271
MCQhard

A company has an Amazon RDS for PostgreSQL instance that is running out of storage. The database is 2 TB in size and growing at 10 GB per day. They need a solution that allows automatic storage scaling with minimal downtime. What should they do?

A.Enable Storage Auto Scaling
B.Purchase reserved instances for cost savings
C.Create a read replica and promote it
D.Take a manual snapshot and restore to a larger instance
AnswerA

Automatically scales storage with no downtime.

Why this answer

Amazon RDS Storage Auto Scaling automatically increases storage when needed, with no downtime. Option A (manual snapshot) requires downtime. Option B (read replica) doesn't address storage.

Option D (reserved instances) is a billing option.

272
MCQmedium

A company runs an analytics platform that queries billions of rows of sales data. Queries are complex and involve aggregations across multiple dimensions. The data is updated in bulk daily. Which service should be used as the primary data store?

A.Amazon Redshift
B.Amazon DynamoDB
C.Amazon Athena
D.Amazon RDS for MySQL
AnswerA

Redshift is purpose-built for large-scale data warehousing and analytical queries.

Why this answer

Amazon Redshift is the correct choice because it is a fully managed, petabyte-scale data warehouse optimized for complex analytical queries involving aggregations across multiple dimensions. Its columnar storage, massively parallel processing (MPP) architecture, and ability to handle bulk daily updates via COPY commands or INSERT operations make it ideal for querying billions of rows of sales data.

Exam trap

The trap here is that candidates often confuse Amazon Athena as a primary data store because it can query data in S3, but it is a serverless query engine, not a data store, and lacks the performance optimizations for complex aggregations on billions of rows that a dedicated data warehouse like Redshift provides.

How to eliminate wrong answers

Option B is wrong because Amazon DynamoDB is a NoSQL key-value and document database designed for high-throughput, low-latency transactional workloads, not for complex analytical queries with multi-dimensional aggregations on billions of rows. Option C is wrong because Amazon Athena is a serverless interactive query service that queries data directly in Amazon S3 using standard SQL, but it is not a primary data store—it is a query engine, and it lacks the performance and optimization for frequent, complex aggregations on large datasets compared to a dedicated data warehouse. Option D is wrong because Amazon RDS for MySQL is a relational database optimized for OLTP workloads with row-based storage, which performs poorly on large-scale analytical queries and aggregations across billions of rows due to its lack of columnar storage and MPP capabilities.

273
MCQeasy

A company needs to store time-series data from IoT sensors. Each sensor sends a reading every minute. The data is rarely accessed after 30 days. The query pattern is to retrieve all readings for a specific sensor within a time range. Which AWS database is most cost-effective?

A.Amazon Timestream
B.Amazon Redshift
C.Amazon DynamoDB with Time-to-Live (TTL)
D.Amazon RDS for PostgreSQL with partitioning
AnswerA

Optimized for time-series data with automatic storage tiering.

Why this answer

Option B is correct because Timestream is purpose-built for time-series data with automatic tiering. Option A is wrong because DynamoDB is more expensive for this pattern. Option C is wrong because RDS is not optimized for time-series.

Option D is wrong because Redshift is for analytics, not real-time ingestion.

274
MCQmedium

A company runs an online gaming platform that uses Amazon DynamoDB to store player profiles and game state. The platform experiences sudden spikes in write traffic when popular events occur. During these spikes, some write requests fail with ProvisionedThroughputExceededException. The operations team has configured DynamoDB Auto Scaling with a maximum write capacity of 10000 WCU, but during spikes, the write rate exceeds 10000 WCU for short bursts. The team needs to handle these bursts without losing data or sacrificing performance. What is the MOST effective solution?

A.Enable DynamoDB Accelerator (DAX) to cache write requests and reduce the load on the table.
B.Shard the DynamoDB table manually by adding a random suffix to the partition key to distribute writes more evenly.
C.Increase the maximum write capacity for Auto Scaling to a higher value, such as 20000 WCU.
D.Implement an Amazon SQS queue to buffer write requests and process them in batches, with a Lambda function writing to DynamoDB.
AnswerD

SQS decouples the write path, absorbing spikes and allowing throttled writes to DynamoDB.

Why this answer

DynamoDB Auto Scaling can increase capacity, but it reacts to CloudWatch alarms and takes time (minutes). For sudden spikes, the best solution is to use DynamoDB Accelerator (DAX) for reads, not writes. For writes, you can implement exponential backoff and retries in the application, but that may increase latency.

Another option is to use a queue (Amazon SQS) to buffer writes and process them at a controlled rate. This decouples the application from the database, allowing spikes to be absorbed. Option A (increase max WCU) helps but may not be enough if spikes are very high and unpredictable.

Option B (DAX) does not help with writes. Option C (SQS buffer) is a common pattern. Option D (sharding) requires application changes and may not be necessary.

So the best is to use SQS to buffer writes.

275
MCQmedium

A financial services company needs a database to store transaction records with strict ACID compliance and the ability to run complex JOIN queries for reporting. The workload is read-heavy with occasional batch inserts. Which AWS database service should they choose?

A.Amazon RDS for PostgreSQL
B.Amazon DynamoDB
C.Amazon Aurora Serverless
D.Amazon Timestream
AnswerA

PostgreSQL is fully ACID-compliant and supports complex queries.

Why this answer

Option A is correct because Amazon RDS for PostgreSQL is a relational database that provides ACID compliance and supports complex joins. Option B is wrong because DynamoDB is NoSQL and does not support complex joins. Option C is wrong because Aurora Serverless is good but may not be the best for complex joins; however, it is still relational.

Option D is wrong because Timestream is for time-series.

276
Multi-Selecthard

A company is designing a database for a social media analytics platform that requires: 1) storing relationships between users, posts, and interests; 2) running complex graph queries like 'find all friends of friends who like topic X'; 3) high availability with multi-region replication. Which TWO AWS services should they consider? (Choose TWO.)

Select 2 answers
A.Amazon Neptune
B.Amazon Redshift
C.Amazon Aurora Global Database
D.Amazon DynamoDB with Global Tables
E.Amazon ElastiCache for Redis
AnswersA, C

Neptune is purpose-built for graph queries.

Why this answer

Option B (Neptune) is correct for graph queries. Option D (Global Database for Aurora) provides multi-region replication for relational data, but for graph queries Neptune is primary. Since Neptune does not natively support multi-region replication, the platform might use Aurora for metadata and Neptune for graph, but the question expects two services.

Alternatively, DynamoDB Global Tables for key-value and Neptune for graph. However, given options, B and D are the best combined for graph and replication. Option A (DynamoDB) is not graph.

Option C (Redshift) is analytics. Option E (ElastiCache) is caching.

277
MCQhard

A company is building a real-time analytics dashboard from IoT sensor data. Data arrives as time-series with millions of writes per second. The dashboard queries the last hour of data with aggregations. Which database design is most cost-effective?

A.Amazon DynamoDB with TTL and DAX
B.Amazon Redshift with streaming ingestion
C.Amazon Timestream
D.Amazon RDS for PostgreSQL with TimescaleDB extension
AnswerC

Optimized for time-series with low cost for high write throughput and efficient recent data queries.

Why this answer

Amazon Timestream is purpose-built for time-series data, offering automatic tiered storage (in-memory for recent data and magnetic for historical) and built-in aggregation functions optimized for time-based queries. This design handles millions of writes per second cost-effectively, as it eliminates the need for manual sharding or TTL management, and its serverless model charges only for data written and queried, making it ideal for real-time analytics on the last hour of IoT sensor data.

Exam trap

The trap here is that candidates often choose DynamoDB with TTL and DAX because they associate it with high write throughput and caching, but they overlook that time-series aggregation queries require native time-based functions and cost-efficient storage tiering, which Timestream uniquely provides.

How to eliminate wrong answers

Option A is wrong because DynamoDB with TTL and DAX is optimized for key-value and low-latency point lookups, not for time-series aggregations over a sliding window; TTL only deletes expired data but does not provide native time-based aggregation functions, and DAX accelerates reads but does not reduce the cost or complexity of scanning and aggregating millions of writes per second. Option B is wrong because Redshift with streaming ingestion is designed for large-scale analytical queries on structured data, but its minimum cluster size and compute costs make it over-provisioned and expensive for real-time dashboards querying only the last hour of data; streaming ingestion adds latency and complexity for sub-second updates. Option D is wrong because RDS for PostgreSQL with TimescaleDB extension requires manual provisioning of compute and storage, incurs costs for idle capacity, and its hypertable partitioning and continuous aggregates still involve overhead for millions of writes per second, making it less cost-effective than a fully managed serverless time-series service like Timestream.

278
Multi-Selectmedium

Which TWO database services are suitable for storing time-series data with high ingestion rates? (Select TWO.)

Select 2 answers
A.Amazon Timestream
B.Amazon RDS for MySQL
C.Amazon ElastiCache for Memcached
D.Amazon DynamoDB with TTL
E.Amazon Redshift
AnswersA, D

Purpose-built for time-series.

Why this answer

Amazon Timestream is purpose-built for time-series. DynamoDB with TTL can be used for time-series with efficient expiration. Options C, D, E are not optimal for high ingestion time-series.

279
MCQmedium

A company is designing a database for a social media application that needs to handle friend-of-friend queries and recommendation engine traversals. Which AWS database is best suited?

A.Amazon DynamoDB
B.Amazon DocumentDB (with MongoDB compatibility)
C.Amazon ElastiCache for Redis
D.Amazon Neptune
AnswerD

Graph database optimized for traversals and relationships.

Why this answer

Amazon Neptune is a fully managed graph database service optimized for storing and querying highly connected data. It supports both property graph (Apache TinkerPop/Gremlin) and RDF (SPARQL) models, making it ideal for friend-of-friend queries and recommendation engine traversals that require navigating complex relationships with low latency.

Exam trap

The trap here is that candidates often choose DynamoDB or ElastiCache because they associate social media with key-value or in-memory caching, overlooking that graph databases are specifically designed for relationship-heavy traversals like friend-of-friend queries.

How to eliminate wrong answers

Option A is wrong because Amazon DynamoDB is a key-value and document database that lacks native graph traversal capabilities; performing friend-of-friend queries would require multiple expensive queries and client-side joins, leading to poor performance at scale. Option B is wrong because Amazon DocumentDB (MongoDB-compatible) is a document database that does not support graph-specific query patterns like Gremlin or SPARQL, and its aggregation pipeline is inefficient for multi-hop relationship traversals. Option C is wrong because Amazon ElastiCache for Redis is an in-memory data store that can model graphs using data structures like sets or sorted sets, but it lacks a native graph query language and optimized traversal engine, making it unsuitable for complex multi-level recommendation traversals at scale.

280
MCQeasy

A retail company runs its inventory management system on Amazon RDS for PostgreSQL. The application performs frequent updates to inventory counts. The operations team notices that write latency increases significantly during peak sales hours. The database is a single db.r5.large instance with General Purpose SSD (gp2) storage. The CPU utilization is around 40% during peaks, but the write latency spikes. The team suspects a storage bottleneck. Which change would most effectively reduce write latency?

A.Enable Multi-AZ deployment.
B.Change storage type to Provisioned IOPS (io2) with sufficient IOPS.
C.Add a read replica to offload read traffic.
D.Scale up to a db.r5.xlarge instance.
AnswerB

Provisioned IOPS provides consistent low-latency write performance.

Why this answer

Option B is correct. Provisioned IOPS (io1/io2) storage provides consistent low-latency I/O performance compared to gp2, which can have variable performance due to burst credits. Option A (increase instance size) may not address I/O bottleneck.

Option C (Multi-AZ) improves availability, not latency. Option D (read replica) offloads reads, not writes.

281
MCQmedium

A company is migrating an on-premises MongoDB workload to Amazon DocumentDB. The current workload uses secondary indexes heavily for reporting queries. Which design consideration should the company evaluate to ensure optimal performance on DocumentDB?

A.Enable Multi-AZ deployment to improve read performance.
B.Shard the collection across multiple DocumentDB clusters.
C.Use the MongoDB aggregation pipeline to bypass indexing.
D.Evaluate using covered queries instead of secondary indexes.
AnswerD

DocumentDB does not support secondary indexes; covered queries can help performance.

Why this answer

Covered queries retrieve all required data from an index without accessing the underlying documents, reducing I/O and improving performance. In Amazon DocumentDB, which is compatible with MongoDB 4.0, covered queries can often replace secondary indexes for reporting workloads, minimizing index maintenance overhead and storage costs. This design consideration directly addresses the heavy reliance on secondary indexes by optimizing query execution.

Exam trap

The trap here is that candidates assume secondary indexes are always necessary for query performance, overlooking that covered queries can eliminate document lookups and reduce index overhead, which is a key optimization for DocumentDB's architecture.

How to eliminate wrong answers

Option A is wrong because Multi-AZ deployment provides high availability and automatic failover, not improved read performance; read replicas (not Multi-AZ) are used for read scaling. Option B is wrong because DocumentDB does not support manual sharding across clusters; it uses a single cluster with auto-scaling storage, and sharding is not a native feature. Option C is wrong because the MongoDB aggregation pipeline does not bypass indexing; it can leverage indexes for performance, and avoiding indexes would degrade query performance, not improve it.

282
MCQmedium

A company is designing a database for a ride-sharing application that requires real-time location updates and driver-passenger matching. The database must support geospatial queries to find nearby drivers within a radius. The expected throughput is 10,000 writes per second and 5,000 reads per second. The company wants a fully managed solution with low latency. The application team has experience with PostgreSQL. Which database design should they choose?

A.Use Amazon Aurora PostgreSQL with the PostGIS extension and use read replicas for scaling reads.
B.Use Amazon DynamoDB with a geospatial library to encode locations into a partition key.
C.Use Amazon DynamoDB with a global secondary index on a geohash attribute for proximity queries.
D.Use Amazon RDS for MySQL with spatial indexes and Multi-AZ deployment.
AnswerA

Aurora PostgreSQL with PostGIS provides geospatial support, scalability, and managed service.

Why this answer

Option A is correct because Amazon Aurora PostgreSQL supports PostGIS for geospatial queries, can scale to handle the throughput with write replicas and auto-scaling, and is fully managed. Option B (DynamoDB) is not ideal for geospatial queries; it requires complex partitioning. Option C (DynamoDB with GSI) still not good for radius queries.

Option D (RDS MySQL) has geospatial support but may not scale as well as Aurora.

283
Multi-Selectmedium

A company is building a real-time leaderboard for a mobile game using Amazon DynamoDB. The leaderboard displays the top 100 players by score. The table has 'game_id' as partition key and 'player_id' as sort key. The score is updated frequently. Which THREE design patterns should the company implement to ensure low-latency reads for the leaderboard? (Choose three.)

Select 3 answers
A.Use 'ScanIndexForward: false' on the base table to get top players.
B.Enable DynamoDB Accelerator (DAX) to cache the leaderboard query.
C.Use 'begins_with' operator on the sort key to filter by score range.
D.Create a global secondary index (GSI) with 'game_id' as partition key and 'score' as sort key.
E.Use DynamoDB Streams and AWS Lambda to maintain a separate leaderboard table.
AnswersB, D, E

Caches the query results for low-latency reads.

Why this answer

Option B is correct because DynamoDB Accelerator (DAX) provides an in-memory cache that can serve repeated leaderboard queries with microsecond latency, reducing the read load on the base table and avoiding throttling. For a real-time leaderboard that is read frequently, DAX ensures low-latency responses without needing to query DynamoDB directly each time.

Exam trap

The trap here is that candidates may think using ScanIndexForward on the base table (Option A) is sufficient, but they overlook that the base table's sort key is player_id, not score, so it cannot sort by score without a GSI or separate table.

284
Multi-Selectmedium

A company is running a critical application on Amazon DynamoDB. The table has a partition key of 'user_id' and a sort key of 'timestamp'. The application frequently queries for all items for a given user within a date range. The read capacity is often throttled during peak hours. Which THREE steps should the database specialist take to resolve the throttling?

Select 3 answers
A.Enable DynamoDB adaptive capacity to automatically adjust throughput
B.Change the partition key to 'timestamp' to improve read distribution
C.Decrease the provisioned write capacity units (WCU) to free up resources for reads
D.Increase the provisioned read capacity units (RCU) for the table
E.Implement DynamoDB Accelerator (DAX) to cache frequent reads
AnswersA, D, E

Adaptive capacity helps manage uneven access patterns and reduces throttling.

Why this answer

Option A is correct because DynamoDB adaptive capacity automatically manages throughput to accommodate uneven access patterns, such as when a single 'user_id' partition receives more reads than provisioned. It allows the table to absorb throttling by redistributing unused capacity from other partitions, which directly addresses the peak-hour throttling without manual intervention.

Exam trap

The trap here is that candidates may think decreasing WCU can reallocate resources to reads, but DynamoDB's read and write capacity are independent, so reducing one does not benefit the other.

285
MCQmedium

A company is deploying an RDS MySQL database using the above CloudFormation template. After deployment, the database automatically reboots during the maintenance window. The company wants to reduce the impact of maintenance events. Which parameter change would minimize unavailability?

A.Set AutoMinorVersionUpgrade to true in the template.
B.Increase BackupRetentionPeriod to 30 days to have more recovery points.
C.Increase AllocatedStorage to 500 GB to improve performance during maintenance.
D.Change PreferredMaintenanceWindow to a less busy time.
AnswerA

Automatic minor version upgrades ensure the database is updated during maintenance windows, reducing the need for manual updates that could cause longer downtime.

Why this answer

Setting AutoMinorVersionUpgrade to true ensures that minor version upgrades are applied automatically during the maintenance window, but more importantly, it enables the use of a Multi-AZ deployment's automatic failover to reduce downtime. In a Multi-AZ RDS MySQL setup, the primary database reboots during maintenance, but the standby instance takes over with minimal interruption. This parameter change minimizes unavailability by leveraging the failover mechanism, whereas other options do not directly address the impact of maintenance reboots.

Exam trap

The trap here is that candidates often assume changing the maintenance window to a less busy time (Option D) reduces impact, but it only shifts the downtime without reducing its length; the correct answer focuses on enabling Multi-AZ failover through AutoMinorVersionUpgrade, which actually minimizes unavailability during maintenance events.

How to eliminate wrong answers

Option B is wrong because increasing BackupRetentionPeriod to 30 days provides more recovery points for point-in-time restore, but it does not reduce the impact of maintenance events; backups are taken asynchronously and do not affect availability during a reboot. Option C is wrong because increasing AllocatedStorage to 500 GB improves I/O performance and throughput, but it does not prevent or shorten the downtime caused by a maintenance reboot; storage size is unrelated to the failover or reboot process. Option D is wrong because changing PreferredMaintenanceWindow to a less busy time only shifts when the reboot occurs, but it does not reduce the duration or impact of the unavailability; the database still reboots and becomes unavailable during that window.

286
MCQmedium

A company is migrating an on-premises MySQL database to Amazon Aurora MySQL. The database is 2 TB and the migration must have minimal downtime. The network bandwidth between the on-premises data center and AWS is 1 Gbps. Which migration approach is most appropriate?

A.Use mysqldump to export the data, upload to Amazon S3, and import into Aurora
B.Take a snapshot of the on-premises database and restore it to Aurora
C.Use AWS Snowball Edge to transfer the data physically to AWS
D.Use AWS Database Migration Service (DMS) with ongoing replication to keep the target in sync
AnswerD

DMS supports continuous replication, allowing minimal downtime migration.

Why this answer

AWS DMS can migrate data with minimal downtime. Using DMS with a full load and ongoing replication (change data capture) allows the source to remain active until the cutover. Option B (Aurora S3) is for importing from S3, not for live migration.

Option C (RDS snapshot) is for RDS to Aurora, not on-premises. Option D (Snowball) is for large data volumes with limited bandwidth, but 2 TB at 1 Gbps can be transferred in about 5 hours (theoretical), so DMS is feasible and minimizes downtime.

287
MCQmedium

A social media startup stores user posts in Amazon DynamoDB with a partition key of user_id and sort key of post_timestamp. The application frequently queries the five most recent posts for a given user. Which design pattern improves query performance and reduces cost?

A.Enable DynamoDB Accelerator (DAX) for the table
B.Increase the read capacity units on the table
C.Use a global secondary index on post_timestamp
D.Create a local secondary index on user_id and post_timestamp
AnswerD

LSI allows efficient query on user_id with sorted results.

Why this answer

Option D is correct because a Local Secondary Index (LSI) on user_id (hash key) and post_timestamp (range key) allows DynamoDB to efficiently query the five most recent posts for a given user without scanning the entire table. Since the LSI shares the same partition key as the base table, it provides strongly consistent reads and avoids the overhead of a separate index, reducing both latency and consumed read capacity.

Exam trap

The trap here is that candidates often choose a GSI on post_timestamp (Option C) thinking it will help with sorting, but without user_id as the partition key, the GSI cannot efficiently scope the query to a single user, leading to full scans and higher costs.

How to eliminate wrong answers

Option A is wrong because DAX is an in-memory cache that reduces read latency but does not improve query efficiency for retrieving the top N items by sort key; it still requires a full scan or query with filtering, and adds cost without addressing the core pattern. Option B is wrong because increasing read capacity units only raises the provisioned throughput, not the efficiency of the query; the same expensive scan or filter would still be performed, increasing cost linearly with capacity. Option C is wrong because a Global Secondary Index (GSI) on post_timestamp alone cannot efficiently retrieve the five most recent posts for a specific user without a partition key; it would require a full scan of the index or a query with a filter on user_id, which is inefficient and costly.

288
Multi-Selectmedium

A company is running a PostgreSQL database on Amazon RDS. They need to improve read performance for a reporting application that runs complex queries. The reporting application can tolerate slightly stale data. Which THREE actions should they take? (Choose three.)

Select 3 answers
A.Modify the DB parameter group to optimize settings for reporting workloads, such as increasing shared_buffers and work_mem.
B.Upgrade the RDS instance to a larger instance class with more vCPUs and memory.
C.Create one or more read replicas of the RDS instance and direct reporting queries to them.
D.Enable Multi-AZ on the RDS instance.
E.Implement an Amazon ElastiCache cluster to cache query results.
AnswersA, B, C

Tuning PostgreSQL parameters can improve performance for complex queries.

Why this answer

To improve read performance, you can create read replicas to offload queries, adjust instance class for more CPU/memory, and use parameter groups to optimize for reporting workloads (e.g., increased shared_buffers, work_mem). Option A (Multi-AZ) improves availability, not read performance. Option B (read replicas) distributes read traffic.

Option C (ElastiCache) can cache results of frequent queries. Option D (instance class) provides more resources. Option E (parameter groups) allows tuning.

So the correct three are B, D, and E. Option C is also valid but not typically 'action' on RDS; it's an additional service. The question says 'actions they should take' which could include using ElastiCache.

However, the exam often considers creating read replicas, modifying instance class, and optimizing parameters as direct actions. I'll choose B, D, E.

289
MCQhard

A company is running a production Amazon RDS for PostgreSQL database. The database experiences high write latency during peak hours. The company wants to reduce latency without changing the application code. Which solution is MOST cost-effective and scalable?

A.Change the storage type to Provisioned IOPS (io1)
B.Enable RDS Proxy to pool database connections
C.Increase the instance size to a larger DB instance class
D.Add a Multi-AZ standby to offload writes
AnswerC

Vertical scaling can improve write throughput.

Why this answer

Increasing the instance size to a larger DB instance class directly addresses high write latency by providing more CPU and memory resources, which improves the database's ability to process write operations faster. This is the most cost-effective and scalable solution because it does not require application code changes and can be scaled vertically as needed, whereas other options either do not reduce write latency or introduce unnecessary complexity.

Exam trap

AWS often tests the misconception that Multi-AZ standby can offload writes, but in reality, the standby is a synchronous replica that does not accept write traffic and only provides failover redundancy.

How to eliminate wrong answers

Option A is wrong because changing to Provisioned IOPS (io1) improves I/O performance but does not address the underlying compute or memory bottleneck causing high write latency; it also incurs additional cost without guaranteeing latency reduction if the instance is already undersized. Option B is wrong because RDS Proxy pools database connections to reduce connection overhead and improve scalability, but it does not reduce write latency on the database itself; it is designed for connection management, not write performance. Option D is wrong because adding a Multi-AZ standby provides high availability and failover support, but it does not offload writes; the standby is a read-only replica that cannot handle write traffic, so it does not reduce write latency on the primary instance.

290
MCQhard

A company is designing a multi-tenant SaaS application on Amazon RDS for PostgreSQL. Tenants have vastly different data sizes and access patterns. The current design uses a separate schema per tenant, but some tenants experience slow queries while others are fine. Which approach would best isolate tenant performance and simplify management?

A.Use row-level security (RLS) policies within a single schema to restrict tenant data access.
B.Keep the current schema design and add a tenant_id index to all tables.
C.Use a separate database per tenant.
D.Use Amazon RDS Proxy to manage connections and improve performance.
AnswerC

Separate databases provide strong performance isolation and allow per-tenant resource allocation and backup.

Why this answer

Option C is correct because using a separate database per tenant provides the strongest resource isolation at the database instance level. This design prevents noisy neighbors—tenants with large data volumes or heavy access patterns from degrading the performance of other tenants—and simplifies management tasks such as backup, restore, and point-in-time recovery on a per-tenant basis. Amazon RDS for PostgreSQL supports multiple databases within a single DB instance, and each database operates with its own catalog, tables, and connection pool, ensuring that query execution and memory allocation are not shared across tenants.

Exam trap

The trap here is that candidates often confuse logical data isolation (RLS or schema-per-tenant) with performance isolation, assuming that indexing or connection pooling can solve resource contention, when in fact only physical separation (separate databases) guarantees that one tenant's workload does not impact another's performance.

How to eliminate wrong answers

Option A is wrong because row-level security (RLS) policies operate within a single schema and do not isolate performance; all queries still compete for the same shared buffer pool, CPU, and I/O resources, so a heavy tenant can still cause slowdowns for others. Option B is wrong because adding a tenant_id index to all tables only improves query performance for individual queries but does nothing to prevent resource contention between tenants; the underlying shared infrastructure remains a bottleneck. Option D is wrong because Amazon RDS Proxy manages connection pooling and reduces connection overhead, but it does not isolate tenant workloads or prevent resource contention at the database engine level; it is a connection management layer, not a performance isolation mechanism.

291
Multi-Selecthard

A company is designing a data lake on Amazon S3 with Amazon Redshift Spectrum for analytics. The data includes JSON logs from web servers. Which THREE design practices should the company follow to optimize query performance and cost?

Select 3 answers
A.Compress files using gzip or snappy.
B.Use many small files to maximize parallelism.
C.Partition the data by date (e.g., year/month/day) in S3.
D.Convert JSON files to Apache Parquet format.
E.Create indexes on the S3 data using AWS Glue.
AnswersA, C, D

Compression reduces storage and I/O.

Why this answer

Option A is correct because compressing JSON files with gzip or Snappy reduces the data size stored in S3, lowering storage costs and minimizing the amount of data that Redshift Spectrum must scan over the network. Redshift Spectrum can read compressed files directly, and compression often improves query performance by reducing I/O, even though it adds a small CPU overhead for decompression.

Exam trap

Cisco often tests the misconception that more files equals more parallelism, but in Redshift Spectrum, excessive small files increase overhead and reduce performance, while the correct approach is to use fewer, larger files in a columnar format with partitioning.

292
Matchingmedium

Match each AWS service to its primary purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Relational database service with managed instances

NoSQL key-value and document database

In-memory caching service supporting Redis and Memcached

Petabyte-scale data warehouse

MongoDB-compatible document database

Why these pairings

These are core AWS database services with distinct use cases.

293
MCQmedium

A gaming company uses Amazon DynamoDB for player profiles. The access pattern is to retrieve a player's profile by 'player_id'. Each profile includes a list of 'achievements' that can grow up to 400 KB. Recently, the application has been encountering 'ProvisionedThroughputExceededException' errors. The table has 1000 read capacity units (RCU) and 500 write capacity units (WCU). The average item size is 200 KB. What is the MOST likely cause of the throttling?

A.The item size exceeds the DynamoDB item size limit of 400 KB.
B.The read capacity units are set too low for the number of partitions.
C.The partition key 'player_id' is causing hot partitions.
D.The application is using strongly consistent reads, which consume double the read capacity.
AnswerD

Strongly consistent reads consume twice as many RCUs as eventually consistent reads.

Why this answer

Strongly consistent reads in DynamoDB consume twice the read capacity units (RCUs) as eventually consistent reads. With an average item size of 200 KB, each strongly consistent read consumes 200 KB / 4 KB = 50 RCUs (rounded up). If the application is using strongly consistent reads, a single read of a 200 KB item uses 50 RCUs, which can quickly exhaust the 1000 RCU table capacity, especially under concurrent access, leading to ProvisionedThroughputExceededException.

Exam trap

The trap here is that candidates may overlook the RCU consumption difference between strongly consistent and eventually consistent reads, assuming all reads consume the same capacity, and instead blame hot partitions or item size limits.

How to eliminate wrong answers

Option A is wrong because the item size limit for DynamoDB is 400 KB, and the profile includes a list of achievements that can grow up to 400 KB, so it does not exceed the limit. Option B is wrong because read capacity units are provisioned per table, not per partition; DynamoDB distributes RCUs across partitions automatically, and the total RCU of 1000 is sufficient for the described access pattern if reads are eventually consistent. Option C is wrong because while hot partitions can cause throttling, the access pattern is to retrieve by 'player_id', which is the partition key, and there is no indication of uneven access distribution; the primary issue is the high RCU consumption per read due to strongly consistent reads.

294
MCQeasy

A company needs to store JSON documents that are up to 10 KB in size. The documents are accessed by a primary key, and the company requires single-digit millisecond latency. Which database service should be used?

A.Amazon Neptune
B.Amazon DynamoDB
C.Amazon S3
D.Amazon RDS for MySQL with JSON data type
AnswerB

Provides single-digit ms latency for key-value access.

Why this answer

Option A is correct because DynamoDB is a key-value and document database that provides single-digit millisecond latency at scale. Option B is wrong because RDS for MySQL can store JSON but may not provide consistent single-digit ms latency under load. Option C is wrong because Neptune is for graph data.

Option D is wrong because S3 has higher latency for small objects.

295
MCQmedium

A financial services company uses Amazon DynamoDB to store transaction records. Each transaction has a partition key of customer_id and a sort key of transaction_timestamp. The application queries transactions for a specific customer within a date range. Recently, the query latency increased significantly for customers with a large number of transactions. The company needs to improve query performance without changing the application code. The table is provisioned with 5000 RCUs and 2000 WCUs. Which design change should be made to optimize for this workload?

A.Create a global secondary index with customer_id as partition key and transaction_timestamp as sort key.
B.Enable DynamoDB Accelerator (DAX) on the table.
C.Increase the provisioned RCUs to 10000.
D.Change the sort key to a composite key including a tenant identifier.
AnswerA

A GSI with the same key structure allows efficient querying without impacting the base table.

Why this answer

Option A is correct because creating a global secondary index (GSI) with customer_id as the partition key and transaction_timestamp as the sort key allows efficient querying of transactions for a specific customer within a date range. The existing table's sort key is transaction_timestamp, but the GSI provides a separate index optimized for this access pattern, avoiding full table scans on large customer partitions. This improves query performance without requiring application code changes, as the application can query the GSI directly.

Exam trap

The trap here is that candidates often confuse caching (DAX) with query optimization, or assume that increasing RCUs alone will solve latency issues, when the real bottleneck is the inefficient scan of large partitions due to the lack of an appropriate index.

How to eliminate wrong answers

Option B is wrong because DynamoDB Accelerator (DAX) is an in-memory cache that reduces read latency for frequently accessed items, but it does not address the underlying issue of inefficient querying on large partitions; it would only cache results after the first slow query and does not optimize the query pattern itself. Option C is wrong because increasing RCUs to 10000 only adds more read capacity, which does not solve the problem of scanning through many items in a large partition; the query still has to read all items matching the partition key and filter by sort key, leading to high latency regardless of RCU allocation. Option D is wrong because changing the sort key to a composite key including a tenant identifier would require application code changes and does not directly optimize the existing query pattern; it also introduces unnecessary complexity and potential data modeling issues.

296
MCQmedium

A company is designing a database for a real-time leaderboard in a mobile game. The leaderboard updates thousands of times per second and must return the top 100 scores with minimal latency. Which AWS database service is most suitable for this workload?

A.Amazon Neptune
B.Amazon ElastiCache for Redis
C.Amazon DynamoDB
D.Amazon Aurora
AnswerB

Redis sorted sets provide efficient leaderboard operations.

Why this answer

Amazon ElastiCache for Redis with sorted sets is optimized for real-time leaderboards because it provides in-memory operations with O(log N) complexity for adding scores and O(log N+m) for retrieving top N items. Option B (DynamoDB) is wrong because it is not designed for sorted range queries with frequent updates at high throughput without secondary indexes and provisioned throughput. Option C (Aurora) is wrong because it is a relational database with higher latency and not optimized for this specific pattern.

Option D (Neptune) is wrong because it is a graph database not suited for leaderboard operations.

297
MCQhard

A financial services company runs a critical application on Amazon RDS for MySQL. The database stores transaction data that must be retained for 7 years for regulatory compliance. The current retention policy stores all data in the same table, causing performance degradation on the main transactional table. The company needs to archive data older than 1 year while keeping it queryable. Which design should they implement?

A.Migrate to Amazon Redshift and use workload management to prioritize transactions.
B.Use Amazon ElastiCache for Redis to cache recent data and move old data to S3.
C.Use Amazon RDS for MySQL with a read replica for reporting, and set up a Lambda function to export partitions older than 1 year to Amazon S3 in Parquet format, queryable via Amazon Athena.
D.Migrate to Amazon DynamoDB with TTL to automatically expire old data.
AnswerC

Preserves relational structure for recent data, archives to S3 for cost-effective storage, and allows querying via Athena.

Why this answer

Option C is correct because it uses RDS for MySQL read replicas to offload reporting traffic, while a Lambda function archives partitions older than 1 year to Amazon S3 in Parquet format. This keeps the main transactional table lean, improves performance, and retains data for 7 years in a cost-effective, queryable format via Amazon Athena, meeting both compliance and queryability requirements.

Exam trap

The trap here is that candidates may think DynamoDB TTL is suitable for archiving, but TTL only deletes data, not retains it, and they may overlook the need for a queryable archive solution like Athena on S3.

How to eliminate wrong answers

Option A is wrong because migrating to Amazon Redshift is designed for analytical workloads, not for transactional OLTP operations, and would introduce unnecessary complexity and latency for the primary application. Option B is wrong because ElastiCache for Redis is an in-memory cache, not a persistent storage solution; moving old data to S3 without a query engine like Athena or Glue makes it non-queryable for compliance needs. Option D is wrong because DynamoDB TTL automatically deletes expired data, which violates the 7-year retention requirement since data older than 1 year must be retained, not deleted.

298
MCQhard

A company is migrating a PostgreSQL database to Amazon Aurora PostgreSQL. The current database has complex queries that join multiple tables and performs well. After migration, the same queries are slower on Aurora. What is the most likely cause?

A.The DB instance class does not have enough memory for the buffer cache.
B.Aurora PostgreSQL does not support complex joins; the queries must be rewritten.
C.Aurora PostgreSQL does not support indexes on joined columns.
D.The default DB parameter group is optimized for write-heavy workloads, not read-heavy.
AnswerA

Aurora's buffer cache is in memory; insufficient memory leads to more disk reads.

Why this answer

Option A is correct because after migrating to Aurora PostgreSQL, the same complex queries are slower, which often indicates that the buffer cache is too small to hold the working set of data. Aurora uses a distributed storage system where the buffer cache is managed by the DB instance's memory; if the instance class lacks sufficient memory, frequently accessed data pages must be read from storage more often, increasing I/O latency. This is a common performance bottleneck when migrating from on-premises PostgreSQL, where the buffer cache might have been larger or the working set fit entirely in memory.

Exam trap

The trap here is that candidates may assume Aurora PostgreSQL has inherent limitations with joins or indexes (options B and C), when in fact the most common post-migration performance issue is insufficient memory for the buffer cache, not a missing feature.

How to eliminate wrong answers

Option B is wrong because Aurora PostgreSQL fully supports complex joins, including hash joins, merge joins, and nested loop joins, just like standard PostgreSQL; no query rewriting is required. Option C is wrong because Aurora PostgreSQL supports indexes on joined columns, including B-tree, GiST, GIN, and BRIN indexes, and indexes are critical for join performance. Option D is wrong because the default DB parameter group in Aurora PostgreSQL is not optimized specifically for write-heavy workloads; it provides balanced settings, and performance issues with complex queries are more likely due to memory or configuration of the buffer cache, not a default parameter group bias.

299
MCQeasy

A company is using Amazon RDS for PostgreSQL for its transactional database. The application generates reports that query millions of rows, causing high CPU on the primary instance. The reports are not time-sensitive. What is the MOST cost-effective way to offload the reporting queries without affecting write performance?

A.Create an Amazon RDS Read Replica and direct reporting queries to the replica.
B.Use Amazon ElastiCache to cache report results.
C.Enable Multi-AZ to distribute reads to the standby instance.
D.Migrate reporting to Amazon Redshift.
AnswerA

Read Replicas can handle read traffic without impacting the primary.

Why this answer

Creating an Amazon RDS Read Replica offloads reporting queries to a separate read-only instance, preventing CPU contention on the primary. Since the reports are not time-sensitive, the replica can handle the large queries without impacting write performance, and it is cost-effective because you only pay for the replica's compute and storage.

Exam trap

The trap here is that candidates may confuse Multi-AZ standby instances with Read Replicas, mistakenly believing that the standby can serve read traffic, but AWS explicitly does not allow reads from the standby in a Multi-AZ deployment.

How to eliminate wrong answers

Option B is wrong because ElastiCache caches query results, but it does not offload the actual query processing from the primary instance; the initial query still runs on the primary, causing CPU spikes. Option C is wrong because Multi-AZ standby instances are not used for read traffic; they are only for failover and do not serve read requests. Option D is wrong because migrating to Amazon Redshift is overkill and more expensive for this use case; a Read Replica is simpler and more cost-effective for offloading reporting queries from RDS.

300
MCQhard

A company runs a financial application on Amazon RDS for PostgreSQL that requires point-in-time recovery (PITR) with a recovery point objective (RPO) of 1 second and recovery time objective (RTO) of 5 minutes. Which configuration meets these requirements at the lowest cost?

A.Multi-AZ RDS with synchronous standby.
B.Single-AZ RDS with automated backups and manual snapshot restore.
C.Single-AZ RDS with a read replica and promote on failure.
D.Single-AZ RDS with cross-region snapshot copy.
AnswerA

Automatic failover within minutes, minimal data loss.

Why this answer

Multi-AZ RDS for PostgreSQL with synchronous standby replication provides automatic failover to a standby in a different Availability Zone, enabling an RTO of typically 1–2 minutes, well within the 5-minute requirement. Automated backups and transaction logs allow PITR with an RPO of 1 second by restoring to any point within the retention period, and the synchronous standby ensures zero data loss during failover, meeting the strict RPO at the lowest cost for this high-availability need.

Exam trap

The trap here is that candidates often assume a read replica can provide fast failover and low RPO, but they overlook that read replicas use asynchronous replication, which introduces lag and requires manual promotion, failing both the RPO and RTO requirements.

How to eliminate wrong answers

Option B is wrong because Single-AZ RDS with automated backups and manual snapshot restore cannot achieve an RTO of 5 minutes; restoring from a snapshot or automated backup takes significantly longer (often 15–60 minutes depending on database size) and does not provide automatic failover. Option C is wrong because Single-AZ RDS with a read replica and promote on failure does not guarantee an RPO of 1 second; read replicas use asynchronous replication, which can lag by seconds to minutes, and promotion is a manual or scripted process that increases RTO beyond 5 minutes. Option D is wrong because Single-AZ RDS with cross-region snapshot copy cannot meet the RTO of 5 minutes; restoring from a cross-region snapshot requires copying the snapshot to the target region and then restoring, which takes much longer than 5 minutes, and the RPO is limited by the snapshot schedule (e.g., every 5–30 minutes), not 1 second.

← PreviousPage 4 of 6 · 444 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Workload-Specific Database Design questions.