350-401 Practice Question: Is using Ansible to push ACL changes to a group…

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 have a different IOS version that interprets 'outbound' as 'in'.

  Why it's wrong here

  The direction parameter is validated by the Ansible module itself, not by the router's IOS. The `ios_acl_interfaces` module only accepts the exact string values `in` or `out` for `direction`, so passing `outbound` would either cause a validation error or be ignored/defaulted; it cannot be reinterpreted by the device. Different IOS versions do not change how the module handles the parameter because the module runs on the control node and translates the validated value into the correct CLI command. Thus, the router's IOS version is irrelevant to the symptom.

• ✓

  The playbook uses 'direction: outbound' but the module expects 'direction: out'.

  Why this is correct

  This is the root cause: `ios_acl_interfaces` requires `direction` to be literally `in` or `out`, and `outbound` is not a valid enum value. If the module does not immediately raise an argument-spec error, it may silently fall back to the default direction, which is `in`, thereby applying the ACL to inbound traffic. The observed behavior matches exactly: the ACL is active but filtering the wrong direction. Correcting the value to `out` would produce the intended outbound traffic filtering.

• ✗

  The engineer forgot to include the 'state: present' parameter, so the module did not apply the ACL.

  Why it's wrong here

  In Ansible's `ios_acl_interfaces`, `state: present` is the default behavior, so omitting it would still apply the configured ACLs to the interface. If the module for some reason did not apply the ACL, the interface would have no `ip access-group` binding at all, resulting in no ACL filtering for either direction. The problem here is an ACL that is actually active but applying inbound, which indicates a successful application with the wrong direction parameter—not a failure to apply anything. Hence, this option does not explain the symptom.

• ✗

  The ACL itself is defined with the wrong direction in the playbook.

  Why it's wrong here

  The ACL definition itself is direction-agnostic; it contains only match criteria (like source/destination addresses) and actions (permit/deny). The direction in which the ACL is evaluated is determined exclusively by the `direction` field in the interface's `access_groups` configuration, which is part of the module's interface-level parameters. If the ACL rules themselves were incorrect, the filtering action would be wrong irrespective of direction, but the symptom of applying inbound when outbound was intended points to the binding configuration, not the ACL content. Therefore, defining the ACL with a 'wrong direction' is not a valid explanation.

Go deeper

Related to this question