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

Question 380

An RDS system uses automated backups and Multi-AZ failover, with retention required for a compliance recovery window. What should its operational plan verify?

Assume Multi-AZ standby is a permanent immutable backup of every deleted row.
Disable automated backups immediately after the first healthy failover.
Promote a Multi-AZ standby during an outage and assume that the standby retains every historical row deleted during the past 30 days.
Confirm automated-backup retention and restorable points independently of failover, then test restoring to a separate instance.

Explanation

Correct Answer

Failover continuity and historical recovery are different capabilities; a successful standby takeover does not prove older points remain usable.

Incorrect Answers

Standby replication propagates writes and deletions, so historical recovery needs backups.

That removes required historical recovery points.

Standby replication includes recent writes and deletes. Recovering a past version of data requires backups and supported point-in-time restore history.

Question 381

An ALB serves targets in us-east-1a only. When that AZ loses connectivity, regional DNS still resolves but every application request fails. Why did the design not meet its AZ-failure goal?

The DNS alias did not use a very short TTL.
The S3 bucket lacked a second lifecycle rule.
Increase a single-AZ target group’s deregistration delay and assume draining connections will create healthy alternative AZ targets during regional ALB failover.
The target fleet had no healthy capacity in a second Availability Zone.

Explanation

Correct Answer

A regional ALB alone is not sufficient when all backing targets share one AZ failure domain.

Incorrect Answers

DNS TTL cannot create healthy targets in another AZ.

Object lifecycle does not address missing web compute.

Connection draining controls how existing traffic winds down; it cannot create surviving application targets in another Availability Zone.

Question 382

An RDS Multi-AZ DB instance writer fails. The application remains pointed at a hard-coded old writer IP and does not recover when failover completes. What went wrong?

A Multi-AZ standby should answer report SQL on a permanent separate reader endpoint.
Cache the RDS writer endpoint DNS result for the entire process lifetime and reuse its obsolete address after failover rather than reconnecting.
The application bypassed the stable RDS DB endpoint and pinned a physical IP that changed during failover.
The RDS failover mechanism guarantees that a hard-coded former writer IP always persists.

Explanation

Correct Answer

Automatic DB standby promotion requires clients to reconnect through the appropriate DNS endpoint, including cache/session refresh.

Incorrect Answers

Conventional Multi-AZ instance standby is not a reporting reader.

Even if the application originally resolved the managed endpoint, stale cached IPs and sessions must be refreshed after AWS moves the writer.

Failover can move the writer to different networking resources.

Question 383

A supported Amazon RDS Multi-AZ DB cluster already has its report clients connected through the correct reader endpoint, but one pooled database CONNECTION persists for hours and carries most reporting SQL while the other reader stays lightly loaded. Why does the reader endpoint not distribute each SQL statement evenly between reader instances?

The reader endpoint always connects to the writer even when two healthy DB cluster readers exist.
Creating a second read-capable standby automatically migrates each SQL query on an already-open PostgreSQL session between database instances.
The Multi-AZ DB cluster reader endpoint chooses an eligible reader for each NEW connection; a long-lived session stays on its assigned instance rather than rebalancing each SQL statement.
RDS Multi-AZ DB clusters cannot expose a reader endpoint and must run every report against the writer.

Explanation

Correct Answer

AWS describes connection-level reader endpoint routing. Appropriate connection-pool distribution or supported instance endpoints can avoid concentrating all reads on one long-lived session.

Incorrect Answers

Reader endpoints for the cluster are intended to connect sessions to read-capable replica instances, not always the writer.

SQL sessions are attached to a selected server connection. Adding replicas does not retarget each statement in a persistent connection.

Supported Multi-AZ DB clusters provide a dedicated read-only reader endpoint, separate from the writer endpoint.

Question 384

An Aurora writer stops. A particular reader was designated as preferred failover target, but a different reader is promoted because the preferred one is unavailable. Which assumption failed?

A configured promotion priority is a preference among eligible healthy readers, not a guarantee that an unavailable replica becomes writer.
Aurora must always choose an unhealthy priority-0 reader and accept total outage.
Set all healthy Aurora replica promotion tiers to the same lowest priority and assume instance naming alone forces the preferred reader to be elected.
Changing the DNS record name of the reader forces its priority to outrank health.

Explanation

Correct Answer

Aurora evaluates eligible promotion candidates and can choose a different healthy reader when the preferred one cannot be promoted.

Incorrect Answers

Failover can use other available replicas.

Equal configured tiers cause Aurora to use other candidate-selection criteria. Naming a reader does not guarantee promotion or supersede health eligibility.

Endpoint text does not supersede Aurora promotion eligibility.

Question 385

An RDS single-AZ primary is backed by an asynchronous read replica. Primary storage fails, and the company assumed the replica had been promoted automatically with zero lag. Why is this unsafe?

Read replicas always retain all uncommitted transactions that the primary did not write.
AWS guarantees all independent RDS read replicas are synchronous HA standbys.
The customer must remove database indexes before enabling a replica.
An ordinary read replica uses asynchronous replication and does not provide the same automatic synchronous Multi-AZ standby failover contract.

Explanation

Correct Answer

A read replica may lag and ordinarily requires an intentional promotion/failover strategy.

Incorrect Answers

Uncommitted changes are not guaranteed on an asynchronous reader.

Read replication and Multi-AZ standby semantics differ.

Index management does not fix the HA assumption.

Question 386

A Route 53 failover configuration has a primary alias but its health check tests only the instance TCP port, which remains open while the HTTP app returns 500. Users never fail over. What is wrong?

Route 53 never supports health-based failover for any DNS records.
The configured health signal does not reflect actual application usability, so the primary stays classified healthy.
Change the Route 53 health check from HTTPS to TCP on the same open port, leaving application HTTP 500 errors invisible to the health signal.
A CloudFront price class must be enabled before Route 53 can see 500 responses.

Explanation

Correct Answer

A suitable application-level health check must exercise the meaningful endpoint failure.

Incorrect Answers

Route 53 does support conditional failover records.

TCP reachability does not show whether checkout can serve real requests. An application-level HTTP or calculated health signal must cover the relevant failure.

CDN pricing scope does not change Route 53 health check target behavior.

Question 387

A team uses a weighted Route 53 record with weights 90:10 to send traffic to two Regions. The primary Region goes offline, yet some DNS answers still select it. Why?

Weighted routing is equivalent to an active/standby failover policy in every configuration.
The record cannot include two targets in different AWS Regions.
Weighted routing alone is traffic distribution; failout of an unhealthy endpoint requires supported health-check integration.
Create a static Route 53 weighted policy with equal health thresholds omitted and assume an unhealthy 90-weight target is removed solely because its weight is high.

Explanation

Correct Answer

Weights specify desired answer allocation; add appropriate health conditions if unhealthy targets must be excluded.

Incorrect Answers

Weights do not imply health-aware failover when no health checks are configured.

Weighted policies can route among eligible targets across Regions.

Weights determine answer distribution, not automatic endpoint failure detection. Configure supported record health checks or target-health evaluation.

Question 388

A CloudFront origin group switches GET requests after selected 500 errors but a POST payment write still fails rather than being transparently replayed to the backup origin. Why?

POST requests always have a durable exactly-once CloudFront replay contract.
Set CloudFront origin failover response status codes correctly but assume those status codes override its method restriction for POST order requests.
CloudFront origin failover supports only eligible HTTP methods/status conditions; it is not a general transactional POST replay engine.
The backup origin can never accept a POST request even when called directly by an application.

Explanation

Correct Answer

Application write failover needs separate idempotency and transaction reconciliation rather than assuming CDN origin failover.

Incorrect Answers

CloudFront does not guarantee generic POST transactional retries across origins.

Failover status selection is separate from the supported request-method boundary. Payment writes require an application-level replay/reconciliation design.

The limitation is CloudFront failover handling, not universal endpoint POST support.

Question 389

A two-Region DynamoDB global table is configured for default MREC. Two clients update the same item nearly simultaneously in different Regions and the older value overwrites a business field after replication. Why?

MREC resolves concurrent writes with last-writer-wins item conflict handling, so application-level conflicting updates require a design strategy.
MREC global tables guarantee serializable cross-region transaction merging of individual fields.
DynamoDB global tables support only read-only replicas.
Enable Route 53 latency routing between two global-table Regions and assume resolver choice serializes concurrent DynamoDB item updates.

Explanation

Correct Answer

Asynchronous multi-writer replication can converge in a way that is not the application’s intended merge.

Incorrect Answers

Default MREC does not automatically merge concurrent business edits field by field.

Default multi-Region eventual consistency (MREC) global-table replicas can accept writes, so a read-only replica restriction does not explain the observed conflicting updates.

DNS placement does not implement a data-level conflict-resolution protocol. MREC global tables can see asynchronous last-writer-wins conflict outcomes.

Question 390

An Aurora Global Database secondary has replication lag. A regional cutover immediately after a primary writer failure loses the last few writes, contrary to an assumed zero-RPO promise. What was overlooked?

Cross-Region Aurora Global Database replication is typically asynchronous; failover must account for lag and selected recovery procedure.
Aurora Global Database uses no replication between Regions.
Assume the secondary Aurora Region has every acknowledged primary transaction because its read-only cluster is queryable, without measuring replication lag.
Changing RDS instance tags makes replication synchronous by default.

Explanation

Correct Answer

Low lag does not imply that every unreplicated transaction will survive an unplanned regional failover.

Incorrect Answers

It does replicate; the issue is its timing and recovery semantics.

A readable secondary can still lag the primary during asynchronous cross-Region replication. Unplanned recovery may lose recent unreplicated changes.

Tags do not change data propagation guarantees.

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

Question 380

Explanation

Correct Answer

Incorrect Answers

Question 381

Explanation

Correct Answer

Incorrect Answers

Question 382

Explanation

Correct Answer

Incorrect Answers

Question 383

Explanation

Correct Answer

Incorrect Answers

Question 384

Explanation

Correct Answer

Incorrect Answers

Question 385

Explanation

Correct Answer

Incorrect Answers

Question 386

Explanation

Correct Answer

Incorrect Answers

Question 387

Explanation

Correct Answer

Incorrect Answers

Question 388

Explanation

Correct Answer

Incorrect Answers

Question 389

Explanation

Correct Answer

Incorrect Answers

Question 390

Explanation

Correct Answer

Incorrect Answers

AWS Certified Solutions Architect - Associate SAA-C03 Practice Tests