Your customer wants to do resilience testing of their authentication layer. This consists of a regional managed instance group serving a public REST API that reads from and writes to a Cloud SQL instance. What should you do?
A.
Engage with a security company to run web scrapers that look your for users' authentication data om malicious websites and notify you if any is found.
B.
Deploy intrusion detection software to your virtual machines to detect and log unauthorized access.
C.
Schedule a disaster simulation exercise during which you can shut off all VMs in a zone to see how your application behaves.
D.
Configure a read replica for your Cloud SQL instance in a different zone than the master, and then manually trigger a failover while monitoring KPIs for our REST API.
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.
You're not testing *authentication*, you're testing *the resilience of the authentication layer*. "A resilient app is one that continues to function despite failures of system components" (https://cloud.google.com/architecture/scalable-and-resilient-apps#resilience_designing_to_withstand_failures) - such as shutting down all VMs in a zone.
Resilience in this case means at least be able to support a failure of a zone, so considering that the MIG is regional, so it can withstand a zonal failure, the only other thing is to have a failover strategy for Cloud SQL and triggering it.
D. is not correct as this tests the resilience of the database (Cloud SQL) but not necessarily the authentication layer. The authentication layer might have separate components or dependencies that need to be tested under failure conditions.
Option C, which involves scheduling a disaster simulation exercise to shut off all VMs in a zone, is indeed a strong choice for resilience testing. This approach helps you understand how your application behaves under failure conditions and ensures that your system can handle unexpected disruptions.
However, Option D is also highly relevant. Configuring a read replica for your Cloud SQL instance in a different zone and manually triggering a failover while monitoring KPIs for your REST API directly tests the resilience of your database layer. This can provide valuable insights into the failover process and the impact on your application’s performance and availability.
Both options have their merits, but if the primary goal is to test the resilience of the authentication layer specifically, Option D might be more targeted and effective.
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.
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
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
Kri_2525
Highly Voted 5 years, 6 months agoJack_in_Large
5 years agovartiklis
3 years, 6 months agoelaineshi
3 years agoheretolearnazure
1 year, 9 months agoKouShikyou
Highly Voted 5 years, 7 months agoDarahaas
4 years, 9 months agof3e7abb
Most Recent 2 weeks, 4 days agoMrAZ105
1 month, 1 week agokhadar2001
1 month, 4 weeks agodavid_tay
3 months, 3 weeks agoJonathanSJ
5 months, 2 weeks agoEkramy_Elnaggar
7 months agonareshthumma
7 months, 3 weeks agowooyourdaddy
8 months, 3 weeks agohitmax87
1 year, 1 month ago666Amitava666
1 year, 1 month agoactivist
1 year, 2 months agosantoshchauhan
1 year, 2 months agoRehamss
1 year, 3 months agoTeckexam
1 year, 4 months agopractice_sample
1 year, 4 months ago