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.
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
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.
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.
Exactly. Because in GCP a read replica cant be auto upgraded to become a master in case of failover. So basically the database will allow only READ operations and not WRITE operations. Basically leaving it non-functional
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 agoJack_in_Large
4 years, 6 months agovartiklis
2 years, 11 months agoelaineshi
2 years, 6 months agoheretolearnazure
1 year, 3 months agoKouShikyou
Highly Voted 5 years agoDarahaas
4 years, 2 months agoEkramy_Elnaggar
Most Recent 1 week, 6 days agonareshthumma
1 month, 1 week agowooyourdaddy
2 months agohitmax87
6 months, 2 weeks ago666Amitava666
7 months, 1 week agoactivist
8 months agosantoshchauhan
8 months, 1 week agoRehamss
8 months, 2 weeks agoTeckexam
9 months, 3 weeks agopractice_sample
9 months, 3 weeks agodidek1986
10 months, 2 weeks agoTamim321
11 months, 1 week agoRoro_Brother
11 months, 3 weeks agojuliansierra
1 year, 1 month agoparthkulkarni998
11 months, 3 weeks agoRuibinC
1 year, 1 month ago