CCNP 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.

• ✗

  Set ansible_ssh_private_key_file in the inventory but omit the passphrase

  Why it's wrong here

  Setting ansible_ssh_private_key_file in the inventory tells Ansible which private key file to use for SSH connections, but it does not unlock that key. If the key is encrypted with a passphrase, Ansible cannot read it without the passphrase, and simply omitting the passphrase from the inventory or command line will not bypass that requirement. The key must be decrypted and loaded into the SSH agent, which is exactly what ssh-add accomplishes; otherwise, the SSH connection will fail with a 'Permission denied' error, even though the key file path is correct.

• ✗

  Set ansible_user to the correct username in the inventory

  Why it's wrong here

  Configuring ansible_user to the correct username in the inventory is necessary for any SSH connection, but it only defines the SSH login identity, not the authentication mechanism. A username alone cannot authenticate to a device that requires a specific private key, especially one protected by a passphrase. Ansible still needs an available, decrypted key, either via the SSH agent or an explicit passphrase, so this setting alone does not solve the passphrase issue or load the key into the agent.

• ✓

  Run ssh-add on the control node to add the private key to the SSH agent

  Why this is correct

  Running ssh-add on the control node is the correct solution because it loads the passphrase-protected private key into the running SSH agent, where its decrypted form is retained for the duration of the agent session. Once the key is in the agent, Ansible's SSH connections can use it transparently without prompting for the passphrase, since the agent responds to authentication requests. This directly addresses the root cause: the key must be pre-authenticated to the SSH agent before Ansible attempts to connect, and ssh-add is the standard way to do that in an automated, non-interactive workflow.

• ✗

  Enable keyboard-interactive authentication on the IOS devices

  Why it's wrong here

  Enabling keyboard-interactive authentication on the IOS devices would allow interactive password or challenge-response authentication, but it is unrelated to SSH key authentication. The problem here is a passphrase-protected private key, not a password prompt needing a keyboard-interactive exchange. IOS devices would still require the key to be presented, and keyboard-interactive would not make Ansible supply the passphrase, so this option fails to address the key-loading requirement and could even introduce an unintended security weakness by enabling interactive login methods.