Infosys Containers & Kubernetes interview questions

Follow a Deployment change through the API server, controllers, scheduler and kubelet. Each handoff gives you a different place to investigate when a pod never starts.

A pod is a shared network and storage boundary that happens to contain containers. Once you can say what the containers inside one share, sidecars and init containers stop needing separate explanations.

A Service moves connections and an Ingress reads requests. The gap between those two sentences is hostname routing, path routing and TLS, and it is also why an Ingress object alone does nothing.

A namespace scopes names, permissions and quotas. It does not scope the kernel or the network by default, and the gap between what people assume it isolates and what it does is where the trouble starts.

A ReplicaSet keeps a count. A Deployment manages a sequence of ReplicaSets, and that is the entire difference: it is what turns a change into a rollout you can pause and undo.

Build instructions depend on earlier inputs, so changing source can invalidate a dependency installation placed after it. Ordering the Dockerfile by how often things change is the whole optimisation, and multi-stage is how the compiler stops shipping to production.

It is Kubernetes with an opinion, and the opinion that catches everyone is that containers do not run as root. A manifest that works on vanilla Kubernetes and fails here usually fails for exactly that reason.

The pair everyone configures and few can explain. QoS hints at eviction risk, but usage versus requests and Pod priority determine node-pressure ranking, and CPU and memory behave completely differently when you exceed them.

A practical question with a precise answer, and the size is not the real cost. Pull time on every node, registry storage, and attack surface all scale with it.

Default-deny egress breaks name resolution before it breaks anything else, and every connection times out confusingly. The practitioners are the ones who test with positive AND negative probes and know their CNI's fine print.

Explain per-node eligibility and update behaviour, then verify that a Ready collector is actually delivering logs.

Quotas are admission-time contracts counted in requests, not measured usage. That single sentence explains most quota outages, most quota confusion, and the reason LimitRange must sit beside every quota.

Pull auth resolves on the node before any container exists. Ordering the credential chain and reading 401 against 403 against 429 in the events turns this into a minutes-long diagnosis; without it the only move left is rotating secrets blind.

Exec into a distroless image and you get nothing, because there is nothing to exec into. Ephemeral containers inject tooling into a running pod without restarting it, and the security caveats are what interviewers really listen for.

Two artifacts hide under 'Kubernetes backup' and they recover different things. The misses are what decides whether a restore works: volume bytes, encryption keys, and everything that never lived in etcd at all.

Best-effort objects, one-hour TTL, deduplicated by count, invisible unless shipped out. Events narrate scheduling and lifecycle decisions; treating them as durable records is the expensive mistake.

Two-phase deletion, a controller that purges content, finalizers holding the door. Stuck CRD instances, dead webhooks and GitOps recreates are the real story; standards prevent the ticket.

Both run pods, so the answer sounds obvious until an interviewer asks what happens when you delete one. The guarantees are narrower and more specific than most candidates think.

Service types choose how an application is exposed. Follow the actual traffic path: cloud controllers can target nodes or pods, and internal exposure differs from public exposure.

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

Everyone can recite the three. Explain what each failure causes, and why a badly configured liveness probe is more dangerous than none at all.

Almost always a finalizer, and the fast fix is the one that loses data. The safe answer explains what the finalizer is protecting against before removing it.

The writable layer is part of the container, not the image, and it dies with the container. Everything about volumes follows from knowing which of those two a file is in.