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.

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.

My Answer is B Why not D ? I think - Each day we cannot know. What times of the day are peak usage times? Implementing routinely scheduled failovers won't solve the problem. - if Implement routinely scheduled failovers of your databases but replica database server is a same spec with main database server , replica database server will crashes by high traffic portion same a main database server

Answer is D. Implement routinely scheduled failovers of your databases This option is most aligned with addressing the issue. Routine failovers can help ensure that the failover process is working correctly and that the system is resilient to crashes. It can be part of a disaster recovery plan, where you routinely test the failover to the replica to ensure that it can handle being promoted to a master if needed. For the above reasons, i believe D is correct.

Why not B? Using a large instance during low traffic hours means incurring more cost than benefit except the instance is elastic. Therefore using a larger instance is not cost effective and the answer is D.