Containers and Orchestration Questions and Answers

Answer: C

Correct answer: Both A and R are true, and R is the correct explanation of A

Both are true and the reason gives the necessity. Pods are ephemeral: rescheduling, scaling and rolling updates all replace them, and each replacement gets a new address. A Service provides a stable name and virtual address in front of whichever pods currently match its selector, so callers need not track the churn behind it.

Answer: D

Controllers observe the difference and act to close it, repeatedly and indefinitely. This is what makes the system self healing when a node or pod is lost. The loop never stops running. Failure is corrected without intervention.

Answer: A

Correct answer: Both A and R are true, and R is the correct explanation of A

Both are true and the reason describes the control loop that makes it happen. Kubernetes is declarative: the ReplicaSet controller continuously compares the observed number of ready pods with the number declared and creates or deletes pods to close the gap. Recovery from a node failure is not a special case but simply that loop noticing a discrepancy.

Answer: B

The first two are correct. The third describes an imperative system, and the continuous reconciliation is precisely what distinguishes the declarative approach. Intent rather than steps. The gap is closed again and again.

Answer: C

The orchestrator runs what it is given and has no view of what the code does. The other three are exactly the operational concerns it exists to handle. The code is the developer's business. Operations are what it takes over.

Answer: D

Correct answer: should receive traffic

A readiness probe answers whether the pod can serve requests now; failing it removes the pod from its Service’s endpoints without restarting it, so a pod still warming its cache or waiting on a dependency stops receiving traffic and then resumes. The liveness probe is the separate one that decides whether the container should be restarted, and confusing the two produces restart loops during slow startups.

Answer: A

Both are true and the reason gives the distinction, and using the same endpoint for both is a common source of restart loops during slow startup. Separate endpoints are safer. One decides restarts and the other traffic.

Answer: B

Correct answer: identity and storage must persist

A stateless replica is interchangeable, which is what the whole scheduling model assumes. A stateful one is not: it needs a stable network identity, its own persistent volume that follows it, and often an ordered start-up and shutdown so that a cluster forms correctly. StatefulSets exist to provide those guarantees, and they are more constrained than a Deployment precisely because of them.

Answer: C

The first two are correct. The third is optimistic, since backup, failover and upgrade of a database remain hard problems whatever the orchestrator provides. The primitives help but do not solve it. Stateless services are far simpler.

Answer: D

Correct answer: 2

The declared state is 5 replicas and 3 survive, so the controller creates the 2 that are missing - it reconciles the difference rather than recreating the whole set. Whether those 2 can actually be placed depends on capacity elsewhere in the cluster; without it they remain pending, which is why cluster autoscaling is usually paired with this behaviour.