- A
The service account needs roles/artifactregistry.reader on the repository.
Correct. The node's service account lacks Artifact Registry read permissions. Granting `roles/artifactregistry.reader` on the repository allows the node to authenticate when pulling images, resolving the error.
- B
The service account needs roles/storage.objectViewer on the bucket where images are cached.
Why wrong: Incorrect. Artifact Registry does not use a separate storage bucket for images. While images are stored in Cloud Storage, the IAM permissions are managed through Artifact Registry roles, not direct storage roles.
- C
The service account needs roles/container.clusterAdmin on the cluster.
Why wrong: Incorrect. `roles/container.clusterAdmin` grants full cluster management permissions and is overly broad. It does not directly address the image pull authentication issue.
- D
The service account needs roles/iam.serviceAccountUser on the GKE node service account.
Why wrong: Incorrect. Granting `roles/iam.serviceAccountUser` to the Cloud Build service account allows Cloud Build to impersonate the node service account, but the node service account still lacks Artifact Registry read permissions. This action does not fix the pod's authentication during image pull.
Cloud Build Workload Identity Service Account Impersonation
This PCSE practice question tests your understanding of gke node service account. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. A key principle to apply: gKE Node Service Account. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
A multinational corporation is implementing a least-privilege access model for their CI/CD pipeline using Cloud Build, Artifact Registry, and GKE. The pipeline builds container images, pushes them to Artifact Registry, and deploys them to GKE clusters. The security team wants to ensure that the Cloud Build service account used by the pipeline has only the minimum necessary permissions. The service account currently has: roles/cloudbuild.builds.editor, roles/artifactregistry.writer, and roles/container.developer. After a successful build and push, the deployment step completes without errors, but the newly deployed pods on GKE immediately fail with ImagePullBackOff errors. The error message indicates: "Failed to pull image 'us-central1-docker.pkg.dev/my-project/my-repo/my-image:latest': rpc error: code = PermissionDenied desc = unauthenticated: Request had insufficient authentication scopes." The GKE cluster is a private cluster with Workload Identity enabled. The node pool uses a default Compute Engine service account with only the storage scope. What is the most likely missing permission or configuration that prevents the pods from pulling images?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue:
"most likely"Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
Clue:
"least"Why it matters: You want the option with minimum overhead, fewest steps, or lowest impact — not the most feature-rich or comprehensive answer.
Clue:
"minimum / minimize"Why it matters: Asks for the least resource use — fewest addresses, smallest subnet, lowest overhead. Eliminate over-provisioned options even if they would technically work.
Clue:
"immediately / without restart"Why it matters: Time or reboot constraint — the correct answer must take effect right away without requiring a reboot or reload.
Quick Answer
The answer is that the Cloud Build service account requires the `roles/iam.serviceAccountUser` role on the GKE node’s Compute Engine service account. This is because, with Workload Identity enabled, the node’s service account—not the Cloud Build service account—authenticates to Artifact Registry when pods pull images. Without this impersonation permission, the Cloud Build service account cannot delegate its identity to the node’s service account, causing the `PermissionDenied` error despite the deployment step succeeding. On the Google Professional Cloud Security Engineer exam, this scenario tests your understanding of how Workload Identity decouples pod identity from the underlying node’s scopes; a common trap is assuming the Cloud Build service account’s `roles/artifactregistry.writer` is sufficient for image pulls, when in fact the node’s service account needs explicit `roles/artifactregistry.reader` and the Cloud Build account needs `iam.serviceAccountUser` to enable the impersonation chain. Memory tip: “Build writes, node reads—impersonation bridges the deeds.”
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
The service account needs roles/artifactregistry.reader on the repository.
The ImagePullBackOff error occurs because the GKE node's default Compute Engine service account lacks the necessary authentication scopes and IAM permissions to pull images from Artifact Registry. The node pool uses a service account with only the storage scope, meaning it cannot authenticate to Artifact Registry. Although Workload Identity is enabled, it is not properly configured for the pods; the pods are falling back to the node's service account. To resolve this, the node's service account must be granted `roles/artifactregistry.reader` on the Artifact Registry repository. Alternatively, Workload Identity can be used to bind the pod's Kubernetes service account to a dedicated Google service account with that role. The missing permission is `roles/artifactregistry.reader` on the repository for the node's service account.
Key principle: GKE Node Service Account
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The service account needs roles/artifactregistry.reader on the repository.
Why this is correct
Correct. The node's service account lacks Artifact Registry read permissions. Granting `roles/artifactregistry.reader` on the repository allows the node to authenticate when pulling images, resolving the error.
Clue confirmation
The clue words "most likely", "least", "minimum / minimize", "immediately / without restart" in the question point toward this answer.
Related concept
GKE Node Service Account
- ✗
The service account needs roles/storage.objectViewer on the bucket where images are cached.
Why it's wrong here
Incorrect. Artifact Registry does not use a separate storage bucket for images. While images are stored in Cloud Storage, the IAM permissions are managed through Artifact Registry roles, not direct storage roles.
- ✗
The service account needs roles/container.clusterAdmin on the cluster.
Why it's wrong here
Incorrect. `roles/container.clusterAdmin` grants full cluster management permissions and is overly broad. It does not directly address the image pull authentication issue.
- ✗
The service account needs roles/iam.serviceAccountUser on the GKE node service account.
Why it's wrong here
Incorrect. Granting `roles/iam.serviceAccountUser` to the Cloud Build service account allows Cloud Build to impersonate the node service account, but the node service account still lacks Artifact Registry read permissions. This action does not fix the pod's authentication during image pull.
Common exam traps
Common exam trap: answer the scenario, not the keyword
Candidates often think the issue is with the Cloud Build service account's permissions, but the error occurs at pod runtime when the node tries to pull the image. The node's service account needs the Artifact Registry reader role, not the Cloud Build service account. Additionally, Workload Identity is a red herring here because it's enabled but not leveraged; the pod inherits the node's identity.
Detailed technical explanation
How to think about this question
Workload Identity in GKE allows pods to use a Kubernetes service account that is bound to a Google service account (GSA). When a pod tries to pull an image from Artifact Registry, the GKE node's GSA must have `roles/artifactregistry.reader` on the repository. The Cloud Build service account must have `roles/iam.serviceAccountUser` on the node's GSA to create tokens for the deployment step, enabling the node to authenticate. Without this, the node's default GSA (with only storage scope) cannot authenticate to Artifact Registry, causing the `ImagePullBackOff`.
KKey Concepts to Remember
- GKE Node Service Account
- Artifact Registry Permissions
- Workload Identity
- Authentication Scopes
TExam Day Tips
- Watch for words such as best, first, most likely and least administrative effort.
- Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
GKE Node Service Account
Real-world example
How this comes up in practice
A media company stores terabytes of video archives that are accessed once a year for audit purposes. Moving these objects to a cold storage tier (Azure Archive, S3 Glacier, or Google Nearline) costs a fraction of hot storage. Questions like this test whether you understand storage tiers, access frequency tradeoffs, and retrieval latency requirements.
Visual reference
What to study next
Got this wrong? Here's your next step.
Review gKE Node Service Account, then practise related PCSE questions on the same topic to reinforce the concept.
Related practice questions
Related PCSE practice-question pages
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Configuring Access Within a Cloud Solution Environment practice questions
Practise PCSE questions linked to Configuring Access Within a Cloud Solution Environment.
Ensuring Data Protection practice questions
Practise PCSE questions linked to Ensuring Data Protection.
Managing Operations in a Cloud Solution Environment practice questions
Practise PCSE questions linked to Managing Operations in a Cloud Solution Environment.
Configuring Network Security practice questions
Practise PCSE questions linked to Configuring Network Security.
Supporting Compliance Requirements practice questions
Practise PCSE questions linked to Supporting Compliance Requirements.
PCSE fundamentals practice questions
Practise PCSE questions linked to PCSE fundamentals.
PCSE scenario practice questions
Practise PCSE questions linked to PCSE scenario.
PCSE troubleshooting practice questions
Practise PCSE questions linked to PCSE troubleshooting.
Practice this exam
Start a free PCSE practice session
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Questions learners often ask
What does this PCSE question test?
GKE Node Service Account
What is the correct answer to this question?
The correct answer is: The service account needs roles/artifactregistry.reader on the repository. — The ImagePullBackOff error occurs because the GKE node's default Compute Engine service account lacks the necessary authentication scopes and IAM permissions to pull images from Artifact Registry. The node pool uses a service account with only the storage scope, meaning it cannot authenticate to Artifact Registry. Although Workload Identity is enabled, it is not properly configured for the pods; the pods are falling back to the node's service account. To resolve this, the node's service account must be granted `roles/artifactregistry.reader` on the Artifact Registry repository. Alternatively, Workload Identity can be used to bind the pod's Kubernetes service account to a dedicated Google service account with that role. The missing permission is `roles/artifactregistry.reader` on the repository for the node's service account.
What should I do if I get this PCSE question wrong?
Review gKE Node Service Account, then practise related PCSE questions on the same topic to reinforce the concept.
Are there clue words in this question I should notice?
Yes — watch for: "most likely", "least", "minimum / minimize", "immediately / without restart". Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
What is the key concept behind this question?
GKE Node Service Account
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Keep practising
More PCSE practice questions
- Match each encryption scope to its description.
- Drag and drop the steps to set up a Private Google Access for on-premises hosts using Private Service Connect in the cor…
- A company is designing a CI/CD pipeline using Cloud Build. Security requirements mandate that the pipeline deploy only t…
- A company must implement data residency requirements that prohibit storing data outside the European Union. They are usi…
- A company wants to allow employees to access a web application running on Google Kubernetes Engine (GKE) using their cor…
- A company is deploying a multi-tier application on Google Cloud. The web tier must be accessible from the internet, whil…
Last reviewed: Jun 30, 2026
This PCSE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCSE exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.