Container Orchestration practice questions

Expose the database via Ingress

Why it fails: Ingress is for HTTP/HTTPS traffic, not TCP for databases.

Use a Headless Service

Why it fails: Headless services are for discovering pods, not external services.

Create an EndpointSlice manually with the pod IP

Why it fails: EndpointSlice is used for internal endpoints, not external IPs.

The ReplicaSet is paused

Why it fails: ReplicaSets do not have a paused field; that feature is for Deployments.

The nodeSelector does not match any node

Why it fails: Pods would remain pending, but the ReplicaSet would still show the desired count.

A ResourceQuota in the namespace limits the number of pods

Why it fails: ResourceQuota would prevent pod creation, resulting in fewer replicas, but the ReplicaSet would show the desired count.

NetworkPolicy

Why it fails: NetworkPolicy controls traffic, does not expose services.

Ingress resource

Why it fails: Ingress provides HTTP routing, not a direct service endpoint for protocols other than HTTP.

Deployment with replicas

Why it fails: Deployment does not expose a network endpoint.

Headless Service

Why it fails: Headless Service is for internal discovery, no external exposure.

ClusterIP Service

Why it fails: ClusterIP is internal only.

Ingress

Why it fails: Ingress is not a Service type; it's a separate resource.

Increase the number of backend replicas to 5 to absorb the failures.

Why it fails: More replicas may reduce impact but not eliminate timeouts if traffic still hits the unhealthy pod.

Add a liveness probe to the frontend Deployment.

Why it fails: Liveness probe restarts frontend pods, which does not address backend issues.

Increase the frontend connection pool timeout to 10 seconds.

Why it fails: Longer timeout may reduce timeouts but does not prevent traffic to unhealthy backend.

Verify the Secret update → Update the Secret → Force Pod recreation if needed → Wait for new Pods to be ready → Verify the new value in the Pods

Why it fails: This is incorrect because you cannot verify the update before performing it. The update must come before verification.

Update the Secret → Force Pod recreation if needed → Verify the Secret update → Wait for new Pods to be ready → Verify the new value in the Pods

Why it fails: This is incorrect because you should verify the Secret update before forcing Pod recreation to ensure the new value is available and avoid unnecessary recreation.

Update the Secret → Wait for new Pods to be ready → Force Pod recreation if needed → Verify the new value in the Pods → Verify the Secret update

Why it fails: This is incorrect because waiting for new Pods before forcing recreation does not cause the new value to be picked up, and verifying the new value before verifying the update is out of order.

API Server: A distributed key-value store used as Kubernetes' backing store.

Why it fails: Incorrect — this role belongs to etcd, not the API Server.

etcd: Watches for newly created pods and assigns them to nodes.

Why it fails: Incorrect — this role belongs to the Scheduler, not etcd.

Increase the CPU request for the container

Why it fails: OOMKilled signals the container exceeded its memory limit, so raising the CPU request changes nothing about memory allocation and the pod keeps being terminated. CPU requests govern scheduling and compute share, making this the right lever when a pod is throttled or unschedulable for processor capacity, not when the kernel kills it for memory.

Delete and recreate the pod to clear the crash loop

Why it fails: Recreating the pod produces an identical spec, so the container again exceeds its memory limit and is OOMKilled; the crash loop is a symptom, not stale state. Deleting pods is the correct remedy when a pod is stuck due to a failed node, eviction or immutable field change, none of which apply here.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the namespace destroys every workload, service and configuration in production, yet the replacement pods inherit the same memory limit and are OOMKilled again. Namespace deletion suits tearing down an entire isolated environment, not remediating one container whose memory limit sits below its actual working-set demand.

4 pods running

Why it fails: 4 would be the maximum allowed by maxSurge=1, but the controller would not keep both old and new at full count simultaneously during update.

3 pods running

Why it fails: 3 would be the initial count; after update and failure, only 2 remain.

1 pod running

Why it fails: The new ReplicaSet has 2 pods; the old had 1 left before failure, but after failure, only the 2 new pods remain.

Ensure Service A's pod has the label 'app: frontend' on its pod spec

Why it fails: Incorrect. A podSelector alone matches pods in the same namespace only, so adding the label to Service A's pod in the 'default' namespace will not allow ingress from the 'backend' namespace's NetworkPolicy.

Add a similar NetworkPolicy in the 'default' namespace allowing egress to the 'backend' namespace

Why it fails: Incorrect. Egress policies control outbound traffic from pods in the 'default' namespace, but the traffic direction is from Service A (default) to Service B (backend), so an ingress policy on the backend namespace controls access. Adding an egress policy is not necessary and does not allow the traffic.

Change the NetworkPolicy to allow all ingress traffic from any source

Why it fails: Incorrect. Changing the policy to allow all ingress is too permissive and violates security best practices. The proper approach is to use a namespaceSelector to restrict cross-namespace traffic.

Job

Why it fails: Jobs run to completion and do not restart.

DaemonSet

Why it fails: DaemonSets ensure one pod per node but do not focus on restarting crashed pods.

CronJob

Why it fails: CronJobs run jobs on a schedule.

kubectl logs mycontainer -p mypod

Why it fails: Incorrect: The `-p` flag is used to view logs from a previously terminated container instance, not to specify the container name.

kubectl logs mypod --container mycontainer

Why it fails: The short flag for selecting a container is -c, not the long-form --container, so this command does not meet the short-flag requirement. The long form works correctly when brevity is irrelevant, such as in readable scripts or documentation.

kubectl logs mypod mycontainer

Why it fails: Passing mycontainer as a positional argument is invalid syntax; kubectl logs accepts only one positional pod name, so the command errors rather than selecting a container. This form would suit a single-container pod where no container selection is needed.

It serves as the container runtime

Why it fails: etcd is the distributed key-value store holding cluster state; the container runtime is containerd or CRI-O, invoked via the CRI. It tempts because etcd runs on control-plane nodes alongside the runtime, but it never executes containers.

It provides DNS-based service discovery

Why it fails: DNS-based service discovery is provided by CoreDNS, which watches the API server; etcd stores that API data but serves no DNS queries. It tempts because etcd underpins the records CoreDNS publishes, yet it is a datastore, not a resolver.

It schedules pods onto nodes

Why it fails: Scheduling is performed by kube-scheduler, which watches for unscheduled pods and binds them to nodes; etcd only stores the resulting state. It tempts because the scheduler reads and writes through etcd, but etcd makes no placement decisions.

replicas: 3

Why it fails: This sets the count but does not spread across nodes.

strategy.type: Recreate

Why it fails: Recreate strategy does not affect node distribution.

template.spec.nodeName

Why it fails: nodeName directly assigns a specific node, not suitable for dynamic scheduling.

The Deployment deletes all pods and recreates them

Why it fails: That would cause downtime and is not default behavior.

The Deployment automatically reverts to the previous ReplicaSet

Why it fails: Auto-rollback is not default; it requires a Deployment with revisionHistoryLimit and manual rollback.

The Deployment continues the rollout, ignoring the failure

Why it fails: The Deployment will stop the rollout if the new pod is not healthy.

Delete and recreate the pod to clear the crash loop

Why it fails: Recreating the pod restarts the same container with the same memory limit, so it will be OOMKilled again once usage peaks. It is tempting because deleting a crashing pod often clears transient faults, but that applies to configuration or image errors, not to a container exceeding its memory allocation.

Increase the CPU request for the container

Why it fails: OOMKilled is the kernel terminating the container because it exceeded its memory limit, so raising the CPU request leaves that limit untouched and the kill recurs. CPU requests govern scheduling and throttling, and would be the right adjustment when a container is CPU-starved rather than memory-terminated.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the namespace destroys every workload, service and persistent volume claim in production, yet the OOMKilled status is scoped to one container's memory limit. Redeploying identical manifests reproduces the same kill. Namespace deletion suits decommissioning an entire environment, not correcting a single container's memory allocation.

container resource limits

Why it fails: Resource limits control CPU/memory usage, not node selection.

tolerations

Why it fails: Tolerations are used to allow scheduling on tainted nodes, not to select nodes by label.

nodeAffinity

Why it fails: `nodeAffinity` is the correct *mechanism* for scheduling pods based on node labels, including the 'disktype=ssd' requirement. However, the question asks for the specific *field* within the pod specification. `nodeAffinity` is itself a sub-field of the broader `affinity` field (`spec.affinity.nodeAffinity`). While `nodeAffinity` is where the rules are defined, `affinity` is the top-level field that encapsulates all node and pod affinity/anti-affinity rules, making it the more encompassing and direct answer for the *field* to configure.

kubectl expose deployment my-svc --type=LoadBalancer --name=my-svc-lb

Why it fails: This would attempt to expose a deployment, not the service.

kubectl expose service my-svc --name=my-svc-lb

Why it fails: Without --type, defaults to ClusterIP, not LoadBalancer.

kubectl expose service my-svc --port=80 --target-port=8080

Why it fails: This changes port mapping but does not set the service type to LoadBalancer.

To check if the pod has been scheduled on a node

Why it fails: Scheduling is handled by the scheduler assigning a pod to a node, and a readiness probe plays no part in that decision; it controls whether the pod's IP is included in the endpoints of a service so traffic is only sent once the container can serve it. A probe that reports on node placement would be the wrong mechanism, since placement is a one-off scheduling event rather than a continuous health signal.

To measure the CPU and memory usage of the container

Why it fails: Readiness probes determine whether a container is ready to receive traffic, gating Service endpoints; they do not report resource consumption. It is tempting because CPU and memory metrics are collected by the pod, but that is the metrics-server or resource requests, not readiness.

To determine if the container is healthy and should be restarted

Why it fails: A readiness probe controls whether the pod's IP is added to Service endpoints, gating traffic until the app can serve requests; it never restarts containers. Liveness probes perform that restart role, so this option describes liveness. Readiness is correct when you must delay traffic during slow startup without killing the pod.

Containers are used exclusively

Why it fails: Immutability describes replacing rather than mutating running instances; it does not require containers, and VM-based deployments can be immutable. Containers are the correct focus when the question asks about packaging and portability of application artefacts, not infrastructure lifecycle.

Infrastructure is version-controlled and tested

Why it fails: Version-controlling and testing infrastructure describes infrastructure as code, a delivery practise that can equally manage mutable servers; it does not itself make infrastructure immutable. Immutability concerns whether running instances are ever modified after deployment. It is tempting because IaC and immutable infrastructure are commonly adopted together, so the two are easily conflated.

Configuration updates are applied directly to running servers

Why it fails: Applying updates directly to running servers is mutable infrastructure: servers persist and are patched in place. Immutable infrastructure instead replaces whole instances with newly built images, never modifying live ones. The option is tempting because in-place patching is the traditional operational habit, and it is what configuration management tools such as Ansible or Puppet were designed to automate.