The correct answer isC: Cluster → Nodes → Pods → Containers. This expresses the fundamental structural relationship in Kubernetes. Aclusteris the overall system (control plane + nodes) that runs your workloads. Inside the cluster, you havenodes(worker machines—VMs or bare metal) that provide CPU, memory, storage, and networking. The scheduler assigns workloads to nodes.

Workloads are executed asPods, which are the smallest deployable units Kubernetes schedules. Pods represent one or more containers that share networking (one Pod IP and port space) and can share storage volumes. Within each Pod arecontainers, which are the actual application processes packaged with their filesystem and runtime dependencies.

The other options are incorrect because they break these containment relationships. Containers do not contain Pods; Pods contain containers. Nodes do not exist “inside” Pods; Pods run on nodes. And the cluster is the top-level boundary that contains nodes and orchestrates Pods.

This hierarchy matters for troubleshooting and design. If you’re thinking about capacity, you reason at the node and cluster level (node pools, autoscaling, quotas). If you’re thinking about application scaling, you reason at the Pod level (replicas, HPA, readiness probes). If you’re thinking about process-level concerns, you reason at the container level (images, security context, runtime user, resources). Kubernetes intentionally uses this layered model so that scheduling and orchestration operate on Pods, while the container runtime handles container execution details.

So the accurate hierarchy from largest to smallest unit is:Cluster → Nodes → Pods → Containers, which corresponds toC.

=========