KCNA Cloud Native Architecture Practice Question
A platform team runs a multi-tenant Kubernetes cluster for several product groups. They want each group's workloads to be logically isolated from one another, with separate quota limits and separate RBAC bindings, while still sharing the same cluster control plane and worker nodes. Which Kubernetes construct BEST provides this isolation boundary?
⚠ Common exam trap
The trap here is assuming that a Namespace provides hard security isolation, when it is really an administrative and naming boundary that needs NetworkPolicy and RBAC layered on top.
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
✓
Namespace
Namespaces are the standard way to carve one Kubernetes cluster into logical partitions for multiple teams. They scope names for objects, act as the boundary for ResourceQuota and LimitRange, and are the natural target for RoleBinding subjects, so separate groups get separate quotas and permissions while sharing the control plane and nodes. The other constructs address scheduling, traffic filtering, or eviction behaviour rather than tenancy.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
NetworkPolicy
Why it's wrong here
NetworkPolicy controls which Pods may send or receive traffic, effectively a Pod-level firewall enforced by the CNI plugin. It is a traffic-control primitive, not an ownership or quota boundary: it grants no RBAC separation and no resource quotas. It could supplement tenant isolation, but on its own it does not satisfy the separate quota and separate RBAC requirements.
- ✗
Node affinity rule
Why it's wrong here
Node affinity only influences which nodes a Pod is scheduled onto, based on node labels. It does not create any administrative or quota boundary, does not scope RBAC, and does not prevent one team's Pods from being scheduled beside another team's Pods. It therefore cannot deliver the tenant isolation, quota separation, or permission separation the platform team needs.
- ✓
Namespace
Why this is correct
A Namespace is the built-in Kubernetes mechanism for partitioning a single cluster into virtual sub-clusters. ResourceQuota and LimitRange objects are scoped to a namespace, and RoleBinding/ClusterRoleBinding subjects can be limited to a namespace, so each product group gets its own quota and permission boundary without provisioning a separate control plane. This directly matches the requirement of logical isolation with shared infrastructure.
- ✗
PodDisruptionBudget
Why it's wrong here
A PodDisruptionBudget limits how many Pods of a replicated workload may be voluntarily evicted at once during operations such as node drains. It is purely an availability safeguard for workloads. It provides no tenancy, no quota enforcement, and no access control, so it is unrelated to partitioning a cluster among product groups.
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
Learn chapter
Security and RBAC in Kubernetes
Key term
Namespaces
A Namespace in Kubernetes is a virtual cluster within a physical cluster that allows you to organize and isolate resources, like an apartment building with separate units for different tenants.
Key term
ReplicaSet and Replication
A ReplicaSet ensures a specified number of identical pod instances are running at all times in Kubernetes, using replication to maintain availability and stability.
About these practice questions
This KCNA question is part of Courseiva's 930-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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 KCNA 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 KCNA exam.