You have built a Docker image locally and want to store it in Google Container Registry (GCR). What is the main result of pushing the image to GCR?
Think about what a registry does with images you push to it.
Pushing an image to GCR uploads and stores it in the registry. This allows other services or users to pull the image later. The image is not converted or deleted automatically.
You have a local Docker image named my-app with tag v1. Your GCP project ID is my-project. Which command correctly tags the image for pushing to Google Container Registry?
Remember the format for GCR image names: gcr.io/[PROJECT-ID]/[IMAGE]:[TAG]
The correct tag format for pushing to GCR is gcr.io/my-project/my-app:v1. This tells Docker where to push the image.
You want your Kubernetes cluster to pull private images from Google Container Registry securely. Which architecture ensures secure and automated access?
Consider a method that avoids managing long-lived keys and automates authentication.
Workload Identity lets Kubernetes service accounts access GCR securely without storing keys, improving security and automation.
You run docker pull gcr.io/my-project/my-app:nonexistent but the tag nonexistent does not exist in GCR. What is the expected behavior?
Think about how Docker handles requests for images that do not exist.
If the requested image tag does not exist, Docker returns an error indicating the image or tag was not found. It does not pull other tags automatically.
You want to grant a user permission to push Docker images to GCR in your project. Which IAM role should you assign?
Consider which role allows writing objects to the underlying storage bucket used by GCR.
Google Container Registry stores images in Cloud Storage buckets. The role roles/storage.objectAdmin allows users to upload (push) images by managing objects in the bucket.