CKAD Practice Question: Application Environment, Configuration and Security
A Pod in namespace 'team-a' runs with a serviceAccountName of 'reporter'. The Pod must read a Secret named 'metrics-token' that lives in namespace 'team-b'. Cluster-wide RBAC and the ServiceAccount token are already configured correctly. Which Pod specification change allows the container to obtain the Secret's data?
⚠ Common exam trap
The trap here is expecting a namespace field on a Secret reference or on the Pod spec to permit cross-namespace Secret access.
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
✓
Use the ServiceAccount token to call the API server for the Secret in 'team-b', then write the returned data into a file the application reads.
Secret references such as secretKeyRef and secret volume sources resolve only inside the Pod's own namespace, so a Pod in 'team-a' cannot directly project a Secret stored in 'team-b'. The API server is the cross-namespace path, and the Pod's ServiceAccount token, combined with the already-correct RBAC, lets the container retrieve the Secret and stage its data into a file the application consumes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use the ServiceAccount token to call the API server for the Secret in 'team-b', then write the returned data into a file the application reads.
Why this is correct
Secrets are namespaced objects, and the supported way to reach one in another namespace is through the Kubernetes API with credentials that RBAC authorizes. Since the ServiceAccount token and cluster-wide RBAC are already correct, the container can project the token and use an init container or sidecar to fetch the Secret and write it to a shared file for the application.
- ✗
Create a Secret in 'team-a' that has the same name, and rely on the kubelet to mirror the data from 'team-b' automatically.
Why it's wrong here
Kubernetes never replicates Secret objects between namespaces, and duplicate names in different namespaces are independent objects. The kubelet only projects Secrets that exist in the Pod's own namespace, so a same-named Secret in 'team-a' would have to be populated separately and would not track changes in 'team-b'. There is no automatic mirroring behavior for Secrets, making this approach invalid.
- ✗
Mount a volume of type secret with secretName 'metrics-token' and add a volumeMount at /var/run/metrics.
Why it's wrong here
A Secret volume source resolves the named Secret in the Pod's namespace only; the secretName field has no namespace selector. Because the Pod runs in 'team-a' while the Secret lives in 'team-b', the kubelet cannot find it and the volume mount fails, leaving the container stuck in ContainerCreating. Cross-namespace Secret projection requires a different mechanism than a plain secret volume.
- ✗
Add an env entry with valueFrom.secretKeyRef naming 'metrics-token' and set the Pod's namespace field to 'team-b'.
Why it's wrong here
A Pod's namespace is set by the API request context, not by a spec field, so adding a namespace field to the Pod spec is invalid and rejected. Even ignoring that, secretKeyRef resolves only within the Pod's own namespace, so referencing a Secret in another namespace this way cannot work. The scenario needs cross-namespace access, which this option does not provide.
Visual reference
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This CKAD 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 CKAD exam.