DevOps Engineer interview prep

Short answer: An L4 balancer sees only IPs and ports — it spreads TCP/UDP flows, fast and cheap, but the protocol is opaque to it. L7 parses HTTP: routing by path and headers, retries, TLS termination, cookie affinity — at the cost of CPU spent parsing.

In depth:

Examples: L4 — IPVS, AWS NLB; L7 — nginx, Envoy, AWS ALB. A common cascade: L4 on the edge → L7 inside.

⚠️ Common mistake: expecting retries or path-based routing from L4 — it doesn't see HTTP and fundamentally can't tell where one request ends and the next begins.

Short answer: A container is just a regular Linux process that the kernel hands an isolated view of the system: namespaces hide everything else, cgroups cap resources, and a layered filesystem provides its own rootfs. There is no guest kernel — one kernel serves everyone, and that is the real difference from a VM.

In depth:

1. Namespaces — visibility isolation: each type hides its own slice of the system.
2. cgroups — limits on CPU, memory, IO: how much the process may use, not what it sees.
3. Layered rootfs (overlayfs) — its own filesystem on top of shared read-only image layers.

⚠️ Common mistake: "a container is a lightweight VM." A VM has a hypervisor and its own guest kernel; a container shares the host kernel — that's why it starts in milliseconds, but isolation is weaker: one kernel vulnerability pierces every container at once.

Short answer: kubectl validates the manifest and sends it to the API server: authn → RBAC → admission webhooks → persisted to etcd. That is where the synchronous part ends — controllers, the scheduler, and kubelet notice changes asynchronously via watch and drive the cluster toward the desired state. Nobody pushes anything.

In depth:

1. API server — authentication, authorization (RBAC), admission (mutating → validating webhooks), object stored in etcd.
2. Deployment controller — sees the new Deployment (watch) and creates a ReplicaSet.
3. ReplicaSet controller — creates Pod objects, with no node assigned yet.
4. Scheduler — finds pods with an empty nodeName, filters and scores nodes, binds.
5. kubelet — on the chosen node sees "its" pod: pulls images, starts containers via CRI, networking comes up via the CNI plugin.
6. Readiness — probe passes → the pod joins the EndpointSlice and starts receiving traffic.

kubectl ──► API server (authn → RBAC → admission) ──► etcd
              ▲ watch      ▲ watch       ▲ watch      ▲ watch
  deploy-ctrl → RS    rs-ctrl → Pods   scheduler → bind   kubelet → CRI/CNI

⚠️ Common mistake: "the API server schedules the pod and starts containers." It only stores and serves state — all the work is done by independent controllers via the watch/reconcile model.

Short answer: Continuous deployment is only real with trunk-based + feature flags: small batches, branches that live hours, main always deployable. GitFlow with long-lived develop/release branches means big batches and merge hell; its home is boxed, versioned software.

In depth:

1. Flags decouple deploy from release — code ships to prod turned off; turning it on is config, not a deploy. That removes the fear of merging unfinished work into main.
2. The argument is batch size, not taste: the longer a branch lives, the more conflicts, the longer the lead time, the scarier the rollback — DORA metrics are exactly about this.

⚠️ Common mistake: answering "whatever the team prefers." It is not taste: long branches → big batches → long lead time — a measurable argument.

Short answer: With locking, the second apply blocks or fails with "Error acquiring the state lock" — the first one holds the lock. Without it — a race: both read the same state version and overwrite each other's writes, leaving the state inconsistent.

In depth:

with lock:    A: apply ──► lock OK ──► works ──► unlock
              B: apply ──► Error acquiring the state lock ✗

without lock: A: read state v1 ──► write v2a ─┐
              B: read state v1 ──► write v2b ─┴─► last writer
                                                  "wins"

1. Consequences of the race — lost records: a resource exists in the cloud but not in state (orphan), or the state is corrupted and gets fixed by hand via state rm/import.
2. Mechanics — the backend takes a lock for the duration of the operation (a DynamoDB table for S3); force-unlock is only for stuck locks.
3. The full answer — applies run only through the CI pipeline, serially; humans run plan locally.

⚠️ Common mistake: treating locking as an optional nicety "for big teams" — one overlapping apply is enough to spend a day untangling state by hand.