PROFESSIONAL-CLOUD-DEVELOPER · Question #363
You maintain a CI/CD pipeline for an application running on GKE. You use Cloud Build to create container images and push the images to Artifact Registry. When you build the image, you use the latest…
The correct answer is B. Build a separate Docker image for each new version of the application, and tag it with the version. Tagging each image with a unique, immutable version identifier (such as a Git commit SHA, semantic version number, or build ID) ensures every build produces a distinct, retrievable artifact. This makes rollbacks trivial-you simply reference the exact tag of the previously…
Question
You maintain a CI/CD pipeline for an application running on GKE. You use Cloud Build to create container images and push the images to Artifact Registry. When you build the image, you use the latest tag in your pipeline. You recently had to roll back a deployment 24 hours after rollout. The rollback process was difficult because the latest tag had been overwritten. You need to prevent this issue in the future. You want to use the most efficient approach. What should you do?
Options
- ARebuild the Docker image for each environment, and tag it with the specific environment name.
- BBuild a separate Docker image for each new version of the application, and tag it with the version
- CImplement Helm charts to manage your container deployments.
- DUse a Docker registry to store the container images, and create separate repositories for each
How the community answered
(25 responses)- A4% (1)
- B76% (19)
- C12% (3)
- D8% (2)
Explanation
Tagging each image with a unique, immutable version identifier (such as a Git commit SHA, semantic version number, or build ID) ensures every build produces a distinct, retrievable artifact. This makes rollbacks trivial-you simply reference the exact tag of the previously known-good image. The 'latest' tag is mutable by design and gets overwritten on every build, making it impossible to reliably reference a specific past state. Option A tags by environment name, which is also mutable and doesn't solve the versioning problem. Option C (Helm charts) improves deployment management and templating but does not address the root cause: the lack of immutable image tags. Option D (separate repos per environment) adds complexity and splits images across registries without fixing the tagging strategy.
Topics
Community Discussion
No community discussion yet for this question.