350-401 Practice Question: Uses Ansible to manage network device…

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 routers are configured with a different enable secret that does not match the one in the Ansible vault.

  Why it's wrong here

  An incorrect enable secret in the Ansible vault would produce an immediate authentication failure — IOS would return '% Bad secrets' or 'Enable password incorrect' — causing the task to error out, not hang while waiting for a prompt. The indefinite wait suggests Ansible never even attempted to send the enable command because it did not know to use enable as the become method. Thus the failure is a missing escalation configuration, not a credential mismatch.

• ✓

  The 'ansible_connection' is set to 'network_cli' but the 'ansible_become_method' is not set to 'enable'.

  Why this is correct

  With ansible_connection: network_cli, Ansible must be told to escalate privileges by setting ansible_become: yes and ansible_become_method: enable. If the become method is omitted, the automation engine has no way to issue the enable command, so IOS remains at the user EXEC prompt and Ansible times out waiting for a privileged prompt that never arrives. The ios_command tasks then fail with a 'timeout waiting for privilege escalation prompt' error instead of returning command output.

• ✗

  The SSH key exchange is taking longer than the default 12-second timeout.

  Why it's wrong here

  SSH key exchange and the default 12-second connection timeout occur during transport establishment, before the CLI session is interactive; a problem there would surface as an unreachable host or 'SSH Error: timeout' without ever reaching a prompt. The described symptom specifically involves waiting for a shell/privilege prompt after the SSH session is already up, so it cannot be caused by key exchange latency. Therefore it is a post-authentication escalation issue, not a transport-layer timeout.

• ✗

  The ios_command module requires a different privilege level to execute 'show ip route'.

  Why it's wrong here

  The ios_command module does not enforce privilege levels; the device does, and 'show ip route' would at worst produce an IOS authorization error such as 'Invalid input' if executed from a restricted view, not an indefinite wait. The timeout shown indicates the session was never elevated to privileged EXEC mode, so the command was never actually sent. That points to the missing become_method setting, not to a requirement that the command run at a different privilege level.

Go deeper

Related to this question