What a DevOps Internship Actually Expects You to Know About Networks

Most candidates arrive for a DevOps intern interview with a strong grasp of code, CI/CD, and container build files, and only a vague memory of the networking course from the first year of their degree. That mismatch is not your fault. Modern development tools abstract away TCP, DNS, and routing so cleanly that you can ship for months without ever looking at a packet. The team interviewing you knows that, and they are not expecting a network engineer. They are expecting someone who can reason about the layer underneath their code when it misbehaves, and that expectation shapes the questions you will actually get.

This guide walks through what a DevOps internship genuinely expects on the network side: which topics get tested at which depth, what level of understanding clears the bar, what you can safely learn on the job, and the troubleshooting and documentation habits that turn an intern into a relied on member of the on call rotation. If you study the wrong things, you will spend weeks on routing protocol timers nobody will ask about. If you study the right things, you will walk into the interview able to answer the network questions that separate candidates.

The Network Is the Interview Filter

DevOps is the discipline where code and operations touch, and the network is the medium both of them run on. Even though interns rarely touch switch or router configuration, deployments, container traffic, DNS resolution, and alerting all assume the network behaves. Interviewers therefore use network questions as a filter for how you think: can you localize a failure to a layer, or does everything look like an application bug to you? The strongest signal is a candidate who can say “that looks like DNS, here is how I would prove it” rather than someone who knows every flag of ip but cannot structure a search.

The expectations follow a clear shape. IP addressing and CIDR math get drilled because they are the language of every subnet, VPC, and pod pool you will touch. DNS and ports are tested heavily because they sit behind most “production is down” incidents on modern stacks. VLANs and segmentation earn middle tier questions because container and cloud networking both assume you understand isolation boundaries. Deep routing protocols like BGP and OSPF, and low level switching details, are the topics that anchor a CCNA, and a DevOps internship will not reach them on day one.

Layer 3 Math and the Boundary You Must See

The most repeated network question in DevOps intern interviews is “how many usable addresses are in a /23” or “why can the web subnet not reach the database subnet”. Both reduce to the same core idea: the boundary between switching and routing. Layer 2 moves frames between devices on the same segment by MAC address, which is what VLANs carve up. Layer 3 moves packets between different segments by IP address through a gateway. A host on 10.0.1.0/24 cannot reach a host on 10.0.2.0/24 directly; the traffic must be routed, and in modern stacks that routing is implicit in a VPC route table, a Kubernetes service, or a load balancer.

CIDR math is the arithmetic you will use weekly, so make it fast. A /24 prefix leaves 8 host bits: 2 to the 8th is 256 total addresses, minus the network and broadcast address leaves 254 usable. A /23 doubles that to 510 usable, and every bit you shrink the prefix doubles the block again. If an interviewer asks you to carve up 10.0.0.0/16, the answer is 256 possible /24 subnets, and you should know the private ranges by heart: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Nearly every internal network you ever touch will live inside one of those three blocks.

The same math shows up in places that do not look like Ethernet. A VPC has a CIDR. A Kubernetes pod pool has an allocation range. A cloud subnet is a prefix carved out of the VPC block. When you say “the app subnet is nearly exhausted”, you are doing the same two to the n arithmetic on a cloud reservation. That is why interviewers respect it: the ability to reason about address space transfers directly to the infrastructures you will actually operate.

DNS and DHCP Run Hidden Under Everything

DNS is the cause of more “the network is down” alarms than any hardware fault, because it is the first thing almost every client does: turn a hostname into an address. You should be able to explain the resolution chain from memory. The browser and OS caches, the stub resolver, the recursive resolver, and the authoritative servers that hold the zone. You should know that A records map names to IPv4, AAAA to IPv6, CNAME points one name at another, and MX tells mail where to go. And you should be able to check any of it with dig, not by opening a third party website.

DHCP is the quieter sibling. In a server world it mostly cares for switches, baseboard controllers, and out of band management, but anywhere clients exist it is the piece handing out addresses, and a misconfigured pool makes devices fail mysteriously: they have an address but no DNS server, or a lease that collides with a reservation. The practical lesson for an intern is that “there is no network” is rarely a single answer. Train yourself to ask whether the symptom lives at the DNS layer, the DHCP layer, the routing layer, or the application, because each has different commands and different failure signatures.

Ports, Firewalls, and Load Balancers

After DNS, the next most common production incident is a port that should accept traffic and does not. Learn the common ones by heart: 22 for SSH, 80 and 443 for HTTP and HTTPS, 3306 for MySQL, 5432 for Postgres, 6379 for Redis, 2379 for etcd in Kubernetes clusters. The interview question is usually a scenario: “the frontend cannot reach the API, what do you check?” The answer sequence is the same every time: does DNS resolve, does the route exist, is the port open on the target, and does the firewall allow the traffic. Knowing the order is what makes you methodical instead of lucky.

Firewalls and load balancers are where you will spend real time. Security groups in cloud environments are stateful: if you allow outbound traffic, the return traffic is implicitly allowed. Network ACLs are stateless, and you must allow both directions explicitly. Load balancers come in two flavors that matter. Layer 4 balancers forward TCP by destination port and IP, while Layer 7 balancers terminate the connection, understand HTTP, and route on paths and headers. A Layer 7 balancer is also where TLS termination happens, which means the certificate lives there, not on every backend.

Trace that path until it is second nature. A browser resolves “app.internal”, the DNS answer points at the load balancer’s virtual IP, the balancer picks a healthy backend from the pool and forwards on a private range, and the backend reaches the database only over the path the security rules allow. When a service is “unreachable”, the load balancer health check is usually the fastest diagnostic: it answers whether the pool thinks the backend is up, which is a different question from whether the backend is actually up.

Containers and Cloud Made Segmentation Your Job

Segmentation used to be a physical network concern: split a campus into VLANs so departments do not see each other’s traffic. Modern DevOps contexts have simply renamed the same idea and made it routine. A VLAN is a Layer 2 isolation boundary enforced on switch ports. A cloud VPC’s subnets are Layer 3 segments with route tables and security groups. A Kubernetes namespace with network policies is a policy boundary over pods that share one flat pod network. The concept is consistent: separate workloads, then control which segments may talk to each other. As an intern, your job is to understand the concept deeply enough that the vendor names stop mattering.

That is exactly why the map matters, because odds are your first task involves inheriting a list of networks nobody fully remembers. Before you can reason about segmentation you need the documented map: which range is the web segment, which is the database segment, which prefix is already exhausted, and whether a new service can share a segment. An intern who can answer those questions from a record instead of from tribal memory is useful from day one.

The Five Tools That Make You Useful Fast

Interviews respect tools you can operate from memory, and the list of network tools a DevOps intern is expected to know is short. dig answers DNS questions. ping and traceroute answer reachability and path questions. nc checks whether a port is open, and ss shows who is listening. curl exercises the HTTP layer with control over method and headers. tcpdump shows the packets themselves. Each one answers a specific question, and the skill is not memorizing flags, it is knowing which question to ask next.

The habit interviewers actually screen for is sequential diagnosis: observe the symptom, run the cheapest test for the most likely cause, and let the result pick the next test. When curl to a service fails, resolve the name first, because a DNS failure produces a completely different error than a timeout or a connection refused, and every message names its layer. If you practice this flow on your own stack, even a laptop with two containers, the interviewer will hear you think in layers instead of guess, and that is the difference between a candidate who knows commands and one who can operate.

The Documentation Habit That Separates Strong Interns

The network skill most overlooked in interview prep is documentation, and it is the one teams reward most once you start. Nobody expects an intern to memorize a fleet’s address space. They expect you to be able to find answers: which subnet does the payments service sit in, what IP does the database accept connections on, how is that circuit patched. Teams with a maintained source of truth let you look those up in seconds. Teams without one burn your first two weeks rediscovering everything, and the difference shows up in whether you contribute from day one or spend it asking where things live.

You can practice this habit before you get the job. Build a small lab early, then keep a record of everything you create: an IP address management list of what you allocated, a network topology diagram of how your devices connect. It feels like overhead until the first time a project breaks and you find the fault in minutes because the record told you what should be there. That is the habit teams hire for: not memorizing the network, but keeping an accurate record of what is true.

Practice the Skill the Interview Tests

If you can build a small network, understand why traffic moves the way it does, troubleshoot it methodically in the right order, and keep documentation accurate enough to survive contact with reality, you will be more prepared for a DevOps internship than someone who memorized routing protocol timers. The fundamentals in this guide are learnable in a weekend of hands on practice, while the documentation habit takes the longest to build, which is exactly why starting it now is the advantage.

Practice that habit in your homelab: allocate subnets, lay out your segments, document each device, and map how everything connects. Keeping that documentation current as the network evolves is one of the best ways to turn the theory you just read into experience you can describe in an interview. Put your subnets, devices, and topology in one place from the start, and document your homelab with Obelinf beginning with the first device you configure.