CKA Practice Question: Cluster Architecture, Installation and Configuration
You have configured a ServiceAccount with an associated image pull secret. The Pod referencing this ServiceAccount still fails with ImagePullBackOff due to authentication errors. What is the most likely misconfiguration?
⚠ Common exam trap
Candidates often forget that Secrets are namespace-scoped. Even if a ServiceAccount correctly references an image pull secret by name, the secret must be created in the same namespace as the ServiceAccount and the Pod using it.
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 secret is not in the same namespace as the Pod.
Secrets in Kubernetes are namespace-scoped. When you configure `imagePullSecrets` on a ServiceAccount, the ServiceAccount admission controller automatically injects these secrets into any Pod referencing that ServiceAccount. However, because Secrets are namespace-scoped, the secret must exist in the same namespace as the ServiceAccount and the Pod. If the secret was created in a different namespace, the Pod will fail to pull the image with an authentication error (ImagePullBackOff).
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 secret is not in the same namespace as the Pod.
Why this is correct
A Kubernetes Secret, including one used for image pull credentials, must reside in the same namespace as the Pod that attempts to consume it. While this is a fundamental requirement for secret access, the primary issue indicated by the correct answer is that the ServiceAccount itself isn't configured to *use* any image pull secret. Therefore, the error would not specifically point to a cross-namespace secret issue, but rather a lack of credentials being presented at all.
- ✗
The secret type is wrong; it should be kubernetes.io/dockercfg.
Why it's wrong here
The correct and modern secret type for Docker registry authentication credentials is `kubernetes.io/dockerconfigjson`, not `kubernetes.io/dockercfg`. While using an incorrect secret type would indeed prevent successful image pulls, the more fundamental problem here, as highlighted by the correct option, is that the ServiceAccount isn't even referencing *any* secret for image pulls. The type becomes relevant only once a secret is actually linked.
- ✗
The ServiceAccount does not have the imagePullSecrets field configured.
Why it's wrong here
For a Pod to automatically inherit image pull credentials from its associated ServiceAccount, that ServiceAccount must explicitly list the relevant `Secret` in its `imagePullSecrets` array. If this field is absent or empty within the ServiceAccount definition, the Kubernetes admission controller will not inject the necessary authentication tokens into the Pod, leading to `ImagePullBackOff` errors due to unauthorized access to private registries. This is the standard and most secure method for managing registry credentials at scale.
- ✗
The Pod spec must set the secret in imagePullSecrets directly.
Why it's wrong here
While it is technically possible to specify `imagePullSecrets` directly within a Pod's `spec`, this approach is generally discouraged for security and manageability reasons, especially when ServiceAccounts are available. The recommended practice is to configure the `imagePullSecrets` on the ServiceAccount, allowing all Pods using that ServiceAccount to automatically inherit the credentials without needing individual Pod modifications. This centralizes credential management and reduces the risk of exposing secrets in Pod definitions.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF 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 CKA exam.