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

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.

Question 561

Aurora Serverless v2 reaches its maximum ACU during a promotion and query latency rises without further scaling. What is the immediate configuration ceiling?

The cluster maximum ACU setting bounds each serverless DB instance, so it cannot scale above that configured limit.
Aurora Serverless v2 automatically ignores the configured maximum ACUs after traffic rises above a fixed threshold.
Reader endpoint connection balancing automatically increases serverless writer capacity without regard to its ACU maximum.
Add more Aurora reader instances but continue directing the overloaded write transactions to the serverless writer, assuming readers raise the writer maximum ACU bound.

Explanation

Correct Answer

Review engine/platform support and capacity settings before increasing the ceiling; serverless is not unbounded.

Incorrect Answers

The configured maximum is a real capacity ceiling for the eligible serverless instance even during strong demand.

Reader endpoints can distribute eligible reads but do not remove configured writer instance scaling bounds.

Read replicas provide eligible read capacity, not a way to exceed the configured ACU maximum on the serverless writer instance. Adjust limits after measuring supported instance and engine ceilings.

Question 562

A supported Amazon RDS database uses gp3 storage with 12,000 provisioned IOPS and 250 MiB/s provisioned storage throughput. During large sequential writes, CloudWatch shows WriteIOPS of about 4,000 but WriteThroughput consistently reaches 250 MiB/s and write latency rises. Which storage adjustment most directly addresses the measured bottleneck?

Increase provisioned IOPS alone from 12,000 to 20,000 while keeping the same 250 MiB/s throughput setting.
Increase the gp3 provisioned storage throughput within the supported storage, DB instance and engine limits, validating the observed byte-per-second load.
Increase allocated storage GiB alone and assume it automatically raises gp3 throughput for every supported instance class.
Enable a read replica and route the large database write transactions through its read-only endpoint.

Explanation

Correct Answer

For supported gp3 RDS configurations, throughput is a separate performance dimension from IOPS and volume capacity. The measured bytes per second have reached the configured throughput, not the IOPS setting, so raise throughput after checking service and instance ceilings.

Incorrect Answers

The workload uses substantially fewer I/O operations per second than its 12,000 IOPS budget, so raising IOPS alone leaves the saturated 250-MiB/s byte-throughput cap unchanged.

Adding disk space is not a guaranteed way to raise gp3 throughput: configurable gp3 performance is decoupled within AWS-supported size and engine constraints. The problem is a known storage bandwidth setting, not free-space exhaustion.

A read replica cannot accept primary write transactions, and replication does not add capacity to the writer volume throughput limit responsible for the observed high write latency.

Question 563

An RDS for PostgreSQL database received a large bulk import that changed the customer and date distribution in an orders table. A useful B-tree index already exists, but EXPLAIN shows a newly chosen sequential scan for highly selective searches and table statistics predate the import. What should be done before buying larger DB compute?

Double the DB instance CPU and assume PostgreSQL recalculates all column statistics during every SELECT without another operation.
Create another identical B-tree index on the same columns without reviewing the current planner statistics or actual query plan.
Run ANALYZE on the changed table to refresh planner statistics, compare EXPLAIN plans and then investigate index suitability if the costly scan remains.
Force one generic prepared-statement plan for every customer and date value to avoid considering changed data distribution or statistics.

Explanation

Correct Answer

ANALYZE refreshes PostgreSQL statistics used to estimate selectivity and choose access paths. The explicit before-import statistics and newly poor plan justify updating estimates, inspecting the result and revisiting indexing only if needed.

Incorrect Answers

More CPU does not make old data-distribution statistics current. PostgreSQL planning can remain poor after a major import until statistics accurately represent the changed table, especially for selective predicates.

Duplicating an existing useful index does not correct the outdated cardinality estimates or prove that the planner knows the new distribution. Confirm statistics and the selected plan before adding redundant schema cost.

Forcing a generic plan can worsen heavily skewed parameter ranges because it need not reflect the particular customer or date values. Refreshed statistics and evidence from EXPLAIN should guide the fix.

Question 564

An app requests ConsistentRead=true on a DynamoDB global secondary index and gets a validation error. What constraint explains it?

The GSI only needs twice the provisioned RCUs to support strong consistency and will accept the request.
A DynamoDB LSI always rejects ConsistentRead=true, so the GSI must be the only strong-read choice.
A successful strongly consistent query requires using DAX rather than the DynamoDB table itself.
Strongly consistent reads are unsupported on GSIs; they provide eventually consistent query results.

Explanation

Correct Answer

Use a base-table or supported LSI read when read-after-write certainty is essential.

Incorrect Answers

GSIs are eventually consistent by definition; additional capacity does not enable the unsupported ConsistentRead=true mode.

LSIs support strongly consistent reads, whereas GSIs cannot; the index types have distinct consistency capabilities.

DynamoDB supports strong reads on the table/LSI path; DAX does not make unsupported strong GSI reads valid.

Question 565

An analyst writes in the primary Aurora Region and immediately reads the old value from a secondary global Region. Why?

Cross-Region Aurora Global Database replication is asynchronous, so remote readers can lag the primary.
Aurora Global Database synchronously commits all secondary Region replicas before acknowledging primary transactions.
CloudFront invalidation delay controls when each Aurora reader applies its database redo logs.
Setting the read endpoint to the local Region makes secondary reads strongly consistent by default across all Regions.

Explanation

Correct Answer

Route read-after-write sensitive workflows appropriately, rather than assuming local global readers have zero replication delay.

Incorrect Answers

Aurora global replication is asynchronous and can lag the primary, so remote readers are not guaranteed instant read-after-write visibility.

CloudFront CDN cache events do not control Aurora physical cross-Region database replication.

A nearby reader reduces network latency but does not eliminate Aurora Global Database’s asynchronous replication lag.

Question 566

A Redshift query joins two very large fact tables and spills data between nodes despite ample overall disk. Which modeling issue should be investigated?

A larger Redshift node always eliminates join redistribution regardless of how tables are distributed on the compute slices.
Poor data distribution or join-key alignment causes large redistributions and skew across Redshift slices.
Switch both Redshift tables to DISTSTYLE ALL regardless of their fact-table size and assume duplicating every large fact table on each node always reduces total join memory and network use.
Choose a DISTKEY column with extremely low cardinality for both fact tables and assume that merely matching that column guarantees even parallel slice work.

Explanation

Correct Answer

Choose distribution strategies from query plans and workload patterns rather than treating total disk capacity as join throughput.

Incorrect Answers

Poor distribution keys cause network shuffles and skew; memory/capacity alone does not resolve an inefficient join data layout.

DISTSTYLE ALL can help small dimension lookups but can be wasteful for very large fact tables. Choose a distribution key or automatic style from join patterns, table size and skew measurements.

Matching join keys can reduce redistribution, but a low-cardinality or skewed key can concentrate too many rows on a few slices and defeat parallel performance.

Question 567

An OpenSearch domain has long refresh intervals; a newly indexed document is not found immediately by a search query although indexing succeeded. Why?

Search visibility follows the index refresh cycle, which differs from acknowledging an indexing write.
An indexing acknowledgment guarantees that all search segments are refreshed and queries see the document instantly.
The document must be missing from the index because OpenSearch never supports searching data written through indexing APIs.
Force an OpenSearch search using a newer client-side timeout while leaving the index refresh interval unchanged, assuming the timeout makes the acknowledged document search-visible.

Explanation

Correct Answer

A refresh or waiting for index visibility is needed for immediate search assertions; a successful HTTP indexing response alone is insufficient.

Incorrect Answers

OpenSearch near-real-time search visibility depends on refresh behavior rather than on the write acknowledgment alone.

OpenSearch supports indexed document queries; the scenario is about the refresh interval delaying visibility, not absent capability.

Longer timeouts do not trigger a segment refresh. Use a supported refresh policy or wait for refresh, balancing search visibility needs against indexing throughput.

Question 568

A DynamoDB TransactWriteItems call fails a condition check; neither the inventory decrement nor the order insert appears. Why?

DynamoDB applies the inventory decrement first and only rolls back the order item on a failed condition.
The transaction is all-or-nothing; a failed condition cancels the entire atomic write set.
The transaction generated a provisional partial success visible to strongly consistent reads until the next index refresh.
Retry the same TransactWriteItems request with a less restrictive condition on only the order item but leave the failed inventory condition unchanged, expecting an order-only partial commit.

Explanation

Correct Answer

The absence of partial writes is expected transaction behavior, not proof that the request silently succeeded.

Incorrect Answers

A failed TransactWriteItems call cancels the complete transaction rather than leaving a partial inventory modification.

DynamoDB transactions provide atomic outcomes; a failed condition prevents the participating writes from committing.

A conditional failure on any participating transaction action cancels the complete atomic transaction; selective weakening of an unrelated condition does not permit a partial write set.

Question 569

A global SaaS site serves the same versioned JavaScript and images to users on five continents. Its single-Region S3 origin sees high RTT and repeated downloads. Which architecture improves delivery?

Cache every HTML response permanently with a single unrestricted CloudFront cache key even when it includes logged-in user data.
Serve cacheable static assets through Amazon CloudFront with an S3 origin and tuned cache keys/TTLs.
Keep all global clients downloading the same JavaScript from the single-Region S3 origin without edge caching, and assume latency is independent of distance.
Set every static asset to Cache-Control: no-store and expect CloudFront to retain reusable edge copies through a long TTL anyway.

Explanation

Correct Answer

CloudFront places copies near viewers in edge locations and reduces repeat origin requests for cacheable objects.

Incorrect Answers

CloudFront can accelerate cacheable assets, but sharing private personalized responses under one cache key leaks content and violates safe caching semantics.

Distance and repeated origin trips affect global object delivery; caching versioned static assets near users with CloudFront reduces repeat origin requests and latency.

Origin and cache policies govern eligibility and TTL. no-store with an effective zero minimum TTL prevents the desired shared caching of immutable assets.

Question 570

A global multiplayer game must use TCP and UDP endpoints with stable global entry IP addresses, and must rapidly route clients around unhealthy Regional endpoints. Which front door fits?

Use CloudFront as a raw UDP proxy with two static anycast IP addresses and expect it to route arbitrary datagrams.
Use an Application Load Balancer HTTPS listener as the only global entry IP and assume it directly accepts arbitrary UDP game traffic.
Publish one Regional NLB address through DNS and assume it automatically provides globally stable anycast IPs and health-based routing across Regions.
Use AWS Global Accelerator with static anycast IP addresses and appropriately configured Regional endpoints.

Explanation

Correct Answer

Global Accelerator uses the AWS global network for supported transport traffic and endpoint health-driven traffic steering.

Incorrect Answers

CloudFront distributes supported HTTP(S) web content; Global Accelerator is the AWS global IP-based accelerator for general TCP/UDP endpoints.

An ALB targets HTTP/HTTPS application requests and is not a general UDP global anycast endpoint; Global Accelerator supports static anycast and TCP/UDP use cases.

A Regional load balancer cannot on its own deliver Global Accelerator’s global anycast ingress and cross-Region endpoint-group health routing.

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

Question 560

Explanation

Correct Answer

Incorrect Answers

Question 561

Explanation

Correct Answer

Incorrect Answers

Question 562

Explanation

Correct Answer

Incorrect Answers

Question 563

Explanation

Correct Answer

Incorrect Answers

Question 564

Explanation

Correct Answer

Incorrect Answers

Question 565

Explanation

Correct Answer

Incorrect Answers

Question 566

Explanation

Correct Answer

Incorrect Answers

Question 567

Explanation

Correct Answer

Incorrect Answers

Question 568

Explanation

Correct Answer

Incorrect Answers

Question 569

Explanation

Correct Answer

Incorrect Answers

Question 570

Explanation

Correct Answer

Incorrect Answers

AWS Certified Solutions Architect - Associate SAA-C03 Practice Tests