Deploying Docker Containers to GKE: From Dockerfile to Running Pod

Deploying a Docker container to Google Kubernetes Engine is a five-step workflow that the Associate Cloud Engineer exam expects you to know in order. This article covers the workflow itself, what each step actually does, the commands you would run, and the way this topic shows up on the ACE exam.

It does not cover writing Dockerfiles from scratch, every kubectl flag, networking inside the cluster, or autoscaling the underlying node pool. Those are real topics, but they are not what the Associate Cloud Engineer exam is testing when it asks about deployment. The exam is testing whether you know the order of steps and which tool does which step.

The five steps

The Associate Cloud Engineer exam lists this workflow exactly. Create or acquire a Dockerfile. Build a Docker image from it. Push the image to Artifact Registry or Container Registry. Create a Kubernetes Deployment manifest that references the image. Use kubectl to apply the manifest, which deploys the container as a pod on your cluster.

The most important thing to internalize is which tool does which step. Docker builds and pushes the image. The registry stores it. kubectl deploys it. Kubernetes itself runs it. If you mix those up on the exam, you will pick the wrong answer on a question that should be free.

Step 1 and 2: Dockerfile and image

A Dockerfile is a text file that defines what goes into a container. The base operating system, your application code, dependencies, environment variables, the command to run when the container starts. You build it into an image with one command:

docker build -t us-central1-docker.pkg.dev/PROJECT/REPO/my-app:v1 .

The tag matters here. Tagging the image with the registry path up front means you do not have to retag it later before pushing.

Step 3: Push to Artifact Registry

Artifact Registry is the destination for the image. Container Registry was the older option and is being retired, but it may still appear on older Associate Cloud Engineer exam questions. For new work, use Artifact Registry.

docker push us-central1-docker.pkg.dev/PROJECT/REPO/my-app:v1

The user or service account doing the deployment needs read access to the registry. For Artifact Registry, that means the Artifact Registry Reader role. For the older Container Registry, Storage Object Viewer is enough because Container Registry stored images in Cloud Storage buckets.

Step 4: The Deployment manifest

A Deployment is a Kubernetes resource that manages a set of identical pods. The manifest is a YAML file that tells Kubernetes what image to run, how many replicas you want, and how to label the pods. Here is a minimal example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: us-central1-docker.pkg.dev/PROJECT/REPO/my-app:v1
        ports:
        - containerPort: 80

The field that connects this manifest to the work you did in steps 1 through 3 is the image field. That string has to match exactly what you pushed.

Step 5: kubectl apply

The last step is one command:

kubectl apply -f deployment.yaml

kubectl reads the manifest, sends it to the cluster's control plane, and the control plane creates the pods on whatever nodes have capacity. After a few seconds, you can check that the pods are running:

kubectl get pods

What the exam tests

If you see a question about deploying a containerized application to GKE that lists steps out of order, the answer is the option where the order matches what is above. Build, push, manifest, apply.

If you see a question where someone wrote a Dockerfile and now wants to run it on a GKE cluster, the answer involves all five steps, not just kubectl apply. A common wrong answer on these questions is to deploy the Dockerfile directly with kubectl, which is not a thing. kubectl works against manifests, not Dockerfiles.

If you see a question about why a deployment is failing because pods cannot pull the image, the answer is almost always a registry permissions problem. The service account running on the GKE nodes needs read access to the registry where the image lives.

The bottom line

Deploying a Docker container to GKE is Dockerfile, image, registry, manifest, kubectl apply. Docker handles the first three steps. kubectl handles the last. The Associate Cloud Engineer exam tests whether you know that order and which tool owns each step. If you can recite the five steps, almost every deployment question on the exam answers itself.

My Associate Cloud Engineer course covers GKE deployment in the containers section alongside Cloud Run, Artifact Registry permissions, and the kubectl commands the ACE exam tests.