Page 1 of 2
Not all load balancers operate at the same layer, and the distinction has real operational consequences. An L4 load balancer works at the transport layer - it looks only at IP addresses and ports, forwarding raw TCP or UDP traffic without inspecting the content at all. It's fast and protocol-agnostic, but it can't make decisions based on anything inside the request, like a URL path or a header.
An L7 load balancer operates at the application layer - it actually parses HTTP, which means it can route based on path (/api to one service, /static to another), host header, or cookie value. That flexibility costs more processing overhead per request, and it means the load balancer itself needs to understand your application protocol, not just move bytes.
Session persistence (sticky sessions) is where this gets operationally tricky: some apps store session state in server memory rather than a shared store, so a user needs to keep hitting the same backend for their session to keep working. A load balancer can enforce this via a cookie or client IP hash - but sticky sessions actively work against even load distribution, and they turn "a server needs to be taken out of rotation" into "some users lose their session," which is exactly the failure mode you were trying to avoid by load balancing in the first place. The more resilient fix is almost always to move session state out of the server and into a shared store (Redis, a database) so any backend can serve any request - sticky sessions are a workaround, not a solution.
A single certificate is easy to manage by hand. A hundred services, each with its own certificate, is not - and certificate expiry is one of the most common, most entirely preventable causes of production outages, precisely because nothing "changes" the day it happens; a cert that was fine yesterday just stops being valid, all at once, everywhere it's used.
Let's Encrypt and the ACME protocol changed the calculus here by making certificate issuance and renewal fully automatable - tools like certbot or ingress controllers can request, validate, and renew certificates with no human in the loop, typically well before the (often 90-day) expiry window. The operational tradeoff for that automation is that renewal now has more moving parts that can silently fail: a DNS validation step that starts failing, a rate limit hit during a burst of renewals, an automation job that stops running and nobody notices for months.
The practical mitigation is monitoring the certificate itself, not just the automation that's supposed to renew it - alerting on days-until-expiry directly, independent of whether the renewal system reports success, catches the case where the automation claims to have worked but didn't. At real scale, this usually means a certificate management layer (like cert-manager in Kubernetes) that treats certificates as declarative, continuously-reconciled resources rather than one-off files somebody generated manually and will eventually forget about.
Security groups (or equivalent constructs across clouds) are stateful firewalls attached to individual resources rather than a whole network perimeter, and the shift in thinking they require is significant: instead of one big wall around everything, every resource carries its own explicit rule set about what can reach it.
The production discipline that matters here is segmentation - deliberately restricting what can talk to what, even inside your own network, rather than treating "internal" as automatically trusted. A database tier should only accept connections from the application tier that needs it, not from every other server in the account. This limits blast radius: if one service is compromised, segmentation is what stops that compromise from being able to freely reach everything else, rather than just everything outside the perimeter.
A concrete practice worth internalizing: security group rules should reference other security groups, not hardcoded IP ranges, wherever possible. "Allow traffic from the app-tier security group" survives autoscaling, redeploys, and IP changes; "allow traffic from a specific instance's IP" silently breaks the moment that specific instance is replaced.
A DDoS (Distributed Denial of Service) attack floods a target with traffic from many sources at once, aiming to exhaust some resource - bandwidth, connection slots, CPU handling requests - so legitimate traffic can't get through. Mitigating this isn't one technique, it's layered defense at multiple levels simultaneously.
At the network edge, providers absorb and filter volumetric attacks (sheer traffic volume) before they ever reach your infrastructure - this is largely why CDNs and cloud DDoS protection services exist as a first line of defense, since they have far more absorbable capacity than a single origin server ever could. Below that, rate limiting and connection limits protect against smaller, more targeted floods that make it past the edge. At the application layer, the concern shifts to attacks that look like legitimate but expensive requests - a search endpoint that triggers a heavy database query, hit thousands of times a second, can take a service down with a traffic volume that wouldn't register as unusual at all.
The operational reality worth internalizing: you can't fully prevent an attack from being attempted, only limit its ability to actually degrade service - which is why this is architected as absorb-and-filter at every layer, not a single control you can just turn on.
Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.