Correct Answer: 1

Google Artifact Registry manages container images directly without relying on individual Cloud Storage buckets for each image. Instead, Artifact Registry is a unified platform that provides repository-level permissions, allowing more granular access control over specific repositories and images. To enable a Kubernetes Engine (GKE) cluster to access images stored in the Artifact Registry from another project, the appropriate IAM permissions must be set for the service account used by the GKE nodes.

In this case, assigning the Artifact Registry Reader or Storage Object Viewer role (depending on the level of access needed) at the repository level in the td-devops project to the GKE service account will allow the nodes to securely pull images as needed. This approach eliminates the need for bucket-specific or object-level permissions associated with Cloud Storage, providing a simpler and more secure method for controlling access to container images.

Hence, the correct answer is: In the td-devops project, assign the Storage Object Viewer IAM role to the service account used by the GKE nodes. We can further improve this by limiting access to the specific bucket, which is used by the GCR to store the container images.

The option that says: Upon creating the GKE cluster, set the Access Scopes setting under Node Security to Allow Full Access to all Cloud APIs is incorrect because this does not give permissions to access Container Registry images on a different project. GKE nodes, by default, are configured with appropriate permissions to push or pull images from an Artifact Registry storage bucket but only on the same project.

The option that says: Generate a P12 key for a new service account. Use the generated key as an imagePullSecrets in Kubernetes to access the private registry is incorrect because it is not possible to authenticate using P12 keys in the Artifact Registry. Rather, you can use JSON keys, access tokens, standalone, and gcloud credential helpers. Using these authentication methods are best for accessing Artifact Registry images from a non-GKE environment.

The option that says: In the Google Cloud Storage, configure the ACLs on each container image stored and provide read-write access to the service account used by the GKE nodes is incorrect because Artifact Registry does not use Cloud Storage ACLs for access control. Instead, it relies on IAM roles set at the repository level to control permissions for container images. Assigning the Storage Object Viewer or Artifact Registry Reader IAM role to the service account used by the GKE nodes is the proper way to provide secure access to the images stored in the Artifact Registry.

References:

https://cloud.google.com/container-registry/docs/access-contro
https://cloud.google.com/container-registry/docs/advanced-authentication#methods

Check out our Google Container Registry Cheat Sheets:

https://tutorialsdojo.com/google-container-registry/

Note: This question was extracted from our Google Certified Associate Cloud Engineer Practice Exams.