24 network security interview questions and answers

Fresher to mid-level · 24 questions with answers

Network security answers should explain how traffic moves, where a control acts and what evidence would support your conclusion. This Cyber Shikshaa guide contains 24 core questions and three FAQs for learners in India. Examples are synthetic, not claims about candidate experience. Practise only on owned or explicitly authorised systems, and describe lab work honestly. Reviewed 12 October 2026.

By Cyber Shikshaa · Reviewed · Educational guidance, not legal advice.

Reading isn't practising

You'll answer these out loud, under time pressure, with an interviewer asking follow-ups. Do a free 5-question AI mock interview and get scored feedback in minutes — no card needed.

Start free mock interview

How to use these answers

  • Start with the mechanism, explain its security purpose, and finish with one limitation or trade-off.
  • Use the synthetic examples to plan an authorised lab; do not present them as projects you completed.
  • Name the evidence you would check, such as TCP flags, firewall decisions, VPN counters or endpoint events.
  • Separate an observation from a conclusion: repeated SYN packets show retries, not automatically an attack.
  • If you are unsure, explain how you would verify the claim safely rather than guessing.

Protocols and fundamentals

Use protocol behaviour to explain controls. OSI labels and product names are useful shorthand, but packet fields, policy decisions and endpoint evidence provide stronger explanations.

1.How does the OSI model help explain where security controls operate?

Practice this with AI
Show model answer

The OSI model describes seven layers: physical, data link, network, transport, session, presentation and application. Use it as a troubleshooting framework rather than a literal map of every implementation. Switch controls can restrict local link behaviour; IP rules filter network addresses; transport rules examine ports and connection state; application controls interpret requests. TLS sits above transport in common web stacks rather than fitting neatly into one OSI layer. Layered controls provide different evidence and protections, but add complexity. A permitted TCP connection does not prove the application request is authorised.

Worked example: In an isolated two-VM lab, allow TCP 443 but configure the test application to reject an unauthorised account. Expect a completed connection followed by an application denial, demonstrating separate enforcement layers.

Common mistake: Assigning every product to exactly one OSI layer obscures overlapping inspection capabilities and confuses network connectivity with application authorisation.

Follow-up: What evidence would distinguish a TCP connection failure from an HTTP authorisation failure?

2.How does the TCP three-way handshake work, and what can go wrong?

Practice this with AI
Show model answer

A client sends SYN with an initial sequence number, the server replies with SYN-ACK, and the client acknowledges the server's sequence number. This establishes synchronised connection state; it does not authenticate either application. A SYN flood can consume half-open connection resources when replies are not completed. SYN cookies defer allocating some state until a valid acknowledgement arrives, reducing that particular pressure. They do not solve upstream bandwidth exhaustion or every connection attack. Backlog tuning, rate controls and upstream protection have different trade-offs, including legitimate traffic loss when thresholds are too aggressive.

Worked example: Capture one connection between owned lab VMs using 192.0.2.10 and 192.0.2.20 on an isolated network. Expect SYN, SYN-ACK and ACK; compare retransmissions after a deliberately configured firewall drop.

Common mistake: Treating every repeated SYN as a flood ignores packet loss, blocked return paths and ordinary client retries during service outages.

Follow-up: How would your capture differ if the destination port were closed rather than silently filtered?

3.How does DNS resolution work, and which protections address different DNS attacks?

Practice this with AI
Show model answer

A client usually asks a recursive resolver, which uses cached answers or follows referrals through root, top-level-domain and authoritative servers. Attackers may forge responses, abuse compromised DNS administration, generate excessive queries or encode data in names. DNSSEC authenticates signed DNS data when validation succeeds; it does not encrypt queries. DoH and DoT encrypt transport to the resolver, but do not make a malicious domain safe. Analyse query patterns alongside endpoint activity and approved resolver policy. High-entropy names can indicate tunnelling, but legitimate software also generates them, so blocking on appearance alone risks disruption.

Worked example: Use an owned resolver and a locally configured example.test zone. Compare ordinary queries with synthetic random labels. Expect different name patterns, but no justified exfiltration conclusion without corroborating endpoint evidence.

Common mistake: Claiming DNSSEC or encrypted DNS prevents all DNS abuse confuses answer authenticity, transport confidentiality and the trustworthiness of requested destinations.

Follow-up: Which endpoint evidence would help distinguish DNS tunnelling from a legitimate telemetry agent?

4.What is ARP spoofing, and what are the limits of its defences?

Practice this with AI
Show model answer

ARP maps an IPv4 address to a link-layer address on a local network. Because ordinary ARP lacks authentication, forged messages can persuade a host to associate a gateway address with the wrong MAC address. This may redirect traffic or cause denial of service. Dynamic ARP inspection checks bindings, often learned through DHCP snooping, but static-address environments need suitable trusted bindings and careful configuration. Port security alone does not authenticate every IP-to-MAC claim. Correctly validated TLS still protects application confidentiality and integrity, although an on-path attacker can disrupt connections and observe some metadata.

Worked example: On an isolated owned switch, compare the gateway binding with DHCP snooping records and ARP inspection logs. A deliberately inconsistent test binding should produce an inspection denial rather than accepted traffic.

Common mistake: Assuming encryption makes local network manipulation harmless overlooks availability attacks, exposed metadata and applications that fail to validate peer certificates correctly.

Follow-up: How would you protect a static-address printer without accidentally breaking its ARP traffic?

5.How is NAT different from a firewall?

Practice this with AI
Show model answer

Network address translation rewrites addresses and, with port translation, transport ports, maintaining mappings so replies reach the correct internal host. A firewall decides whether traffic is permitted under policy. Dynamic NAT often prevents unsolicited inbound connections when no mapping exists, but this behaviour is not a substitute for explicit access rules. Static mappings and port forwarding can expose services. NAT also complicates attribution because investigators need translation records and timestamps to identify an internal source. Firewalls and NAT frequently share an appliance, but separating their functions makes policy review and troubleshooting more reliable.

Worked example: In an isolated gateway lab, publish a test service through a static mapping, then deny it with a firewall rule. Expect the mapping to exist while the policy still blocks connection attempts.

Common mistake: Treating a private address as proof of protection ignores outbound threats, forwarded services and the actual policy enforced at network boundaries.

Follow-up: Which records would you need to identify a host behind a shared translated address?

6.How does a proxy improve security, and what visibility does it lack?

Practice this with AI
Show model answer

A forward proxy mediates client requests, while a reverse proxy fronts servers. Depending on its configuration, it can authenticate users, restrict destinations, enforce request limits and record transactions. An HTTPS tunnel may expose connection metadata without revealing encrypted request content. TLS interception creates separate TLS connections and requires managed trust, careful key protection and explicit organisational approval. It may break certificate pinning or mutual TLS and introduces privacy concerns. Proxy logs cover only traffic that actually traverses the proxy, so combine them with endpoint and network records rather than assuming complete outbound visibility.

Worked example: Configure an owned browser to use a lab proxy for example.test. Compare a CONNECT tunnel log with an authorised reverse-proxy request log; expect different detail about paths and response status.

Common mistake: Promising that a proxy logs every outbound request ignores bypass routes, encrypted tunnels, unsupported protocols and applications with independent networking settings.

Follow-up: What could you investigate from CONNECT metadata when HTTPS content inspection is unavailable?

Encryption in transit

Distinguish authentication, key agreement and record encryption. Explain which secrets protect a connection and which failures encryption cannot address.

1.How does a typical certificate-authenticated TLS 1.3 handshake work?

Practice this with AI
Show model answer

The client sends ClientHello with supported parameters and usually a key share. The server selects parameters in ServerHello, and both sides derive handshake secrets from their key agreement. In a certificate-authenticated handshake, the server sends its certificate chain and uses CertificateVerify to sign the handshake transcript, demonstrating possession of the corresponding private key. The client checks trust, identity and validity; Finished messages verify the transcript using derived secrets. Application traffic then uses symmetric authenticated encryption. TLS 1.3 does not use RSA key transport. Encryption protects transit, not compromised endpoints or malicious application responses.

Worked example: Connect an owned client to a lab TLS 1.3 server for example.test with a trusted lab certificate. Expect visible hello messages, followed by encrypted handshake records rather than a plaintext certificate.

Common mistake: Describing TLS 1.3 as encrypting a session key with the server's RSA public key repeats an obsolete key-transport explanation.

Follow-up: What does CertificateVerify prove that merely receiving a certificate does not?

2.What does forward secrecy protect, and what does it not protect?

Practice this with AI
Show model answer

Forward secrecy means later compromise of a long-term authentication key should not reveal previously recorded session contents, provided ephemeral secrets were generated securely and erased. Ephemeral Diffie-Hellman key agreement supports this because session secrets are not recoverable from the certificate private key alone. TLS 1.3 certificate-based connections use this model, but PSK-only modes and early data have different properties. Forward secrecy does not protect sessions when an endpoint exposes live traffic secrets or plaintext. The trade-off includes key-agreement computation and operational complexity when troubleshooting encrypted traffic without weakening production secret handling.

Worked example: In an owned TLS lab, inspect negotiated key exchange and compare it with server certificate type. Expect an RSA certificate to coexist with ephemeral key agreement; certificate type alone does not establish forward secrecy.

Common mistake: Equating forward secrecy with immunity to key theft overlooks live session secrets, endpoint compromise and the special risks of early data.

Follow-up: Why might a captured session remain confidential after certificate-key theft but not after traffic-secret theft?

3.How should you compare IPsec VPNs with TLS-based VPNs?

Practice this with AI
Show model answer

IPsec protects IP traffic and commonly connects gateways or remote clients. TLS-based VPN products use TLS for some connection functions and may offer browser application access, a full network tunnel or another data transport. Therefore, IPsec does not inherently mean broad access, and TLS does not inherently mean application-only access. Compare supported applications, authentication, device posture, routing, gateway exposure and least-privilege enforcement. TLS-based access can be convenient on restrictive networks, while IPsec supports many network-to-network designs. Both require patching and careful policy; tunnel encryption cannot make an unmanaged or compromised endpoint trustworthy.

Worked example: Give a lab user access only to an owned example.test application through two test access designs. Expect the permitted workflow to succeed and unrelated internal services to remain unreachable in both.

Common mistake: Assuming the VPN protocol determines access scope overlooks gateway policy, route configuration and products that provide both application and network access.

Follow-up: Which controls would keep a contractor's VPN session limited to one application?

4.How do IPsec transport mode, tunnel mode, AH and ESP differ?

Practice this with AI
Show model answer

In transport mode, IPsec protects the upper-layer payload while retaining the original IP header for routing. In tunnel mode, the original IP packet is encapsulated inside a new outer packet, which suits gateway connections. ESP commonly provides confidentiality and integrity with authenticated encryption, although its exact protections depend on the negotiated configuration. AH provides integrity and origin authentication without confidentiality and is problematic across address translation because it authenticates selected IP-header fields. Encapsulation adds overhead and can expose MTU problems. Neither mode hides the outer endpoints or automatically restricts which internal services peers may reach.

Worked example: Inspect captures on the inner and outer interfaces of owned tunnel endpoints. Expect original application addresses inside the tunnel and gateway addresses outside, with ESP or UDP-encapsulated ESP protecting the inner packet.

Common mistake: Saying IPsec always encrypts everything ignores visible outer headers, AH's lack of confidentiality and the negotiated properties of individual security associations.

Follow-up: Why might small packets cross an IPsec tunnel while larger application transfers stall?

5.How would you manage certificate expiry across many services?

Practice this with AI
Show model answer

Maintain an inventory linking certificates to service owners, endpoints, issuers, renewal methods and dependencies. Automate issuance and renewal where supported, using ACME or an appropriate internal PKI workflow, but also verify deployment and service reloads. Monitor the certificate actually presented by each endpoint rather than trusting a successful renewal job. Shorter lifetimes reduce exposure from lost keys but make reliable automation more important. Protect private keys, restrict issuance privileges and plan revocation or replacement after compromise. Track trust-chain changes and client compatibility because an unexpired certificate can still cause an authentication outage.

Worked example: Renew a short-lived lab certificate for example.test, deliberately leaving one owned test endpoint unchanged. Expect issuance to succeed while endpoint monitoring still reports the old certificate on that instance.

Common mistake: Treating renewal success as deployment success misses stale load-balancer nodes, failed reloads and clients that cannot validate a changed certificate chain.

Follow-up: How would you verify that every load-balancer node serves the renewed certificate?

VPN, IPsec and firewall operation

Use current IKEv2 terminology, separate control-plane success from data-plane delivery, and explain firewall decisions using explicit traffic flows.

1.How is an IKEv2 IPsec VPN established?

Practice this with AI
Show model answer

IKEv2 begins with IKE_SA_INIT, which negotiates algorithms and exchanges Diffie-Hellman values and nonces. IKE_AUTH authenticates peers, protects identity exchanges and normally establishes the first CHILD_SA for IPsec traffic. Additional or replacement CHILD_SAs use CREATE_CHILD_SA exchanges. Traffic selectors define which traffic the negotiated associations protect, while routing and firewall policy still determine actual delivery. The IKEv1 terms phase 1, phase 2, main mode and aggressive mode describe legacy operation, not IKEv2's exchange names. Strong algorithms help, but mismatched identities, certificates or selectors can prevent service despite otherwise sound cryptography.

Worked example: Connect two owned IKEv2 gateways on an isolated network and inspect their negotiation logs. Expect IKE_SA_INIT and IKE_AUTH, followed by an installed CHILD_SA with the intended traffic selectors.

Common mistake: Explaining all modern IPsec negotiations through IKEv1 phases hides IKEv2 exchange boundaries and can send troubleshooting toward the wrong failure stage.

Follow-up: What would you check if IKE_SA_INIT succeeds but IKE_AUTH fails?

2.When would you choose site-to-site or remote-access VPN connectivity?

Practice this with AI
Show model answer

A site-to-site VPN connects networks through gateways, usually authenticating those gateways rather than every person whose packets traverse them. Remote-access VPNs connect individual devices or users and should integrate strong authentication, device checks and role-based restrictions. Choose based on the required flows, endpoint ownership and operational support rather than assuming one model is always safer. Application-specific access can reduce broad network exposure, but cannot replace every legacy protocol or network dependency. Zero trust is an architectural approach to explicit, contextual access decisions, not a product or proof that every VPN should be removed.

Worked example: Model an owned branch subnet and a separate contractor device in a lab. Expect gateway policy to restrict branch flows, while the contractor receives only the explicitly authorised application access.

Common mistake: Treating a site-to-site tunnel as authentication of every internal user grants excessive trust to compromised hosts behind an otherwise legitimate gateway.

Follow-up: How would you prevent a compromised branch workstation from reaching central management interfaces?

3.What is split tunnelling, and how should its risks be evaluated?

Practice this with AI
Show model answer

Split tunnelling sends selected destinations through a VPN while other traffic uses a local route. It can reduce gateway load and improve latency, but internet-bound traffic may bypass central inspection and logging. A device is not automatically a network bridge merely because it has both routes; actual forwarding, endpoint compromise and access policy matter. Full tunnelling centralises more traffic but adds capacity, privacy and availability considerations. Evaluate application sensitivity, DNS routing, endpoint controls and local-network access. Test IPv4 and IPv6 paths because a policy that covers only one family can create unintended bypasses.

Worked example: On an owned VPN client, inspect routes and capture traffic to an internal test service and example.test. Expect each destination to follow its configured path, including any separately configured IPv6 route.

Common mistake: Calling every split-tunnel endpoint a bridge confuses simultaneous connectivity with forwarding and distracts from verifiable routing, endpoint and access-policy risks.

Follow-up: How would you detect DNS requests leaving through an unintended local resolver?

4.How do stateful and stateless firewalls differ in practice?

Practice this with AI
Show model answer

A stateless firewall evaluates individual packets against fields such as addresses, protocol and ports, without remembering a connection. A stateful firewall maintains flow information and can admit return traffic associated with a permitted session. For UDP, this is usually time-limited flow tracking rather than a TCP-style handshake. State tracking simplifies many policies but consumes resources and can fail when asymmetric routing hides part of a conversation. Neither approach automatically understands application authorisation. Stateless filtering remains useful for simple boundary rules and high-volume controls, while stateful inspection requires appropriate capacity, timeouts and routing design.

Worked example: In an owned firewall lab, allow a client-initiated connection and inspect the session table. Expect tracked return packets to pass, while an unrelated inbound connection still requires its own policy permission.

Common mistake: Assuming stateful inspection authenticates application requests mistakes connection tracking for user identity, business permissions and validation of the traffic carried inside.

Follow-up: What symptoms would asymmetric routing create on a stateful firewall?

5.How would you design firewall rules for a web application in a DMZ?

Practice this with AI
Show model answer

Start with documented application flows and deny traffic that has no approved purpose. Permit public HTTPS to the intended entry point, then narrowly allow required connections between web, application and database tiers. Restrict administration to an approved management path with strong authentication. Include necessary DNS, time synchronisation, updates, health checks and monitoring rather than blindly blocking dependencies. Limit outbound access to reduce abuse after compromise. Associate rules with owners and review dates, and test both allowed and denied paths. Logging supports verification, but indiscriminate deny logging can overwhelm storage and hide useful signals.

Worked example: Build an isolated three-tier lab with a management host. Expect HTTPS to the front end and the documented application-to-database flow to succeed, while direct client-to-database and public management connections fail.

Common mistake: Writing only inbound rules leaves compromised servers with unrestricted outbound access and often overlooks dependencies needed for reliable operation and monitoring.

Follow-up: How would you permit software updates without granting the DMZ unrestricted internet egress?

6.Why does IPsec use NAT traversal?

Practice this with AI
Show model answer

Native ESP is an IP protocol without TCP or UDP ports, which complicates tracking and multiplexing through many NAT devices. IKEv2 detects address or port translation during negotiation and commonly uses UDP encapsulation for ESP on port 4500. This provides a transport that NAT devices can map, while keepalives can help preserve mappings. Address translation does not generally invalidate ESP tunnel-mode integrity because the outer IP header is not included in that protection; AH has different difficulties. NAT traversal improves reachability but cannot bypass every restrictive firewall, captive portal or incorrect gateway configuration.

Worked example: Place an owned VPN client behind a lab NAT gateway and compare outer-interface captures with gateway logs. Expect IKE traffic and, after NAT detection, UDP-encapsulated protected traffic on port 4500.

Common mistake: Saying NAT always breaks ESP integrity confuses ESP's protected fields with AH and overlooks the separate problem of translating portless traffic.

Follow-up: What evidence would distinguish a blocked UDP 4500 path from failed peer authentication?

7.How would you investigate a VPN that is established but carries no useful traffic?

Practice this with AI
Show model answer

An established IKE association proves control-plane progress, not successful delivery of the intended application flow. Define one failing source, destination, protocol and timestamp, then verify the relevant CHILD_SA and selectors. Trace routing, NAT and firewall decisions on both sides, including the return path. Compare encrypted packet counters and captures to locate where traffic disappears, then correlate with endpoint listeners and application logs. If small requests work but larger transfers fail, investigate MTU and path-MTU discovery. Change one variable at a time under approval; broad temporary allow rules can mask the cause and expose unrelated systems.

Worked example: In an isolated owned tunnel, remove the return route for one test subnet. Expect outbound protected counters to increase without a successful application response, with the remote capture revealing the return-path problem.

  1. Record the authorised scope, failing flow and a shared time reference before changing configuration.
  2. Confirm the matching CHILD_SA, selectors and current packet counters on both gateways.
  3. Check source routing, NAT order and firewall decisions for the exact test flow.
  4. Capture at approved inner and outer interfaces and correlate packet fields and timing with endpoint logs.
  5. Verify return routing, destination listener state and MTU behaviour; retest one approved correction and retain evidence.

Common mistake: Restarting the tunnel repeatedly before collecting counters and timestamps destroys useful context and rarely explains a persistent routing or policy error.

Follow-up: What would rising outbound encryption counters but unchanged remote decryption counters suggest?

Reading isn't practising

You'll answer these out loud, under time pressure, with an interviewer asking follow-ups. Do a free 5-question AI mock interview and get scored feedback in minutes — no card needed.

Start free mock interview

Architecture, hardening and investigation

Architecture limits reachable attack paths; investigation tests what actually happened. Preserve evidence and perform containment only within documented authority.

1.What is a DMZ, and what security boundary does it provide?

Practice this with AI
Show model answer

A DMZ is a separately controlled network zone for services exposed to less-trusted networks, commonly the internet. Policy boundaries restrict connections from that zone to internal systems, reducing reachable paths if a public service is compromised. A DMZ can use physical firewalls, virtual controls or cloud networking; two separate appliances are not mandatory. Its value comes from enforced policy rather than the label or subnet alone. Shared credentials, permissive management access and unrestricted outbound traffic can undermine isolation. Extra boundaries also add operational work, so validate dependencies and ownership instead of assuming separation guarantees containment.

Worked example: Place an owned test web server in a separate lab zone and attempt its documented backend connection plus an unrelated management connection. Expect only the explicitly permitted backend flow to succeed.

Common mistake: Calling a public subnet a DMZ without checking enforced boundaries mistakes an address arrangement for actual isolation and controlled application dependencies.

Follow-up: Which shared services could let a compromised DMZ host bypass your intended isolation?

2.How would you segment a corporate network without breaking essential work?

Practice this with AI
Show model answer

Begin with asset ownership, sensitivity and observed application dependencies, then define zones such as user devices, production services, management, guests and operational technology. Enforce explicit flows between zones using suitable network or host controls; VLAN membership alone is not an access policy. Administrative access needs stronger restrictions than ordinary application traffic. Pilot changes, observe denied dependencies and maintain an approved rollback path. Microsegmentation can reduce lateral reach but increases policy and identity-management complexity. Verify controls with positive and negative tests, and let accountable risk owners decide documented exceptions rather than silently broadening access.

Worked example: Separate owned user, server and management VMs in an isolated lab. Expect users to reach the test application but not administrative ports, while an authorised management host reaches only its approved targets.

Common mistake: Creating VLANs while allowing unrestricted inter-VLAN routing preserves most lateral access and can create false confidence in a segmented network design.

Follow-up: What evidence would justify a temporary cross-zone exception, and who should own its residual risk?

3.How would you harden a network device and verify the result?

Practice this with AI
Show model answer

Use a supported firmware release and a reviewed baseline appropriate to the device's role. Remove default credentials, disable unnecessary services, restrict management sources and use encrypted administration such as SSH or HTTPS. Apply central authentication and least privilege where supported, with a protected emergency-access method to avoid lockout during identity-service failure. Secure backups, synchronise time and forward relevant logs. Prefer authenticated, encrypted management telemetry where available. Hardening can affect compatibility and availability, so stage changes with rollback. Evidence should include effective configuration and access tests, not merely a policy document saying the device is secure.

Worked example: Harden an owned virtual router with a console rollback option. Expect management access from the approved lab host, denial from the user subnet and a corresponding central log for each tested action.

Common mistake: Disabling access methods without testing emergency recovery can turn a security change into an avoidable outage when central authentication becomes unavailable.

Follow-up: How would you prove that the management restriction is enforced rather than only documented?

4.What can a WAF do, and where must application controls take over?

Practice this with AI
Show model answer

A web application firewall evaluates HTTP requests and sometimes responses using signatures, protocol checks, rate rules or behavioural models. It can reduce exposure to common payloads and provide temporary protection while a verified application fix is deployed. It generally lacks the full business context needed to decide whether one authenticated user may access another user's record. Custom rules can mitigate selected access patterns, but they do not replace server-side authorisation. False positives can block legitimate users, while encoding differences or uninspected paths permit bypasses. Tune rules against representative traffic and verify application fixes independently using authorised tests.

Worked example: Use an owned demonstration application with two synthetic accounts. Expect a WAF rule to reject a configured test pattern, while object ownership remains the application's responsibility during cross-account access checks.

Common mistake: Treating a clean WAF dashboard as proof of secure code ignores unobserved routes, business-logic flaws and requests that appear syntactically normal.

Follow-up: How would you test whether an object-level access-control fix works independently of the WAF?

5.How would you investigate suspected lateral movement?

Practice this with AI
Show model answer

Start with an unusual internal connection and identify the source host, destination, account and time window. Correlate network flow or packet evidence with authentication and endpoint activity; SMB or RDP alone is not proof of compromise. Look for departures from the account's normal access, remote execution and unexpected service creation. Windows Event 4688 requires process-creation auditing, with additional configuration for command-line detail; Event 7045 is in the System log. ATT&CK helps frame hypotheses, not prove them. Preserve relevant records and contain only within documented authority, balancing reduced attacker access against service disruption and evidence loss.

Worked example: Perform an approved remote administrative action between owned Windows lab VMs. Expect related network and endpoint records when auditing is configured; compare this known activity with a synthetic alert before assigning intent.

  1. Confirm scope and preserve the initial alert, timestamps and relevant logs in approved storage.
  2. Identify the source, destination and account, accounting for address translation and clock differences.
  3. Correlate packet fields and connection timing with authentication, process and System service-installation records.
  4. Compare the activity with approved administration and the account's history; document supporting and conflicting evidence.
  5. Escalate proposed containment for the required approval and record impact, actions and follow-up verification.

Common mistake: Declaring every workstation-to-workstation connection malicious ignores administration patterns, while expecting unconfigured audit events can leave an investigation with unexplained visibility gaps.

Follow-up: How would you proceed if a suspicious connection exists but process-creation auditing was not enabled?

6.How would you detect and assess possible port scanning?

Practice this with AI
Show model answer

Port scanning probes services to learn which endpoints respond and how. Detection can examine one source contacting many destination ports, many hosts on one port, or repeated incomplete connections. Responses such as resets or ICMP errors help interpretation, but packet loss, health checks and software discovery can produce similar patterns. Slow or distributed scanning may evade simple rate rules. Correlate firewall decisions and endpoint records with the source's approved role before escalating. Thresholds must reflect local traffic and observation coverage. Blocking a shared source without checking attribution can disrupt legitimate users while failing to address the actual origin.

Worked example: Within an isolated owned lab, run a limited TCP connection scan against one test VM. Expect attempts to the specified ports and compare the capture with listener configuration and firewall decisions.

  1. Confirm the target, source and permitted test scope before collecting or generating traffic.
  2. Group observed attempts by source, destination, port and time window without assuming a universal malicious threshold.
  3. Inspect connection outcomes and compare packet timing with firewall and endpoint records.
  4. Check scanner inventories, change approvals and source attribution before classifying the activity.
  5. Document the conclusion and visibility limits; request any blocking action through the authorised process.
nmap -sT -p 22,80,443 192.0.2.20
# Illustrative only: use an explicitly authorised target in an isolated lab configured with this address.

Common mistake: Using a universal connection threshold as proof of scanning overlooks network size, approved scanners, shared addresses and low-rate or distributed activity.

Follow-up: How would you distinguish an approved vulnerability scanner from a compromised host using similar probes?

Frequently asked questions

Are network security fundamentals useful for cybersecurity careers in India?

Network fundamentals remain relevant because SOC, cloud security, incident response and security engineering all involve traffic paths and access decisions. Understanding DNS, TCP, TLS and routing helps explain why a connection failed or why an alert needs investigation. This is a statement about technical overlap, not evidence of a particular hiring rate or guaranteed role. Compare current job descriptions with your interests and build small, authorised demonstrations of the requested skills. Specialisation can deepen expertise, but narrow product knowledge without protocol understanding makes unfamiliar environments harder to troubleshoot. Describe only work you actually completed.

How technical should I expect a network security interview to be?

Depth varies by role, so use the job description to prepare rather than assuming every interview requires identical packet analysis. A useful answer moves from the mechanism to expected evidence, then acknowledges uncertainty and operational trade-offs. For example, explain what SYN retransmissions show and which endpoint or firewall records would help locate the loss. For behavioural questions, use genuine coursework, support work or authorised lab experience; if you lack an example, explain a proposed approach explicitly as hypothetical. Memorised definitions are quick to deliver, but evidence-based reasoning adapts better when the interviewer changes the scenario.

Which tools should I practise for a network security interview?

Practise a packet analyser, a capture utility, an authorised service-discovery tool and one firewall or VPN platform, but connect each tool to a question you can answer. For example, correlate Wireshark packet fields and timing with endpoint logs rather than treating a capture as complete evidence. Use isolated owned VMs, synthetic accounts and deliberately limited tests; expect configured listeners, packet responses and policy logs to agree. Product breadth offers familiarity, while deeper practice improves explanation. Keep captures in approved storage, never upload confidential evidence to public tools, and never execute unknown files on a workstation.

From the blog

20 scenario questions Indian SOC interviewers ask

Network questions get followed up with scenarios — practise both.

Career switch from IT support or network admin

Your networking background is the advantage — here's how to use it.

Cyber security roadmap for beginners in India

Where networking depth fits in the full path.

Continue preparing

Cyber security interview questions and answers

56 questions · All levels · fresher-friendly

17 SOC analyst interview questions and answers

17 questions · L1 and L2 · entry to mid

17 cyber security interview questions for freshers

17 questions · Fresher · 0–1 years

Reading isn't practising

You'll answer these out loud, under time pressure, with an interviewer asking follow-ups. Do a free 5-question AI mock interview and get scored feedback in minutes — no card needed.

Start free mock interview
Practise these free