Exam Professional Cloud Architect topic 1 question 36 discussion

Let's go with option elimination A. Log in to a server, and iterate on the fix locally >> Long step, hence eliminate B. Revert the source code change and rerun the deployment pipeline >> This revert will be logged in the source repo. Will go with this way although D also is correct. C. login to the servers with the bad code change, and swap in the previous code >> C is manually doing what can be automatically done by B and C, hence eliminate. D. Change the instance group template to the previous one and delete all instances >> This is similar to B but why manually do something which is automated. Hence eliminate. But is also correct. But B is better from code lifecycle perspective. Hence B

Too many responses saying B is the answer - I wonder if GCP pays people to provide the wrong answers on this website. It's clearly D, MIG templates support versioning, they were created to solve this exact problem. You simply select the previous template version, set that as the new deployment, and it will roll back the KPI depriving deployment and roll out the previous working deployment. The only part of D I don't like is the "terminate all instances" since you should engage in a rolling deployment, but if it's not a live website I suppose that would be fine. https://cloud.google.com/compute/docs/instance-groups/rolling-out-updates-to-managed-instance-groups

If you have a pipeline that deploys, changing the deployment manually is an anti-pattern - it causes the code in the repo to be inconsistent with the code that runs. Fix forward is not an option ("investigation can take a week") so revert source code change is the only possibility.

1. Quickest path to recovery: Reverting the code change that caused the performance degradation is the fastest way to restore your key performance indicator (KPI) to its previous level. Your pipeline is designed to automate deployments, so re-deploying the known good version should be straightforward. 2. Minimizes downtime: While investigating the issue is important, it can take time. Reverting first minimizes the duration of the negative impact on your KPI. 3. Clean and controlled: This approach avoids making ad-hoc changes directly on servers (options A and C), which can lead to inconsistencies and make it harder to track the problem's source. 4. Maintains instance group integrity: Option D involves deleting instances, which can disrupt services and lead to unnecessary re-creation of resources.

option B

Agree with B

D is infrastructure change. B is application change. So B is correct.

D The question is talking abt MIG and you can revert Inst Template same as B. Since this is about MIG's I will choose D

D. This is a question about instance groups and so modifying templates should be what we're looking for.

This a B for sure

The popped up with source code changes, hence reverting the change and deployment will solve the issue. B. Revert the source code change, and rerun the deployment pipeline

D is incorrect: - MIG instance group template is immutable, there is no version concept. The context never mentioned that team created multiple instance group templates. - Software code change might not all ended up in the instance group templates, it depends on how the deployment pipeline is configured. Regardless, B is a best practices, ensure that your infrastructure is synced with your source control system.

You don't need to touch your code, just deploy and older version and fix the code, then deploy the fixed version

The most secure option is D Revert a source code change could be complex (if change was made in various components)

Because the question starting from source code

by bard: The correct answer is B. Revert the source code change, and rerun the deployment pipeline.

B. The keyword here is source code not VM configuration. If it was the later then instance group templates is the answer. But in this case simply rollback your source code change and rerun to last workable version. Simples!