AWS Database common mistakes
AWS Database · Understand the traps and how to avoid them.
Selecting DynamoDB as the store for a workload whose queries need multi-table joins, ad-hoc aggregation, and flexible filtering, because the requirements mention 'serverless', 'fully managed', and 'unlimited scale'.
Those adjectives are strong distractors, and candidates pattern-match on operational benefits while skipping the access-pattern analysis that is the deciding factor. Keyword-driven selection is the most frequent source of loss on design items.
What to do instead
Before choosing an engine, write out the top 3-5 queries and check whether each needs a join or an unindexed scan. If they do, the answer is a relational engine (Aurora, RDS); DynamoDB is defensible only when every access path is known in advance and is key-based.
Choosing a Multi-AZ deployment to absorb read traffic from a reporting process, or expecting Multi-AZ standbys to serve reads.
Multi-AZ and read scaling are both presented as 'high availability and performance' options, and the standby is invisible during normal operation, so candidates treat it as a second usable node.
What to do instead
Separate the two concerns explicitly: Multi-AZ is failover only (no read capacity, no read endpoint), while read replicas serve reads and can be promoted. For read offload, answer read replicas; for zone-failure durability, answer Multi-AZ.
Sizing a DynamoDB table by dividing total item bytes by 1 KB for writes and treating one read capacity unit as one 4 KB read, ignoring item-size rounding, the 4 KB/1 KB granularity split, and the difference between eventually consistent and strongly consistent reads.
The arithmetic looks trivial, so candidates do the division once and forget that every item is rounded up to the next 4 KB (reads) or 1 KB (writes), and that strongly consistent reads cost double.
What to do instead
Redo the math per item: writes = ceil(itemKB) WCU; eventually consistent reads = ceil(itemKB/4) RCU, doubled for strongly consistent, doubled again for transactional. Then state the assumption about consistency in the answer so the examiner can see the reasoning.
Assuming AWS Database Migration Service alone will convert an Oracle or SQL Server schema - stored procedures, triggers, sequences, and proprietary data types - into Aurora PostgreSQL during a heterogeneous migration.
DMS and the Schema Conversion Tool are marketed together, so candidates collapse them into one service. DMS moves data, not code, and stored procedures that cannot be auto-converted are the classic exam trap.
What to do instead
Answer with two components: use the Schema Conversion Tool for schema and code conversion and DMS for the data movement (full load plus CDC). State explicitly that non-convertible procedural code must be rewritten manually and that this effort must be included in the plan.
Planning a production cutover that stops application writes and then relies on the ongoing replication task to 'catch up', without ever validating row counts, LOB handling, or replication lag before switching the connection string.
The migration is treated as a copy job rather than a change-management event, so validation, lag monitoring, and a rollback path are omitted from the answer.
What to do instead
Build the cutover into the answer: enable and monitor CDC lag, run data validation on target, then briefly quiesce writes, wait for lag to reach zero, and only then repoint the application. Include a rollback step that keeps the source intact until validation passes.
Connecting an application to the Aurora cluster endpoint when the goal is to spread read-only queries across replicas, or using the reader endpoint for a custom subset of instances.
The cluster endpoint is the default name handed out and 'cluster' sounds like it covers everything; the writer/reader/custom endpoint distinction is easy to skim past.
What to do instead
Memorise the endpoint roles as a table: cluster endpoint = writer only; reader endpoint = load-balanced across replicas (and it does not guarantee which one); custom endpoints = a named subset of instances for specialised workloads such as reporting.
Changing a parameter that turns out to be static (for example a memory- or engine-level setting) and stating the change takes effect immediately, or modifying an instance class during peak hours without accounting for the maintenance window.
Parameter groups show a single 'apply' action and candidates do not check the apply-type column; similarly, instance class changes are assumed to be online when many require a reboot or a window.
What to do instead
For any parameter change, check whether it is dynamic or static. Static parameters require a reboot of the instance, so the answer must sequence the change with a maintenance window and a failover to keep the service reachable.
Setting automated backup retention to 0 (or assuming automated backups are taken by default with indefinite retention), then writing an answer that depends on point-in-time recovery to a moment several weeks ago.
Retention periods and snapshot behaviour are easy to conflate: automated backups are enabled by default with a finite retention window, are deleted with the instance, and PITR is bounded by that retention.
What to do instead
Distinguish clearly: automated backups (default retention, bounded PITR window, deleted on instance deletion unless the deletion policy retains them) versus manual DB snapshots (persist until deleted). For long-horizon restore requirements, include scheduled manual snapshots or an export to S3 in the design.
Diagnosing a database performance problem purely from CloudWatch's basic database metrics, or assuming Performance Insights and Enhanced Monitoring are on by default for every engine and instance class.
All three appear in the console, so candidates treat them as interchangeable and miss that OS-level metrics such as per-process memory and CPU by process are only in Enhanced Monitoring, and that Performance Insights has engine and retention constraints.
What to do instead
Map symptom to tool in the answer: latency and wait-event analysis points to Performance Insights; OS-level and process-level resource data points to Enhanced Monitoring; alarm-based trend and threshold monitoring points to CloudWatch metrics and Logs export.
Stating that encryption at rest can be turned on for an existing unencrypted RDS instance by modifying it and selecting a KMS key, or granting IAM database authentication to an application running on SQL Server or Oracle.
Most instance attributes can be changed in place, so encryption appears to be one more toggle; and IAM database authentication is described generically rather than per engine and per connection model.
What to do instead
For encryption, always describe the snapshot-copy-with-encryption-and-restore path, then repoint; there is no in-place enable. For IAM database authentication, restrict the answer to supported engines (MySQL, PostgreSQL, Aurora equivalents), note the 15-minute token lifetime, and flag that connection pools and heavy connection churn make it a poor fit.