Containerising an application solves the problem of 'it works on my machine' by packaging an application with everything it needs to run into a single, portable unit. This is crucial for the PCDOE exam because Google Cloud uses containers as the foundation for deploying and scaling modern applications reliably. Understanding containers and how to store them in a registry is a core skill for any DevOps engineer.
Jump to a section
A simple way to picture Containerizing Applications and Using Container Registry
When you cook a meal for a friend, you use your own kitchen, your own pans, and your own ingredients. If you want to cook that exact same meal in a different kitchen — say, at a holiday rental — you have to check if they have the right pans, if the oven temperature is calibrated the same, and if the ingredients are available. That is slow and unreliable. This is exactly the problem that containerising an application solves.
Containerising an application is like packing your entire meal — the raw ingredients, the exact recipe, the pans, the stove settings, and even the chef’s instructions — into a single, sealed shipping container. You can then ship that container to any kitchen in the world. When it arrives, the receiving kitchen does not need to guess anything: the container has everything inside to recreate your meal exactly as you intended. It does not matter if the host kitchen runs gas or electric; your container has its own self-contained environment.
Now, the Container Registry is like a giant, secure warehouse where you store all your finished shipping containers (your container images). When you want to deploy your application to a new server (a new kitchen), you pull the exact container image from this registry, just as you would fetch a specific numbered shipping container from the warehouse. The registry ensures you can always find the right version, share it with your team, and roll back to an earlier version if the new recipe has a fault.
Containerising an application means bundling your application code with all of its dependencies (libraries, system tools, settings) into a single package called a container image. This container image is the 'what' — it is the file that defines how your application should run. When you run that image, it becomes a container, which is the actual running instance of that image.
Before containers, developers used virtual machines (VMs) to isolate applications. A VM runs a full operating system (OS) on top of a hypervisor, which is a piece of software that creates and runs VMs. This is heavy and slow to start because every VM includes its own copy of the OS kernel. A container, on the other hand, shares the underlying host OS kernel but isolates the application process. It is much lighter and starts in seconds instead of minutes. This is possible because of a technology built into the Linux kernel called cgroups (control groups) and namespaces. Cgroups limit how much CPU, memory, and disk a container can use. Namespaces create a walled garden so the container thinks it has its own view of the system — it sees its own file system, its own process list, and its own network interfaces — but it is actually sharing the host kernel.
The standard way to create a container image is by writing a Dockerfile. A Dockerfile is a text file that contains a set of instructions. A typical Dockerfile might start with a base image (like 'node:18' for a Node.js application), then copy in your application code, install dependencies, and define the command to run when the container starts. Each instruction in the Dockerfile creates a layer in the image. Layers are read-only snapshots of the file system at that point. If you change your code and rebuild the image, only the layers that changed need to be rebuilt and re-uploaded, which makes the process efficient.
Once you have built your container image, you need to store it so you can use it later or share it with others. This is where a Container Registry comes in. A Container Registry is a private or public repository for storing, managing, and distributing container images. Google Cloud’s offering for this is called Artifact Registry (formerly Container Registry, though the exam may still use the old name). Artifact Registry is a fully managed service that lets you store your container images in a secure, scalable, and highly available way. It integrates with other Google Cloud services like Cloud Build (for building images), Cloud Run (for running serverless containers), and Google Kubernetes Engine (GKE, for orchestrating containers).
To store an image in Artifact Registry, you first tag it with a name that points to your registry location. For example, you might tag your image as us-central1-docker.pkg.dev/my-project/my-repo/my-image:latest. This tag includes the region (us-central1), the project ID (my-project), the repository name (my-repo), the image name (my-image), and an optional version tag (latest). Version tags are critical for managing releases. You can have v1.0.0, v1.1.0, and latest all stored in the same repository. When you want to deploy a specific version, you pull that exact tag.
Security is a major concern. You control who can push and pull images using Identity and Access Management (IAM) roles. For example, you can give a developer the Artifact Registry Writer role to push new images and a CI/CD pipeline the Artifact Registry Reader role to pull images during deployment. You can also use Vulnerability Scanning, which automatically checks your images for known security flaws in the packages they contain. This scanning is built into Artifact Registry and integrates with Cloud Build to block builds that contain critical vulnerabilities.
Containerisation replaces the old way of deploying applications, which often involved manual configuration management with tools like Chef or Puppet, or script-based deployments that were prone to human error. With containers, the entire environment is version-controlled and reproducible. You can take the same image used in development, test it, and deploy it to production without any changes. This is often summarised as 'build once, run anywhere'.
Write a Dockerfile
Create a text file named 'Dockerfile' (no extension) in your project directory. Start with a base image using the FROM instruction, copy in your application code with COPY, install dependencies with RUN, and define the startup command with CMD. This file is the recipe for your container image.
Build the container image locally
Run the `docker build` command in your terminal, pointing it to the directory containing the Dockerfile. For example: `docker build -t my-app:latest .`. The `-t` flag tags your image with a name and version. Docker reads the Dockerfile instructions and produces a local image stored on your machine.
Tag the image for Artifact Registry
Tag your local image with the full Artifact Registry path using `docker tag`. For example: `docker tag my-app:latest us-central1-docker.pkg.dev/my-project/my-repo/my-app:latest`. This path tells Docker which registry repository to push to.
Authenticate to Artifact Registry
Run `gcloud auth configure-docker us-central1-docker.pkg.dev` to configure Docker to authenticate to Artifact Registry using your Google Cloud credentials. Without this step, the push will fail with a permission error.
Push the image to Artifact Registry
Run `docker push us-central1-docker.pkg.dev/my-project/my-repo/my-app:latest`. Docker uploads the image layers to the repository. Artifact Registry stores each layer separately and deduplicates layers across images, saving storage space.
Set up a Cloud Build trigger (optional but recommended)
In the Cloud Console, go to Cloud Build and create a trigger linked to your Git repository. Configure it to build the image from the Dockerfile and push it to Artifact Registry whenever code is committed to a specific branch like 'main'. This automates the build and push steps.
An IT professional working towards the Google PCDOE certification might be tasked with modernising a legacy application for a financial services company. The legacy app is a Java-based web service that handles loan applications. Currently, it is deployed on a single virtual machine running CentOS 7. The deployment process involves an ops engineer logging into the server, copying a WAR file (a Java web archive), and restarting Tomcat. This is error-prone, slow, and means the company cannot easily scale during peak loan application periods.
The professional’s job is to containerise this application. Here is what happens step by step:
First, the professional creates a Dockerfile. They start with a base image like eclipse-temurin:17-jre (a standard Java runtime). They add the WAR file into the container, expose the port the app runs on, and set the command to start the Tomcat server. They test this locally by building the image and running it to confirm the app works.
Next, they set up a Cloud Build trigger. This is a configuration that automatically builds a new container image every time the team pushes code to the main branch of their Git repository. Cloud Build reads the Dockerfile, builds the image, and automatically pushes it to Artifact Registry. The image is tagged with the Git commit hash (e.g., a1b2c3d4) and the latest tag.
The team then tests the image in a staging environment. They pull the image from Artifact Registry and deploy it to a small GKE cluster (Google Kubernetes Engine, which is a platform for running containers in production). They run automated tests to verify that the loan application logic still works inside the container.
Once tests pass, they promote the image to production by updating the deployment manifest in their Git repository to point to the new image tag. GKE pulls the new image from Artifact Registry and performs a rolling update, meaning it gradually replaces old containers with new ones so there is zero downtime.
Finally, the professional sets up vulnerability scanning on the Artifact Registry repository. When a new image is pushed, Artifact Registry automatically scans it for known vulnerabilities in all the packages (Java libraries, system tools). If a critical vulnerability is found, Cloud Build can be configured to block the build, and an alert is sent to the security team.
In this scenario, the containerised application is faster to deploy (minutes instead of hours), easier to roll back (just redeploy the previous image tag), and much more secure (built-in scanning). The company can now scale horizontally by running multiple copies of the container across many machines, handling ten times the number of loan applications during peak times.
The PCDOE exam tests your understanding of containerising applications and using Container Registry (now Artifact Registry) in several specific ways. The exam is not about writing Dockerfiles from scratch in a code editor; it is about knowing how the pieces fit together in a real Google Cloud environment. Expect to see questions that present a scenario and ask you to choose the correct service or configuration.
Key topics that appear frequently:
The difference between Artifact Registry and the legacy Container Registry. The exam will test that you know Artifact Registry is the current recommended service and that it supports multiple formats (Docker images, Maven packages, npm packages), not just containers.
IAM roles for container images: you must know which role allows a service account to push images (Artifact Registry Writer) and which allows pulling (Artifact Registry Reader). A common trap is selecting Storage Object Viewer or Storage Admin, but the correct answer will always be the Artifact Registry-specific roles.
Cloud Build integration: questions will describe a CI/CD pipeline and ask you which permissions Cloud Build needs to push the built image to Artifact Registry. The answer is that Cloud Build’s service account needs the Artifact Registry Writer role on the repository.
Vulnerability scanning: you need to know that scanning is automatically enabled for Artifact Registry repositories unless you disable it. The exam may present a scenario where a build fails because of a critical vulnerability, and you must recognise that the vulnerability scanning feature flagged it.
Tagging and versioning: questions will ask about best practices for tagging images. The correct approach is to use a unique identifier (like the Git commit SHA) as the primary tag and also apply a human-readable tag like latest. A trap is using only latest because that makes it impossible to roll back to a specific version.
Multi-architecture images: the exam might test that Artifact Registry supports storing images for different CPU architectures (e.g., x86 and ARM) under the same image name. You can create a manifest list that points to the correct image for the target architecture.
Image immutability: a common exam concept is that once you push an image with a specific digest (the hash of the image content), you cannot change that digest. If you want to update the image, you must push a new digest. Understand that tags are mutable pointers to digests, but digests themselves are immutable.
Exam traps to watch out for:
Choosing a Google Cloud service that does not handle containers, like Cloud Storage, when the question asks for storing container images.
Thinking that Cloud Build is required to build containers. While it is a common choice, you can also build images locally and push them to Artifact Registry.
Confusing Artifact Registry with Cloud Source Repositories (which store code, not containers) or Cloud Functions (which run code but not in containers).
Not knowing that Artifact Registry is regional and that you must specify a region in the image tag. Using a global tag without a region will not work.
To memorise:
Artifact Registry replaces Container Registry.
Use IAM roles: Artifact Registry Writer for push, Artifact Registry Reader for pull.
Cloud Build needs Artifact Registry Writer.
Vulnerability scanning is on by default.
Tag with a unique build ID, not just 'latest'.
A container image is a lightweight, standalone, executable package that includes everything needed to run an application, including code, runtime, system tools, and libraries.
Artifact Registry is the recommended Google Cloud service for storing and managing container images, replacing the legacy Container Registry.
You control access to container images in Artifact Registry using IAM roles: Artifact Registry Writer for pushing images and Artifact Registry Reader for pulling them.
Always tag your container images with a unique identifier, such as a Git commit SHA, not just 'latest', to enable precise rollbacks and traceability.
Vulnerability scanning in Artifact Registry is enabled by default and automatically checks images for known security issues when they are pushed.
Container images are built from a Dockerfile, which defines a series of layers that are cached and reused, making rebuilds faster and more efficient.
Artifact Registry supports multiple package formats beyond containers, including Maven, npm, and Python packages, all within the same service.
These come up on the exam all the time. Here's how to tell them apart.
Container Image
Shares the host OS kernel, so it is much smaller (MBs).
Starts in seconds because it does not boot an OS.
Uses cgroups and namespaces for isolation at the process level.
Virtual Machine Image
Includes a full OS with its own kernel, making it large (GBs).
Takes minutes to boot because it starts a full operating system.
Uses a hypervisor for hardware-level virtualisation providing stronger isolation.
Artifact Registry
Newer, recommended service with ongoing development.
Supports multiple artifact formats (Docker, Maven, npm, etc.).
Integrated with VPC Service Controls and CMEK for enhanced security.
Google Container Registry (gcr.io)
Legacy service; no new features being added.
Only supports Docker container images.
Lacks some newer security features like CMEK support for certain regions.
Image Tag (e.g., 'latest')
A human-readable label that can be changed or moved.
Can point to different digests over time, enabling 'latest' updates.
Not unique; multiple tags can point to the same digest.
Image Digest (e.g., sha256:abc123)
A unique, immutable hash that identifies a specific image content.
Cannot be changed once the image is built; guarantees you get the exact same code.
Used for immutable deployments and audit trails, because it is permanent.
Cloud Build
Fully managed Google Cloud service; no infrastructure to maintain.
Integrates natively with Artifact Registry and other GCP services.
Supports build triggers from Git repositories for automated CI/CD.
Local Docker Build
Requires a local machine or self-managed build server with Docker installed.
Needs additional configuration to authenticate and push to Artifact Registry.
Good for development and testing, but not ideal for automated pipelines.
Mistake
A container image is the same as a virtual machine image.
Correct
A container image shares the host OS kernel and is much lighter, while a VM image includes a full OS with its own kernel. Container images are measured in megabytes, VM images in gigabytes.
Both are called 'images' and both provide isolation, so beginners assume they are the same thing. The exam expects you to know the size and performance differences.
Mistake
Once you push a container image to Artifact Registry, you cannot update it. You have to delete and re-push.
Correct
You cannot change the content of an existing digest, but you can push a new digest and point the same tag (like 'latest') to it. The old digest remains stored and can still be pulled by its digest hash.
Newcomers hear 'immutable' and think the entire image is locked. Only the digest is immutable; tags are mutable pointers. This misconception leads to incorrect answers about rollback strategies.
Mistake
You must use Cloud Build to build container images for Google Cloud.
Correct
Cloud Build is a recommended and integrated service, but you can build images on your local machine or in any CI/CD tool and push them to Artifact Registry using the docker push command. Cloud Build is optional.
Google Cloud documentation heavily pushes Cloud Build, so beginners assume it is mandatory. The exam will test that you know alternative methods exist.
Mistake
Container Registry and Artifact Registry are two separate services that you choose between for different use cases.
Correct
Artifact Registry is the successor to Container Registry. Google recommends using Artifact Registry for all new projects. Container Registry is deprecated, and new features are only added to Artifact Registry.
The exam may still reference 'Container Registry' in legacy context, but the correct answer for a new deployment will always involve Artifact Registry. Beginners confuse the two and pick the wrong service.
Mistake
Vulnerability scanning in Artifact Registry must be manually enabled for each repository.
Correct
Vulnerability scanning is enabled by default for all repositories in Artifact Registry. You can disable it, but it is on by default. You also get automatic re-scanning when new vulnerabilities are discovered in the CVE database.
Many beginners assume security features require extra configuration. The exam tests that scanning is automatic, which is a selling point of the service.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Dockerfile is the text file that contains the instructions for building a container image, like a recipe. A container image is the resulting built file that you can run, like the baked cake.
No, but you need a Docker client (like Docker Engine) installed on your machine to build and push images. Artifact Registry is the storage service that holds your images after you push them.
You can grant the specific IAM role of Artifact Registry Reader on the repository to their Google account or a service account. Alternatively, you can make the repository public, but that is not recommended for security reasons.
Yes. Artifact Registry supports multiple formats, including Maven packages (Java), npm packages (JavaScript), Python packages (PyPI), and even generic artifacts, not just container images.
Deleting an image removes the tag and the underlying layers. If you have another image that shares those layers, they are preserved because layers are stored independently and only deleted when no image references them.
No. Artifact Registry is the newer, recommended service that replaces Container Registry. Container Registry (gcr.io) still works for legacy projects, but new features and integrations are only added to Artifact Registry.
You've finished Containerizing Applications and Using Container Registry. Continue through the PCDOE study guide to build a complete picture of the exam.
Done with this chapter?