AWS Certified Solutions Architect - Associate SAA-C03 Practice Test 74
Question 730
A DynamoDB table scales successfully, but the DAX cache cluster saturates on read bursts and has a single point of cache failure. Which component needs its own capacity and availability plan?
- Increase DynamoDB base-table RCUs and assume this automatically creates additional DAX nodes.
- Scale and configure the DAX cache cluster with appropriate nodes and AZ redundancy independently of table read capacity.
- Disable DAX failover and use one cache node because DynamoDB itself is replicated.
- Raise the API Gateway rate limit and expect DAX to gain memory and CPU automatically.
Explanation
Correct Answer
B:DAX is a distinct service tier with its own node throughput and topology, even though it fronts DynamoDB.
Incorrect Answers
A:Table capacity and DAX cluster node allocation are separate control planes.
C:The application can still lose its cache endpoint or suffer high latency when a single DAX node fails.
D:Gateway request settings do not add DAX cache compute resources.
Question 731
A product table supports only order-id primary-key queries. A new API needs efficient `status` plus timestamp lookup. A developer recommends DAX caching rather than introducing a suitable GSI or changing the key model. What is the distinction?
- Add DAX and assume it transparently creates an index over every nonkey attribute.
- Increase DynamoDB stream retention and expect it to enable partition-key lookups on `status`.
- Design a suitable DynamoDB key/index access pattern for the new query; DAX improves compatible cached reads but does not invent a new query key schema.
- Use ConsistentRead on a nonexistent GSI as a substitute for creating the index.
Explanation
Correct Answer
C:DAX may speed eligible API calls, while a GSI changes which attributes can be used as index keys.
Incorrect Answers
A:A cache does not automatically implement arbitrary GSI or Scan-to-Query transformations.
B:Streams capture item changes, not alternate query key definitions.
D:Consistency settings cannot address an access path that is not modeled.
Question 732
A news platform caches article access-control metadata in ElastiCache with no expiration. When permissions are revoked, readers remain authorized by obsolete cache entries. What should the cache policy introduce?
- Use a long eviction-free cache policy to reduce database reads and rely on the database transaction log to invalidate authorizations implicitly.
- Enable ElastiCache Multi-AZ replication so role revocations automatically invalidate cached permission keys in every reader.
- Add more cache nodes and use a least-frequently-used memory policy in place of event-driven invalidation or expiration.
- Invalidate affected authorization cache keys when permissions change and enforce a bounded TTL to limit stale entries if an invalidation event is missed.
Explanation
Correct Answer
D:Explicit invalidation on role-change events removes the stale value promptly; bounded expiration provides a backstop after missed events, subject to the security requirement’s maximum staleness window.
Incorrect Answers
A:A database commit does not automatically invalidate separate application-managed cache keys. Persistent stale grants remain dangerous even when the system of record is correct.
B:ElastiCache replica synchronization copies cached state, including stale entries. Multi-AZ improves availability but does not translate database role updates into cache invalidations.
C:More nodes or an LFU eviction algorithm addresses memory pressure, not correctness of cached access-control decisions after a revocation.
Question 733
An order API relies on an ElastiCache cluster for frequently accessed but reconstructible data. During a node crash, the whole cache becomes unreachable because there is no standby path. The availability requirement covers a single-AZ cache loss. What helps?
- Configure supported cache replication, Multi-AZ failover and suitable client reconnection behavior.
- Keep one cache node but increase its memory to prevent any physical server outage.
- Use an S3 lifecycle rule as a replacement for cache-node replication.
- Remove all application retry logic because managed cache failover never interrupts active TCP connections.
Explanation
Correct Answer
A:An appropriate replicated cache topology can promote or serve from surviving nodes when a cache node/AZ fails.
Incorrect Answers
B:Node size does not create a second fault domain or guarantee uninterrupted hardware.
C:Object transitions do not preserve live Redis/Valkey endpoints during node failure.
D:Topology changes can still drop connections and need client recovery.
Question 734
A checkout platform uses an Amazon ElastiCache Redis OSS replication group in cluster-mode-disabled configuration. Its cache has a primary node and a same-AZ read replica, and a full Availability Zone outage would interrupt writes. The authoritative order database is already durable; the objective is faster cache recovery after an AZ outage. Which adjustment best fits?
- Increase the primary cache node memory and leave both nodes in the same Availability Zone, treating memory headroom as AZ failover.
- Place at least one read replica in another Availability Zone and enable ElastiCache Multi-AZ with automatic failover so an eligible replica can be promoted on primary failure.
- Keep the same-AZ replica and manually update the application’s hard-coded primary IP whenever a cache node fails, without enabling failover.
- Enable cross-Region S3 replication for an unrelated bucket and assume it promotes the Redis primary within the existing Region.
Explanation
Correct Answer
B:For a compatible Valkey or Redis OSS replication group, Multi-AZ with a replica in a different AZ enables automatic promotion when the primary fails. The application must still tolerate a brief write interruption and the applicable asynchronous replication characteristics.
Incorrect Answers
A:More cache memory may reduce eviction or cache misses, but it does not create an independent Availability Zone failure domain for the only primary and same-AZ replica.
C:Manual reconfiguration is slower and fragile. A replica in the same AZ also leaves an AZ-wide outage without a surviving failover target.
D:S3 object replication is unrelated to primary selection within an ElastiCache replication group and does not supply cache-node automatic failover.
Question 735
RDS Proxy is inserted in front of a database, reducing expensive connect/disconnect overhead. However the database's maximum backend connections still cause failure under unprecedented traffic. Which limit matters?
- Set the proxy pool to unlimited and assume it creates infinite database backend sessions.
- Add more database TLS certificates because each certificate increases maximum query throughput.
- Right-size RDS Proxy connection pool limits and database capacity, and bound client concurrency/retries.
- Increase the number of API request headers and assume pooled SQL sessions become more efficient.
Explanation
Correct Answer
C:Connection reuse reduces churn but the database still has finite connections, CPU and transaction capacity.
Incorrect Answers
A:A managed proxy cannot exceed the database's actual connection or compute limits.
B:Certificates secure connections; they do not allocate backend SQL processing resources.
D:HTTP header count does not remove a database connection bottleneck.
Question 736
A legacy MySQL application uses session variables and temporary tables with RDS Proxy. Backend connection reuse falls far below expectations because sessions are pinned. What should be investigated?
- Increase the number of API DNS queries and assume this releases pinned SQL sessions.
- Enable longer database parameter retention without changing the session variable usage.
- Add reader replicas and assume this automatically removes per-session pinning in the proxy's writer pool.
- Inspect session/transaction behaviors that cause RDS Proxy pinning and modify stateful connection usage where compatible.
Explanation
Correct Answer
D:Session-level state can require a client to remain on a particular backend, reducing the connection-multiplexing benefit.
Incorrect Answers
A:DNS resolution is unrelated to session state held within established database connections.
B:Unmodified stateful sessions can remain pinned regardless of administrative settings.
C:Read replicas address read capacity, not the session semantics that prevent multiplexing.
Question 737
An application uses RDS Proxy in front of an RDS database. During traffic bursts, clients see long waits before SQL execution begins. Database CPU and QueryDatabaseResponseLatency remain steady, but DatabaseConnectionsBorrowLatency rises sharply while DatabaseConnections approaches MaxDatabaseConnectionsAllowed. What is the best first diagnosis and measurement plan?
- Investigate RDS Proxy backend connection borrowing and pool saturation using the borrow-latency and available-connection metrics; then examine pinning and headroom before adjusting pool settings.
- Assume the SQL optimizer has regressed and immediately increase statement timeouts, because the stable database response-latency metric proves that query execution slowed.
- Create RDS read replicas and assume the current proxy will immediately route every write and read to a new reader without endpoint or workload changes.
- Increase the proxy IdleClientTimeout alone so that clients hold idle frontend sessions longer, and treat that setting as a guarantee of available backend connections.
Explanation
Correct Answer
A:DatabaseConnectionsBorrowLatency measures time waiting for a backend database connection. Rising borrow latency with connections near the allowed limit and stable query response latency points first to proxy pool contention, pinning, and capacity headroom—not necessarily slow SQL.
Incorrect Answers
B:QueryDatabaseResponseLatency tracks database response time; its stability does not substantiate a new SQL execution bottleneck. Changing query timeouts does not restore available proxy database connections.
C:Read replicas can serve eligible read workloads but do not automatically repair a saturated proxy pool or cause all existing proxy traffic to be transparently rerouted. The observed metric pattern needs connection-layer diagnosis.
D:IdleClientTimeout determines when idle client-to-proxy connections are closed; it is not a reservation of available proxy-to-database connections and does not alone address exhausted backend capacity.
Question 738
An RDS transactional database has low CPU but sustained write latency with IOPS metrics at its configured storage limit. The engine and deployment support a provisioned IOPS storage configuration. Which tuning path is relevant?
- Add more application read replicas as the only remedy for writer disk saturation.
- Evaluate a supported provisioned-IOPS storage option and increase I/O capacity based on measured operations and latency.
- Increase only database query timeout while leaving I/O saturation unresolved.
- Enable a bigger ALB idle timeout to increase backend DB storage I/O capacity.
Explanation
Correct Answer
B:When storage I/O saturation is confirmed, provisioning appropriate IOPS can address the bottleneck without unrelated CPU scaling.
Incorrect Answers
A:Additional read serving does not necessarily accelerate the primary's transaction log writes.
C:Longer timeouts may mask symptoms but cannot deliver more disk IOPS.
D:HTTP connection settings are separate from database storage provisioning.
Question 739
An Amazon RDS for PostgreSQL order table is updated and deleted from continuously. Over several weeks its physical table size and query latency have grown even though the logical row count is steady and instance CPU and storage I/O metrics show available capacity. pg_stat_user_tables shows many dead tuples and an old last_autovacuum timestamp. What is the most relevant corrective investigation?
- Provision much higher gp3 throughput immediately, since dead tuples always prove the EBS bandwidth limit has been reached.
- Disable autovacuum on the busy table permanently to remove its background work and prevent further dead tuples.
- Inspect dead-tuple counts and vacuum history, then tune suitable PostgreSQL autovacuum thresholds and worker capacity for the high-churn table.
- Create a Multi-AZ standby and expect failover alone to remove the PostgreSQL table bloat on both database instances.
Explanation
Correct Answer
C:PostgreSQL autovacuum runs VACUUM and ANALYZE in the background to reclaim reusable space and keep planner statistics current. For update-heavy tables, check pg_stat_user_tables and tune the relevant vacuum thresholds, scale factors and worker resources.
Incorrect Answers
A:Higher storage throughput cannot directly reclaim obsolete PostgreSQL MVCC tuple versions or correct missed vacuum cycles. The scenario reports spare I/O capacity and concrete dead-tuple evidence.
B:Disabling autovacuum permits dead tuples and transaction age to accumulate, increasing bloat and potential wraparound risk; it does not clean the affected table.
D:A standby is an availability mechanism, not a solution to excessive dead tuples or ineffective autovacuum configuration. The database maintenance issue must be addressed.
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.
