Hard Difficulty Questions

Hardware replacement

Why it fails: Policy objects control traffic forwarding, path selection and security enforcement; hardware replacement is a physical logistics and inventory task outside policy scope. It is tempting because hardware lifecycle is part of SD-WAN operations, but it is handled through device management and RMA workflows, not Policy objects.

Firmware updates

Why it fails: Prisma SD-WAN Policy objects govern traffic behaviour — path selection, QoS, security rules and application priority — not device firmware. It is tempting because firmware management is a genuine SD-WAN operational task, but it is performed through device software management, not the Policy object.

Topology View

Why it fails: The Topology View displays the network topology, including sites, links, and overlays, but it does not show the detailed policy rules or their evaluation. It can help visualize connectivity but lacks the granular policy information needed to troubleshoot why a specific VLAN's traffic is not being forwarded correctly. Therefore, it is not the best tool for verifying effective policy.

Event Log

Why it fails: The Event Log records system and policy events, such as alarms and configuration changes, but it does not provide a view of the effective policy or path selection logic. While it might show policy-related events, it does not offer the comprehensive policy evaluation details needed to diagnose a VLAN forwarding issue. Thus, it is not the appropriate tool for this task.

Flow Analytics

Why it fails: Flow Analytics provides detailed flow-level data, such as source/destination IP, ports, and application identification, but it does not show the effective policy configuration or how path selection decisions are made. While it can confirm whether traffic is flowing, it does not explain why a particular path was chosen or if a policy rule is misconfigured, making it less suitable for verifying policy application.

Configure static routes on each branch ION device that point business-critical prefixes to the high-performance circuits.

Why it fails: Static routes on every branch device do not scale and require manual updates whenever prefixes change, violating the design requirement to avoid per-application static routes. They also lack the dynamic path selection and policy-based steering that Prisma SD-WAN provides. This approach would create operational overhead and potential routing inconsistencies across many sites, making it unsuitable for a scalable data center steering design.

Use BGP communities to tag business-critical prefixes and rely on the data center routers to prefer the high-performance circuits for those tags.

Why it fails: BGP communities can influence routing at the data center edge, but they do not provide end-to-end application-aware steering from the branch. Branch traffic would still need to reach the data center first, and the SD-WAN fabric would not dynamically choose the high-performance circuit based on application identity. This approach is indirect and does not satisfy the scalable, application-based steering requirement.

Create separate virtual routing and forwarding instances per application on every branch device and map each VRF to a specific circuit.

Why it fails: Per-application VRFs on every branch device add significant configuration complexity and do not scale well across many sites. They also do not inherently provide application-aware path selection or performance-based failover. While VRFs can segment traffic, they are not the intended mechanism for steering specific applications over chosen circuits in Prisma SD-WAN, making this a poor design choice.

Increase the bandwidth of the ISP link used by the Service Connection to Prisma Access.

Why it fails: Increasing ISP bandwidth does not fix the routing problem. Internal traffic is still being sent to Prisma Access, adding latency regardless of bandwidth. The issue is policy steering, not link capacity, so this change would not resolve the slowness.

Disable Dynamic Path Selection on the Service Connection to force traffic over a single path.

Why it fails: Disabling Dynamic Path Selection does not change where internal traffic is sent. It may reduce resiliency and does not address the backhaul of internal traffic to Prisma Access. The traffic would still be inspected unnecessarily, so performance would not improve.

Configure a static route on the ION device that points internal prefixes to the Prisma Access tunnel.

Why it fails: This would reinforce the incorrect behavior by explicitly sending internal prefixes to Prisma Access. The goal is to keep internal traffic on the SD-WAN fabric, not to route it to the cloud. This change would worsen the latency issue.

ISP contract end date

Why it fails: ISP contract end date is commercial procurement data held outside the site's network definition, which instead describes circuits, interfaces, and routing attributes. It is tempting because each site does terminate physical ISP links, and would be correct when tracking circuit renewals in an asset or contract register.

User password history

Why it fails: User password history belongs to identity and authentication policy, not to the branch-site topology object that defines circuits, interfaces, and routing for a location. It is tempting because credentials are configured somewhere in the management portal, and would be correct when hardening operator account authentication rather than describing a site.

Local ISP DNS settings

Why it fails: Local ISP DNS settings affect name resolution at the branch, not the CloudBlades tunnel or policy that redirects traffic to the CSSP. DNS configuration is the correct area to check when branch clients fail to resolve SaaS hostnames, not when steering traffic.

DHCP Server scope

Why it fails: DHCP scope governs LAN address assignment and has no bearing on CloudBlades tunnel selection or traffic steering. It is tempting because DHCP appears in branch network configuration, but it is the correct focus when troubleshooting client IP allocation, not CSSP redirection.

VLAN ID matching

Why it fails: VLAN IDs are Layer 2 segmentation identifiers on the LAN side; CloudBlades steers traffic by service and tunnel, not by VLAN tag matching. VLAN configuration is the right thing to verify when isolating branch segments or mapping switch ports, not for CSSP redirection.

Monitor > Devices > WAN Edge

Why it fails: The WAN Edge device view provides system-level health, interface statistics, and control connection status for each router. It does not break down application flows or show the path selection logic per application. Although it can confirm that the broadband interface is operational, it will not reveal the policy evaluation details that caused the MPLS path to be preferred.

Monitor > Network > Topology

Why it fails: The topology view shows the physical and logical connections between sites and controllers, along with link status. It does not display per-application path selection decisions or the policy reasoning behind them. While it can confirm that both transports are up, it will not explain why the application-aware routing policy chose MPLS over broadband for a specific flow.

Monitor > Network > Interfaces

Why it fails: The Interfaces view shows per-interface traffic counters, errors, and bandwidth utilization. It can help determine whether the broadband circuit is congested or experiencing errors, but it does not show application-aware routing decisions. The administrator would see that traffic is flowing over MPLS but not understand the policy-based reason for that choice.

CPU utilization exceeding threshold

Why it fails: vManage does not have a built-in alarm for CPU utilization thresholds on vEdge routers. CPU monitoring is typically done via SNMP or syslog, and while vManage can display CPU usage, it does not generate configurable alarms for it out-of-the-box.

Interface duplex mismatch

Why it fails: While duplex mismatches can cause performance issues, vManage does not have a built-in alarm specifically for duplex mismatch. Such issues are typically detected via interface error counters and are not a standard vManage alarm type. Other tools like SNMP traps from the device might be used, but not vManage alarms.

BGP neighbor flap

Why it fails: BGP neighbor flaps are not a native vManage alarm type. vManage focuses on SD-WAN overlay events. While BGP is used in some SD-WAN designs, vManage does not directly generate alarms for BGP neighbor state changes unless integrated with external monitoring.

WAN Edge routers immediately drop all data plane traffic until they reconnect to a surviving vSmart controller.

Why it fails: WAN Edge routers do not depend on vSmart for data plane forwarding. They maintain forwarding state and continue to forward traffic based on existing OMP routes and local policies even if the vSmart connection is lost. Dropping all data plane traffic would defeat the purpose of the distributed control plane design, so this statement is incorrect.

WAN Edge routers stop advertising their TLOCs to other sites until a vSmart controller is reachable again.

Why it fails: WAN Edge routers continue to advertise their TLOCs through the surviving vSmart controllers or via direct OMP peering if configured. They do not stop advertising simply because one vSmart controller is down. Halting advertisements would disrupt fabric connectivity and is not the expected behavior during a vSmart failover.

WAN Edge routers revert to a default route and forward all traffic to the vBond orchestrator until a vSmart controller is available.

Why it fails: vBond is responsible for initial authentication and orchestration, not for data plane forwarding. WAN Edge routers do not send traffic to vBond as a fallback. They rely on their existing OMP routes and policies. This statement misrepresents the role of vBond and the failover behavior, so it is incorrect.

IPsec Tunnel Groups

Why it fails: IPsec tunnel groups encrypt and authenticate traffic between sites, providing confidentiality rather than logical separation between user groups. Tunnel groups are the right choice when securing site-to-site connectivity, but they do not create the distinct segments HR, Engineering, and Guest require.

Subnet Masking

Why it fails: Subnet masking divides an address space into broadcast domains, but SD-WAN fabric segmentation requires a construct the overlay recognises end-to-end. Subnetting is the right tool for IP address planning and routing hierarchy, not for isolating HR, Engineering, and Guest traffic across transport links.

VLAN Tagging

Why it fails: VLAN tagging provides Layer 2 separation within a single switched domain, but tags are not carried across the SD-WAN overlay unless mapped to a fabric-level construct. VLANs are correct for isolating traffic on one LAN, not for maintaining isolation across multiple WAN transports.

Run the CLI command 'show ipsec dpd' on the ION device.

Why it fails: The command 'show ipsec dpd' is not a valid command on ION devices. Prisma SD-WAN uses a proprietary CLI, and IPsec DPD settings are not exposed via that specific command. The administrator would need to use the correct diagnostic commands or the orchestrator interface to view DPD-related information.

Check the ION device's local syslog for DPD messages.

Why it fails: While syslog may contain some IPsec events, DPD configuration and detailed statistics are not typically logged there. The orchestrator provides a more direct and real-time view of DPD status. Relying on syslog alone would be inefficient and might miss critical DPD-related data needed for troubleshooting.

Use the 'debug ipsec' command on the ION device to enable DPD logging.

Why it fails: The 'debug ipsec' command is not available on ION devices. Prisma SD-WAN uses a different debugging framework, and enabling DPD logging is not done via that command. The orchestrator is the correct place to view DPD statistics without impacting device performance.

Ensure that the ION devices are licensed for SD-WAN and have valid certificates.

Why it fails: Licensing and certificates are required for the ION devices to communicate with the Prisma SD-WAN controller, but they do not directly affect IPsec tunnel establishment between devices. Once the devices are operational and connected to the controller, they can form tunnels regardless of licensing. This is not the primary cause of tunnel failure.

Review the firewall rules on the ION device to see if they are blocking IPsec traffic.

Why it fails: Firewall rules on the ION device typically apply to traffic traversing the tunnel, not to the IPsec negotiation itself. IPsec negotiation uses UDP ports 500 and 4500, which are usually allowed by default. While a firewall could block these, it is less likely than a misconfiguration in the IPsec parameters. The administrator should first check the IPsec settings.

Check the BGP configuration to ensure that route advertisements are being exchanged.

Why it fails: BGP is used for route exchange over an established tunnel. If the IPsec tunnel is not up, BGP cannot form a session. Therefore, checking BGP is premature; the tunnel must be established first. The issue is at the IPsec layer, not the routing layer.

show bgp summary

Why it fails: While 'show bgp summary' provides an overview of BGP neighbor states and prefix counts, it does not show the actual routes received. It would indicate if the BGP session is established and how many prefixes are received, but not the specific routes. This command is useful for a quick check but insufficient to verify route details.

show route bgp

Why it fails: 'show route bgp' displays the BGP routes in the routing table, but it does not show which neighbor advertised them or the full BGP attributes. While it can confirm if routes are installed, it lacks the neighbor-specific detail needed to troubleshoot why routes are not being received from a particular neighbor.

show ip bgp neighbors <neighbor-ip> routes

Why it fails: This command is not valid on the ION device. The correct syntax to view routes received from a specific neighbor is 'show bgp neighbor <neighbor-ip> routes'. Using incorrect syntax will result in an error. It is crucial to use the correct command to avoid unnecessary delays in troubleshooting.

show route table

Why it fails: The 'show route table' command shows the overall routing table, which includes routes from all sources, not just BGP. While it can indicate a loop, it does not specifically show BGP-learned routes or their attributes, making it less useful for diagnosing BGP-specific issues.

show ip bgp summary

Why it fails: The 'show ip bgp summary' command, if available, typically provides a summary of BGP neighbor states and prefix counts, but not the detailed routes themselves. It is useful for a quick health check but insufficient for analyzing received routes in detail.

show bgp neighbors

Why it fails: The 'show bgp neighbors' command provides information about BGP neighbor relationships, such as peer addresses and session states, but it does not display the actual routes received. To see received routes, a different command is needed that shows the BGP table.

DPD timeout

Why it fails: The DPD timeout is the duration to wait for a DPD response before considering the probe missed. While increasing the timeout can help, it is not the parameter that controls the number of missed probes. The retry count is more directly related to tolerance of delays because it allows multiple missed probes.

DPD mode

Why it fails: DPD mode typically refers to on-demand or periodic DPD. Changing the mode might affect when DPD is triggered but does not directly control the tolerance to temporary delays. The retry count is the specific parameter that determines how many missed probes are allowed before declaring the peer dead.

DPD interval

Why it fails: The DPD interval controls how often DPD probes are sent. Increasing the interval might reduce the frequency of probes but does not directly affect tolerance to delays; it could actually delay detection of a dead peer. Adjusting the interval alone is not the primary parameter to increase tolerance.

Set the LTE interface's bandwidth to zero in the interface configuration so no traffic can be sent over it.

Why it fails: Setting bandwidth to zero would prevent the interface from being used at all, including during a broadband failure. The LTE circuit would be effectively disabled, so failover would not work. Bandwidth values are used for capacity planning and QoS, not for controlling active/standby state.

Apply a QoS policy that marks all traffic as low priority on the LTE interface, causing the SD-WAN fabric to avoid it.

Why it fails: QoS marking affects prioritization within a path but does not prevent a path from being used. Traffic could still be sent over LTE if the path is considered available. The requirement is strict: no LTE traffic unless the broadband fails. QoS alone cannot enforce that behavior; a standby WAN configuration is required.

Configure a load balancing policy across both WAN interfaces with a higher weight on the broadband circuit.

Why it fails: Load balancing distributes traffic across both interfaces, even if one has a lower weight. This would cause some traffic to traverse the LTE circuit during normal operation, violating the requirement that LTE must carry no traffic unless the broadband circuit fails. Weighted load balancing is not the same as active/standby failover.

Cloud application popularity

Why it fails: The check sequence validates hardware, licensing and connectivity to the controller, not application popularity, which is a monitoring statistic gathered later. Popularity data is tempting because the dashboard displays it, but startup checks verify device readiness, not traffic analytics.

User browser history

Why it fails: Startup checks verify hardware, licensing and controller reachability; browser history is user data never inspected by the device. It is tempting because the ION device inspects traffic, but that inspection concerns flow classification and policy, not per-user browsing records.

Check the ION device's system logs for policy deny messages.

Why it fails: While system logs can show policy deny events, Prisma SD-WAN application policies do not typically deny traffic; they direct it based on application characteristics. Deny actions are usually part of security policies, not application policies. Therefore, checking for policy deny messages in system logs is unlikely to reveal why the application policy is not being applied as expected. The administrator should focus on policy configuration and traffic flow analysis instead.

Verify that the ION device has the latest software version installed.

Why it fails: While software bugs can cause unexpected behavior, intermittent packet loss on a specific application is more likely due to policy misconfiguration than a software version issue. Upgrading software is a general troubleshooting step but does not directly verify policy application. The administrator should first confirm policy configuration and flow behavior before considering software updates, which could introduce other variables.

Run a traceroute from the ION device to the application server to identify the path taken.

Why it fails: Traceroute shows the network path but does not indicate which application policy was applied. It can help identify routing issues, but packet loss due to policy misconfiguration would not be revealed by traceroute alone. The administrator needs to see the policy decision, which is available through Flow Analytics and policy stack review. Traceroute is a useful complementary tool but does not directly verify policy application.

Enable BGP on the branch ION device and peer with the firewall using an eBGP session.

Why it fails: BGP peering requires the firewall to support and be configured for BGP, but the scenario states it does not participate in dynamic routing. Attempting an eBGP session would fail to establish, and the data center prefix would never be learned. This violates the constraint that the firewall must remain unchanged.

Enable NAT on the branch ION device so the data center subnet appears as a directly connected network.

Why it fails: NAT translates addresses but does not advertise prefixes into a routing domain. Making the subnet appear directly connected via NAT would not inform other ION devices how to reach it, and it would break end-to-end addressing for return traffic. NAT is unrelated to the requirement to propagate the prefix.

Enable OSPF on the branch LAN interface and redistribute connected routes.

Why it fails: OSPF requires the neighboring device to run the same protocol and form an adjacency. The third-party firewall is explicitly static-only and does not participate in dynamic routing, so no adjacency can form. Advertising connected routes via OSPF on the LAN interface would not propagate the data center subnet into the fabric in this design.

The 'Low Latency' action requires a path quality profile to be associated with the policy.

Why it fails: While path quality profiles are used for monitoring, the 'Low Latency' action itself does not require a separate profile to be associated; it uses the built-in latency metric. The issue is more likely related to the order of policy evaluation or missing criteria.

The 'Low Latency' action only works for traffic that is already marked with DSCP EF.

Why it fails: The 'Low Latency' action does not depend on DSCP markings; it can match traffic based on application identification or other criteria. DSCP is not a prerequisite for this action, so this is not the cause of the problem.

The branch ION device does not have a second WAN link configured for failover.

Why it fails: The scenario states there are two WAN links, and the 'Low Latency' action can use any available path. The issue is not the absence of a second link but rather the policy evaluation order that prevents the action from taking effect.