Artifact Registry Study Notes

Artifact Registry is Google Cloud's fully managed service for storing, managing, and securing private artifacts, including container images and language packages. It replaces Container Registry as the recommended registry service and supports multiple artifact formats in regional or multi-regional repositories. Teams use it as the trusted source that Cloud Build fills and that GKE, Cloud Run, and other runtimes pull from.

Key facts

• A single Artifact Registry repository has one format, such as Docker, Maven, npm, Python, or Apt, so you create separate repositories for different artifact types or teams.
• Repositories are regional or multi-regional resources, and placing a repository in the same region as your workloads reduces latency and cross-region data transfer.
• Docker repositories store OCI-compatible container images that GKE, Cloud Run, App Engine flexible, and Compute Engine container workloads can pull using standard tooling.
• Access is controlled with IAM at the project or repository level, so you can grant a team pull access to one repository without giving access to all artifacts in the project.
• Cleanup policies can automatically delete old or untagged artifacts or keep a minimum number of recent versions, which controls storage cost for images nobody deploys anymore.
• Remote repositories act as a caching proxy for an external source such as Docker Hub or a public package repository, while virtual repositories can combine several upstream repositories behind one endpoint.
• Artifact Registry integrates with vulnerability scanning through Artifact Analysis, which can scan container images on push and report known vulnerabilities and package metadata.
• Service accounts used by GKE nodes or Cloud Run services need the Artifact Registry Reader role, or an equivalent permission, on the repository to pull private images successfully.

What the exam expects you to know

• Identifying Artifact Registry, not Container Registry, as the current recommended service for private container images and packages on new exam scenarios.
• Creating repositories with the right format and location for a workload, and knowing format and location are set at creation.
• Diagnosing an image pull failure as an IAM problem by checking whether the runtime's service account has reader access to the repository.
• Using cleanup policies to control storage growth from old image versions while protecting images that are still referenced by deployments.
• Explaining remote and virtual repositories as ways to cache public artifacts and simplify client configuration.
• Connecting the delivery chain: Cloud Build pushes to Artifact Registry, and GKE or Cloud Run pulls from it at deploy time.

Artifact Registry vs Container Registry: when to use which

Artifact Registry is the successor to Container Registry and is the right choice for new work: it supports multiple package formats beyond Docker, repository-level IAM, regional repositories, cleanup policies, and remote and virtual repositories. Container Registry is the older, Docker-only service backed by Cloud Storage buckets with project-level access control. For the exam, treat questions about storing Maven, npm, or Python packages, or about per-repository permissions, as Artifact Registry questions, and treat Container Registry mainly as legacy context that Google recommends migrating away from. See also the Container Registry notes.

Useful gcloud commands

gcloud artifacts repositories create my-repo --repository-format=docker --location=us-central1
gcloud artifacts repositories list
gcloud artifacts docker images list us-central1-docker.pkg.dev/my-project/my-repo
gcloud auth configure-docker us-central1-docker.pkg.dev

Common exam traps

• Trying to store two formats in one repository: each repository is a single format, so Docker images and npm packages need separate repositories.
• Assuming a node or service can pull any private image in the project: repository-level IAM means the specific service account needs reader access to that repository.
• Ignoring old images until storage costs grow: without cleanup policies, every build leaves tagged images behind indefinitely, so set retention rules deliberately.
• Choosing a distant repository region for convenience: pulls from another region add latency and possible transfer cost, so co-locate repositories with the runtimes that use them.

Frequently asked questions

What artifact formats does Artifact Registry support?

It supports Docker and OCI container images plus common language and operating system package formats, including Maven and Gradle for Java, npm for Node.js, Python packages, Go modules, and Apt and Yum repositories. Each repository is created for one format, and clients use their normal tools, such as docker, npm, or pip, against it.

How does vulnerability scanning work with Artifact Registry?

When scanning is enabled, Artifact Analysis scans container images when they are pushed and continues to monitor them as new vulnerability data appears. Results list known CVEs, severity, and the affected packages, and they appear in the console alongside the image. Teams use these results to gate deployments and prioritize image updates.

Why use a remote repository instead of pulling from Docker Hub directly?

A remote repository caches artifacts from an external source inside your own region and project, so repeated pulls are faster, more reliable, and governed by your IAM policies. It also insulates your builds and deployments from upstream rate limits and outages, because previously pulled artifacts are served from the local cache.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.