This article covers the difference between Container Registry and Artifact Registry, why Google has been pushing teams to migrate, what each service is for, and the IAM roles that show up on the Associate Cloud Engineer exam for both.
It does not cover the specifics of migrating an existing Container Registry over to Artifact Registry, the gcr.io domain rewrites, or vulnerability scanning configurations. Those exist and the docs cover them well. The ACE exam tests this at a higher level.
Container Registry is the older service. It is a private repository for Docker container images. It has been around for years and many teams still use it. It is being retired, with the official sunset date in spring 2025, but it still shows up on the ACE exam.
Artifact Registry is the successor. It does what Container Registry does (stores Docker images) and more. It also handles language packages like Maven artifacts, npm packages, Python packages, and other build artifacts. It is the recommended option going forward, and Google is steering everybody to it.
The single most important difference is scope. Container Registry only stores container images. Artifact Registry stores container images plus other artifact types. For a team that uses Docker only, both work the same. For a team that has a real software supply chain with multiple package formats, Artifact Registry replaces what would otherwise be several separate tools.
Beyond scope, Artifact Registry has more granular IAM controls and better regional repository support. From the perspective of the Associate Cloud Engineer exam, the most important thing is just that Container Registry is going away and Artifact Registry is the replacement.
The flow is the same regardless of which registry you use. You build a Docker image. You push it to a registry. The user or service account responsible for deploying needs read access to the registry. Then the image gets pulled from the registry and deployed to your compute target, which on GCP is usually Cloud Run, GKE, or Compute Engine.
The exam expects you to recognize this flow and the role of the registry as the storage layer between build and deploy.
This is where the two services diverge on the exam, and it is worth memorizing.
Container Registry stores images in Cloud Storage buckets under the hood. So the role for pulling images from Container Registry is Storage Object Viewer. That is a Cloud Storage role, applied to the bucket Container Registry uses. It works because Container Registry is just a thin layer on top of GCS.
Artifact Registry does not use Cloud Storage buckets directly. So the Storage Object Viewer role does not work there. To pull images from Artifact Registry, you need Artifact Registry Reader or Artifact Registry Viewer. Reader gives you read access to artifacts. Viewer adds repository metadata visibility on top of that.
If the exam shows a question where a service account cannot pull an image and asks what role it needs, the answer depends on which registry the question describes. Container Registry, Storage Object Viewer. Artifact Registry, Artifact Registry Reader.
The exam tests Artifact Registry and Container Registry in a few consistent patterns.
The first is the migration narrative. A scenario describes a team that has been using Container Registry and asks what they should migrate to. The answer is Artifact Registry, because Container Registry is being retired and Artifact Registry covers the same use case plus more.
The second is the IAM role pattern I described above. A service account cannot pull an image. The fix is the right read role on the right registry.
The third is the artifact type framing. A team needs to store both Docker images and Maven packages in one place. The answer is Artifact Registry, because Container Registry only handles Docker.
If you see in the question something about retiring or migrating from Container Registry, or storing multiple artifact formats in one registry, think Artifact Registry. If you see Storage Object Viewer in an answer choice, the question is probably testing Container Registry's bucket-backed model.
Container Registry is the old Docker-only registry, backed by Cloud Storage, with a sunset date. Artifact Registry is the replacement and handles more artifact types with native IAM roles. The pull permissions are Storage Object Viewer for Container Registry, and Artifact Registry Reader or Viewer for Artifact Registry.
For the Associate Cloud Engineer exam, recognize the migration story and know the IAM role distinction. That covers most of what gets tested.
My Associate Cloud Engineer course covers both registries and the deployment flow alongside Cloud Build, which is the service that pushes most images into them.
