Exam Professional Cloud Architect topic 1 question 73 discussion

Agree with A

Has anyone who has taken the exam recently seen any lingering questions with the Stackdriver nomenclature or is it all cloud logging, cloud monitoring, etc.?

Answer is: A

While I understand the doubts of selecting a 32 core machine from the start, answer A might be wrong... According to this article: https://cloud.google.com/sql/docs/mysql/instance-settings#impact ''For MySQL instances, changing either the machine type or the zone of the instance results in the instance going offline for several minutes.'' And I understand that instance type == machine type. If we switch to a PostgreSQL or SQL Server instance, similar warnings appear: PostgreSQL: ''Changing the number of CPUs or the memory size results in the instance going offline for less than 60 seconds. The total time for the changes to take effect can take several minutes.'' SQL Server: ''Changing the number of CPUs or the memory size results in the instance going offline for less than 60 seconds.''

You are using Cloud SQL as the database backend for a large CRM deployment. You want to scale as usage increases and ensure that you don't run out of storage, maintain 75% CPU usage cores, and keep replication lag below 60 seconds. What are the correct steps to meet your requirements? C & D is out of question as it is talking of 75% of storage, where in question it says 75% of CPU. Option A says monitoring before before taking action and sharding will also help in reducing latency. Option B specifies specific machine type, which is not correct and also memcache which is used to recude the round trip to fetch data, it will help in reducing latency. I would prefer to go with Option A, as it is correct sequence to solve the problem.

For me is A.

The correct answer is D. 1. Create a Stackdriver alert when storage exceeds 75%, and increase the available storage on the instance to create more space. 2. Deploy memcached to reduce CPU load. 3. Create a Stackdriver alert for replication lag, and change the instance type to a 32-core machine type to reduce replication lag. This approach ensures that you are able to address the three requirements specified in the question: - Monitoring storage usage and increasing storage when it exceeds 75% to avoid running out of storage. - Reducing CPU load by deploying memcached, which can be used to cache frequently-used data, offloading some of the load from the database. - Monitoring replication lag and increasing the number of cores to reduce lag.

It may be A for the simple fact that all the other answers throw in a tiny detail about 32 cores. This seems like a red herring (unnecessary details that are meant to distract), so for that reason, A is the answer.

A is ok

A is right

A is incorrect. because of the wording "Shard the database". How can you shard the database in Cloud SQL without causing major disruptions? Sharding is not a core feature of RDBMS. B should be correct. inspite of the mention of a fixed 32 core

vote for A

Go for A

A is the correct answer

We can directly eliminate C and D we are doing some work that is already automated. Still, I cannot make a point why not B is better than A? I believe adding memcash will give an additional boost Can someone help me point out why A is better than B?

Answer is A

A it is