350-401 Automation Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  manager.lock('candidate') manager.edit_config(target='candidate', config=config_payload) manager.validate('candidate') manager.commit() manager.unlock('candidate')

  Why this is correct

  This sequence correctly locks the candidate datastore, edits it with the desired configuration, validates the candidate, commits the changes to running, and then unlocks the candidate. This follows the NETCONF confirmed-commit workflow and is the standard approach when using the candidate datastore with ncclient. It ensures atomicity and prevents conflicts.

• ✗

  manager.lock('running') manager.edit_config(target='candidate', config=config_payload) manager.validate('candidate') manager.commit() manager.unlock('running')

  Why it's wrong here

  This sequence locks the running datastore but then edits the candidate datastore. Locking running does not protect candidate, and committing without a prior lock on candidate may fail if another session holds the lock. The correct workflow locks the candidate datastore before editing it, then validates and commits. This sequence is inconsistent and may lead to errors.

• ✗

  manager.lock('candidate') manager.edit_config(target='running', config=config_payload) manager.validate('candidate') manager.commit() manager.unlock('candidate')

  Why it's wrong here

  This locks the candidate datastore but then edits the running datastore. The lock on candidate is irrelevant to editing running, and editing running directly bypasses the candidate workflow. The subsequent validate on candidate will not include the changes made to running, and commit may fail or commit nothing. The operations are inconsistent and will not achieve the desired result.

• ✗

  manager.lock('running') manager.edit_config(target='running', config=config_payload) manager.validate('running') manager.commit() manager.unlock('running')

  Why it's wrong here

  Editing the running datastore directly does not use the candidate datastore, so validate and commit operations are not applicable. The validate operation typically works on candidate, and commit is used to apply candidate to running. This sequence would likely raise errors because validate on running is not supported, and commit may not be valid without a candidate.

Go deeper

Related to this question