Network Automation and Programmability
Core concepts
Understand the shift from CLI-driven change to model-driven, idempotent automation. Know the difference between imperative scripts and declarative configuration, and the role of YANG models, NETCONF, RESTCONF, and gRPC/gNMI. Be able to explain REST fundamentals (statelessness, HTTP verbs, status codes), JSON and XML structure, and how version control, CI pipelines, and templating (Jinja-style) support repeatable deployments. Recognize the value of source of truth, drift detection, and intent-based validation.
Traps in questions
A common trap is confusing idempotence with "runs without error": idempotent means repeated runs converge to the same state. Another is treating an HTTP 200 as proof the device applied the change; the response may only acknowledge receipt. Questions may also conflate telemetry (streaming, push) with polling (pull). Watch for answers that automate a bad process faster without adding validation.
Worked rule of thumb
Automate the verification, not just the change. Example: a template generates VLAN configuration for 50 switches. Before pushing, render the config and diff against the running state; after pushing, query operational state through the API and compare to the intended model. If any device deviates, fail the pipeline and alert rather than silently retrying. This makes drift visible and keeps the source of truth authoritative.
Practical guidance
Store credentials securely, prefer structured data over screen-scraping CLI output, and keep a tested rollback path. Treat automation code with the same review rigor as production configuration.