200-301 - Automation and Programmability (10% of the exam) - Section 6.6
Recognise the capabilities of configuration management mechanisms, including Ansible and Terraform.
Recognise how configuration management tools push a desired-state, idempotent configuration to many devices instead of hand-editing each, and that the v1.1 outline centres on agentless Ansible (playbooks over SSH) and Terraform (declarative infrastructure as code). Distinguish their roles: Ansible for device configuration and orchestration, Terraform for provisioning and managing infrastructure state.
Configuration managementAnsible playbooksTerraformIdempotencyInfrastructure as code
Practice question for this objective
lock_openFree sampleAutomation and Programmabilitymedium
A team is choosing a configuration management tool to enforce device state across hundreds of routers. They specifically want an agentless tool that connects over SSH and describes the desired state in YAML playbooks. Which tool matches these characteristics?
AA tool that requires a persistent agent on every router and uses a custom Ruby-based domain-specific language
BTerraform, which uses HashiCorp Configuration Language to provision and manage infrastructure declaratively
CAnsible, which is agentless, pushes configuration over SSH, and defines tasks in YAML playbookscheck_circle Correct
DA pull-based tool where each router runs a local agent that periodically fetches its catalogue from a central master
Ansible is agentless, pushes changes over SSH, and uses YAML playbooks to describe desired device state. Ansible needs no software agent installed on managed nodes, connecting over SSH from a control machine and applying tasks written as YAML playbooks, which is why it fits an agentless, SSH-driven, YAML-based requirement.
Why A is wrong: This describes the agent-based, DSL-driven model of retired tools rather than an agentless YAML tool, so it fails the agentless and YAML requirements.
Why B is wrong: Terraform is declarative and infrastructure-focused, but it uses HCL rather than YAML playbooks and is aimed at provisioning resources, so it does not match the YAML-over-SSH description.
Why C is correct: Ansible runs without a persistent device agent, drives changes over SSH from a control node, and expresses desired state in YAML playbooks, matching every requirement.
Why D is wrong: A periodic pull model with a local agent on every device is the opposite of the agentless push approach the team asked for.
Answers that look right on this material and are not. Each one is a distractor from a different question in the 200-301 bank for this domain.
Ansible needs a dedicated agent daemon installed and running on every managed device before any playbook task can execute against it.
errorWhy it is wrong: This sounds like pull-based tools that use agents, but Ansible is agentless, so requiring a daemon on each device misstates how it works.
Use a tool that requires a persistent agent daemon to be installed and running on each router before any configuration can be applied.
errorWhy it is wrong: The routers have no extra software and the team wants an agentless approach, so a tool depending on a per-device agent daemon directly violates the stated constraints.
It installs a lightweight client on every device that polls a central server for new configuration
errorWhy it is wrong: Tempting because some tools use a poll-based agent, but that is not how Ansible works; describing a per-device client contradicts its agentless push model.