Automation, Orchestration, and Programmability
Domain 5 tests whether you can change the fabric repeatably and safely. Questions focus on data models, APIs, idempotency, and pipeline practice rather than on writing long scripts.
Interfaces and models
- YANG defines the data model; NETCONF, RESTCONF, and gNMI carry it. NETCONF typically uses SSH port 830, RESTCONF uses HTTPS, gNMI uses gRPC.
- Model-driven telemetry streams state changes or periodic samples instead of polling MIBs.
- Declarative tools describe the desired end state; imperative tools describe steps. Only declarative approaches are naturally idempotent.
- A source of truth (IPAM, DCIM, or a Git repository) should own VLAN, VNI, and address allocation so automation does not invent duplicates.
Pipeline practice
- Store intent in Git; run validation and a dry run in CI; deploy through a reviewed change; keep a rollback path.
- Secrets belong in a vault, never in plaintext playbooks or repositories.
Worked example
An Ansible task ensures VLAN 120 exists on a leaf with a declared name. First run reports changed. Second run reports ok with no change, proving idempotency. If the second run still reports changed, the task is probably sending raw CLI commands (imperative) rather than using a declarative resource module that compares current and desired state. The fix is to use the vendor resource module or a REST call with a state check, then add check mode so CI can detect drift before production.
Traps that cost marks
- Claiming a CLI script is idempotent because it can be rerun; rerunning is not the same as converging to desired state.
- Skipping check or dry-run mode and pushing straight to production.
- Hardcoding credentials or management IPs in templates.
- Treating orchestration and automation as identical; orchestration coordinates multiple automated steps and systems.
- Ignoring error handling so a partial configuration is left behind after a failed run.