Amazon AWS Certified Solutions Architect - Associate SAA-C03 Practice Test 56

Question 550

A reporting dashboard shows a newly committed order missing for several seconds on an RDS read replica, although the primary shows it. What explains the discrepancy?

The Multi-AZ standby temporarily stops synchronous replication whenever a SELECT query is issued against the source.
The source transaction was rolled back after its commit, and the replica always displays the last failed transaction.
A read replica is guaranteed to reflect each source commit before the source reports write success.
Asynchronous replication can introduce replica lag, so the replica need not reflect the latest primary commit immediately.

Explanation

Correct Answer

An RDS read replica is not a synchronous standby or a read-after-write consistency guarantee. Route immediate consistency reads to the primary.

Incorrect Answers

The scenario identifies a read replica; its asynchronous replication can lag even with no Multi-AZ standby changes.

A successful primary commit is not necessarily rolled back; an asynchronous replica can have outstanding changes yet to apply.

That would describe a synchronous consistency contract, which regular RDS read-replica asynchronous replication does not provide.

Question 551

A company deploys a supported Amazon RDS for PostgreSQL Multi-AZ DB CLUSTER with one writer and two readable standby DB instances across three Availability Zones. It wants to run heavy read-only analytics without keeping those reports on the writer. Which endpoint should the analytics clients use?

Connect every reporting client to the Multi-AZ DB cluster writer endpoint because it automatically redistributes all SELECT statements to the two reader DB instances.
Connect reporting clients to the writer instance endpoint and enable synchronous failover, expecting each SQL query to run on a standby.
Replace the cluster with a traditional single-standby Multi-AZ DB instance and use that standby for ordinary read-only SQL.
Connect report clients to the Multi-AZ DB cluster reader endpoint, and keep write transactions on the writer endpoint.

Explanation

Correct Answer

The reader endpoint establishes read-only sessions on the two available reader instances of a supported Multi-AZ DB cluster, offloading compatible reports from the writer. Transactions needing writes use its writer endpoint; confirm engine/Region support and replica-lag tolerance.

Incorrect Answers

The writer endpoint connects to the current writer DB instance and permits read/write operations, but does not fan out individual reporting queries across the two readers. The cluster has a separate read-only reader endpoint for that workload.

An instance endpoint targets one specific DB instance. Automatic failover does not transform a writer instance endpoint into a reader-balancing connection, and semisynchronous replication is an availability mechanism rather than query routing.

A traditional Multi-AZ DB instance with one standby reserves that standby for failover and does not expose it for read SQL. The existing Multi-AZ DB cluster already has two separate readable instances.

Question 552

A table with sudden traffic exceeding twice its previous on-demand peak begins throttling. Why does the label on-demand not guarantee instant unlimited capacity?

The table uses an explicit provisioned RCU ceiling that prevents DynamoDB on-demand from applying to any request.
DynamoDB on-demand capacity prohibits scaling above the original amount of data stored in the table.
On-demand scaling still has documented peak-growth behavior and table or account capacity limits; rapid jumps can require prewarming or quota planning.
Every throttled request proves a global secondary index has exceeded a hard 10-GB item collection limit.

Explanation

Correct Answer

The absence of manually specified RCUs does not mean every unbounded spike is accepted without scaling or throughput ceilings.

Incorrect Answers

The stated table is already in on-demand mode; reaching prior peak scaling limits can still throttle without a provisioned RCU setting.

On-demand throughput scaling is related to traffic history, quotas and warm throughput, not simply the table’s stored data size.

The 10-GB item-collection constraint belongs to tables with LSIs; an on-demand traffic spike can throttle independently of index size.

Question 553

A DynamoDB provisioned table keeps throttling in sharp microsecond bursts despite a target-tracking auto scaling policy. Why?

Target tracking reacts to CloudWatch metrics over time and cannot instantly provision capacity for every sudden short spike.
CloudWatch target tracking raises the table’s capacity for a spike before the monitoring service has collected any metrics.
Set DynamoDB Application Auto Scaling target utilization to 50% but choose a very low maximum write capacity, assuming the target tracking policy overrides its configured scale-out ceiling for short bursts.
Auto scaling permanently switches the table to on-demand billing after the first high-utilization alarm.

Explanation

Correct Answer

For spiky workloads, evaluate on-demand, prewarming or sufficient headroom rather than relying on lagging metric adjustment.

Incorrect Answers

Reactive scaling depends on observed demand and has evaluation/provisioning latency; it cannot predict arbitrary brief spikes.

Target tracking stays within configured min/max capacity bounds. An overly low maximum can throttle even with a low target utilization, while a sudden spike may exceed scaling reaction time.

Provisioned target tracking adjusts provisioned RCUs/WCUs and does not silently change DynamoDB capacity mode.

Question 554

An orders DynamoDB base table has well-distributed orderId partition keys and ample provisioned write capacity. After adding a global secondary index with partition key status, most new orders write status="PENDING"; base-table PutItem calls begin returning IndexWriteKeyRangeThroughputExceeded on the GSI ARN. What should the architect change?

Redesign the low-cardinality GSI partition key to distribute index updates, for example with a higher-cardinality composite or sharded key, and adapt query fan-out as necessary.
Raise only the base table write capacity while leaving the hot status-only GSI key and its partition bottleneck unchanged.
Ask the application to use strongly consistent Query requests against the same GSI to increase index-write capacity.
Add a local secondary index under the orders base table partition key and assume that makes the existing GSI receive fewer writes automatically.

Explanation

Correct Answer

The error identifies an index key-range throughput hot spot, even though the base table writes are distributed. A higher-cardinality GSI key or explicit write sharding separates update traffic among index partitions; the query access pattern must be updated to merge or select shards as needed.

Incorrect Answers

Write throttling can propagate from an overloaded GSI to its base table. Increasing table-only capacity cannot resolve the GSI partition hot spot indicated by IndexWriteKeyRangeThroughputExceeded.

Global secondary indexes offer eventually consistent reads only. Read consistency is not a mechanism for provisioning additional index writes or redistributing updates under a status-only key.

An LSI shares the primary table partition key and is maintained separately; creating it does not repartition or stop updates to the existing GSI. The immediate failure source is the status-only GSI write hot spot.

Question 555

After adding a DynamoDB GSI, a dashboard immediately queries the index after PutItem and occasionally does not see the new item. Why?

GSI updates are asynchronous and index reads are eventually consistent, even if base-table read behavior differs.
GSI indexes receive synchronous updates before DynamoDB acknowledges every base-table write.
A GSI supports strongly consistent queries if the application passes ConsistentRead=true.
The missing record proves the base table’s partition key is different from the one used by the index.

Explanation

Correct Answer

Do not promise strongly consistent reads from a GSI or use a newly updated index as an immediate commit acknowledgment.

Incorrect Answers

GSI propagation is asynchronous, so an immediately queried index may not yet contain a recently written base-table item.

DynamoDB global secondary indexes do not support strongly consistent reads; their update visibility is eventual.

A GSI intentionally uses another partition key; the transient delay after a successful PutItem is due to index propagation rather than key disagreement.

Question 556

A DynamoDB LSI-backed table rejects writes for one partition key when its item collection grows beyond 10 GiB. Which limit was reached?

The LSI item collection 10 GiB limit per partition key, including table and index data.
DynamoDB GSIs always inherit a 10-GB total size limit, even when an LSI is present.
Increasing provisioned RCUs will automatically raise the item collection storage limit for each LSI partition key.
The table has exceeded a 10-GB limit on the entire table regardless of partition key or indexes.

Explanation

Correct Answer

Adding more provisioned RCUs cannot remove the per-key item-collection size ceiling; redesign or archive that item collection.

Incorrect Answers

The documented item collection ceiling applies to a table with local secondary indexes for one partition-key value, not a universal GSI limit.

Capacity throughput units do not change the LSI-backed 10-GB item collection size restriction.

The restriction is per logical partition-key item collection for tables containing LSIs, not a 10-GB global table-size limit.

Question 557

A financial workload routes strongly consistent DynamoDB GetItem requests through DAX but observes no cache acceleration. Why?

DAX has automatically converted all strongly consistent reads into stale eventual reads from its item cache.
DAX can cache a strongly consistent result if the client enables the `ConsistentRead=true` request flag.
Strongly consistent reads bypass the DAX cache and go to DynamoDB; DAX caching targets eventually consistent requests.
The DynamoDB table must have an LSI for any DAX GetItem call to use the cache.

Explanation

Correct Answer

DAX cannot replace the strongly consistent read semantics with microsecond cache answers.

Incorrect Answers

DAX forwards strongly consistent requests to DynamoDB; it does not silently weaken those requests into cached eventual results.

Strong consistency bypasses DAX caching, so the flag prevents cache acceleration rather than enabling it.

DAX cache behavior depends on read type and cache hits, not a requirement to add an LSI for key-value lookup caching.

Question 558

An ElastiCache deployment shows nearly no hit-rate improvement after launch; every API path queries RDS before checking Redis. What architectural error explains this?

Redis cache-aside transparently intercepts all SQL SELECT statements without any application changes.
Configure a Redis cache that stores only product IDs but continue using the uncached RDS query result for every API response, expecting the cache alone to lower database read usage.
A high Redis cache hit rate is proven by provisioning a larger cache node regardless of the application access path.
The application never consults the cache before the database, so cache-aside cannot reduce database reads.

Explanation

Correct Answer

A running cache cluster is not a transparent RDS read proxy; integrate lookups and populate cache entries on misses.

Incorrect Answers

Cache-aside requires the application to check and populate the cache before falling back to the database.

Cache storage without routing eligible reads through cached values or populating useful records does not avoid executing the original database query. Align cache keys and lookup sequence with the real access pattern.

Cache hit ratio depends on actual lookup and invalidation behavior; a cache consulted after the database cannot avoid database reads.

Question 559

A Redis cache configured with noeviction begins rejecting writes at its memory limit, even though many entries are cold. Why?

Redis will always evict the least recently used key under noeviction after reaching maxmemory.
The selected noeviction memory policy forbids dropping cached entries when memory is full.
The presence of cold cache keys means there is unlimited available memory if network bandwidth is high.
Change Redis key TTLs but keep the noeviction maxmemory policy while assuming expired-key cleanup guarantees enough space for every write burst.

Explanation

Correct Answer

For disposable cache entries, compare allkeys or volatile eviction policies with product semantics and capacity needs.

Incorrect Answers

The noeviction setting specifically disallows automatic eviction to make room for new writes at the limit.

Memory usage is bounded by the configured maxmemory regardless of whether keys are frequently accessed.

TTL expiry only removes expired keys, not arbitrary cold unexpired keys. A full Redis cache configured noeviction can reject writes despite many cold entries; choose a suitable eviction policy or capacity.

Question 560

A team uses RDS Proxy but every session executes connection-specific SET statements and holds transactions open; database connections still peak. What limits pooling?

Connection pinning has no effect on RDS Proxy because all SQL SET statements can be replayed freely on any backend.
Increase the RDS Proxy connection pool maximum without changing pinned application sessions, assuming the proxy can safely multiplex a backend that an open long-running transaction still owns.
Session pinning or long transactions can hold backend connections and reduce proxy multiplexing efficiency.
Enable an RDS Proxy session pinning filter that ignores all SET variables on a PostgreSQL proxy, assuming it is universally supported and safe for session-dependent SQL.

Explanation

Correct Answer

Check proxy session pinning metrics/logs and application session behavior instead of assuming a proxy eliminates all client connection costs.

Incorrect Answers

RDS Proxy can pin sessions that depend on session-level state or long transactions, reducing its ability to reuse a backend connection.

More permitted backend connections can postpone saturation but cannot make stateful pinned sessions multiplex. Reduce unnecessary pinning and shorten transactions before relying on pooling elasticity.

The available EXCLUDE_VARIABLE_SETS filter is not supported for PostgreSQL and can compromise stateful workload behavior if used indiscriminately in eligible MySQL family engines. Avoid session-state changes or adjust safe initialization.

Pass Your Amazon AWS Certified Solutions Architect - Associate SAA-C03 Exam Easy!

Question 550

Explanation

Correct Answer

Incorrect Answers

Question 551

Explanation

Correct Answer

Incorrect Answers

Question 552

Explanation

Correct Answer

Incorrect Answers

Question 553

Explanation

Correct Answer

Incorrect Answers

Question 554

Explanation

Correct Answer

Incorrect Answers

Question 555

Explanation

Correct Answer

Incorrect Answers

Question 556

Explanation

Correct Answer

Incorrect Answers

Question 557

Explanation

Correct Answer

Incorrect Answers

Question 558

Explanation

Correct Answer

Incorrect Answers

Question 559

Explanation

Correct Answer

Incorrect Answers

Question 560

Explanation

Correct Answer

Incorrect Answers

AWS Certified Solutions Architect - Associate SAA-C03 Practice Tests