Cisco Interview Questions (2026): Most Asked, With Answers

Candidate reports consistently describe three to five stages: an initial recruiter screen, one or two technical rounds, and a final hiring manager or panel round. For individual contributor roles the whole loop often runs two to four weeks from first contact to offer. Aggregate candidate reviews on Glassdoor put Cisco's average interview process at a little over three weeks, which lines up with what most candidates I've talked to describe (Glassdoor, Cisco interview reviews). Senior and staff-level roles, and anything requiring a security clearance for a government-facing team, run longer, sometimes six to eight weeks.

It varies more than most companies of similar size. Cisco is organized into distinct business units, networking, security, collaboration (Webex), and Splunk's observability line since the 2024 acquisition closed, and each hires and interviews somewhat independently. A network engineer candidate gets protocol and IOS questions. A software engineer on a Webex client team gets algorithms and a system design prompt closer to what you'd see at any product company. A security-focused role adds firewall and threat-model questions on top of networking fundamentals. Read the job description closely before you assume a generic CCNA study guide will cover you.

Layer 1, physical, is the actual electrical or optical signal on the wire or fiber, voltage levels, light pulses, nothing about addressing yet. Layer 2, data link, is where a switch operates, using MAC addresses to forward frames within a broadcast domain, and where you'd point to Ethernet framing and VLAN tagging. Layer 3, network, is where a router lives, using IP addresses to forward packets between different networks, and where routing protocols like OSPF and BGP do their work. Layer 4, transport, is TCP and UDP, port numbers, and for TCP the three-way handshake and reliable delivery guarantees that UDP simply doesn't bother with.

Interviewers usually don't stop at the definition. The follow-up is almost always "where would a firewall's stateful inspection sit," and the honest answer is that a modern firewall reaches all the way up to layer 7 for application awareness, even though its core packet-filtering logic still operates primarily at layers 3 and 4.

A switch makes its forwarding decision based on a MAC address table it builds by watching source addresses on incoming frames, and it only makes sense within a single broadcast domain, one subnet, one VLAN. A router makes its forwarding decision based on a routing table built from directly connected networks, static routes, and dynamic routing protocols, and its entire job is moving traffic between different broadcast domains. The shorthand candidates usually land on, switches operate within a network, routers operate between networks, is correct as a first pass, but a strong answer adds that a layer 3 switch blurs this by doing both jobs on one piece of hardware, which is now the default in most modern data center and campus designs.

A VLAN is a logical broadcast domain carved out of a physical switch, letting you segment traffic, say, finance workstations from guest wifi, without needing separate physical switches for each group. A trunk link carries traffic for multiple VLANs over a single physical connection between two switches, using 802.1Q tagging to mark which VLAN each frame belongs to as it crosses the trunk.

Switch1(config)# interface gigabitethernet0/1
Switch1(config-if)# switchport mode trunk
Switch1(config-if)# switchport trunk allowed vlan 10,20,30

Without trunking you'd need one physical cable per VLAN between every pair of switches that needs to share those VLANs, which stops scaling almost immediately past a handful of VLANs.

A static route points to a specific destination network you configure by hand. A default route, 0.0.0.0/0, is the catch-all a router uses when no more specific route matches, typically pointing toward the internet edge or an upstream provider. Static routes make sense on small networks where the topology rarely changes and the operational overhead of a dynamic protocol isn't worth it, a single branch office with one link to headquarters, for instance, or as a backup path with a higher administrative distance that only kicks in if a dynamic route disappears.

You enter global configuration mode, move into the specific interface's configuration context, assign the IP address and subnet mask, and then explicitly bring the interface out of its default administratively-down state.

Router(config)# interface gigabitethernet0/0
Router(config-if)# ip address 192.168.1.1 255.255.255.0
Router(config-if)# no shutdown
Router(config-if)# description Link to Distribution Switch

The step candidates forget most often is no shutdown. Every physical interface on a Cisco router ships administratively down by default, so an otherwise perfectly configured interface with a correct IP and cabling still won't pass traffic until that one line runs.

running-config is the active configuration in memory, everything you've typed takes effect immediately against running-config. startup-config is what's saved to non-volatile memory and gets loaded when the device boots. If you make changes and the device reboots or loses power before you run copy running-config startup-config (or the shorthand write memory), every change is gone and the device comes back up with whatever was last saved. This is a genuinely common real-world incident, someone makes a change, tests it, gets pulled onto something else, and a scheduled maintenance reboot later that week wipes it silently.

A stateless packet filter evaluates each packet in isolation against a rule set, no memory of prior packets, which means it has to explicitly permit both directions of every conversation you want to allow. A stateful firewall tracks active connections in a state table, so once it sees the outbound leg of a TCP session it automatically permits the corresponding return traffic without a separate rule, and it can also detect and drop packets that don't belong to any known session, an unsolicited SYN-ACK with no matching outbound SYN, for example. Nearly every production firewall deployed today is stateful for exactly that reason.

Meraki is Cisco's cloud-managed networking line, switches, wireless access points, security appliances, all administered through a single web dashboard rather than device-by-device command-line configuration. Instead of SSHing into each switch and typing IOS commands, an administrator makes changes once in the Meraki dashboard and they push out to every device in that network automatically, which is a deliberate simplification aimed at organizations without dedicated networking staff at every site, a retail chain with a hundred small locations, for instance, where hiring a CCNA-level engineer per site isn't realistic.

Because configuring devices one at a time through the CLI doesn't scale past a few dozen boxes, and it's error-prone the moment a config change needs to go out identically to a hundred switches. Python, usually paired with a library like Netmiko or NAPALM for talking to network device CLIs, or with an API-driven approach against something like Meraki's dashboard API, lets an engineer push a change, or more commonly pull data to verify a change, across an entire fleet of devices in the time it'd take to log into two or three of them manually. It is not really about writing clever algorithms. It is about eliminating repetitive manual work that's genuinely tedious and genuinely error-prone at scale.

Given how often Cisco's portfolio shifts, new acquisitions, new product lines, security and observability increasingly folded into what used to be pure networking roles, this question is checking for genuine comfort with ongoing change rather than a one-time story from early in your career. Strong answers describe an actual learning approach, reading source documentation first versus asking a colleague first versus building a small test case to learn by doing, and connect it to a specific, recent outcome, not a generic "I'm a fast learner" claim with no example attached.

This shows up for nearly every role, since even a pure backend or networking engineer eventually has to justify a decision to someone outside the immediate team. The interviewer is checking whether you actually adjust your explanation for the audience, dropping jargon and reframing around business impact, or whether you just say the same technical sentence more slowly and louder when the first version doesn't land. A concrete example beats a general philosophy every time here, name the actual audience, the actual thing you were explaining, and how you knew it landed, did they ask a good follow-up question, did the decision they needed to make actually get made.

It's a behavioral-focused conversation, usually with the hiring manager or a peer from the team, built around Cisco's stated conduct principles, things like "we act as one team," "we embrace change," and inclusion and belonging as an explicit theme in Cisco's public culture messaging. In practice it is not really about reciting the company's language back. It is about whether you can describe a real conflict, a real mistake, or a real cross-team dependency and how you handled it without inflating your own role. Interviewers in this round push on specifics. A vague "I'm a team player" answer gets a follow-up asking for a concrete example, names and outcomes optional but details expected.

Generally no, but expect an equivalent hands-on exercise. Network engineering and TAC interviews substitute live troubleshooting for live coding: you're given a topology, sometimes a packet capture or a set of show-command outputs, and asked to diagnose what's wrong out loud. The skill being tested is the same as a coding interview, structured problem solving under mild pressure, just applied to a routing table instead of an array. Systems engineer (pre-sales) roles usually skip both and instead ask you to walk through how you'd position a solution to a hypothetical customer with a stated business problem.

Switches forward frames with no built-in concept of a loop the way IP routing has TTL to kill a looping packet. If you build physical redundancy into a layer 2 topology, two switches connected by two separate links for failover, and don't run STP, a broadcast frame entering that loop gets forwarded, re-forwarded, and duplicated endlessly. This is a broadcast storm, and it can take down an entire switched network within seconds, MAC address tables flap constantly as the same source address appears to arrive from multiple ports, and available bandwidth gets consumed entirely by looping traffic.

STP solves this by electing a root bridge and then blocking redundant paths, putting one of the two physical links into a blocking state so no loop exists logically, while keeping it available to take over automatically if the active link fails. Modern deployments mostly run Rapid STP (802.1w) instead of the original protocol, since convergence in the original spec, tens of seconds, is too slow for anything latency-sensitive.

A distance-vector protocol like RIP shares only what it learns from its immediate neighbors, hop count to a destination, without knowing anything about the actual topology beyond that. It's the routing equivalent of "ask a friend of a friend," and it's prone to slow convergence and routing loops the classic solution to which is split horizon and hold-down timers, band-aids rather than a structural fix.

A link-state protocol like OSPF has every router build a complete map of the network's topology by flooding link-state advertisements to every other router in the area, then runs Dijkstra's shortest path algorithm locally against that full map. Convergence is faster because a topology change gets flooded and recalculated everywhere almost immediately, rather than propagating hop by hop. The tradeoff is more CPU and memory overhead on each router, since every router is now storing and computing against the whole topology instead of just a neighbor table.

Subnetting takes one address block and splits it into smaller networks, mainly to avoid wasting addresses on segments that don't need a full /24 worth of hosts, and to create separate broadcast domains that map to your actual topology, one subnet per floor, per VLAN, per site.

For four equal networks from 192.168.1.0/24, you borrow two bits from the host portion, since 2² gives you four subnets, moving the mask from /24 to /26. That gives 192.168.1.0/26, 192.168.1.64/26, 192.168.1.128/26, and 192.168.1.192/26, each with 64 addresses, 62 usable after subtracting the network and broadcast address. Interviewers ask this specifically because it's fast to verify whether you actually do the binary math or are guessing from memorized patterns.

Administrative distance is a trust ranking Cisco IOS assigns to each route source, lower is more trusted. A directly connected route has an administrative distance of 0, a static route is 1 by default, OSPF is 110, RIP is 120. If a router learns a route to the same destination from two different protocols, or from both a static route and a dynamic protocol, it installs the route with the lowest administrative distance in the routing table and ignores the other, regardless of which one actually has a shorter or faster path. This trips people up in troubleshooting because a perfectly good OSPF route can get silently overridden by an old static route someone forgot was still configured, since 1 beats 110 every time.

An ACL is an ordered list of permit or deny statements matched against traffic, typically by source and destination address, protocol, and port. IOS evaluates an ACL top to bottom and stops at the first match, so a broad deny statement placed above a more specific permit statement silently blocks traffic the more specific rule was meant to allow, even though the permit line is technically still there and correctly written.

access-list 101 deny ip any any
access-list 101 permit tcp any host 10.1.1.5 eq 443
! The permit line never matches, everything already hit the deny above it

There's also an implicit deny-all at the end of every ACL that isn't visible in the configuration, which is the single most common source of "I added a permit rule and it still isn't working" tickets.

A standard ACL filters based only on source IP address, numbered 1 through 99 (or named). Because it can't see destination or port information, best practice is applying it as close to the destination as possible, otherwise you risk blocking traffic from a source to destinations you never intended to affect. An extended ACL, numbered 100 through 199, filters on source, destination, protocol, and port, giving it enough precision that best practice flips: apply it as close to the source as possible, so unwanted traffic gets dropped before it consumes bandwidth traveling across the rest of the network.

A VPN creates an encrypted tunnel across an untrusted network, encapsulating the original traffic inside a new packet so its contents and often its original addressing stay hidden from anything observing the path in between. IPsec operates at the network layer, encrypting entire IP packets, and typically needs a dedicated client or router-to-router configuration, which makes it the standard choice for site-to-site connections between offices or data centers. SSL/TLS VPNs operate higher up and can run through a standard browser or a lightweight client with no dedicated hardware configuration on the far end, which is why they're the more common choice for remote user access where you can't guarantee what device someone's connecting from.

A man-in-the-middle attack positions an attacker between two parties who believe they're communicating directly, letting the attacker read or alter traffic in transit without either side immediately noticing. ARP spoofing is the classic layer 2 version, an attacker sends forged ARP replies claiming their own MAC address maps to the gateway's IP, so nearby hosts send their gateway-bound traffic straight to the attacker's machine instead, which can then forward it along after inspecting or modifying it. Dynamic ARP Inspection, a feature available on Cisco switches, mitigates this by validating ARP packets against a trusted binding table built from DHCP snooping, rejecting anything that doesn't match a known legitimate binding.

Port security limits which MAC addresses are allowed to send traffic on a given switch port, either by manually specifying allowed addresses or by letting the switch learn and lock in the first one (or first few) it sees dynamically. It's a defense against someone unplugging an authorized device and plugging in their own, or against a rogue switch or hub extending the network unintentionally.

Switch(config-if)# switchport port-security
Switch(config-if)# switchport port-security maximum 1
Switch(config-if)# switchport port-security violation shutdown

By default the violation action is shutdown, which puts the port into an err-disabled state the moment an unauthorized MAC address shows up, requiring manual intervention, or an err-disable recovery timer, to bring it back up. The two other options, restrict and protect, drop the offending traffic without taking the port down entirely, which some environments prefer specifically to avoid an accidental full outage from a single misconfigured device.

Authentication answers "who are you," verifying identity, typically a username and password or a certificate. Authorization answers "what are you allowed to do," which permissions and privilege levels apply once identity is confirmed. RADIUS combines authentication and authorization into a single encrypted exchange (only the password is encrypted, not the whole packet) and is the more common choice for network access control, wifi and VPN logins. TACACS+, a Cisco-originated protocol, separates authentication, authorization, and accounting into distinct steps and encrypts the entire packet body, which is why it's the more common choice specifically for administrative access to network devices themselves, since it lets you authorize individual commands a logged-in admin is allowed to run, something RADIUS doesn't do as granularly.

ACI is Cisco's software-defined networking architecture for the data center, built around a spine-leaf physical topology managed centrally through the Application Policy Infrastructure Controller (APIC) rather than configuring each switch individually. The core idea is defining network policy in terms of application requirements, which endpoints need to talk to which other endpoints, and letting the controller push the underlying VLAN, routing, and access configuration automatically, instead of an engineer touching dozens of individual switch configs by hand every time an application's connectivity needs change. The pitch is faster, less error-prone change management at data center scale, where a manual per-switch approach genuinely doesn't hold up once you're past a handful of racks.

A traditional MPLS WAN routes branch-to-branch and branch-to-data-center traffic over a dedicated private circuit leased from a carrier, reliable but expensive, and slow to provision when you open a new site. SD-WAN, which Cisco offers through its Catalyst SD-WAN line built on the Viptela acquisition, uses software to manage traffic across multiple transport types at once, MPLS, broadband internet, LTE, and picks the best path per application in near real time based on measured latency, jitter, and packet loss, rather than a static routing decision made once at design time.

The practical selling point is cost and flexibility: a branch office can use cheaper broadband as its primary transport for most traffic while automatically failing critical applications over to a backup path if that link degrades, without a human intervening or a static route needing to be reconfigured.

Real-time audio and video is fundamentally different from most application traffic because it's latency-sensitive and loss-tolerant in a way a file transfer or a web request isn't. A dropped packet in a video call is better handled by degrading quality briefly than by retransmitting and adding delay, which is part of why real-time media typically runs over UDP rather than TCP. Webex has to negotiate media paths across wildly inconsistent network conditions, home wifi, corporate firewalls, mobile data, often needing to traverse NAT and firewalls using protocols like STUN and TURN to establish a direct or relayed media path at all, adapt video quality dynamically as bandwidth changes mid-call, and keep audio and video in sync across all of that. It's a genuinely different engineering problem than most of what a candidate coming from a typical CRUD-application background has worked on.

UCS is Cisco's data center server platform, combining blade or rack servers, network connectivity, and storage access into a single managed system rather than treating compute, networking, and SAN connectivity as separate silos each with their own management tools and staff. The original pitch, and it's held up reasonably well, was reducing the operational overhead of managing all three separately: a single management plane, UCS Manager, handles firmware, network profiles, and server identity (including MAC and WWN addresses) as reusable service profiles that can move between physical servers, which matters a lot for fast recovery if a physical blade fails and needs to be swapped without redoing every piece of configuration by hand.

The honest answer avoids trashing the competition and instead focuses on total cost of ownership and integration depth. A cheaper standalone switch or router can absolutely match Cisco on a line-item price comparison. What's harder to replicate is the breadth of an integrated stack, networking, security, and observability tooling built to interoperate, plus the depth of TAC support and documented interoperability across a huge installed base most competitors can't match at the same scale. A strong pre-sales answer names the actual tradeoff instead of dodging it: you're often paying for integration and support depth, not just hardware, and that's a legitimate business decision to make explicit rather than assume the customer already values.

Netmiko wraps SSH connection handling and vendor-specific quirks so you don't have to manage a raw paramiko session and screen-scrape prompts yourself.

from netmiko import ConnectHandler

device = {
  "device_type": "cisco_ios",
  "host": "192.168.1.1",
  "username": "admin",
  "password": "changeme",
}

def get_running_config(device):
  connection = ConnectHandler(**device)
  output = connection.send_command("show running-config")
  connection.disconnect()
  return output

config = get_running_config(device)
print(config)

Interviewers are usually less interested in exact syntax recall and more interested in whether you know why a library like this exists at all, handling prompt detection, paging, and command timing that you'd otherwise have to reimplement yourself against a raw SSH connection.

Screen-scraping means parsing plain-text output meant for a human to read, running show interface and regex-matching the counters out of it, which breaks the moment a software update changes spacing, wording, or column order even slightly. A structured API returns data in a predictable format, JSON typically, with a defined schema, so your code reads a specific field by name instead of guessing at text position. RESTCONF and NETCONF give this structured access on IOS-XE devices directly, and the Meraki dashboard API gives it for cloud-managed gear. The tradeoff is that structured APIs require more upfront setup and aren't available on every older device still running classic IOS, so plenty of real automation still leans on screen-scraping through Netmiko out of necessity, not preference.

Ansible is a configuration management tool built around declarative playbooks, you describe the desired end state, "this VLAN should exist, this interface should have this description," rather than writing imperative step-by-step logic for how to get there. Beneath that, network modules in Ansible often use the same connection libraries a hand-written Python script would, but the playbook format makes changes idempotent by default: running the same playbook twice produces the same result without duplicating configuration, and it's easier for a team to read and audit a declarative playbook than to trace through custom Python logic someone else wrote. Teams typically reach for a raw script when the logic is genuinely custom or one-off, and reach for Ansible when the same change needs to apply consistently, repeatedly, across a fleet.

Interviewers here are listening for whether you raised the disagreement directly and professionally, with a specific technical reason, rather than either staying silent or escalating it into a personal conflict. The strongest answers describe bringing data or a concrete scenario to the conversation, "here's what breaks under this design if traffic doubles," rather than a vague feeling that something's wrong, and they describe what happened after, did the decision change, did you get more context that changed your own mind, or did you disagree and commit anyway once the decision was made. All three are acceptable endings. What's not acceptable is an answer where you never actually raised the concern to the person who could act on it.

This question is specifically testing whether you can own a real mistake without either deflecting all blame elsewhere or performing exaggerated self-criticism that isn't credible either. A good answer names a specific, real failure, a missed deadline, a bad estimate, a design decision that didn't hold up under actual production load, states plainly what your part in it was, and then describes what changed in how you work afterward. Interviewers notice when a candidate's "failure" story is actually a thinly disguised success story with a token obstacle, and it reads as evasive rather than honest.

The scenario itself is common, needing a security team's sign-off, a data team's pipeline change, another product team's API to ship your own feature, but the answer that lands is specific about how you built alignment without formal authority: understanding what the other team actually cared about and needed from the interaction, not just what you needed from them, and finding the specific person or forum where a decision could actually get made rather than sending an email into a void and waiting. Cisco is genuinely large and matrixed enough, tens of thousands of employees across distinct business units, that this skill shows up constantly in day-to-day work, which is exactly why it gets asked about directly rather than assumed.

This comes up constantly for TAC, systems engineering, and any customer-facing role, since the volume of incoming requests rarely matches available time. A credible answer names an actual method, severity and business impact first (a full outage beats a cosmetic bug every time), then some combination of deadline proximity and how many other people are blocked waiting on you specifically, rather than "whatever came in first" or "whoever's loudest." The follow-up worth having ready is what you do when two things both look genuinely critical at the same time, since that's the actual hard case, not the easy one where priority is obvious.

OSPF neighbors progress through Down, Init, 2-Way, ExStart, Exchange, Loading, and Full (RFC 2328, OSPF Version 2). Down means no hellos received yet. Init means a hello was received but doesn't yet list the local router, so it's one-directional. 2-Way means bidirectional communication is confirmed, both routers see each other in their neighbor lists, and on a broadcast segment this is where a DR and BDR get elected. ExStart is where the two routers negotiate a master/slave relationship and an initial sequence number for the database exchange that follows. Exchange is the actual trading of database description packets. Loading is where any link-state advertisements referenced but not yet held locally get requested and retrieved. Full means the databases are fully synchronized.

Stuck in ExStart almost always means an MTU mismatch between the two interfaces. Higher MTU router sends a database description packet the neighbor can't process, the neighbor never acknowledges it correctly, and the adjacency never progresses past negotiation even though basic connectivity, and even the earlier hello exchange, works fine. It's one of the most commonly reported real troubleshooting scenarios in Cisco networking interviews precisely because it looks like a working link on the surface.

OSPF is an interior gateway protocol, designed to find the fastest path within a single organization's network, and it converges quickly because it's built around raw topology and cost, generally a function of interface bandwidth. BGP is an exterior gateway protocol, designed to route between separately administered networks, autonomous systems, on the public internet, and it makes path decisions based on policy attributes, AS-path length, local preference, communities, rather than pure speed.

A large enterprise or service provider commonly runs both at once: OSPF (or IS-IS) internally to move traffic efficiently between its own routers and sites, and BGP at the network's edge to exchange routes with ISPs and peer networks, then redistributes selectively between the two. Redistribution done carelessly is one of the more common ways a large network creates a routing loop, since OSPF's cost metric and BGP's path attributes don't translate to each other cleanly, which is exactly why interviewers like asking about it.

A traditional perimeter model assumes anything inside the network boundary is relatively trusted once it's past the firewall, and most of the security effort goes into hardening that boundary. Zero trust starts from the opposite assumption: no user or device is trusted by default regardless of network location, and every request gets verified against identity, device posture, and policy on a per-session basis, not just once at the perimeter.

In practice this means continuous verification instead of a one-time login, and access scoped narrowly to the specific application or resource a user needs rather than broad network-level access once someone's authenticated. Cisco's own security portfolio, built substantially around its Duo acquisition for identity verification alongside its broader security stack, is positioned directly at this shift, which is exactly why an interviewer for a security-adjacent role brings it up even for candidates who aren't applying to the security business unit specifically.

Splunk's core product ingests and searches machine-generated data, logs, metrics, traces, at scale, and Cisco has been integrating it with its own networking and security telemetry rather than keeping it as a standalone acquisition. For a candidate, the practical implication is that questions about observability, "how would you know a specific device or application is degrading before a user complains," increasingly expect an answer that goes beyond a single show command on one router and touches how logs and metrics from many devices get centralized and correlated. You don't need hands-on Splunk experience to answer this well, but an answer that only describes checking one device in isolation, with no mention of centralized logging or alerting, reads as dated to an interviewer who works anywhere near that part of the portfolio.

Shelling out to ping works but is fragile, output format varies by OS and you're parsing text again. A cleaner approach uses a raw socket or a purpose-built library like icmplib to send actual ICMP echo requests and measure the response directly in Python.

from icmplib import ping

def check_hosts(ip_list):
  results = {}
  for ip in ip_list:
    host = ping(ip, count=2, timeout=1)
    results[ip] = host.is_alive
  return results

hosts = ["10.1.1.1", "10.1.1.2", "10.1.1.3"]
print(check_hosts(hosts))

An interviewer asking this is usually checking whether a candidate reaches instinctively for subprocess and string parsing, which works but is brittle, or knows there's a more direct, structured way to do the same thing.

Logging enough detail per device, per command, with success or failure state, that you know exactly where it stopped without re-running the whole batch and guessing which devices already got the change. Idempotent operations matter here too: if the script's commands are written so that re-running them against a device that already has the change is harmless, "ensure VLAN 20 exists" rather than "create VLAN 20" which errors on a device that already has it, then you can safely restart the whole run from scratch instead of hand-tracking which twenty-five devices are done and which twenty-five aren't.

A candidate who answers this well usually mentions checkpointing progress somewhere durable, a file, a database row, not just an in-memory list that disappears if the script itself crashes, plus wrapping each device's operation in its own try/except so one bad device doesn't kill the whole run for the other forty-nine that would have succeeded fine.

Two physical routers instead of one, running a first-hop redundancy protocol, HSRP is Cisco's own, VRRP is the open standard version, so both routers share a virtual IP address that end hosts use as their default gateway. One router is active and forwarding traffic, the other stands by, monitoring the active router's health through periodic hello messages, and takes over the virtual IP automatically if the active router stops responding.

A genuinely strong answer goes further than just naming HSRP and covers what triggers failover beyond a hard crash, tracking an upstream interface so the standby router takes over even if the active router is technically still up but has lost its own connection to the internet or WAN, since a router that's alive but has no useful uplink is functionally just as broken as one that's powered off, and a naive HSRP config without interface tracking would never fail over in that scenario.

Start from actual current utilization data, not the theoretical max the hardware is rated for. Pull real bandwidth and CPU utilization from existing switches and routers over a representative period, ideally including peak hours, not just an average, since average utilization hides the moments that actually cause user-visible problems. Then model where triple the users pushes each constrained resource, wireless AP density in a given floor plan (more users per AP degrades everyone's throughput well before you hit a hard connection limit), switch port count and uplink bandwidth, and DHCP scope size, which is a genuinely common thing teams forget to resize until addresses start running out mid-migration.

The answer an interviewer wants to hear includes building in headroom rather than sizing exactly to the projected number, since growth estimates are routinely wrong in one direction or the other, and a design with zero margin for error turns a modest forecasting miss into an outage.

On-premises gives you full control over hardware, latency, and security posture, but you carry the entire capital cost and the operational burden of capacity planning, hardware refresh cycles, and physical redundancy yourself. A hybrid design shifts variable or bursty workloads to a cloud provider, so you're not over-provisioning on-prem hardware for peak demand that only happens occasionally, but you take on new complexity: consistent security policy across two fundamentally different environments, reliable low-latency connectivity between the two, often via a dedicated interconnect rather than plain internet transit, and a real cost model that needs ongoing attention, since cloud costs scale with usage in a way on-prem capital spend simply doesn't.

A candidate who's actually done this work usually flags that the hardest part in practice isn't the network path itself, that's a solved problem with a dedicated circuit or VPN, it's keeping identity, firewall policy, and monitoring consistent across both environments so a security gap doesn't open up simply because the two sides were configured by different tools with different defaults.

Start from the closest working vantage point and work outward. Ping the router's IP from a device on the same segment, then from further away, to isolate whether the problem is local to that router or somewhere in the path. Check whether you can reach any other device on the same subnet as the router, if nothing on that subnet responds, the problem is likely upstream, a link down, a routing change, or a power issue at that site rather than the router itself specifically.

If you have any out-of-band access, a console server, a cellular failover management connection, that's the next step rather than continuing to guess from the network side. Absent that, check whether anyone recently made a change, an ACL, a routing update, since the most common cause of "router became unreachable" isn't hardware failure, it's a configuration change that accidentally blocked or rerouted management traffic. I'd rather ask a candidate to walk through this reasoning out loud than have them jump straight to "reboot it," since that answer skips past learning what actually broke.

show running-config tells you what's configured, the intended state. show interface tells you the actual observed state and counters, input and output errors, CRC errors, collisions, resets, and how long the interface has been up or down. A flapping link investigation almost always needs the second one first: CRC errors climbing point toward a physical or cabling problem, input errors with no CRC errors point more toward a duplex mismatch, and a high reset count with clean error counters points toward something further up the stack, a spanning tree recalculation or a power issue on the far end, rather than the physical layer.

Start from the physical layout and work up. Two access switches feeding wired desks and printers, uplinked to a small layer 3 switch or router that handles inter-VLAN routing, is enough for 40 people, no need to over-engineer a spine-leaf topology at this scale. Wireless access points, likely Meraki given the low staffing overhead of cloud management for a site this size, on their own VLAN separate from wired traffic. A firewall or SD-WAN edge device at the internet handoff, terminating a VPN tunnel, IPsec site-to-site is the standard choice here, back to headquarters, with a backup broadband circuit as failover if the primary link goes down.

The follow-up interviewers usually ask is what happens if the primary WAN link fails, and the honest answer is you need that failover path designed in from the start, not bolted on later, since retrofitting redundancy into a design that assumed a single link is disruptive and often the mistake real branch office rollouts made a decade ago.

Three separate VLANs at minimum, each with its own subnet, and firewall rules between them that default to deny rather than allow, opening only specific, named exceptions. Guest wifi typically gets internet-only access with no route back into the internal network at all. IoT devices, badge readers, cameras, get their own segment with tightly scoped access, usually just to whatever management server they report to, since these devices are frequently the weakest link security-wise, running outdated firmware that rarely gets patched.

The design detail that separates a strong answer is naming that IoT devices shouldn't be able to reach each other laterally either, not just isolated from corporate traffic, since a compromised camera shouldn't be able to pivot to attack a badge reader on the same segment. That's usually done with private VLANs or per-port ACLs rather than one flat IoT VLAN where everything can see everything else.