# Managing Artifacts and Packages with Artifact Registry

> Chapter 8 of the Courseiva GOOGLE-PCDOE curriculum — https://courseiva.com//learn/google-pcdoe/artifact-management-and-package-registries

**Official objective:** 1.6 — Store, manage, and secure build artifacts and dependencies using Artifact Registry.

## Introduction

Domain 1 of the Google Professional Cloud DevOps Engineer exam, 'Architecture and Service Design', demands you understand how to safely store and manage the components that make your applications work. That's where 'Managing Artifacts and Packages with Artifact Registry' comes in. If you've never built software, think of it as the secure, central warehouse where you keep all the distinct parts that assemble into the final product, ensuring everyone uses the right, safe versions.

## The Family Recipe Box Analogy

Ever spent an hour hunting for that one spice jar in a messy kitchen, only to discover it was right behind the salt the whole time?

That frustrating search mirrors what happens without a central system for managing software components. Imagine your family has a prized heirloom recipe box. This box doesn't just hold the recipe cards (your software builds and dependencies), it also stores every version of every recipe ever tried, from Grandma's first attempt at chocolate cake to this year's improved version. It tracks which recipe each family member last used for the annual bake-off. It has a built-in security guard who checks that no harmful ingredients (like an expired egg or a banned food colouring) accidentally get mixed into the dough. It automatically suggests the most recent, approved version of 'secret sauce' whenever someone starts cooking. And crucially, this box is fireproof and stored safely in a bank vault, so even if the house burns down, the recipes survive.

That's Artifact Registry. It is a single, secure, organised repository (the recipe box) for all the 'ingredients' your software applications need to run — the built code (the recipe itself), the libraries it depends on (the specific brands of flour and sugar), and the configuration files (the oven temperature notes). Without it, your software team is just that person in the messy kitchen, wasting time and risking a ruined meal.

## Core explanation

In the world of software development, an 'artifact' is any file produced during the process of building software. This includes compiled code (like a .jar file for Java or a .exe file for a Windows application), container images (packages that hold an application and everything it needs to run, like a portable virtual computer), and even plain configuration files (text files that tell an application how to behave). A 'package' is a specific type of artifact that bundles software together with metadata about it, such as its version number and what other packages it needs to work (its 'dependencies'). For example, a Python package might be a .whl file that includes the code for a maths library and a note that it requires Python 3.8 to run.

Before Artifact Registry, developers stored these crucial files in a messy, fragmented way. They used different, unconnected services for different file types: one for container images (like Container Registry), another for programming language packages (like PyPI for Python or Maven Central for Java), and a third for generic build outputs. This was like having three separate, uncoordinated storage rooms for your kitchen ingredients. It led to confusion, wasted time hunting for the right version, and security risks because you could easily grab an outdated or malicious ingredient from an external public store.

Artifact Registry is Google Cloud's single, unified solution to this problem. It is a managed service, meaning Google runs the servers and keeps them healthy, so you don't have to. It acts as one central repository that can hold all your artifacts and packages in one place, regardless of their type. You can store Docker container images (the most common type today), language packages (like Java JARs, Python wheels, and Node.js modules), and even generic files like Helm charts (Kubernetes configuration packages) or custom build outputs.

So, how does it work? You first create a 'repository' within Artifact Registry. Think of a repository as a dedicated project folder in your digital warehouse. You give it a name (like 'my-app-prod') and choose a location, either a single region (like 'US Central1') or multiple regions (like 'US' and 'EU') for better disaster recovery if one data centre goes offline. Within each repository, you store your artifacts. Each artifact is identified by its name and a 'version' tag (like 'v1.0.0' or 'latest'). When you are ready to use your software, your build or deployment system (the automated assembly line) tells Artifact Registry, 'Fetch the container image named 'backend' with the tag 'stable'.' Artifact Registry then securely delivers that exact file.

A major reason to use Artifact Registry is security. It integrates deeply with Cloud IAM (Identity and Access Management). This means you can precisely control who can read, write, or delete artifacts. You can say, 'Only the automated build server can upload new versions of the payment module; the QA team can only download and test them.' Additionally, Artifact Registry can scan your container images for known security vulnerabilities (like a package that has a bug allowing hackers in) using a service called Artifact Analysis. If a dangerous vulnerability is found, it can block anyone from deploying that image.

Finally, Artifact Registry is 'reliable' and 'fast'. It uses Google's high-speed global network to distribute your artifacts. If your development team is in London and your deployment servers are in Tokyo, pulling a large container image from Artifact Registry will be much faster than from an old, centralised system. It also supports 'immutable tags', which means once a version tag is assigned to an artifact, it cannot be changed. This prevents a nasty scenario where someone accidentally overwrites the 'production' tag with a faulty, untested version, crashing your live application. In summary, Artifact Registry replaces the old, messy, insecure approach with one organised, secure, and fast system for managing the building blocks of your software.

## Real-world context

Sarah is a DevOps Engineer at 'GreenLeaf Analytics', a company that builds weather prediction software. Her software is composed of dozens of microservices (small, independent services that each do one thing, like 'predict temperature' or 'fetch satellite data'). Each microservice is packaged as a Docker container image. Sarah also uses external Python libraries for data analysis.

Here is what her typical day looks like with Artifact Registry:

- She creates a new Artifact Registry repository called 'greenleaf-prod-images' in the 'us-central1' region, configured as a Docker repository. She sets up IAM permissions so that only the CI/CD pipeline (her automated build system) can write to this repo, and only the production Kubernetes cluster (her automated deployment system) can read from it.
- Her development team commits a code change to fix a bug in the 'wind-speed' microservice. The CI/CD pipeline automatically triggers, builds a new Docker image, and pushes (uploads) it to the 'greenleaf-prod-images' repository with the tag 'v2.1.0-wind-fix'.
- The pipeline then requests Artifact Registry to scan this new image for vulnerabilities using Artifact Analysis. The scan finds a critical flaw in one of the base operating system packages inside the image. The pipeline is automatically configured to halt deployment if critical vulnerabilities are found. The image is not deployed.
- Sarah receives an alert. She looks at the scan report, sees the exact vulnerable package, and directs her team to update the base image to a patched version. They push a new image with the tag 'v2.1.1-wind-fix'. This time, the scan passes.
- The pipeline now fetches that specific image from Artifact Registry and deploys it to the production Kubernetes cluster. Because Artifact Registry uses Google's fast network, the download takes only seconds.
- Months later, a new developer needs to reproduce a bug from version 'v2.0.0'. Sarah's team can go back into Artifact Registry, find that exact historical image, pull it down, and run it. Because Artifact Registry keeps a complete, immutable history, no one needs to rebuild the code from scratch.

Without Artifact Registry, Sarah would have to manage a messy system of manual file sharing, insecure access permissions, and slow, unreliable downloads from public repositories — a recipe for disaster for a critical weather service.

## Exam focus

The PCDOE exam focuses on understanding Artifact Registry's capabilities, its role in a secure software supply chain, and how it differs from older systems. Questions are scenario-based and test your ability to choose the best configuration. Do not memorise commands; understand concepts.

Here are the exact concepts the exam loves to test:

- **Unified vs. Disparate Repositories:** You must know that Artifact Registry is the *single* service that replaces *multiple* previous services. A classic trap question describes a scenario using Container Registry (the old, separate service). The correct answer will always state that operations should be migrated to Artifact Registry for a unified approach.
- **Vulnerability Scanning (Artifact Analysis):** The exam tests that Artifact Registry *automatically* integrates with Artifact Analysis (formerly Container Analysis) to scan for security vulnerabilities. They love to ask, 'How do you prevent a container with a critical vulnerability from being deployed?' The answer is always a combination of enabling vulnerability scanning on the repository and configuring a policy in your CI/CD pipeline to block deployment based on the scan result (often using Binary Authorization).
- **Access Control (IAM) and Repository Modes:** You will be asked about the 'Standard' vs. 'Remote' repository modes. Standard is for your own private artifacts. Remote acts as a caching proxy to a public repository (like Docker Hub or Maven Central). The exam will test that a 'Remote Repository' reduces bandwidth and improves reliability when pulling public dependencies, because it caches a copy in your own project. You must also understand how to use IAM roles like 'artifactregistry.admin' (full control), 'artifactregistry.writer' (push new artifacts), and 'artifactregistry.reader' (pull artifacts).
- **Immutable Tags:** The concept that once you push an artifact with a tag (like 'latest'), you cannot overwrite it unless you delete and re-push. A question might describe a developer trying to fix a bad deploy by pushing a new image with the same tag as the bad one. The correct understanding is that this fails by default because tags are immutable, preventing accidental overwrites. The safe solution is to use versioned tags (like 'v1.2.3') for production.
- **Multi-Region Repositories for Disaster Recovery:** The exam tests that you can create a repository that replicates its data across multiple Google Cloud regions. A scenario asking 'How do you ensure application deployment continues if a region fails?' will have the answer: store artifacts in a multi-region Artifact Registry repository.
- **Traps with 'Build triggers':** A common trap question asks, 'Which service should you use to store the output of a build trigger?' The trick is that the build trigger (Cloud Build) generates artifacts as output. The correct answer is to save those artifacts to Artifact Registry, not to Cloud Storage (though that's an option, Artifact Registry is specialised).
- **Private vs. Public Repositories:** You need to know that Artifact Registry supports both private (your own) and public (access to official Google Cloud images, like 'gcloud' or 'node') images. The exam will not test the public repository deeply, but you should recognise it exists.

## Step by step

1. **1. Create an Artifact Registry Repository** — You start by creating a repository, which is like a dedicated digital shelf for your artifacts. You choose a name, a format (e.g., Docker, Maven, Python), and a location (single or multi-region). This step defines where and how your artifacts will be stored.
2. **2. Configure Access with IAM Permissions** — You grant specific IAM roles to users and service accounts. For example, your automated build server gets the 'artifactregistry.writer' role so it can upload new artifacts, and your production deployment server gets the 'artifactregistry.reader' role so it can pull them. This step is crucial for security.
3. **3. Push a Build Artifact to the Repository** — After a build process compiles your code, you tell the build tool (like Docker or Maven) to authenticate to Artifact Registry and upload the resulting artifact. The artifact is stored with its name and a tag representing its version (e.g., 'my-app:v1.0.0'). This step makes the artifact available for others to use.
4. **4. Enable Vulnerability Scanning on the Repository** — You configure the repository to automatically scan new artifacts for known security vulnerabilities upon upload. This step is passive detection — it creates a report but does not block anything. You must manually review the report or configure a policy to act on it.
5. **5. Configure Deployment Policy (Binary Authorization) to Block Vulnerable Artifacts** — To enforce security, you set up Binary Authorization to require that only scanned and approved images can be deployed. When a deployment requests a vulnerable image, Binary Authorization checks the scan attestation and blocks the deployment. This closes the loop from detection to prevention.
6. **6. Pull and Deploy the Exact Artifact** — Your deployment system (like Kubernetes) authenticates to Artifact Registry and requests the specific artifact by its tag (e.g., 'my-app:v1.0.0'). Artifact Registry delivers the file over Google's fast network. This step starts the actual running of your software using the exact component you stored and validated.

## Comparisons

### Artifact Registry vs Cloud Storage

**Artifact Registry:**
- Purpose-built for software artifacts
- Understands package formats (Docker, Maven, Python)
- Integrates with vulnerability scanning and IAM for package access

**Cloud Storage:**
- General-purpose object storage
- Stores any file as a blob
- No built-in understanding of package types; no vulnerability scanning

### Standard Repository vs Remote Repository

**Standard Repository:**
- Stores your own private, proprietary artifacts
- You have write permission to push your artifacts
- Access controlled by your own IAM policies

**Remote Repository:**
- A cache/proxy for public upstream repositories
- Read-only from your perspective; you cannot push your own code here
- Pulls from public sources (Docker Hub, PyPI) and caches locally

### Immutable Tags vs Mutable Tags

**Immutable Tags:**
- Tag cannot be overwritten once assigned
- Prevents accidental overwrites of 'stable' or 'latest'
- Safe for production deployments

**Mutable Tags:**
- Tag can be reassigned to a different artifact
- Risk of corrupting a deployment by pointing 'latest' to a bad build
- Convenient for development but dangerous for production

### Vulnerability Scanning (Artifact Analysis) vs Binary Authorization

**Vulnerability Scanning (Artifact Analysis):**
- Detection: identifies vulnerabilities and creates a report
- Passive: does not block anything on its own
- Runs automatically on artifact push

**Binary Authorization:**
- Enforcement: uses the scan report to make deployment decisions
- Active: blocks deployment if scan finds a violation
- Requires separate configuration and a policy

## Common misconceptions

- **Misconception:** Artifact Registry is just for storing container images, like old Container Registry. **Reality:** Artifact Registry is a universal, multi-format repository. It can store Docker images, language packages (Python, Java, Node.js, etc.), Helm charts, and generic files all in one service. (People carry over their understanding from Container Registry, which was exclusively for Docker images. Artifact Registry's key feature is unification.)
- **Misconception:** I can just use Cloud Storage buckets to store my build artifacts and it's the same thing. **Reality:** Cloud Storage is for unstructured object storage (backups, files). Artifact Registry is purpose-built for software artifacts: it understands package formats, supports versioning rules, integrates with vulnerability scanning and IAM for package-level access, and provides faster, more reliable downloads for deployment systems. (Cloud Storage is more familiar to beginners. They underestimate the specialised features Artifact Registry provides that are critical for a secure and efficient software delivery pipeline.)
- **Misconception:** Enabling vulnerability scanning on Artifact Registry automatically stops deployment of vulnerable images. **Reality:** Scanning only *reports* vulnerabilities. To actually *prevent* deployment, you must use a separate policy engine, typically Binary Authorization, which checks the scan results and blocks deployment if a policy violation is found. (Beginners assume 'scanning' implies 'blocking'. The exam explicitly tests that you understand the difference between detection and enforcement.)
- **Misconception:** Tags like 'latest' are safe to use in production because they always point to the newest version. **Reality:** Tags are mutable by default, meaning 'latest' can be overwritten with a bad version by mistake. In production, you should use specific, immutable version tags (e.g., 'v1.1.0') to ensure you always deploy exactly what you tested. (The word 'latest' suggests a stable, current pointer. In practice, it is the most dangerous tag because it can change without warning, leading to unexpected and hard-to-debug deployments.)
- **Misconception:** A Remote Repository is essentially the same as a Standard Repository, just in a different location. **Reality:** A Standard Repository stores your own private artifacts. A Remote Repository acts as a read-only cache/proxy for upstream public repositories (like Docker Hub). It does not store your own code, only copies of public packages you specify. (People confuse 'remote' with a distant but private storage location. It is actually a completely different mode: a caching proxy for public packages.)

## Key takeaways

- Artifact Registry is a single, centralised service that replaces multiple older services for storing all types of software artifacts.
- Use 'Standard' repositories for your own private code and 'Remote' repositories as a caching proxy for public dependencies to improve speed and reliability.
- Vulnerability scanning is automatic but blocking deployment requires an additional policy mechanism like Binary Authorization.
- Tags are immutable by default in Artifact Registry, preventing accidental overwrites of important versions in production.
- Storing artifacts in multi-region repositories ensures your deployments can continue even if an entire cloud region goes offline.
- You control who can push and pull artifacts using Cloud IAM roles like 'artifactregistry.writer' and 'artifactregistry.reader'.
- Always use specific, versioned tags (like 'v1.2.3') rather than 'latest' for your production deployments.

## FAQ

**What is the difference between Artifact Registry and Container Registry?**

Container Registry only stores Docker container images. Artifact Registry is the newer, unified service that stores Docker images plus all other artifact types (like Python packages, Java JARs, and Helm charts) in one place. Google recommends using Artifact Registry for everything.

**Is Artifact Registry free to use?**

There is no upfront cost for the service itself, but you pay for the storage you use (how much data you store) and for network egress (data sent out of Google Cloud). Storing an artifact and forgetting about it still incurs a storage charge.

**Can I delete an old version of an artifact from Artifact Registry?**

Yes, but with caution. You can use the 'gcloud' command-line tool or the Cloud Console to delete specific versions or entire repositories. Deleting an old version that is still in use by a running application will break that application the next time it tries to pull that version.

**What happens if someone pushes an image with the same tag as an existing one?**

By default, Artifact Registry enforces immutable tags. The push will fail, and you will receive an error message stating that the tag already exists. To change the image, you must first delete the existing tag or use a new, unique tag.

**How do I use Artifact Registry with a private repository from another service like Docker Hub?**

You do not connect Artifact Registry to Docker Hub directly for your private images. Instead, you push your own images from your build system to Artifact Registry. For public images from Docker Hub, you create a 'Remote Repository' in Artifact Registry that acts as a caching proxy.

**My application is failing because it cannot pull an image from Artifact Registry. What could be wrong?**

The most common cause is an authentication or permission issue. Your deployment system (e.g., Kubernetes) likely does not have the correct IAM permissions to read from the repository. Verify that the service account used by your deployment system has the 'artifactregistry.reader' role.

---

Interactive version with quiz and diagrams: https://courseiva.com//learn/google-pcdoe/artifact-management-and-package-registries