As per google documentation(https://cloud.google.com/solutions/scalable-and-resilient-apps) answer is C. C: A well-designed application should scale seamlessly as demand increases and decreases, and be resilient enough to withstand the loss of one or more compute resources. Resilience: designed to withstand the unexpected A highly-available, or resilient, application is one that continues to function despite expected or unexpected failures of components in the system. If a single instance fails or an entire zone experiences a problem, a resilient application remains fault tolerant—continuing to function and repairing itself automatically if necessary. Because stateful information isn’t stored on any single instance, the loss of an instance—or even an entire zone—should not impact the application’s performance.

Since the question is asking to do a resilience testing, I prefer C.

Chaos testing

I choose Answer C https://cloud.google.com/sql/docs/mysql/replication This URL states "Read replicas are read-only; you cannot write to them. The read replica processes queries, read requests, and analytics traffic, thus reducing the load on the primary instance." "Note: Read replicas do not provide failover capability. To provide failover capability for an instance, see Configuring an instance for high availability." "As a best practice, put read replicas in a different zone than the primary instance when you use HA on your primary instance. This practice ensures that read replicas continue to operate when the zone that contains the primary instance has an outage. See the Overview of high availability for more information."

Testing Database Resilience: By setting up a read replica in a different zone and triggering a manual failover, you simulate a failure of the primary database. This allows you to assess how well your authentication layer and the overall application cope with the loss of the primary database. Monitoring Performance and Availability: During the failover, monitoring key performance indicators (KPIs) for your REST API will give you insights into how the application's performance and availability are impacted. This helps in identifying potential bottlenecks and areas for improvement in your resilience strategy. Ensuring Data Continuity: A read replica ensures data continuity and minimizes downtime, which is critical for an authentication system. The replica will take over as the primary database during the failover, ensuring that the authentication service remains functional.

D is okay

Authentication layer resiliency can be covered as part of overall application resiliency testing. Option C is asking to use read replica which is not useful in case of testing resiliency in case of failure

Read replicas do not provide failover capability. https://cloud.google.com/sql/docs/mysql/replication#read-replicas

It is c

Read replica do not provide failover capability https://cloud.google.com/sql/docs/mysql/replication#:~:text=Note%3A%20Read%20replicas%20do%20not,HA%20on%20your%20primary%20instance.

C is the good choice

I choose C. I don't say D because the REST API read and WRITE in the database, if you create a READ replica in Cloud SQL, the REST API will not have the possibility of write in the database. The answer D doesn't mention anything about promote the read replica to master.

C is good

D can be correct if it's a Failover replica but it's a read replica and not have anything to do with resiliency. It's C

Option A is focused on external threat intelligence and is more suited to security testing rather than resilience testing. Option B is related to security monitoring, and while important, does not directly address resilience testing requirements. Option C simulates a zone failure scenario. This could provide insights into how the application behaves in a failure scenario, making it a valid resilience testing method. However, it does not specifically address the interaction with Cloud SQL. Option D directly addresses resilience testing involving a Cloud SQL instance by creating a read replica in a different zone and simulating a failover. This will allow you to assess the impact on your REST API and verify whether the authentication layer remains functional and available, even when the primary Cloud SQL instance is inaccessible.

its quite tricky here resilient = chaos test. so with C, we have shut down all VMs in one zone to see how its it working on another zone( note that this is regional ) is my chose

The application was deployed to a managed Instance Group, it must have been configured with a load balancer, health check and AutoHealing. Turning off VMs would instantly bring up another instance as soon as the health checks fail, and traffic is automatically redirected to these instances. Therefore, the Answer is D.