
Answer-first summary for fast verification
Answer: Amazon RDS automatically initiates a failover to the standby, in case primary database fails for any reason, RDS applies OS updates by performing maintenance on the standby, then promoting the standby to primary and finally performing maintenance on the old primary, which becomes the new standby
Overall explanation Correct options: RDS applies OS updates by performing maintenance on the standby, then promoting the standby to primary, and finally performing maintenance on the old primary, which becomes the new standby Running a DB instance as a Multi-AZ deployment can further reduce the impact of a maintenance event because Amazon RDS applies operating system updates by following these steps: Perform maintenance on the standby. Promote the standby to primary. Perform maintenance on the old primary, which becomes the new standby. When you modify the database engine for your DB instance in a Multi-AZ deployment, then Amazon RDS upgrades both the primary and secondary DB instances at the same time. In this case, the database engine for the entire Multi-AZ deployment is shut down during the upgrade. Amazon RDS automatically initiates a failover to the standby, in case the primary database fails for any reason - You also benefit from enhanced database availability when running your DB instance as a Multi-AZ deployment. If an Availability Zone failure or DB instance failure occurs, your availability impact is limited to the time automatic failover takes to complete. Another implied benefit of running your DB instance as a Multi-AZ deployment is that DB instance failover is automatic and requires no administration. In an Amazon RDS context, this means you are not required to monitor DB instance events and initiate manual DB instance recovery in the event of an Availability Zone failure or DB instance failure. Incorrect options: For automated backups, I/O activity is suspended on your primary DB since backups are not taken from standby DB - The availability benefits of Multi-AZ also extend to planned maintenance. For example, with automated backups, I/O activity is no longer suspended on your primary during your preferred backup window, since backups are taken from the standby. To enhance read scalability, a Multi-AZ standby instance can be used to serve read requests - A Multi-AZ standby cannot serve read requests. Multi-AZ deployments are designed to provide enhanced database availability and durability, rather than read scaling benefits. As such, the feature uses synchronous replication between primary and standby. AWS implementation makes sure the primary and the standby are constantly in sync, but precludes using the standby for read or write operations. Updates to your DB Instance are asynchronously replicated across the Availability Zone to the standby in order to keep both in sync - When you create your DB instance to run as a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous “standby” replica in a different Availability Zone. Updates to your DB Instance are synchronously replicated across the Availability Zone to the standby in order to keep both in sync and protect your latest database updates against DB instance failure.
Ultimate access to all questions.
No comments yet.
Author: LeetQuiz Editorial Team
The development team at a health-care company is planning to migrate their infrastructure from an on-premises data center to the AWS Cloud. As part of this migration, they are exploring the use of Amazon RDS (Relational Database Service) to serve as the database tier for their primary application.
Given this scenario, which of the following statements about Amazon RDS Multi-AZ deployments are accurate? (Select two)
A
For automated backups, I/O activity is suspended on your primary DB since backups are not taken from standby DB
B
Amazon RDS automatically initiates a failover to the standby, in case primary database fails for any reason
C
To enhance read scalability, a Multi-AZ standby instance can be used to serve read requests
D
RDS applies OS updates by performing maintenance on the standby, then promoting the standby to primary and finally performing maintenance on the old primary, which becomes the new standby
E
Updates to your DB Instance are asynchronously replicated across the Availability Zone to the standby in order to keep both in sync