CCNP Practice Question: Examine the following SD-WAN policy configuration…

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 policy matches routes with prefix 10.0.0.0/24 and sets the community value 100:10 on those routes before advertising them via OMP.

  Why this is correct

  In Cisco SD-WAN, a control policy configured on a vSmart controller matches OMP routes based on attributes such as prefix and applies actions before the routes are advertised via OMP. This policy uses a prefix-list to match 10.0.0.0/24 and sets the OMP community value 100:10 on those matched routes, which then propagate through the overlay to remote edges. The local RIB and routing table are not modified; only the OMP route attributes are updated for advertisement.

• ✗

  The policy matches routes with prefix 10.0.0.0/24 and sets the community 100:10 on the local router's routing table.

  Why it's wrong here

  This is incorrect because SD-WAN control policies operate exclusively in the OMP control plane, not on the local router's RIB. Setting a community on a route in the local routing table would require a traditional route-map applied to redistribution or a routing protocol, which is outside the scope of centralized vSmart policy. The policy only alters OMP route attributes as they are sent over the overlay, leaving the underlying IP routing table unchanged.

• ✗

  The policy denies all routes except 10.0.0.0/24 and sets community 100:10.

  Why it's wrong here

  The policy does not deny unmatched routes because SD-WAN control policies have an implicit default action of 'accept' unless a default action is explicitly set to reject. The policy shown only matches 10.0.0.0/24 and sets a community, but it does not contain a deny statement for other prefixes. Therefore, all other routes continue to be advertised normally without the community; denying them would require an explicit match-all or default-reject action.

• ✗

  The policy is invalid because prefix-list names cannot contain underscores.

  Why it's wrong here

  Underscores are perfectly valid in prefix-list names in Cisco SD-WAN policy configuration; the name is an arbitrary string used for local identification. There is no restriction on underscores, and they are commonly used to make policy names more readable. The policy is syntactically valid, and the only requirement is that the referenced prefix-list is defined with the same name. Thus, this is not a reason for the policy to be invalid.