← all cheat sheets
TAKEOVER PREP · NETWORK & FIREWALL

Network & Firewall Ownership
Interview Prep — Senior Network & Security Engineer

why they're asking — the live branch network, firewall estate & DR programme you'd inherit day one
HEAD OFFICE · Cisco Core
metro fiber
18 BRANCH SITES · Access/Edge
FortiGate + Cisco/Forti
FIREWALL ESTATE
01 Why They'll Ask This
18

Multi-Site Scale

This isn't a green-field design exercise — it's a live network across HO + 18 branches already carrying production traffic. The interviewer is testing whether you can operate and improve an existing estate without breaking it, not whether you can whiteboard one from scratch.

FG

Mixed Vendor Estate

Cisco and Fortinet switches/firewalls in one environment means real day-to-day judgment calls — feature parity gaps, differing CLI/GUI, and knowing which platform to touch for which fix. Harder to fake than reciting one vendor's cert material.

MF

Metro Fiber WAN Dependency

Branch connectivity rides on a carrier's metro fiber, not infrastructure you fully control. Expect questions about circuit outages, carrier escalation, and keeping branches running when the link itself is down.

DR

DR Is Already Running

This isn't "do you know what DR means" — drills are already happening on a cadence. They want proof you can keep executing (and improving) a live DR programme, including the audit/compliance trail behind it.

02 Interview Q&A — Branch & Campus Network
Q How would you approach your first 30 days owning a network you didn't design, across 18 branches?
A Discovery before changes: pull existing topology/config docs (or build them if they don't exist), baseline current performance and error rates, identify single points of failure, and get read access to every device before touching anything.
Q A branch loses connectivity at 2am. Walk through your response.
A Confirm scope first — one branch or many, which points to circuit vs core. Check the metro fiber circuit with the carrier, check core/access switch reachability, verify power/UPS at the branch, then escalate per the runbook. Communicate status on a schedule even with nothing new to report.
Q How do you keep 18 branch configs consistent without hand-configuring each one?
A Standardized golden configs/templates per site role, backed by a config backup/versioning tool (RANCID, Oxidized, or vendor-native) so drift is visible. Manual per-device changes are how environments silently diverge.
Q What's your approach to core switch redundancy, and how do you validate it actually works?
A Redundant core switches with HSRP/VRRP and redundant uplinks — but the real test is scheduling a planned failover and confirming it, not assuming the design works because it's on paper.
Q How would you plan a metro fiber circuit upgrade across branches without a maintenance-window disaster?
A Sequence branches by business criticality, confirm backup connectivity (secondary circuit or 4G/LTE failover, or an accepted outage window) per site, and coordinate the carrier's window directly with branch stakeholders.
03 Interview Q&A — Firewall Estate (FortiGate + Cisco/Forti)
Q You're managing both FortiGate and Cisco firewalls — how do you keep policy management consistent?
A Document naming/policy conventions that translate conceptually across both (zones, object naming, logging standard), keep a change log independent of platform, and manage from each platform's central manager rather than editing devices ad hoc.
Q How do you approach firewall rule base auditing on an estate you just inherited?
A Pull hit counters/logs to find never-matched rules, look for broad any-any rules, check for shadowed rules, and cross-reference each rule against a business justification.
Q What's your change control process for firewall rule changes in production?
A Every change gets a business justification, peer review, a scheduled window unless it's an emergency, and a documented rollback plan before it's applied — especially at the FortiGate/Cisco boundary carrying branch-to-HO traffic.
Q How would you handle firmware/EOL planning across a mixed firewall estate?
A Track firmware/EOL dates per model, stage upgrades in a lab or on a low-risk site first, keep a config backup and downgrade path, and sequence production upgrades outside business hours with a defined rollback window.
Q A user reports "the internet is slow" and you suspect the firewall — what do you check?
A CPU/session count on the firewall, UTM/inspection profile load (SSL inspection and IPS are usual culprits), interface errors/duplex mismatches, and whether it's really the firewall vs the WAN circuit or a specific destination.
04 Interview Q&A — Disaster Recovery & DR Drills
Q Walk me through how you'd run a DR drill for this environment.
A Define scope and success criteria upfront, notify stakeholders, execute the failover per runbook, measure actual RTO/RPO against target, document what broke, and feed findings back into the runbook so the next drill improves on this one.
Q Difference between RTO and RPO, and why do both matter operationally?
A RTO is how long you can be down before it's unacceptable — drives failover speed. RPO is how much data loss is acceptable — drives backup/replication frequency. Nailing RTO with a poor RPO can still be a disaster if near-zero data loss was required.
Q A DR drill fails partway through — what do you do in the moment, and after?
A In the moment: stop and fail back to known-good if continuing risks production. After: root-cause honestly — a drill that reveals a gap is doing its job — and re-test after the fix rather than marking it "passed" on the retry alone.
Q How do you keep DR documentation from going stale between drills?
A Tie runbook updates to change management — any production change affecting failover (new VLANs, firewall rules, circuits) triggers a runbook review, not just the next scheduled drill.
05 Interview Q&A — Team Leadership & Project Coordination
Q You'd be leading an existing IT admin team on day one — how do you build credibility with a team you didn't hire?
A Listen before directing — understand what's already working and who has the informal expertise. Credibility comes from visibly fixing their existing pain points early, not from asserting authority.
Q How do you coordinate an infrastructure project across multiple branches with a small admin team?
A Break it into a repeatable per-site checklist so execution doesn't depend on senior staff being everywhere, sequence sites by risk/priority, and track status centrally.
Q A project is behind schedule due to a vendor delay outside your control — how do you handle it?
A Communicate the slip and its cause early, quantify downstream impact, and present options — accept the delay, re-sequence other workstreams, or escalate to the vendor — rather than just reporting the problem.
Q How do you decide what to delegate versus handle yourself while leading the team?
A Delegate based on growth opportunity and existing strength, not just to offload work — keep ownership of anything with real business risk (core changes, firewall policy, DR) until you trust the team's judgment on it.
06 Scenario-Based / Day-1 Ownership Questions
Q Week one — a branch switch fails and there's no documented spare/replacement process. What do you do?
A Handle the outage with whatever's available, then treat the missing process as a finding — document and fix the gap so the next failure isn't also a scramble.
Q You discover the previous engineer left undocumented "tribal knowledge" — how do you deal with that risk?
A Prioritize capturing it during any handover window available, and independently rebuild documentation from device configs and logs for anything not captured. Undocumented knowledge is a single point of failure, same as hardware.
Q How would you validate that the DR, firewall, and network documentation you inherited is actually accurate?
A Spot-check against reality — compare documented config against running config on a sample of devices/sites, and treat any mismatch as a signal to re-verify the rest.
Q What would you do differently in your first 90 days versus your first week?
A Week one is discovery and stability — don't break anything. By 90 days you should be executing a prioritized list of fixes from that discovery, with the team already seeing you improve things, not just maintain them.
07 Day-1 Ownership Checklist
1

Inventory & Access

Full device inventory, credentials, and topology/config docs — or start building them — before making any change.

Discovery
2

Baseline

Capture current performance, error rates, and firewall session/CPU load as your reference point.

Baseline
3

Risk Scan

Identify single points of failure, EOL hardware, stale firmware, and untested redundancy.

Risk
4

Documentation Audit

Compare documented config/topology against actual running state; flag mismatches.

Verification
5

Relationship Building

Meet the admin team, carrier/vendor contacts, and stakeholders who depend on the branches.

People
6

Prioritized Action Plan

Turn discovery findings into a ranked fix list, starting with anything that's a single point of failure.

Execution
08 Vendor Quick Reference
CS

Cisco IOS-XE (Switches)

show cdp neighbors show spanning-tree show interfaces status show standby brief
HSRP for first-hop redundancy; cross-check show interfaces for errors/duplex before blaming the WAN.
FG

FortiGate

get system status diagnose sys session list get system performance status diagnose debug flow trace start 10
Policies are numbered, zone/interface based; check session count and CPU before assuming a WAN problem.
CK

Circuit / Path Checks

traceroute <dest> show interface counters errors show ip route
Rule out the metro fiber circuit and routing before escalating to the carrier.
09 Quick-Fire Glossary
TermMeaning
RTORecovery Time Objective — max acceptable downtime before failover must complete
RPORecovery Point Objective — max acceptable data loss, measured in time since last good backup/replication
HSRP / VRRPFirst-hop redundancy protocols giving a virtual gateway IP across redundant switches
EOL / EOSEnd-of-Life / End-of-Support — vendor stops selling/patching a platform, a driver for upgrade planning
Golden ConfigApproved standard configuration template a site/device should match
Config DriftGradual divergence between documented/intended config and actual running config
RunbookStep-by-step documented procedure for a known scenario (failover, outage response)
Change WindowPre-approved time slot for making production changes, minimizing business impact