AWS Certified Solutions Architect - Associate SAA-C03 Practice Test 75
Question 740
An RDS database performs a slow 20-million-row nested loop join. Execution plans show a missing selective index, but DB storage IOPS remains far below its limit. The team proposes expensive provisioned IOPS. What should it do first?
- Buy more IOPS solely because every slow SQL statement is a disk-rate problem.
- Add read replicas but leave the expensive join plan unchanged in every copy.
- Increase log retention and treat RDS logs as an automatically maintained index over join columns.
- Improve SQL predicates and indexes based on the execution plan, then benchmark the corrected queries.
Explanation
Correct Answer
D:The measured bottleneck is inefficient query access, not an exhausted device IOPS ceiling.
Incorrect Answers
A:Additional IOPS may not reduce the wasteful join work when I/O headroom remains.
B:Replicas spread calls but do not improve the single query's plan.
C:Logging does not create relational access paths for the optimizer.
Question 741
A production RDS database slows intermittently. CPU, read latency, active sessions and lock waits all fluctuate, but the only available monitoring chart is storage GiB consumed. What observability should be enabled or reviewed?
- Review CloudWatch Database Insights in an appropriate mode, RDS Enhanced Monitoring and database query/lock-wait telemetry.
- Increase allocated RDS storage and provisioned IOPS based only on the observed storage-consumption chart.
- Use RDS event notifications and instance-status checks alone as the complete query-performance diagnostic.
- Enable RDS storage autoscaling and treat the resulting free-capacity metric as a complete performance analysis.
Explanation
Correct Answer
A:CloudWatch Database Insights exposes database load and wait dimensions; Enhanced Monitoring adds host and process metrics. Correlating those with query plans, lock activity and storage I/O separates CPU, concurrency, indexing and I/O causes rather than guessing from used GiB.
Incorrect Answers
B:Storage or IOPS changes might help an actual storage bottleneck, but storage-capacity utilization alone does not identify SQL lock waits, session saturation or CPU contention.
C:Events expose service-level changes but cannot by themselves identify SQL wait classes, top queries, blocking sessions or host resource contention.
D:Storage autoscaling prevents some capacity exhaustion, but it does not reveal the lock and query wait causes of intermittent slowness.
Question 742
A reservation system needs ACID transactions spanning related orders, seats and payments, plus multiple SQL joins over structured tables. Its team proposes a simple DynamoDB key-value schema solely for raw throughput. Which database family should be evaluated?
- Use DynamoDB transactions and a partition-key data model while leaving the existing arbitrary multi-table SQL join workload unchanged.
- Use Amazon RDS or Aurora with a relational schema and a transaction design matched to those SQL relationships.
- Use Amazon Redshift as the live booking transaction database because it can join large SQL tables in analytic queries.
- Migrate the existing relational schema without query rewrites to Amazon DocumentDB as a drop-in SQL database.
Explanation
Correct Answer
B:RDS or Aurora relational engines provide transactional SQL semantics, constraints and joins appropriate to the described booking workflow. Throughput sizing matters, but it does not erase the required OLTP data model.
Incorrect Answers
A:DynamoDB supports transactional APIs for defined items, but arbitrary relational joins and foreign-key behavior do not transparently map to item lookups. This would require a different data model and application queries.
C:Redshift is optimized for warehouse analytics, not high-frequency interactive row-level reservations where ACID OLTP concurrency and transaction latency dominate.
D:DocumentDB uses document-oriented APIs with MongoDB compatibility, not the same arbitrary SQL joins and relational constraint model the workload requires.
Question 743
An IoT telemetry service receives millions of device updates. Each request gets or updates one device state by a known partition key, with no SQL joins. Automatic horizontal scale and predictable key access are priorities. Which store fits?
- Choose a complex multi-table RDS join model solely because every device state lookup needs relational foreign keys.
- Use S3 Glacier Deep Archive as a low-latency per-device mutable key-value database.
- Model the device state in DynamoDB around partition-key access and the expected hot-key distribution.
- Use Route 53 DNS records as the authoritative store for rapidly updated sensor readings.
Explanation
Correct Answer
C:DynamoDB supports managed, horizontally scaled key-value operations when access patterns are designed for its partitions.
Incorrect Answers
A:The workload has simple keyed operations, so unnecessary joins may add overhead.
B:Deep archive retrieval is not appropriate for continuous fast state updates.
D:DNS record semantics are not a general operational key-value database.
Question 744
An Amazon Redshift reporting cluster repeatedly executes the same multi-table join and daily SUM aggregations over billions of fact rows for a dashboard. The dashboard accepts data up to fifteen minutes old. Query analysis shows the repeated aggregation, rather than network latency, dominates execution time. Which change most directly avoids recomputing the whole aggregation for each dashboard refresh?
- Increase the number of API Gateway stages in front of Redshift; each stage automatically stores aggregate SQL results for the next execution.
- Increase application connection-pool size without changing query structure, because more sessions eliminate the computation performed by each GROUP BY.
- Create a plain Redshift view over the same join and select it repeatedly, since regular views always persist precomputed data between queries.
- Create a Redshift materialized view for the stable aggregate and refresh it at an interval that respects the dashboard’s freshness limit.
Explanation
Correct Answer
D:A Redshift materialized view stores precomputed results for reuse, avoiding repeated base-table aggregation. Refresh strategy must fit the permitted fifteen-minute staleness because queries see data as of the last refresh.
Incorrect Answers
A:API Gateway stages provide API deployment and management boundaries, not persisted Redshift SQL aggregates; they would not remove costly warehouse join and grouping work.
B:Connection pooling can reduce connection overhead but does not materialize repeated query results. The cluster would still process each large aggregation, potentially with more contention.
C:A normal SQL view stores a query definition, not necessarily the computed dataset. The underlying join and aggregate can still run on each use.
Question 745
A data platform holds billions of rows but requires complex multi-record atomic business transactions and flexible ad hoc SQL joins. A proposal selects DynamoDB solely because of row count. What should influence the choice?
- Model transaction boundaries, consistency semantics and query access patterns before comparing relational and DynamoDB scaling options.
- Adopt DynamoDB on-demand capacity for billions of items while preserving the existing arbitrary SQL joins and multi-record transaction behavior without redesign.
- Select Aurora only because it has a SQL endpoint, without assessing the required throughput, transaction isolation or access paths.
- Put the active booking dataset in S3 and run Athena SELECT queries as the sole synchronous transaction processing layer.
Explanation
Correct Answer
A:A very large row count is a scaling input, not a proof of DynamoDB fit. Compare required multi-item atomicity, isolation and ad hoc join access against real database capabilities and operational scaling boundaries.
Incorrect Answers
B:On-demand scaling changes DynamoDB capacity management, not the supported query language or consistency model. Existing relational joins require deliberate modeling or a relational engine.
C:SQL compatibility is relevant, but a proper architecture choice still needs transaction and query profiling, capacity limits and consistency requirements.
D:Athena is designed for analytical queries over object data, not a low-latency ACID OLTP transaction manager for concurrent bookings.
Question 746
An application stores nested JSON documents and relies on a subset of the MongoDB API. Its team wants a managed document database and can validate compatibility for the commands it actually uses. Which AWS service is relevant?
- Assume Amazon Neptune is a MongoDB document server because it also manages flexible records.
- Evaluate Amazon DocumentDB with confirmed MongoDB API/feature compatibility for the specific application.
- Use DynamoDB with no data-model changes and assume it implements every native MongoDB server command.
- Use RDS Proxy alone as the persistent JSON document database engine.
Explanation
Correct Answer
B:DocumentDB targets document-oriented MongoDB-compatible workloads, subject to a documented feature compatibility matrix.
Incorrect Answers
A:Neptune is purpose-built for graph models and traversals, not a general MongoDB wire-compatible replacement.
C:DynamoDB is a different managed key-value/document API with different query semantics.
D:RDS Proxy manages database connections rather than storing and querying a native document collection.
Question 747
An anti-fraud service follows many-hop relationships among bank accounts, devices and addresses to find fraud rings. Relational self-joins are becoming difficult to manage. Which specialized data store aligns?
- Use S3 versioning as the graph traversal query engine over arbitrary entity edges.
- Use RDS Proxy as a graph database that creates edges from pooled SQL connections.
- Consider Amazon Neptune for graph traversal over connected entities and edges.
- Choose DAX as the graph engine solely because it caches keyed DynamoDB reads.
Explanation
Correct Answer
C:Graph engines are designed around connected relationships and traversal operations central to fraud-network investigation.
Incorrect Answers
A:Object versions retain history but do not provide native graph traversal semantics.
B:Connection pooling is not a persistent graph data model.
D:Caching individual key requests does not supply a native graph traversal engine.
Question 748
An Amazon DocumentDB 5.0.1 cluster stores millions of order documents. A frequent query filters by a high-cardinality customer_id and sorts by created_at, but latency spikes and an explain execution plan shows a COLLSCAN with large documents-examined counts. The team can change indexes and wants to reduce unnecessary scans without changing the application data model. What should be done?
- Add read replicas only, without changing query plans or indexes, because replica count always converts each existing COLLSCAN into an IXSCAN.
- Enable a VPC gateway endpoint for DocumentDB and expect network routing to eliminate collection scans inside the database engine.
- Increase the client connection pool size and disable query plan inspection, because parallel collection scans cannot affect database compute pressure.
- Inspect the DocumentDB explain execution statistics and create a suitable selective compound index with customer_id and created_at in the supported order, then verify index usage and latency.
Explanation
Correct Answer
D:DocumentDB explain execution statistics can reveal collection scans and index use. A selective compound index that matches the filter and sort shape can reduce documents examined; validate actual query plans and write overhead.
Incorrect Answers
A:Replicas can add read capacity, but an unindexed query can still scan the entire collection on each replica and consume excessive CPU and I/O.
B:Private networking controls data paths but does not supply database query indexes or change a COLLSCAN into an indexed lookup.
C:More active client sessions often increase resource contention when the underlying plan repeatedly scans a large collection. It does not fix missing selective indexes.
Question 749
Two independent inventory services read the same DynamoDB item, each seeing Version=12, then calculate different stock updates. The business must not silently accept a stale write that overwrites the result of the other service. Conflicts are uncommon and a rejected writer can reload and retry. Which DynamoDB approach enforces this concurrency rule?
- Apply an UpdateItem condition that the stored version still equals 12, increment the version on success, and handle a failed condition by re-reading before retrying.
- Switch the table to on-demand billing and assume automatic capacity scaling serializes all competing updates correctly.
- Enable a DynamoDB Stream consumer and assume its later change event prevents the earlier overwritten item from being committed.
- Enable a DAX read cache and assume lower read latency makes concurrent blind PutItem overwrites impossible.
Explanation
Correct Answer
A:DynamoDB condition expressions can compare the version read by the caller with the current item version atomically at write time. A stale update fails rather than silently overwriting the newer state; the caller must handle the conflict.
Incorrect Answers
B:On-demand capacity controls how request throughput is billed and scaled, not the data-level concurrency rule. Sufficient capacity cannot stop logically stale writes by itself.
C:Streams emit item-change records after accepted writes; a downstream consumer is not an atomic precondition for whether a competing UpdateItem should commit.
D:DAX accelerates supported reads but does not enforce optimistic locking for concurrent writers. A conditional write or other explicit concurrency mechanism remains necessary.
Question 750
An Aurora PostgreSQL-compatible application handles low traffic on weekdays but bursts sharply during a two-hour batch of billing reconciliations. Its current provisioned DB instance is oversized most of the week. The team wants database compute to adjust within an approved min/max range without manually changing instance classes before each burst. Which capability fits?
- Use an S3 Intelligent-Tiering storage-class transition to change Aurora DB CPU capacity every hour.
- Use a supported Aurora Serverless v2 writer or reader with appropriate minimum and maximum ACU capacity configured on the cluster, after verifying engine-version compatibility and performance.
- Create only an additional DNS alias for the same provisioned DB instance and assume DNS scales its memory.
- Raise the Aurora database connection timeout to unlimited values, which provisions CPUs when query throughput grows.
Explanation
Correct Answer
B:Aurora Serverless v2 automatically varies supported DB instance compute capacity in ACUs between configured minimum and maximum values. Version eligibility and workload memory/connection requirements should be checked when selecting the capacity range.
Incorrect Answers
A:S3 object storage transitions have no effect on a running Aurora database instance class.
C:DNS aliases change how a database is addressed, not its CPU and memory allocation.
D:Longer connection timeouts do not allocate additional compute capacity and may worsen contention.
