Automation and DevOps Fundamentals
Automation in networking means replacing manual CLI work with repeatable, versioned, machine-executed processes. A candidate must understand the core DevOps vocabulary: idempotency (running a task repeatedly yields the same end state), declarative vs. imperative models (describe the desired end state vs. list the steps), infrastructure as code (IaC), configuration drift (live state diverging from intended state), source of truth, and the pipeline concept (commit → validate → test → deploy → verify).
Know the tool categories and what they are for: configuration management (Ansible, Salt), device libraries (Junos PyEZ), templating (Jinja2), version control (Git), CI runners, and orchestration. Understand the difference between push (controller sends config to devices) and pull (device fetches its intended state) models, and between agent-based and agentless operation - a common trap is assuming Ansible needs an agent on the device (it does not; it uses SSH/NETCONF/REST).
Traps to watch: conflating idempotent with automatic; assuming automation removes the need for change control; and treating orchestration (coordinating multiple systems) as identical to automation (executing a single task). Also expect questions on the business drivers - consistency, reduced human error, faster rollback, auditability - and on where automation should not be used without guardrails (e.g., production changes without validation or peer review).
Rule of thumb: if a task is repeated, error-prone, and has a verifiable end state, it is a candidate for automation; if it requires judgment with no clear success criteria, keep a human in the loop.
Worked example: A team pushes the same VLAN config to 200 switches nightly. Because the playbook declares desired state and only changes what differs, re-running it produces no changes - this is idempotency, not a failure.