Network Automation Questions

Automate network device configuration, provisioning, and operational workflows using automation frameworks and Infrastructure as Code principles tailored to networking. Topics include configuration management and orchestration for network devices, programmatic device access libraries, version controlling network configurations, testing and validation of network changes, event driven remediation, performance and scale considerations, and common challenges such as state reconciliation and vendor heterogeneity. Candidates should be able to discuss tools and libraries used in network automation and strategies for deploying safe, repeatable network changes at scale.

HardTechnical

27 practiced

Design a safe event-driven remediation loop that correlates telemetry signals (interface errors, BGP flaps, CPU spikes) and executes automated remediation while preventing feedback loops where remediation itself generates further alerts. Include detection thresholds, suppression windows, action verification, throttles, and escalation to human operators when needed.

Sample Answer

**Overview / goal**Design an event-driven remediation loop that correlates multi-signal telemetry, performs safe automated fixes, and prevents feedback loops by verifying actions, suppressing symptom storms, and escalating when necessary.

**Requirements & thresholds**- Signals: interface errors (CRC/input errors), BGP flaps, CPU spikes (1m/5m).- Detection thresholds (example starting points): - Interface errors: >100 errors/min for 2 consecutive minutes. - BGP flaps: >3 session resets in 5 minutes. - CPU: sustained >85% for 3 minutes and 90% peak.- Correlation rule: require at least two distinct signal classes tied to same device, module, or path within 5 minutes to trigger remediation (or one high-confidence single-signal rule for critical devices).

**Flow / components**- Ingest: telemetry -> aggregator with TTL-tagged events.- Correlator: time-windowed rule engine that groups by device/context and applies thresholds.- Decision engine: maps correlated alarm patterns to safe playbooks (read-only checks, partial remediations, full remediations).- Executor: remediations run via idempotent API calls with guardrails.- Verifier: post-action readback and telemetry validation.- State-store: tracks actions, suppression windows, and throttles.

**Safety controls to prevent feedback loops**- Suppression window: after a remediation on an object, suppress identical symptom-triggered remediations for 15–60 minutes (configurable by action severity).- Throttle: global and per-device limits (e.g., max 2 automated actions per device per hour; global max 5/hour) with exponential backoff.- Action verification: require pre-checks (e.g., validate BGP peer state, config diff dry-run) and post-checks (BGP stable for 10 min, interface error rate < threshold).- Change fencing: mark actions that modify forwarding as “risky” and require two independent signals plus operator approval.- Idempotence & dry-run: use idempotent API calls; support dry-run mode to evaluate effect; rollback plan stored with action.

**Escalation & human-in-the-loop**- Automatic escalation when: - Post-verification fails - Action limit exceeded - Correlated pattern includes critical services- Notify on-call with context: correlated signals, playbook executed, timestamps, pre/post telemetry, and suggested manual steps.- Provide one-click approve/abort in runbook UI.

**Example playbooks**- BGP flap + CPU spike on router: run read-only diagnostics -> clear BGP soft-reset on selected peer (not global) -> verify BGP stable 10m -> suppress similar actions 30m.- Interface errors alone below risky threshold: schedule interface counters reset during maintenance window; don't auto-change cabling/patching.

**Monitoring & metrics**- Track MTTR, number of automated actions, success/failure rate, and number of escalations. Audit logs for every action for post-incident review.

This design balances automation speed with safeguards to avoid remediation-induced storms, using correlation, verification, suppression, and human escalation.

MediumTechnical

34 practiced

You need to collect interface state and distribute a standard SNMP community string across 500 heterogeneous devices. Compare NAPALM, Netmiko, and Paramiko for this task in terms of abstraction, error handling, idempotency, and speed. Which would you choose and why? Describe a short implementation approach using your chosen library.

Sample Answer

**Direct answer / choice**I would choose NAPALM. It provides a device-agnostic abstraction, built-in idempotent config methods, and consistent error handling across vendors—ideal for collecting interface state and distributing a single SNMP community to 500 heterogeneous devices.

**Comparison**- **Abstraction** - NAPALM: High-level, vendor-neutral get/config APIs (interfaces, config merge). - Netmiko: CLI session helper; you write vendor-specific command sequences. - Paramiko: Low-level SSH channel; you must implement everything.- **Error handling** - NAPALM: Exceptions and dry-run apply/commit patterns; consistent failures. - Netmiko: Command/expect failures; you must parse output and detect errors. - Paramiko: Raw I/O errors; no semantic parsing.- **Idempotency** - NAPALM: Supports compare_config/load_merge_candidate/commit — enables idempotent changes. - Netmiko: You must implement checks (show run grep) and conditional changes. - Paramiko: Same as Netmiko but more manual.- **Speed** - Paramiko/Netmiko can be faster per-device because they’re lightweight; NAPALM may be slightly slower but scales well with concurrency (async or thread pools). For 500 devices, parallelism matters more than library overhead.

**Implementation approach (NAPALM)**1. Inventory devices with driver/vendor and connection info.2. Parallelize (ThreadPoolExecutor) batches of connections.3. For each device: - open NAPALM driver, load() get_interfaces() and retrieve SNMP state - build candidate config to set community (or use vendor-specific template) - use load_merge_candidate(), compare_config(), commit_config() if change needed; rollback on exception4. Log results and produce a report.

Example snippet:

python

# python
from napalm import get_network_driver
from concurrent.futures import ThreadPoolExecutor

def apply_snmp(device, community):
    driver = get_network_driver(device['vendor'])
    with driver(**device['connect']) as d:
        interfaces = d.get_interfaces()
        # gather state (example)
        snmp_conf = f"snmp-server community {community} RO"
        d.load_merge_candidate(config=snmp_conf)
        diff = d.compare_config()
        if diff:
            d.commit_config()
            return True, diff
        else:
            d.discard_config()
            return False, None

# parallel execution omitted for brevity

This balances safety (idempotency, dry-run), vendor abstraction, and operational visibility—making NAPALM the pragmatic choice for large, heterogeneous deployments.

EasyTechnical

18 practiced

Your team opens new branch offices every month, and each site needs a router, switches, baseline ACLs, and monitoring settings before the local IT team can use it. If you were asked to automate that provisioning flow from an empty rack to a usable site, what would you define as the source of truth, how would you keep the process repeatable, and how would you handle site-specific values without making the workflow brittle?

HardTechnical

27 practiced

You are asked to migrate manual firewall rule changes into Infrastructure as Code across multiple firewall vendors. Design the migration plan that includes policy abstraction, versioned policy as code, unit and integration tests (including simulated traffic tests), staging and production promotion, rollback strategies, and compliance reporting to meet audit requirements.

Sample Answer

**Situation & Goal**Migrate ad-hoc/manual firewall changes across multiple vendors into a repeatable, auditable Policy-as-Code pipeline that supports testing, staged promotion, rollback, and compliance reporting.

**Plan Overview**1. Policy abstraction- Define a vendor-agnostic model: objects (zones, hosts, services), rules (source, dest, ports, action), intents (allow/deny, business justification, risk level).- Implement translators (adapters) per vendor that map abstract model to vendor-specific configs (PanOS, ASA/FTD, Palo, Check Point, cloud SGs).

2. Versioned Policy-as-Code- Store policies in Git with branching model (feature -> staging -> main). Use YAML/JSON schema and enforce via CI linting and schema validation.- Tag releases; require PRs with justification, owner, and ticket ID.

3. Testing- Unit tests: schema validation, rule conflict detection, least-privilege checks, overlap/duplication detection.- Integration tests: use vendor emulators or lab firewalls in CI to deploy generated configs to ephemeral environments.- Simulated traffic tests: orchestrate traffic generator (Iperf, hping, Scapy) in isolated testbed to validate allow/deny behavior; include negative tests and timeouts.

4. Promotion & Deployment- Automated CI/CD: merge to staging triggers deployment to staging firewalls and automated test suite. After owner sign-off and successful tests, promote to production via controlled change window with automated playbooks (Ansible/Terraform/REST APIs).

5. Rollback & Safety- Always create config snapshots and checkpoint before push. Implement atomic change with canary subset (small DMZ) then progressively roll out.- Automated health checks and fast rollback job that re-applies previous tagged config if test/monitoring alarms fire.

6. Compliance & Reporting- Generate audit artifacts per change: policy diff, PR metadata, test results, deployment logs, and snapshots. Store in immutable artifact store.- Implement periodic compliance scans (rule aging, unused rules, segregation violations) and produce reports mapped to controls (PCI/DORA/SOC2).- Provide RBAC and MFA for approvals; retain retention policy for audit trail.

**Metrics & Validation**- Success metrics: reduction in emergency manual changes, MTTR for rollback, percent of rules covered by tests, audit pass rate.

This approach balances vendor heterogeneity, safety, and auditability while enabling automation and repeatable deployments.

MediumSystem Design

30 practiced

Describe the architecture and operational practices necessary to scale network automation to manage 10,000 devices across multiple regions. Discuss distributed orchestration, inventory partitioning, concurrency controls, rate-limiting, HA considerations for orchestration components, observability, and strategies for staged rollout and emergency fixes.

Unlock Full Question Bank

Get access to hundreds of Network Automation interview questions and detailed answers.

Join thousands of developers preparing for their dream job.