DBS-C01 · Question #12
A company is using an Amazon Aurora PostgreSQL DB cluster with an xlarge primary instance master and two large Aurora Replicas for high availability and read-only workload scaling. A failover event…
The correct answer is C. Configure one Aurora Replica to have the same instance class as the primary DB instance. Explanation During an Aurora failover, Aurora promotes one Aurora Replica to become the new primary instance. If the promoted replica is a smaller instance class (large) than the original primary (xlarge), it will handle write traffic with insufficient compute resources…
Question
A company is using an Amazon Aurora PostgreSQL DB cluster with an xlarge primary instance master and two large Aurora Replicas for high availability and read-only workload scaling. A failover event occurs and application performance is poor for several minutes. During this time, application servers in all Availability Zones are healthy and responding normally. What should the company do to eliminate this application performance issue?
Options
- AConfigure both of the Aurora Replicas to the same instance class as the primary DB instance.
- BDeploy an AWS Lambda function that calls the DescribeDBInstances action to establish which
- CConfigure one Aurora Replica to have the same instance class as the primary DB instance.
- DConfigure both Aurora Replicas to have the same instance class as the primary DB instance.
How the community answered
(50 responses)- A4% (2)
- B8% (4)
- C70% (35)
- D18% (9)
Explanation
Explanation
During an Aurora failover, Aurora promotes one Aurora Replica to become the new primary instance. If the promoted replica is a smaller instance class (large) than the original primary (xlarge), it will handle write traffic with insufficient compute resources, causing the observed performance degradation for several minutes. Configuring one Aurora Replica to match the primary's xlarge instance class ensures the promoted replica can immediately handle the primary workload without a performance penalty - this is the minimum necessary change.
Why the distractors are wrong:
- Option A is identical to Option D (both describe configuring both replicas to match the primary), making it a duplicate distractor - configuring both replicas to xlarge is unnecessary and cost-inefficient, since only one replica is promoted during failover.
- Option B (using a Lambda function with DescribeDBInstances) only detects the failover state; it does nothing to resolve the underlying resource mismatch causing poor performance.
- Option D (same as A) wastes resources by over-provisioning both replicas when only one needs to match the primary for failover readiness.
Memory Tip
Think "One Spare Tire Rule" - you only need one full-size spare tire in your car for an emergency; having two is redundant and wasteful. Similarly, you only need one replica sized to handle primary duties during a failover.
Topics
Community Discussion
No community discussion yet for this question.