Google Exam Professional Cloud DevOps Engineer Topic 6 Question 61 Discussion

Actual exam question for Google's Professional Cloud DevOps Engineer exam

Question #: 61
Topic #: 6

[All Professional Cloud DevOps Engineer Questions]

You are investigating issues in your production application that runs on Google Kubernetes Engine (GKE). You determined that the source Of the issue is a recently updated container image, although the exact change in code was not identified. The deployment is currently pointing to the latest tag. You need to update your cluster to run a version of the container that functions as intended. What should you do?

ACreate a new tag called stable that points to the previously working container, and change the deployment to point to the new tag.

BApply the latest tag to the previous container image, and do a rolling update on the deployment.

CBuild a new container from a previous Git tag, and do a rolling update on the deployment to the new container.

DAlter the deployment to point to the sha2 56 digest of the previously working container.

Show Suggested Answer

Suggested Answer: D

by Mozell at Feb 13, 2024, 01:01 AM

Limited Time Offer

25%

Off

Get Premium Professional Cloud DevOps Engineer Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

Submit Cancel

Germaine

11 months ago

That could work too, as long as we ensure we are pointing to the correct version of the container.

upvoted 0 times

...

Jaime

11 months ago

But what about altering the deployment to point to the sha256 hash of the previous working container?

upvoted 0 times

...

Kenneth

11 months ago

Building a new container from a previous Git tag could also be a good option for updating the deployment.

upvoted 0 times

...

Germaine

11 months ago

I disagree. I believe we should apply the latest tag to the previous container image for the rolling update.

upvoted 0 times

...

Jaime

11 months ago

I think we should create a new tag called stable and point the deployment to it.

upvoted 0 times

...

Lezlie

1 years ago

I don't know, I'm kind of leaning towards option D. Pointing to the SHA256 digest seems like it might be a bit more robust, you know? It's not dependent on tags or anything like that. But I can see the appeal of C as well. Tough call.

upvoted 0 times

...

Emerson

1 years ago

Haha, can you imagine if we tried option B? 'Apply the latest tag to the previous container image'? That's like trying to put a fresh coat of paint on a broken-down car and expecting it to run better. No, I think C is the way to go. Keep it simple, you know?

upvoted 0 times

Della

11 months ago

Good call. Option C seems like the most reliable solution to get our application back on track.

upvoted 0 times

...

Reiko

12 months ago

Absolutely, simplicity is key when dealing with these kind of issues. Let's stick with option C for now.

upvoted 0 times

...

Lynna

12 months ago

Yeah, option B does sound pretty risky. I agree with you on going with option C for a safer approach.

upvoted 0 times

...

Von

12 months ago

D) Alter the deployment to point to the sha2 56 digest of the previously working container.

upvoted 0 times

...

Rex

12 months ago

C) Build a new container from a previous Git tag, and do a rolling update on the deployment to the new container.

upvoted 0 times

...

Elden

12 months ago

B) Apply the latest tag to the previous container image, and do a rolling update on the deployment.

upvoted 0 times

...

Willard

12 months ago

A) Create a new tag called stable that points to the previously working container, and change the deployment to point to the new tag.

upvoted 0 times

...

Weldon

1 years ago

Yeah, I agree with you there. Option C seems like the most straightforward approach. We know the previous version was working, so let's just build a new container from that and swap it in. I'm not a big fan of the other options - they seem like they might introduce more complexity than necessary.

upvoted 0 times

...

Maile

1 years ago

Hmm, this is a tricky one. I'm not sure if I fully understand the context here. But from what I can gather, it seems like we need to revert to a previous, working version of the container image. I think option C might be the way to go - building a new container from a previous Git tag and doing a rolling update on the deployment.

upvoted 0 times

...