Kubernetes Fundamentals practice questions

Deployment with pod anti-affinity to schedule each pod on a different node.

Why it fails: Anti-affinity doesn't provide unique identifiers.

DaemonSet with a node name environment variable.

Why it fails: DaemonSet pods are per node, not per replica.

Job with a completion index environment variable.

Why it fails: Jobs are for run-to-completion, not long-running services.

The readiness probe is misconfigured.

Why it fails: Readiness probe doesn't affect port binding.

The container image is missing the application binary.

Why it fails: Missing binary would give 'command not found'.

The pod is using hostPort and two pods on the same node conflict.

Why it fails: hostPort would cause conflict across pods, but single pod restart shows the same pod.

Create a StatefulSet with pod hostnames.

Why it fails: StatefulSet provides identity, not network service exposure.

Create a Service of type ExternalName.

Why it fails: ExternalName maps to an external DNS, not to pods.

Create a ConfigMap with pod IPs.

Why it fails: ConfigMap does not expose pods as a service.

The pod has at least one endpoint in its Service's endpoints list.

Why it fails: Endpoints are added after readiness, not a requirement for readiness.

The liveness probe has succeeded.

Why it fails: Liveness probe determines if container is alive, not ready.

The pod's resource limits are too low.

Why it fails: Incorrect; low limits cause OOM or throttling, not bind errors.

An environment variable has a typo in the Deployment spec.

Why it fails: Incorrect; typos cause application errors, not port binding failures.

The readiness probe is misconfigured.

Why it fails: Incorrect; readiness probes affect service routing, not pod startup.

Use a StatefulSet with podAntiAffinity.

Why it fails: Pod anti-affinity only spreads pods across nodes; it neither reschedules a pod after node failure nor expresses a soft availability-zone preference. StatefulSets with anti-affinity suit stable-identity, per-node workloads such as databases, not a critical pod requiring zone-preferential failover.

Run a static pod defined in the kubelet configuration.

Why it fails: Static pods are managed directly by the kubelet on a single node and are never rescheduled elsewhere, so node failure simply removes the pod. They suit control-plane bootstrap components such as etcd or kube-apiserver, not workloads needing zone preference and failover.

Create a DaemonSet with a nodeSelector for the zone.

Why it fails: A DaemonSet runs one pod per node, so it cannot express a zone preference or migrate a workload when a node fails. Node affinity with preferredDuringSchedulingIgnoredDuringExecution plus pod anti-affinity achieves zone preference and rescheduling. DaemonSets suit per-node agents, not movable application pods.

The pod will fail to start because the probe port mismatches the container port.

Why it fails: A mismatched probe port does not block container startup; the kubelet starts the container, then the liveness probe fails against port 8080, triggering restarts after the failure threshold. It is tempting because admission-time validation does catch some manifest errors, but probe ports are not cross-checked against containerPort.

The liveness probe will fail, but the pod will still be marked as Ready.

Why it fails: A failing liveness probe marks the pod Not Ready and restarts the container; readiness gates traffic, so it cannot remain Ready. It is tempting because readiness and liveness probes are separate mechanisms, and a failing readiness probe alone would leave the pod running but unready.

The pod will run successfully because the probe is not required.

Why it fails: A liveness probe is optional in the manifest, but once defined it is enforced; repeated failures against port 8080 restart the container. It is tempting because omitting the probe entirely would let the pod run, yet the exhibit includes one, so that exemption does not apply.

The StatefulSet requires a headless Service that does not exist

Why it fails: A headless Service is not mandatory for scheduling; it is used for DNS.

The pod has a resource request that cannot be satisfied by any node

Why it fails: The error message explicitly mentions anti-affinity, not resource constraints.

There are not enough nodes in the cluster to schedule the third pod

Why it fails: There are exactly 3 nodes, matching the replica count, but anti-affinity blocks placement.

The nginx:latest image does not exist.

Why it fails: nginx:latest is a valid public image.

The containerPort is not matching the actual port nginx listens on.

Why it fails: containerPort is informational; nginx defaults to 80, so it matches.

The readiness probe is failing because the root path is not returning 200.

Why it fails: The root path typically returns 200 from nginx, so readiness should pass.

NodeAffinity: Ensures pods are scheduled together with other pods on the same node.

Why it fails: Incorrect — this describes PodAffinity, not NodeAffinity.

PodAffinity: Repels pods from nodes unless they have a specific label.

Why it fails: Incorrect — this describes Taints and Tolerations, not PodAffinity.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the namespace destroys every workload in production without altering the container's memory limit, so the redeployed pod is OOMKilled identically. Namespace deletion fits tearing down an entire isolated environment, not correcting one container's resource configuration.

Increase the CPU request for the container

Why it fails: OOMKilled signals the container exceeded its memory limit, so raising the CPU request leaves the memory ceiling untouched and the pod keeps restarting. CPU requests govern scheduling and compute share, so this would be the right lever when a pod is throttled or unschedulable for CPU, not when it is killed for memory.

Delete and recreate the pod to clear the crash loop

Why it fails: Deleting the pod only restarts the same container with unchanged memory limits, so it will be OOMKilled again. It is tempting because recreation clears transient crash loops, and it would be the correct choice for a stuck pod caused by a one-off fault rather than a memory-limit breach.

The Deployment was created with 'kubectl create deployment' instead of 'kubectl apply'

Why it fails: Both commands can create deployments; the issue is not about the command used.

The new Pods are not receiving traffic because the Service selector doesn't match

Why it fails: A Service selector mismatch would affect traffic routing, but the rollout itself would not fail; the new Pods would still be created.

The Deployment's update strategy is set to 'Recreate'

Why it fails: A Recreate strategy would delete all old Pods before creating new ones, so old Pods would not remain running.

ports

Why it fails: Ports are defined inside the container spec, not at the Pod level.

clusterIP

Why it fails: clusterIP is a field of Service objects, not Pods.

The Deployment will create pods with a random label

Why it fails: No random labels are added; the template labels must be explicitly set.

The pods will be created but will not be part of the Deployment

Why it fails: Without matching labels, the pods are not associated with the Deployment; they are orphaned.

The pods will be created but will not have networking

Why it fails: Networking is not affected by label mismatch; the issue is ownership.

Node

Why it fails: A Node is the worker machine hosting pods, so it is a larger infrastructure unit, not the smallest deployable object. Nodes are the answer when asked what runs the kubelet and container runtime, not what Kubernetes schedules.

Container

Why it fails: A Container is the packaged runtime image, but Kubernetes schedules and deploys Pods, which wrap one or more containers sharing network and storage. Containers are the answer when discussing image packaging or runtime isolation, not the deployment unit.

Deployment

Why it fails: A Deployment is a controller managing replica sets and rolling updates for Pods, so it sits above the deployable unit. It is correct when the question concerns declarative rollout, scaling or versioning of stateless applications, not the smallest unit.

kubectl update -f manifest.yaml

Why it fails: `kubectl update` is not a valid kubectl command; the correct imperative update commands are `kubectl edit` or `kubectl patch`.

kubectl replace -f manifest.yaml

Why it fails: `kubectl replace -f manifest.yaml` is an imperative command that only updates existing resources and fails if the resource does not exist, so it is not a general create or update method.

To provide a graphical interface for managing containers

Why it fails: Kubernetes orchestrates containerised workloads — scheduling, scaling, self-healing and service discovery across a cluster. A graphical interface is optional tooling such as the Dashboard or Lens; the control plane itself is API-driven, so a GUI is not its purpose.

To replace virtual machines with containers

Why it fails: Kubernetes orchestrates containers; it does not eliminate virtual machines. Clusters typically run on VMs in cloud environments, and containers share the host kernel rather than replacing hypervisor isolation. Replacing VMs is a migration outcome, not Kubernetes's purpose.

To compile container images from source code

Why it fails: Kubernetes schedules and runs already-built container images; it never compiles source code. Image building belongs to tools such as Docker Build, Buildah or Kaniko. Compilation is a CI concern, entirely outside the orchestrator's runtime scope.

The Deployment's resource requests exceed node capacity

Why it fails: If resources were insufficient, pods would be pending, not running but unavailable.

The Service selector does not match the pod labels

Why it fails: Service selector does not affect the Deployment's available count.

The kubelet on one node is not functioning

Why it fails: If a kubelet were down, the pod would be in an unknown state, not running but unavailable.

kubectl patch deployment my-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.16"}]}}}}'

Why it fails: The `kubectl patch` command directly mutates the Deployment's pod template, but it does not orchestrate a rolling update with zero downtime. The correct approach requires `kubectl set image` or `kubectl edit` combined with a `RollingUpdate` strategy, which gradually replaces old pods with new ones while keeping the service available. `kubectl patch` is tempting because it can update any field in a resource, and would be correct for a non-disruptive change to a static field, such as modifying a label or annotation, where no pod replacement is needed.

kubectl edit deployment my-deployment --image=nginx:1.16

Why it fails: 'edit' opens an editor; it doesn't accept --image flag.

kubectl update deployment my-deployment --image=nginx:1.16

Why it fails: 'update' is not a valid kubectl command.

The Service port does not match the container port

Why it fails: If ports don't match, the connection would reach the service but fail at the container; however, the symptom would be connection refused, not DNS failure.

The Service type should be NodePort

Why it fails: NodePort is for external access; internal access works with ClusterIP.

The Service selector does not match any pod labels

Why it fails: If selectors don't match, the Service has no endpoints, but the connection might still reach an empty set.