Infrastructure as Code (IaC) Characteristics for Cisco DevNet Associate
Which TWO statements accurately describe characteristics of infrastructure as code (IaC) in network automation?
Quick Answer
The answer is that IaC allows network configurations to be stored in version control and tested before deployment. This is correct because Infrastructure as Code treats network state as machine-readable definition files—whether declarative (desired end state) or imperative (step-by-step)—which can be committed to Git, reviewed, and validated in a staging environment before touching production. On the Cisco DevNet Associate 200-901 exam, this characteristic tests your understanding of how tools like Ansible, Terraform, or Cisco NSO enforce consistency and prevent configuration drift. A common trap is confusing IaC with simple scripting: IaC’s key differentiator is its repeatability through version-controlled, testable templates, not just automation. Remember the memory tip “Version, Test, Repeat”—if a solution lacks version control or pre-deployment testing, it is not true IaC.
⚠ Common exam trap
Cisco often tests the misconception that IaC is only for virtual or cloud environments, when in fact it is designed to manage any programmable network device, including physical hardware, via standard interfaces like NETCONF/RESTCONF.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
IaC tools use declarative or imperative models to define the desired state of network infrastructure.
Option D is correct because IaC tools such as Terraform, Ansible, and Puppet/Chef operate on either declarative models (defining the desired end state, e.g., Terraform HCL) or imperative models (defining step-by-step commands, e.g., shell scripts), so both paradigms are valid ways to express the intended state of network infrastructure. Option E is correct because a core IaC practice is treating configuration as code: storing templates and playbooks in version control systems like Git, enabling peer review, diffing, and automated testing (e.g., CI pipelines, linters, and unit/integration tests) before pushing changes to production devices. Option A is wrong because IaC does not remove human review; change control, pull-request approvals, and validation remain essential safeguards even when automation applies the change. Option B is wrong because IaC manages existing physical and virtual devices via APIs, SSH, NETCONF, or CLI—it does not require replacing hardware with software equivalents. Option C is wrong because IaC applies broadly to physical routers, switches, firewalls, and other appliances, not only to virtual network functions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
IaC eliminates the need for manual review of configuration changes before deployment.
Why it's wrong here
IaC codifies configurations for version control and automated testing, but human review of proposed changes before merge remains a core control, not something it removes. It tempts because IaC does automate deployment, which people conflate with eliminating review gates entirely.
- ✗
IaC requires that all network devices be replaced with software-based equivalents.
Why it's wrong here
IaC manages configuration declaratively and works against physical routers and switches through their APIs and CLIs; hardware replacement is unrelated. It tempts because IaC is heavily associated with cloud and virtualised infrastructure, where software-defined equivalents are common.
- ✗
IaC is only applicable to virtual network functions, not physical devices.
Why it's wrong here
IaC applies equally to physical network devices, provisioning them via declarative templates and device APIs. It tempts because virtual network functions are frequently the first targets of automation programmes, giving the impression that IaC is scoped to them.
- ✓
IaC tools use declarative or imperative models to define the desired state of network infrastructure.
Why this is correct
Declarative models specify the intended end state and let the tool reconcile differences, while imperative models issue explicit step-by-step commands. Both are genuine IaC approaches, so this statement correctly captures how IaC defines network infrastructure desired state rather than relying on manual configuration.
- ✓
IaC allows network configurations to be stored in version control and tested before deployment.
Why this is correct
Storing configurations as code in version control enables peer review, change history and rollback, and lets teams test configurations in isolated environments before pushing to production. This is a defining IaC characteristic, satisfying the requirement for auditable, repeatable and pre-validated network automation.
Go deeper
Related to this question
About these practice questions
Courseiva writes every 200-901 question from scratch — 975 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on 200-901
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO of the following are characteristics of a declarative automation model? (Select exactly 2.)
medium- A.It requires procedural scripts
- ✓ B.You specify the desired end state
- C.Idempotency is not a concern
- ✓ D.The tool handles ordering and dependencies
- E.You specify the exact steps to achieve the state
Why B: Option B is correct because a declarative automation model is defined by describing the desired end state (for example, a Terraform HCL resource block or an Ansible task declaring 'state: present'), and the tool then works out how to reach that state. Option D is correct because in declarative tools the engine itself determines execution order and resolves dependencies, such as Terraform building a dependency graph from resource references or Ansible handling task ordering and handlers. Option A is incorrect because procedural scripts are the hallmark of imperative, not declarative, automation. Option C is incorrect because idempotency is a core concern and benefit of declarative models, ensuring repeated runs converge to the same state without unwanted changes. Option E is incorrect because specifying exact steps is the defining trait of an imperative model, whereas declarative models specify the outcome, not the steps.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.