Cybersecurity and network engineer interview questions

Two tracks, one set of fundamentals

Cyber security analyst interview questions and network engineer interview questions overlap more than the job titles suggest, because both roles read the same traffic. The split is what you are expected to do with it.

The US Bureau of Labor Statistics describes information security analysts as planning and carrying out security measures to protect an organization’s computer networks and systems, with duties that include monitoring networks for security breaches and investigating when one occurs, checking for vulnerabilities, and preparing reports that document attempted attacks and breaches. A network support or engineering role, in the same handbook, is framed around analyzing, troubleshooting and maintaining computer networks. So a security interview leans toward detection, evidence and risk; a network interview leans toward design, routing and fault isolation.

Both rounds open with rapid-fire fundamentals, because they are cheap to ask and hard to bluff. Information security interview questions then move to policy and process, while network interviews move to topology and troubleshooting. If the advert names a certification track such as CCNA, expect its vocabulary: addressing, switching, routing, access control lists and basic security features, asked as plain questions rather than exam items.

Networking fundamentals, answered precisely

The OSI model has seven layers: physical, data link, network, transport, session, presentation and application. The practical point to add is that troubleshooting runs bottom-up: cable and link, then addressing, then reachability, then the application.

TCP against UDP is the next near-certain question. TCP sets up a connection, numbers its bytes, retransmits what is lost and controls its sending rate; UDP sends datagrams with none of that, which is why it suits DNS queries, voice and video, where a late packet is worse than a missing one. The TCP connection opens with a three-way handshake: the client sends SYN, the server replies SYN-ACK, the client answers ACK. A graceful close uses FIN and ACK in each direction.

DHCP is the four-step exchange often called DORA: discover, offer, request, acknowledge, carried over UDP. DNS resolution is worth describing as a chain: the stub resolver on the host asks a recursive resolver, which, if nothing is cached, walks from a root server to the top-level domain servers to the authoritative server for the zone, and each answer is cached for its time to live. That TTL sentence is the reason for most “it works for me but not for them” reports.

Finish with the layer pairs. A switch forwards frames at layer two using MAC addresses, a router forwards packets at layer three using IP, and ARP connects the two by resolving an IP address to a MAC address inside one broadcast domain. VLANs cut one physical switch into separate broadcast domains, with 802.1Q tags carrying the VLAN across trunk links. NAT rewrites private addresses to a public one on the way out, and port translation lets many hosts share a single public address. Know the common ports as plain facts: 22 for SSH, 53 for DNS, 80 and 443 for HTTP and HTTPS, 3389 for RDP.

The subnetting question

Hard networking interview questions usually include arithmetic on a whiteboard: given 192.168.10.37/26, what is the network address, the broadcast address and the usable host range?

Do it in blocks rather than binary. A /26 takes two bits from the last octet, so the mask is 255.255.255.192 and the space is cut into blocks of 64: 0, 64, 128 and 192. The address 37 sits in the first block, so the network is 192.168.10.0, the broadcast is 192.168.10.63, and usable hosts run from .1 to .62, which is 62 of the 64 addresses once network and broadcast are set aside. You can check your own examples beforehand without binary arithmetic.

import ipaddress

net = ipaddress.ip_network("192.168.10.37/26", strict=False)
print(net)                    # 192.168.10.0/26
print(net.network_address)    # 192.168.10.0
print(net.broadcast_address)  # 192.168.10.63
print(net.num_addresses)      # 64, of which 62 are usable host addresses

The follow-up is usually private ranges, so have them exact: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. The 172 range is the one people get wrong, because it stops at 172.31.255.255, so 172.32.0.0 is public. Asked to carve a /24 for four sites of about 50 hosts, give the answer with the reason: four /26 blocks, 62 usable addresses each.

Security fundamentals and the vocabulary interviewers check

Expect to define the CIA triad and to use it as a frame rather than a recital: confidentiality is who may read the data, integrity is whether it is unaltered and provably so, availability is whether it is there when needed. Ransomware is a useful example, because it attacks all three at once.

Authentication is proving who you are, authorization is what you may then do. Hashing and encryption are not interchangeable: a hash is one-way and used to verify, encryption is reversible with the right key and used to protect. For stored passwords, the expected answer is a purpose-built slow hash with a per-user salt, such as bcrypt, scrypt or Argon2, not a fast general-purpose digest. Symmetric encryption uses one shared key and is fast; asymmetric encryption uses a key pair and solves the problem of agreeing that shared key, which is what a TLS handshake does before switching to symmetric encryption for the session.

For application risks, the OWASP Top 10 is the common reference, and the 2025 edition leads with A01 Broken Access Control, A02 Security Misconfiguration and A03 Software Supply Chain Failures, with Injection at A05. Naming three of them correctly, and saying what you would check for one, is worth more than listing all ten vaguely. Round it out with the principles interviewers want to hear applied: least privilege, defence in depth, patch and asset inventory discipline, and multi-factor authentication on anything exposed to the internet.

Cyber security interview questions for freshers often stop at this vocabulary. The way to stand out is to attach each definition to something you have done, even in a home lab: a firewall rule you wrote, a phishing email you analysed, a packet capture you read.

Alert triage and incident scenarios

The analyst scenario is the heart of a SOC interview. An alert says a user logged in from two countries within an hour, or a workstation contacted a domain registered yesterday. What do you do?

Answer in order, and say the order out loud. Establish what the alert actually detected and how reliable that detector is. Gather context: whose account, which asset, what else happened around that timestamp, whether this is normal for that user. Form a hypothesis, then look for evidence that would disprove it, which is the habit separating triage from guessing. Decide inside your mandate: close as benign with a note, enrich and escalate, or contain the host. Then write it up so the next analyst can follow your reasoning, which is the part candidates forget to mention.

It helps to show you know this is a documented discipline rather than improvisation. NIST publishes incident response recommendations as SP 800-61 Revision 3 (April 2025), which frames incident handling inside the wider risk management cycle: prepare, reduce how often incidents happen and how much damage they do, then improve detection, response and recovery. On containment, state the trade-off honestly: pulling a machine off the network destroys live evidence, leaving it connected risks spread, and the call depends on the asset and on who has the authority to make it.

Network troubleshooting scenarios

Network rounds test fault isolation with a vague complaint: a site is slow, a link drops every afternoon, one subnet cannot reach a server. The structure of a good answer is always the same, namely cut the problem in half and prove which half is broken.

Start with the scope question. One user, one subnet, or everyone? One destination or all of them? That single question eliminates most causes before you touch a device. Then test by layer: link and interface errors, then addressing and gateway, then name resolution, then the path, then the application. Checking name resolution separately from connectivity matters, because an address that resolves but does not answer and a name that fails to resolve look identical to the user.

For path problems, traceroute sends packets with increasing time-to-live values and reads the time-exceeded replies from each hop, which shows where the path stops but not always why; many routers de-prioritize those replies, so one slow hop with normal results after it is usually noise. Be ready for maximum transmission unit trouble too: when large packets disappear but small ones succeed, suspect a lower MTU on the path and filtered ICMP preventing path MTU discovery from signalling it. On the physical side, mention interface error counters, duplex mismatches on older links, and the repeated up and down transitions that mark a flapping interface. When the hypotheses run out, capture at both ends and compare what each side actually sent.

How to prepare, and the questions that are not technical

Build a small lab and break it on purpose. Two virtual machines, a firewall rule, a DNS server and a packet capture teach you more interview-ready detail than a question bank, because the stories you tell will be your own. Write down three faults you have fixed, however small: what happened, what you checked, what it turned out to be.

Then prepare the non-technical half, where security candidates most often lose offers. Expect questions about a user who refuses a control, about reporting something that makes a colleague look bad, and about what you do when you are not certain. Answer with specifics and without disparaging anyone. Security teams hire for judgement and for the ability to write a clear note at the end of a long night.

If your route into security runs through the service desk, that experience is an asset rather than a gap, since triage, documentation and user communication are the same skills under another name; the IT support interview questions page covers that side. Keep one honest sentence ready about the part of the field you are weakest in and what you are doing about it. It gets asked more often than people expect.