mediumMultiple ChoiceObjective-mapped
Google ACE Practice Question: A team is migrating from Google Container…
A team is migrating from Google Container Registry (gcr.io) to Artifact Registry. Existing automation scripts use `gcr.io/my-project/myimage`. To avoid updating all scripts immediately, which Artifact Registry feature allows gcr.io-addressed pulls to work with Artifact Registry backends?
⚠ Common exam trap
Google Cloud often tests the misconception that DNS manipulation (like Cloud DNS private zones) can solve hostname redirection for external services, but in reality, Google-managed hostnames like `gcr.io` cannot be overridden with private DNS, and the correct solution is the built-in Artifact Registry redirect feature.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enable the gcr.io compatibility redirect in Artifact Registry settings so gcr.io URLs route to Artifact Registry
Artifact Registry offers a gcr.io compatibility redirect feature that automatically routes requests originally targeting `gcr.io/my-project/myimage` to the corresponding Artifact Registry repository. This allows existing automation scripts to continue using the old `gcr.io` hostname without modification, while the underlying storage and image management are handled by Artifact Registry. The redirect is configured at the project level and works transparently for pull operations, eliminating the need for immediate script updates.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Artifact Registry has no gcr.io compatibility — all scripts must be updated immediately
Why it's wrong here
This statement is factually incorrect: Artifact Registry explicitly provides gcr.io compatibility, including a project-level redirect that lets gcr.io URLs dispatch to Artifact Registry. This feature exists precisely to prevent a forced mass update of all scripts on the day Container Registry is shut down, allowing a transition period. You still need to pre-create the appropriate Artifact Registry repositories and push images there, but you do not have to rewrite every gcr.io reference in your scripts immediately, which is the entire point of the compatibility mode.
- ✓
Enable the gcr.io compatibility redirect in Artifact Registry settings so gcr.io URLs route to Artifact Registry
Why this is correct
Enabling the gcr.io compatibility redirect in the Artifact Registry project settings maps the legacy gcr.io hostname to the corresponding Artifact Registry repository, so existing container commands like docker pull gcr.io/my-project/my-image continue to work without immediate script changes. This is the intended migration path because it lets you incrementally move workloads from Container Registry to Artifact Registry while preserving CI/CD pipeline behavior. Without this setting, gcr.io URLs continue to hit the deprecated Container Registry service instead of the new repository, risking breakage when Container Registry is decommissioned.
- ✗
Use a Cloud DNS private zone to redirect gcr.io to Artifact Registry
Why it's wrong here
A Cloud DNS private zone only controls name resolution inside a specific VPC network; it cannot affect how container runtimes or Google Cloud infrastructure resolve the public gcr.io hostname from external networks or from other services. Even if you managed to force a DNS override, the TLS certificate presented by the actual gcr.io endpoint would not match a custom Artifact Registry URL, causing certificate validation errors and image pull failures. The supported and reliable approach is the built-in gcr.io compatibility redirect in Artifact Registry, not a DNS workaround that creates additional fragility.
- ✗
Both Container Registry and Artifact Registry can be active simultaneously with no configuration
Why it's wrong here
Container Registry and Artifact Registry are separate services; both can technically store container images, but that does not make a gcr.io URL resolve to Artifact Registry automatically. Without any configuration, a gcr.io pull still targets the legacy Container Registry service, which will be shut down after the deprecation deadline. The 'no configuration' option ignores the need to explicitly enable the gcr.io compatibility redirect or to update image tags and hostnames so new images live in Artifact Registry; parallel operation alone does not provide a smooth migration path.
Go deeper
Related to this question
Learn chapter
Google Cloud Platform Overview
Key term
Container
A container is a lightweight, standalone software package that includes everything needed to run an application, such as code, runtime, system tools, and libraries.
Key term
Container registry
A container registry is a centralized storage and distribution system for container images, enabling developers to push, pull, and manage versions of application snapshots across environments.
About these practice questions
One of 769 original ACE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.