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
CCNA AI and Network Operations Practice Question
Select the correct sequence of steps to retrieve a specific interface's configuration via RESTCONF and apply a change to the interface description.
⚠ Common exam trap
The key trap is confusing the order of operations: you must retrieve before modifying, and apply before verifying. Candidates often mix up the sequence, especially placing verification too early or modification before retrieval.
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
✓
Send GET request to retrieve interface configuration, parse JSON/XML response, modify the description field, send PUT request with updated configuration, send GET request to verify the change.
The correct sequence for using RESTCONF to modify an interface description is: first retrieve the current configuration with a GET request, parse the JSON or XML response, modify the description field, apply the change with a PUT or PATCH request, and finally verify the change with another GET request. This sequence is correctly described only in option A. Options B, C, and D are incorrect because they either apply changes before retrieving the configuration, modify before retrieving, or verify before applying, which would not work as intended.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Send GET request to retrieve interface configuration, parse JSON/XML response, modify the description field, send PUT request with updated configuration, send GET request to verify the change.
Why this is correct
This is the correct sequence: the GET retrieves the current interface configuration, the JSON/XML response is parsed to locate the description field, and the description is modified in the local representation. A PUT then replaces the resource with the updated configuration, and a final GET confirms the device accepted and stored the change. This order ensures the PUT is based on the actual live state and that verification occurs only after the modification is applied.
- ✗
Send PUT request to apply the change, send GET request to retrieve interface configuration, parse JSON/XML response, modify the description field, send GET request to verify the change.
Why it's wrong here
Because the PUT is sent before any GET, the request payload is not derived from the device's current state; it may omit mandatory YANG nodes or overwrite the entire interface with a partial representation. The subsequent GET and local parse/modify steps produce a corrected object, but no second PUT is issued, so that correction is never transmitted. The final GET therefore verifies the unvetted PUT, not the intended description change.
- ✗
Send GET request to retrieve interface configuration, modify the description field, send GET request to verify the change, send PUT request with updated configuration.
Why it's wrong here
This ordering places the verification GET before the PUT, so the second GET still retrieves the original, unchanged description—verifying nothing about the intended change. A modification made to a locally parsed object is never transmitted to the device, making that step inert. The only useful order is to PUT the new description and then GET to confirm it was applied.
- ✗
Send PUT request with updated configuration, send GET request to retrieve interface configuration, parse JSON/XML response, modify the description field, send GET request to verify the change.
Why it's wrong here
This option does include an 'updated configuration' in the initial PUT, but that payload was built without first retrieving the live running config, so it is a blind replacement that risks discarding existing interface settings that were not included. The GET that follows allows parsing and modifying the response, yet the modified object is never sent back to the device. Hence the later edit has no effect, and the final GET merely confirms the blindly written PUT.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.
✓Send GET request to retrieve interface configuration, parse JSON/XML response, modify the description field, send PUT request with updated configuration, send GET request to verify the change.Correct answer▾
Why this is correct
This is the correct sequence: the GET retrieves the current interface configuration, the JSON/XML response is parsed to locate the description field, and the description is modified in the local representation. A PUT then replaces the resource with the updated configuration, and a final GET confirms the device accepted and stored the change. This order ensures the PUT is based on the actual live state and that verification occurs only after the modification is applied.
✗Send PUT request to apply the change, send GET request to retrieve interface configuration, parse JSON/XML response, modify the description field, send GET request to verify the change.Wrong answer — click to see why▾
Why this is wrong here
The order is reversed; the PUT request must come after the GET and modification steps.
Why candidates choose this
Candidates might think they can directly apply a change without first retrieving the current configuration, but RESTCONF requires the full configuration to be sent in the PUT request.
✗Send GET request to retrieve interface configuration, modify the description field, send GET request to verify the change, send PUT request with updated configuration.Wrong answer — click to see why▾
Why this is wrong here
Verification should be the last step after applying the change.
Why candidates choose this
Candidates might think they need to verify the current state before applying a change, but the verification step is to confirm the change was applied correctly.
✗Send PUT request with updated configuration, send GET request to retrieve interface configuration, parse JSON/XML response, modify the description field, send GET request to verify the change.Wrong answer — click to see why▾
Why this is wrong here
The PUT request should be based on the retrieved configuration; sending it first risks losing data or causing errors.
Why candidates choose this
Candidates might think they can directly push a new configuration without first reading the existing one, but RESTCONF typically requires a read-modify-write pattern.
Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Generative AI Prompting for Network Tasks
Key term
RESTCONF
RESTCONF is a protocol that uses HTTP methods to manage and configure network devices, replacing older command-line methods with a modern web-based approach.
Key term
Interface
An interface is a point of connection or interaction between two systems, devices, or software components that allows them to exchange information or signals.
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 →
JA
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.