Question 410
An ALB passes target health checks because /healthz always returns 200, while the app’s database dependency is unavailable and every purchase request fails. Why is the health signal inadequate?
- The health endpoint tests only process liveness and not the dependency readiness needed for serving purchases.
- HTTP 200 automatically guarantees every downstream business transaction succeeds.
- Return HTTP 200 from /healthz when the purchase database is offline and assume a TCP-ready process proves checkout can commit inventory.
- ALB cannot examine any HTTP health endpoint responses.
Explanation
Correct Answer
A:A meaningful readiness check must reflect conditions relevant to accepting traffic without introducing unsafe coupling.
Incorrect Answers
B:Health probes sample defined behavior, not every application path.
C:A process-liveness check can mask a critical dependency failure. Relevant readiness logic must reflect the operations users actually need to complete.
D:ALB health checks can use configured paths and success codes.
Question 411
An Aurora writer fails, but committed table rows remain available after a reader is promoted, even though the original instance disk is unavailable. Which storage characteristic explains this?
- Every Aurora reader maintained a byte-for-byte copy of only the failed writer’s ephemeral disk.
- Create a third Aurora reader in the same AZ as the failed writer and assume reader compute stores the only durable copy of the transaction log.
- Aurora’s cluster volume stores durable replicated data independently of any single compute instance across multiple AZs.
- The old writer’s DNS IP remained fixed and held the database blocks.
Explanation
Correct Answer
C:Shared distributed storage survives writer replacement and supports eligible replicas using the same logical data volume.
Incorrect Answers
A:Aurora uses a distributed shared cluster volume.
B:Aurora cluster storage is separate from individual compute instances and replicated across AZs; adding a same-zone reader cannot replace the durable cluster volume.
D:DNS names do not persist cluster storage.
Question 412
An RDS Multi-AZ failover succeeds, but a week later the team cannot restore data deleted yesterday because automated-backup retention was set to zero. What went wrong?
- A Multi-AZ standby automatically preserves every old deleted row forever.
- A Route 53 weighted policy controls the historical backup retention count.
- Keep RDS Multi-AZ failover enabled but set automated-backup retention to zero and assume an error from yesterday can still be recovered with a point-in-time restore.
- Failover availability was mistaken for historical recoverability; retention/backup strategy did not preserve older data state.
Explanation
Correct Answer
D:Standby replication propagates deletes and provides continuity, not point-in-time recovery history.
Incorrect Answers
A:Replication reflects current changes, including deletes.
B:DNS routing is unrelated to RDS backup lifecycle.
C:Automatic failover offers continuity but historical point-in-time restore needs supported retained backups. With backup retention disabled, that history is missing.
Question 413
An internet-facing ALB already has healthy web targets in two Availability Zones. Yet all targets mount their only writable shared session files from one EC2 NFS server in AZ-a. When AZ-a fails, web requests in AZ-b also fail. What additional resilience boundary was missed?
- Move session files into an appropriately resilient, shared or replicated storage/session service with surviving-AZ access, and validate application recovery rather than relying solely on multi-AZ web targets.
- Increase the AZ-a NFS instance size and assume that one larger server survives a full AZ outage.
- Enable the ALB cross-zone option while leaving the only writable NFS server in AZ-a and assume this replicates its disk data.
- Remove the AZ-b web targets because a shared database dependency should always be located beside the only web tier.
Explanation
Correct Answer
A:The ALB and stateless fleet can survive only if dependencies needed for real requests survive too. Shared one-AZ session storage remains a cross-zone application single point of failure.
Incorrect Answers
B:Bigger compute resources cannot remain accessible during the loss of their Availability Zone.
C:Forwarding requests to healthy targets does not replicate an application-owned single-AZ NFS dataset or restore its availability.
D:Removing the healthy second-AZ compute tier compounds the single-AZ failure instead of eliminating the shared storage dependency.
Question 414
A traditional Amazon RDS Multi-AZ DB INSTANCE has a scheduled operating-system patch. A team wants to understand how the standby deployment reduces service disruption for eligible OS maintenance, without assuming an engine version upgrade is equally rolling. Which operational sequence is documented?
- Patch the active writer first, leave its instance down for the entire maintenance operation, and then update the standby only if the writer never recovers.
- Skip standby patching entirely because RDS Multi-AZ replication automatically updates every instance operating system without a reboot.
- Set read replica reader-endpoint weights and assume they patch the instance OS on both HA partners.
- For supported operating-system updates RDS typically patches the standby, promotes it through a brief failover, then patches the former primary; engine upgrades may have different downtime characteristics.
Explanation
Correct Answer
D:AWS documents standby-first OS maintenance followed by promotion and old-primary patching for Multi-AZ DB instances, while database engine upgrades may require a different outage plan.
Incorrect Answers
A:RDS can use its standby and controlled failover to minimize OS maintenance interruption rather than unconditionally patching the live writer first.
B:OS patching is not the same as SQL data replication; standby infrastructure still needs explicit managed maintenance.
C:Read scaling endpoint configuration does not determine the RDS Multi-AZ instance maintenance order.
Question 415
A supported Amazon RDS Multi-AZ DB cluster writer sends each database change to two readable replicas in separate AZs. An engineer assumes that a successful writer commit is acknowledged only after BOTH readers have individually applied every change, so a single slow reader must block all commits. What actually governs this replication acknowledgment?
- Commit requires both replicas to finish every SQL transaction before any writer reply; one reader failure necessarily stops writes.
- The Multi-AZ DB cluster uses semisynchronous replication: an acknowledgment from at least one reader is required, but not full application/commit on both readers before the writer commits.
- Multi-AZ DB cluster readers are disconnected snapshot copies updated only by hourly AWS Backup plans.
- The reader endpoint controls commit consensus through DNS weights, not database replication acknowledgments.
Explanation
Correct Answer
B:At least one reader DB instance must acknowledge the change for the writer to commit; the remaining reader may apply it later. That is different from a guarantee that all readers already reflect the new row.
Incorrect Answers
A:AWS documents a semisynchronous commit path with at least one reader acknowledgment, not a requirement that both readers fully apply and commit each transaction.
C:These are readable, continuously replicated DB instances in the supported Multi-AZ DB cluster, not hourly snapshot restorations.
D:The endpoint selects how applications connect; SQL transaction acknowledgment is controlled by the DB cluster replication protocol.
Question 416
Aurora readers vary widely in capacity. During failover, an analytical replica would become an unsuitable writer while a transaction-ready reader is available. Which setting helps?
- Point the Aurora reader endpoint at the analytical instance and assume it changes promotion order.
- Set every Aurora replica to failover priority tier 0 regardless of its constrained instance class and assume the service knows which one must serve production writes.
- Use DNS TTL alone as a guaranteed promotion order.
- Assign appropriate Aurora failover promotion tiers while monitoring candidate eligibility and writer sizing.
Explanation
Correct Answer
D:Promotion preference guides the selection of a capable reader for the primary role.
Incorrect Answers
A:Read traffic routing is not a failover-priority policy.
B:Equal promotion preference does not encode business-specific writer fitness. Size and prioritize suitable healthy candidates while testing fallback behavior.
C:DNS cache policy cannot choose Aurora failover candidates.
Question 417
A conventional RDS Multi-AZ DB instance has an independent asynchronous reporting replica. Its standby just completed an automatic HA takeover, and the reporting replica may still show older committed rows. Which read-consistency policy should the application apply?
- Treat the reporting replica as a guaranteed zero-lag synchronous standby and send read-after-write order confirmations to it.
- Disable the Multi-AZ standby because the existence of an asynchronous reporting replica already guarantees identical failover durability.
- Configure CloudFront to cache reporting SQL and assume it synchronizes the reporting replica with the new writer.
- Send transactions requiring the latest committed state to the current primary endpoint and tolerate/monitor lag on reporting reads from the asynchronous replica.
Explanation
Correct Answer
D:The HA writer endpoint remains the authoritative path for strict latest-state reads. The separate reporting replica is for lag-tolerant reads and should be monitored/reconnected appropriately after failover.
Incorrect Answers
A:A reporting read replica is asynchronously refreshed and can lag, even when a separate Multi-AZ failover protects writer availability.
B:An asynchronous reader is not a replacement for the configured synchronous standby and automatic DB-instance failover behavior.
C:An HTTP CDN cache cannot make remote SQL-replica updates synchronous or solve their replication lag.
Question 418
A two-Region checkout application uses Route 53 DNS failover, but frontend HTTPS in the primary remains healthy even when a separate payment readiness alarm shows that the transaction tier cannot accept orders. The team needs the failover decision to reflect BOTH a direct endpoint signal and a business-critical CloudWatch alarm. What Route 53 health approach should it evaluate?
- Configure suitable Route 53 health checks, including a calculated health check or CloudWatch-alarm-backed check that reflects the required combined availability condition.
- Use only an ICMP ping to the frontend instance and disregard the business-level alarm.
- Add a DNS TXT record that lists the alarm name and assume this makes Route 53 evaluate the alarm.
- Disable routing health checks entirely while keeping the current primary endpoint first in DNS.
Explanation
Correct Answer
A:Route 53 supports health checks linked to CloudWatch alarms and calculated checks combining child states, making the specified transaction-readiness failure an input to regional routing.
Incorrect Answers
B:An open host or HTTPS frontend alone may hide a payment-tier outage and cannot satisfy the combined business-availability requirement.
C:An ordinary TXT record does not bind an alarm state into the Route 53 health check evaluation logic.
D:Static failover records with no health evaluation cannot detect the payment-service outage.
Question 419
A Route 53 weighted policy uses equal 50:50 weights for two healthy regional web endpoints. A product manager assumes exactly half of ALL individual HTTP requests must reach each region every minute, but observed per-request counts vary. What is the appropriate interpretation?
- Weighted Route 53 policy guarantees individual HTTP request balance, independent of DNS resolver caching and client connection reuse.
- Replace weights with geolocation policy, which guarantees exactly 50 percent of worldwide requests for any distribution of countries.
- Weights influence eligible DNS answer selection, not per-HTTP-request load balancing. Resolver caches, TTLs and traffic concentration can cause observed request ratios to differ from 50:50.
- Enable S3 Cross-Region Replication as the mandatory prerequisite to equal HTTP traffic in two active web regions.
Explanation
Correct Answer
C:Routing-weight proportions apply to DNS response selections under the policy. Resolver caching and request patterns can make actual per-request distribution diverge.
Incorrect Answers
A:The DNS service returns records based on configured weights; it does not route or count every subsequent application request.
B:Country-level selection does not guarantee a specific global traffic split and may intensify concentration.
D:Object replication is a data-availability feature, not a DNS sampling or HTTP request balancing control.
Question 420
A CDN origin group protects static GET pages but a payment checkout performs POST writes. Which supplemental resilience approach handles payment writes safely?
- Design application-level regional failover with idempotent transaction IDs and reconciliation rather than relying on CloudFront origin failover for POST.
- Assume CloudFront automatically replays every POST across origins with exactly-once payment commit.
- Use a low cache TTL to turn a POST into an eligible idempotent GET.
- Configure CloudFront origin failover to recognize HTTP 503 responses and assume the same setting automatically retries POST financial mutations with one-and-only-one commit.
Explanation
Correct Answer
A:CDN GET failover and transactional mutation recovery have different semantics.
Incorrect Answers
B:Unsupported generic POST replay risks duplicate or missing writes.
C:HTTP semantics are not converted by TTL.
D:CloudFront failover method constraints are separate from status codes and do not guarantee idempotent payment side effects.
AWS Certified Solutions Architect - Associate SAA-C03 Practice Tests