Drag a concept onto its matching description — or click a concept then click the description.
Structured data format
Data-modeling language
Access-related value used by a client
Secure transport for API communication
Match each automation-related term to the description that best fits it.
Drag a concept onto its matching description — or click a concept then click the description.
Structured data format
Data-modeling language
Access-related value used by a client
Secure transport for API communication
⚠ Common exam trap
A common mistake is confusing declarative with imperative. Declarative focuses on 'what' (desired state), while imperative focuses on 'how' (step-by-step). Also, idempotency is often conflated with idempotent operations in HTTP methods, but here it refers to automation tasks.
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
Idempotent: An operation that can be applied multiple times without changing the result beyond the initial application.
The question requires matching automation-related terms to their correct descriptions. Idempotent means that an operation can be applied multiple times without changing the result after the first application. Declarative is a style where the user defines the desired state and the system determines the steps to achieve it. Imperative is a style where explicit step-by-step instructions are given. Orchestration refers to the automated coordination of multiple systems or services to complete a workflow. Each description aligns precisely with these concepts.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
Idempotent: An operation that can be applied multiple times without changing the result beyond the initial application.
Why this is correct
An idempotent operation produces the same final state whether it is applied once or many times; for example, setting a hostname to 'R1' is idempotent, but adding a duplicate network route may not be unless the module checks for existence first. This property gives network automation tools the ability to re-run configs safely without causing errors or configuration drift. The description accurately reflects that repeated applications do not alter the result beyond the initial application.
Declarative: A style where the desired state is defined, and the system determines the steps to achieve it.
Why this is correct
Declarative automation lets you specify the desired end state (e.g., 'ensure interface GigabitEthernet0/1 is configured with IP 192.168.1.1/24') without dictating the commands to get there. The tool compares the current state to the desired state and determines the necessary actions, such as Terraform or Ansible's 'state=present' modules. This directly matches the description of defining the desired state while the system chooses the steps.
Imperative: A style where explicit step-by-step instructions are given to achieve a desired state.
Why this is correct
Imperative automation is like a procedural script that executes a fixed sequence of commands in a specific order, such as a Python script using Netmiko to push a series of CLI commands to a router. The system does not infer the goal; it simply follows the explicit, step-by-step instructions exactly as written. This aligns with the description of giving explicit steps to achieve a desired state, which is the defining characteristic of imperative automation.
Orchestration: The automated coordination and management of multiple systems or services to achieve a workflow.
Why this is correct
Orchestration goes beyond a single automated task by coordinating multiple systems, services, and workflows into a cohesive process, often with dependency sequencing, retries, and error handling. Tools like Kubernetes coordinate containers, or Ansible Tower/AWX manage multi-tier application deployments across servers. The description captures this cross-system coordination and management, which is the essence of orchestration.
Go deeper
About these practice questions
This 200-301 question is part of Courseiva's 1,389-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-301 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-301 exam.