Courseiva

SOA-C02 Reliability and Business Continuity Practice Question

An RDS Multi-AZ DB instance fails over to the standby. The application uses the DB instance endpoint. What should the SysOps administrator usually do in the application after failover?

⚠ Common exam trap

Many exam-takers think they need to manually update the connection string or IP address, but the DNS endpoint automatically resolves to the new primary after failover, so only retry logic is required.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Ensure the application retries/reconnects using the same DB endpoint.

When an RDS Multi-AZ DB instance fails over to the standby, the DNS record for the DB instance endpoint is automatically updated to point to the new primary instance. The application should simply retry or reconnect using the same endpoint; no manual changes are needed because the endpoint remains valid. This is the standard behavior for Multi-AZ deployments, ensuring minimal disruption.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Ensure the application retries/reconnects using the same DB endpoint.

    Why this is correct

    The RDS Multi-AZ architecture abstracts the active database behind a consistent DNS endpoint. When failover occurs, AWS automatically repoints that endpoint to the newly promoted standby, so the application must simply retry/reconnect to the same hostname rather than changing any configuration. Implementing connection retry logic with backoff is essential, because the failover process typically causes existing connections to be dropped for 60–120 seconds while DNS updates propagate.

  • ✗

    Manually change the application to the standby instance IP address.

    Why it's wrong here

    Manually reconfiguring the application to use the standby instance’s IP address is fundamentally flawed because RDS instances do not have stable IP addresses—the underlying host can change during maintenance or failover, and the standby’s IP is not exposed through normal metadata. Additionally, the DNS endpoint already manages the promotion automatically, so hard-coding an IP bypasses the failover abstraction and introduces a single point of failure when the IP inevitably changes again. The only correct action is to let the application rely on the endpoint, not an IP.

  • ✗

    Restore from the latest snapshot before reconnecting.

    Why it's wrong here

    Restoring from the latest snapshot before reconnecting is a severe overreaction and would cause significant data loss and extended downtime, because snapshots are asynchronous point-in-time backups that do not include transactions committed after the snapshot was taken. In a Multi-AZ failover, the standby has been continuously applying synchronous replication from the primary, so the promoted instance already contains the most recent committed data; no restore is necessary. This action is only appropriate if the database itself has been corrupted or accidentally deleted.

  • ✗

    Create a new read replica and promote it immediately.

    Why it's wrong here

    Creating a new read replica and promoting it immediately is not the standard failover path for Multi-AZ, because the DB instance already has a dedicated standby that is automatically promoted by AWS. Read replicas use asynchronous replication and are intended to offload read traffic or serve as a disaster recovery mechanism in a different region; manually promoting one during a Multi-AZ event would introduce replication lag, require a separate promotion API call, and still leave the application pointing at the same endpoint which would need to be repointed anyway. This approach would delay recovery and add unnecessary complexity, whereas the standby promotion already preserves the same CNAME.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

Courseiva writes every SOA-C02 question from scratch — 1,169 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.