KCNA Kubernetes Fundamentals Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Namespaces provide kernel-level isolation between Pods, equivalent to Linux namespaces used by containers.

  Why it's wrong here

  This conflates two different concepts sharing a name. Kubernetes Namespaces are API-level partitions for naming, RBAC, and quota scoping; they do not create kernel isolation. Actual isolation comes from Linux namespaces (PID, network, mount) applied per container by the container runtime. Pods in different Kubernetes Namespaces can still reach each other over the network unless NetworkPolicy or other controls intervene.

• ✗

  A NetworkPolicy that selects all Pods in a namespace automatically blocks traffic from other namespaces without additional rules.

  Why it's wrong here

  NetworkPolicy is additive and default-allow until a policy selects a Pod; selecting all Pods and defining only ingress rules from same-namespace sources does restrict cross-namespace traffic, but network policies are not namespace objects that apply automatically. The statement overstates automation. Isolation depends entirely on the policy's podSelector and rules, and the cluster's CNI must enforce NetworkPolicy for any effect. Namespaces alone do not provide network isolation.

• ✓

  Deleting a Namespace triggers deletion of the resources it contains, and the Namespace stays in Terminating until finalizers complete.

  Why this is correct

  Namespace deletion is asynchronous: the API server marks the Namespace Terminating and removes its contents, but the object remains until all finalizers and contained resources are cleared. A stuck finalizer on a resource can leave the Namespace terminating indefinitely, which is a common operational issue. This behavior is why namespace deletion should be treated as destructive and potentially slow rather than instantaneous.

• ✗

  Cluster-scoped resources such as Nodes and PersistentVolumes can be created inside any namespace for organizational clarity.

  Why it's wrong here

  Nodes, PersistentVolumes, StorageClasses, and ClusterRoles are cluster-scoped and cannot belong to a namespace. Attempting to create them in a namespace context fails or is ignored depending on the tool. Only namespaced resources such as Pods, Services, ConfigMaps, and PersistentVolumeClaims live inside a namespace. This distinction is fundamental to RBAC design and to how kubectl resolves object scope.

• ✓

  ResourceQuota and LimitRange are namespace-scoped objects used to cap aggregate consumption and set per-container defaults.

  Why this is correct

  ResourceQuota constrains total requests, limits, and object counts within a namespace, while LimitRange supplies default requests and limits and enforces min/max per container or Pod. Together they govern multi-tenant capacity. They are namespaced resources, so each namespace needs its own definitions, and a quota on compute resources requires that Pods specify requests and limits or be rejected by admission.

Go deeper

Related to this question