Exam AWS Certified DevOps Engineer - Professional DOP-C02 topic 1 question 5 discussion

B and D are incorrect because Aurora cluster provides cluster and read endpoints, but does not support creating custom ANY endpoints. C and D are incorrect because Amazon Aurora's multi-AZ option must be set when the DB instance is created. Therefore, A is correct.

Option A is the right choise for an existing Cluster without Multi-AZ! Refer to: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html #Read the Tip Box# "You can set up a Multi-AZ cluster by making a simple choice when you create the cluster. The choice is simple whether you use the AWS Management Console, the AWS CLI, or the Amazon RDS API. You can also make an existing Aurora cluster into a Multi-AZ cluster by adding a new reader instance and specifying a different Availability Zone."

aurora cluster turn on multi az by default. for limit downtime, we create a new read instance. When an update window in the primary instance, the read instance become a new primary instance

For me option C is the correct!

C. Turn on the Multi-AZ option on the Aurora cluster. Update the application to use the Aurora cluster endpoint for write operations. Update the Aurora cluster’s reader endpoint for reads. Enabling Multi-AZ ensures that the data in the Aurora cluster is replicated across multiple Availability Zones (AZs), providing high availability and durability. During maintenance, the update will be applied to one AZ at a time, allowing the cluster to remain available. Updating the application to use the cluster endpoint for write operations ensures that writes will continue to be directed to the primary instance in the cluster, while updating the reader endpoint for reads allows read traffic to be routed to the appropriate instance. Adding a reader instance or creating a custom ANY endpoint are not necessary for meeting the requirement of minimizing interruption during maintenance.

To meet the requirement of keeping the Aurora cluster available with the least possible interruption during the maintenance window, the DevOps engineer should choose option C: Turn on the Multi-AZ option on the Aurora cluster. Update the application to use the Aurora cluster endpoint for write operations. Update the Aurora cluster’s reader endpoint for reads. Option A is incorrect because adding a reader instance alone does not provide high availability during maintenance, and updating the application to use the reader endpoint for reads is unnecessary when the Multi-AZ option is enabled

Option A is the correct choice, adding a reader instance after provisioning is the same as setting a Multi-AZ during creation. In the event that the primary fails, the reader instance will be promoted to do both reading and writing automatically. Additionally, reader instance can also be used for read activity if you use the cluster reader endpoint which you can serve to user/application closer to the region for better performance.

"You can set up a Multi-AZ DB cluster by making a simple choice when you create the cluster. You can use the AWS Management Console, the AWS CLI, or the Amazon RDS API. You can also convert an existing Aurora DB cluster into a Multi-AZ DB cluster by adding a new reader DB instance and specifying a different Availability Zone."

To meet the requirements of the given scenario, the DevOps engineer should do the following: Add a reader instance to the Aurora cluster: This will allow the application to offload read operations to the reader instance, reducing the load on the primary instance. The application should be updated to use the Aurora cluster endpoint for write operations and the reader endpoint for read operations. The engineer should not turn on the Multi-AZ option on the Aurora cluster. Multi-AZ is used to provide high availability and failover capabilities, but it does not necessarily minimize interruption during a maintenance window. Adding a reader instance is a more appropriate solution to maintain availability and distribute the read workload. Therefore, the correct option is A. Add a reader instance to the Aurora cluster and update the application to use the appropriate endpoints for read and write operations.

You cannot change the az option after creation but can deploy a reader instance in another az and use it for reading and writing in your main instance.

There isn't a specific Multi-AZ mode for Aurora it's multi-AZ by default (it uses all three AZs). So I think A or B. A is the most commonly used method but I think B offers less disruption because requests are always routed to the instance with greater availability.

By enabling Multi-AZ deployment, creating a custom ANY endpoint, and updating the application to use this endpoint for all read and write operations, the DevOps engineer can ensure that the Aurora cluster remains available during the maintenance window with minimal interruption. The application will be able to transparently connect to the available instances (primary or read-only replica), and Aurora will automatically fail over to the read-only replica if the primary instance becomes unavailable during the maintenance process.

Can't tell the difference between A and C except Multi-AZ, both should be working if only read is needed during maintenance window. And also not understand why only read is needed when people choose them. Some say there is no custom ANY endpoint, I think it only means you can choose any instance or instances to that endpoint. So I go with B

answer A). the question doesn't mention what DB is behind the Aurora. Multi-AZ config avoids downtime EXCEPT MySQL/MariaDB. So the question mentions "the least possible interruption", then A) is the appropriate one

is corret is ='c' - > 'a' is not This option leverages Aurora's built-in high availability and failover mechanisms to ensure minimal interruption. By using the cluster endpoint for writes, the application automatically writes to the primary instance. In case of maintenance or failure, Aurora handles failover to another instance with minimal downtime. The reader endpoint distributes read traffic across available replicas, enhancing read scalability and availability without affecting write operations. This setup ensures that the application remains as available as possible during maintenance

A is good

A is correct.