DevOps Engineer interview prep

Short answer: OSI is a reference (theoretical) model that splits networking into 7 layers, where each layer provides services to the one above it and uses services of the one below it. In practice it's used less than TCP/IP, but it's handy for discussion and troubleshooting.

In detail:

Layers from bottom to top (mnemonic: "Please Do Not Throw Sausage Pizza Away"):

#	Layer	What it does	Data unit	Examples
7	Application	Interaction with the application	Data	HTTP, DNS, FTP, SMTP
6	Presentation	Encoding, encryption, compression	Data	TLS, JPEG, ASCII
5	Session	Setting up/managing a session	Data	sockets, RPC
4	Transport	Delivery between processes, ports	Segment (TCP)/Datagram (UDP)	TCP, UDP
3	Network	Logical addressing, routing	Packet	IP, ICMP
2	Data Link	Transfer within a network segment, MAC	Frame	Ethernet, Wi-Fi, ARP
1	Physical	Bits over the transmission medium	Bit	cables, radio, optics

When sending, each layer adds its own header (encapsulation); when receiving, it strips it off (decapsulation). For example, HTTP data is wrapped in a TCP segment, which is wrapped in an IP packet, which is wrapped in an Ethernet frame.

Encapsulation diagram:

[ Ethernet [ IP [ TCP [ HTTP data ] ] ] ]
   L2        L3   L4      L7

⚠️ Gotcha: TLS/encryption is often assigned to layer 6 (Presentation) in OSI, but in the actual TCP/IP model it's placed between transport and application. Don't confuse the "theoretical" layer with practice. Also, a MAC address is L2 and an IP address is L3; people often mix them up.

Short answer: Almost certainly not. Linux deliberately fills “spare” memory with page cache — it is handed back to applications instantly. Look at the available column, not free; real memory pressure shows up as swap-in and major page faults.

In depth:

Metric	What it means	Worry?
free	memory occupied by nothing at all	no — near zero on a healthy server
buff/cache	page cache: file and block cache	no — evicted on demand
available	what can really be handed out without swapping	yes, if it steadily heads to zero

1. Empty memory is wasted memory — the kernel caches disk so repeated reads come from RAM instead of the device.
2. Real signs of pressure — growing si in vmstat 1 (swap-in), major page faults, OOM-killer entries in dmesg.

free -h       # watch available, not free
vmstat 1 5    # si/so columns — is active swapping happening

⚠️ Common mistake: “no free memory — let’s reboot” or dropping caches via drop_caches. Page cache is a feature: clearing it only slows the system down until it warms up again.

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:

	L4	L7
Sees	IP:port, SYN	method, path, headers, cookies
Routing	round-robin/hash over flows	/api → one pool, /static → another
Retries & timeouts	none — can't tell where a request ends	per-request retries, circuit breaking
TLS	passthrough only	termination, X-Forwarded-For
Cost	near zero, millions of pps	HTTP parsing: CPU and latency

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.

Namespace	What it isolates
pid	process tree: its own PID 1 inside
net	network stack: interfaces, routes, its own ports
mnt	mount points, its own rootfs
uts	hostname and domainname
ipc	System V IPC, POSIX queues
user	UID/GID mapping: root inside ≠ root outside
cgroup	the visible cgroup hierarchy

⚠️ 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.