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

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!

B is ok for me

I would go with D, but it depends on many details. if it is an app KPI and there is a real issue to the business I would opt to make the app work perfectly again ASAP and then I would address the issue in the code base. But I can understand who would say that they would go with the pipeline approach.

If a change negatively affects your key performance indicator, it's best to revert the source code change to a known good state and rerun the deployment pipeline. This ensures that your infrastructure is restored to a stable state while you investigate and fix the issue. Reverting the change and redeploying the code will allow your instance groups to continue functioning with the previous stable version, minimizing the impact on your application and users.