Instiq

5Infrastructure and Automation

Practice questions →Glossary →
  • 5.1Model-driven programmability and IaC

    Covers the value of moving from manual CLI configuration to Infrastructure as Code (IaC), the IaC principles of being declarative, idempotent, and version-controlled, and choosing between device-level automation that touches each device directly and controller-level automation that goes through a controller's intent, framed as the judgment of "at which layer should this operational problem be automated."

  • 5.2Testing, CI/CD, and automation tools

    Covers the CI/CD pipeline (lint -> test -> deploy) for shipping network changes safely, Cisco Modeling Labs (CML) for trying changes in a virtual lab, pyATS for validating state, and the strengths of Ansible (agentless, idempotent), Terraform (declarative, state management), and Cisco NSO (multi-vendor, service model), framed as the judgment of "what does this pipeline stage protect" and "which tool for this requirement."

  • 5.3Reading automation workflows

    Builds the ability to read a given Python (requests/SDK) script, Ansible playbook, or bash script and determine "what it automates, on which devices, and how." From hosts/tasks/modules/loops/backup/when conditions you judge whether it is idempotent config delivery, information gathering, or backup, and learn to spot dangerous operations (unconditional save/reload).

  • 5.4Interpreting responses and models

    Builds the ability to read RESTCONF/NETCONF responses (JSON/XML, <ok/>, rpc-reply), the underlying YANG data model (the container/list/leaf hierarchy), and the unified diff representing change (the @@ hunk, +/- lines), so you can judge "is this response success or failure," "what does this part of the model represent," and "what does this diff actually change."

  • 5.5Code review and interpreting sequence diagrams

    Builds the ability to grow automation code safely through code review principles (small PRs; emphasis on readability/correctness/security; knowledge sharing) and their benefits, and to read the order and dependency of API calls (token fetch -> GET -> 429 -> retry, etc.) from a sequence diagram (actors/lifelines, request/response arrows, time flowing top to bottom).