Drag and drop the following steps into the correct order to select and implement a network automation solution using the appropriate tool based on the use cases and differences between Puppet, Chef, Ansible, and Python.

CCNA AI and Network Operations Practice Question

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

6Step 6

Correct answer & explanation

✓

Define the network automation goal and the type of configuration changes required.

The correct order follows a systematic approach: First, define the specific network automation goal to understand the scope and constraints. Next, evaluate whether a persistent, agent-based configuration enforcement approach (Puppet/Chef) or an agentless, orchestration-driven approach (Ansible) is required. Then consider the flexibility of a scripting language like Python for custom or one-off tasks. After selecting the tool, write the automation logic (playbook, manifest, or script). Test it in a controlled environment to avoid production issues, and finally deploy and verify the automation to ensure it meets the intended outcome.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Define the network automation goal and the type of configuration changes required.
Why this is correct
Defining the automation goal and the exact configuration changes required is the essential first step because it establishes the desired end state, scope, and success criteria for the whole project. Without this, you cannot determine which tools, scripts, or test plans are relevant. For example, you must know whether you are pushing a new VLAN across 200 switches or removing a route from a single router, as the approach differs drastically.
✓
Assess whether you need agent-based continuous enforcement (Puppet/Chef) or agentless orchestration (Ansible).
Why this is correct
Assessing whether you need agent-based continuous enforcement (e.g., Puppet/Chef) or agentless orchestration (e.g., Ansible) is an architecture decision that depends on your already-defined requirements, such as whether you need to remediate configuration drift automatically. It is not the first step because you must first know what changes are needed and whether the network is on-premises, cloud, or hybrid. This tooling choice also involves operational constraints like agent installation feasibility and permission boundaries.
✓
Determine if a scripting language (Python) is suitable for custom or complex tasks.
Why this is correct
Determining if a scripting language like Python is suitable for custom tasks is an implementation-level consideration that comes after the automation goal is clear. You would evaluate Python when existing Ansible modules or Puppet types do not cover a specific, intricate logic, maybe for a custom transformation of configuration data. But this decision presumes you already know the change type and the expected outcomes, so it cannot be the starting point.
✓
Choose the most appropriate automation tool and write the automation code (playbook, manifest, or script).
Why this is correct
Choosing the most appropriate automation tool and writing the playbook, manifest, or script is the actual coding step, which clearly cannot occur until you have defined the scope and configuration changes. This step is where you translate your plan into YAML, Ruby, or Python code, so it requires a complete understanding of the target devices and the desired state. It also depends on preceding architecture choices like agent-based vs agentless, making it a later phase in the workflow.
✓
Test the automation in a non-production environment.
Why this is correct
Testing the automation in a non-production environment is a critical validation phase, but it logically follows the creation of the automation code. You need a working playbook or script before you can execute it against a lab topology that mirrors production. This step is also separate from defining the goal because you cannot devise meaningful test cases until you know the exact configuration changes and expected outcomes.
✓
Deploy and verify the automation results.
Why this is correct
Deploying and verifying the automation results is the final step in the lifecycle, where you push changes to production and check that the network behaves as intended. It relies on every prior step, including successful tests and code review, so it is the opposite of the first action. Verification might involve comparing `running-config` to the desired state, checking syslogs, or validating connectivity, but all of that presupposes a defined goal.

CCNA AI and Network Operations Practice Question

Why each option matters

Option-by-option breakdown

Related to this question