CCNP Practice Question: An engineer is writing an Ansible playbook to…

Answer analysis

Option-by-option breakdown

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

• ✗

  The Ansible control node is using an outdated version of the nxos_ospf module that does not support idempotency.

  Why it's wrong here

  The nxos_ospf module has supported idempotency for many releases, so an outright lack of idempotency is not a credible cause. Even if the collection were outdated, the uniform 'changed' status on all switches suggests a playbook-level comparison failure (omitted parameters) rather than a module defect. Additionally, updating the module would not address the fact that the desired state configuration is incomplete relative to what the module manages.

• ✓

  The playbook does not specify all OSPF parameters, such as 'router-id', causing the module to detect a difference with the running configuration.

  Why this is correct

  The playbook is likely omitting OSPF attributes that the nxos_ospf module tracks, such as 'router-id'. When a parameter is not specified, the module may treat the desired value as empty or default (e.g., the router-id derived from the loopback address), while the running configuration contains an explicit value, causing the module to detect a difference and report 'changed'. This is a classic idempotency issue: the module does not ignore unspecified parameters; it attempts to reconcile the configuration to the playbook's declared state, and every run sees the same mismatch.

• ✗

  The switches have different NX-OS versions, causing the module to behave inconsistently.

  Why it's wrong here

  If the switches were running different NX-OS versions, you would typically see inconsistent behavior across the fleet—some devices changing and others not—depending on each version's defaults and module compatibility. Here, the fact that all switches report 'changed' points to a consistent, playbook-driven cause rather than a version-specific inconsistency. Moreover, the nxos_ospf module normalizes standard OSPF settings across NX-OS releases, so version skew would be an unlikely explanation for a uniform idempotency failure.

• ✗

  The engineer forgot to use the '--check' flag to verify idempotency.

  Why it's wrong here

  The --check flag performs a dry run, predicting whether changes would be made without actually applying them; it does not change whether the module is idempotent. Forgetting it would only mean the engineer didn't preview the changes, not that the playbook became non-idempotent. In fact, if the engineer ran --check, it would still report 'changed' because the underlying configuration mismatch (missing OSPF parameters) remains, so the root cause is an incomplete desired state, not the lack of a flag.