Exam Professional Cloud Architect topic 1 question 25 discussion

Answer is D

@chiar, I agree the question i s not clear. In GCP larger instances have larger number of CPUs, Memory and come with their own private network. So increases the instance size would help prevent the need for failover during high traffic times. However, routinely scheduled failovers would allow the team to test the failover when it is not requried. This would make sure it is working when it is required.

I'll go with option D based on real life experience. As part of managing environments, failover test for the database is part of regular Infra activity (at least once a year)

Not D because replica is also crashing (why else would it not be promoted). We don't build a layer to fix an underlying layer that isn't working. We fix why the layer isn't working so the answer is B.

Here the issue is existing instance doesn't have enough resources. Even though we ensured that the replica is promoted it too will fail.

D : Chaos testing

D - I think question is related to resiliency & disaster recovery, no matter how big or small the instance is.. Is the application able to achieve its RTO & RPO ?.. We don't know what cause the crash, but we could have avoided it if we had a Routine Scheduled Failovers Check done in past rather than anticipating & waiting for a real crash.

Only a routine check, would indicate a best practice. Larger Instance doesn't guarantee a failover would be prevented

1. Proactive Testing: Regularly scheduled failovers proactively test your database's ability to recover and ensure the replica can successfully take over as the master. This helps identify and address any issues in the failover process before a real crisis occurs. 2. Confidence in Failover: By routinely testing failover, you gain confidence that your system can recover automatically in case of a primary database failure, minimizing downtime and data loss. 3. Improved Recovery Time: Regular failovers help optimize the recovery process, reducing the time it takes to switch to the replica.

Answer is D

- **A. Use a different database**: Simply switching to a different database does not inherently solve the problem of failover and promotion mechanisms. The issue is more about the setup and management of failover strategies rather than the specific database technology used. - **B. Choose larger instances for your database**: While using larger instances might improve performance and potentially reduce the risk of a crash due to resource constraints, it does not address the failover mechanism. The key problem is the replica not being promoted, which larger instances alone won't fix. - **C. Create snapshots of your database more regularly**: Regular snapshots are useful for backups and recovery but do not help with automatic failover and high availability. Snapshots do not ensure that a replica will be promoted to a master if the primary fails.

I think the answer is B, as the most important thing is customer experience. We can NOT expect database fails as a normal event which have direct customer and business impacts (if current data base fail because of load then replica database may fail as well). Of course we need to setup the failover process to work, but the more important task will be to increase database load first, thus I choose B.

I think the answer is D because we can not assume the crash was due to load.

D is correct with given choice, because what if larger instance size is also failed. How ever question ignores logging and networking completely, the best way is to use logging why the DB is crashed, failover is just a remedy to solve the issues at current, not solving the problem itself.

It is important to identify key words, the issue is replica not being promoted when primary instance fails. Regular testing would identify issue

The correct answer is D The question is asking how to avoid the situation of not failing over. The answer is to test the failover procedure. The question does *NOT*ask about what happens in the future and whether the secondary node is large enough.

I would say D. Beacuse also B is correct, but you have a replica here, that is never promoted. So we need failover strategy.