Select Two (Multi-Select) 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.

The device's management interface is configured with a static IP address.

Why it fails: A static IP address on the management interface is not required for control connection establishment. The device can use DHCP or other methods to obtain an IP. The control tunnel is established over the WAN interface, not the management interface, so this check is irrelevant to the described issue.

The device's local firewall is allowing outbound UDP port 4500.

Why it fails: While UDP port 4500 is used for NAT traversal in IPsec, the control connection to the Prisma SD-WAN Controller typically uses TCP port 443. Blocking UDP 4500 might affect data plane tunnels, but it would not prevent the control connection from forming due to certificate or licensing issues. This is a connectivity check, not an identity check.

The device's software version matches the controller's version exactly.

Why it fails: While version compatibility is important, the controller supports a range of software versions and does not require an exact match. Mismatched versions might cause feature discrepancies, but they do not prevent the control connection from forming due to identity or authorization failures. This is not a primary check for certificate or licensing issues.

Background system backups

Why it fails: Background system backups are delay-tolerant bulk transfers, so prioritising them consumes bandwidth that latency-sensitive traffic needs. It is tempting because backups matter for recovery, but QoS should favour real-time voice and video plus business-critical interactive applications; backups belong in a lower or best-effort class.

Operating system updates

Why it fails: Operating system updates are large, deferrable background transfers, so prioritising them delays latency-sensitive voice and video that QoS exists to protect. They are tempting because they consume heavy bandwidth, but QoS ranks by delay tolerance, not size; such bulk traffic belongs in a low-priority class.

Social media browsing

Why it fails: Social media browsing is elastic, latency-tolerant and bandwidth-hungry, so prioritising it starves voice and interactive traffic that QoS exists to protect. It is tempting because it dominates volume, but QoS marks by latency sensitivity, not popularity; bulk recreational flows belong in a default or scavenger class.

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.

A BGP peer between the clinic CPE and the guest Wi-Fi controller

Why it fails: A guest Wi-Fi controller is not a routing peer and does not participate in BGP with the clinic CPE. Peering BGP with it would not help route guest or internal traffic and is not a valid Prisma SD-WAN design element for meeting the stated connectivity requirements.

A NAT pool on the data center CPE for all clinic guest traffic

Why it fails: NAT for guest traffic belongs at the point where that traffic exits to the internet, which in this design is the clinic's local breakout, not the data center CPE. Placing the NAT pool at the data center would force guest traffic to traverse the fabric and is inconsistent with the goal of direct internet access from each clinic.

A static route on the clinic CPE pointing all traffic to the data center gateway

Why it fails: Pointing all traffic to the data center gateway would backhaul guest internet traffic through the data center, contradicting the requirement for direct internet access at the clinic. It also bypasses the SD-WAN fabric's policy-based path selection, so it is not an appropriate design element for this scenario.

Review the BIOS logs

Why it fails: BIOS logs record firmware-level POST and hardware initialisation events, not ION WAN interface state, so they cannot confirm link status or IP assignment. They are consulted when diagnosing boot failures or hardware faults, which is a different troubleshooting scenario entirely.

Ping the device from the internet

Why it fails: Pinging from the internet tests reachability of the device's public address, not the operational state of its WAN interface. It is tempting because a reply suggests connectivity, but ICMP may be blocked or answered via another path. Interface status is verified through the Orchestrator or local CLI diagnostics.

Check the DNS logs

Why it fails: DNS logs record name-resolution queries and responses, revealing nothing about an ION WAN interface's link, address or tunnel state. They are the right source when investigating resolution failures or suspicious domain lookups, not interface status verification.

Device temperature

Why it fails: Path health is judged from probe loss, latency and jitter across the tunnel; device temperature is chassis telemetry unrelated to WAN forwarding. It is tempting because thermal state can indicate hardware stress, and would be the correct check when diagnosing an appliance overheating or shutting down.

User authentication status

Why it fails: User authentication concerns who may administer or connect through the device, not whether the underlying WAN path is forwarding acceptably. It is tempting because authentication failures do block access, and would be the correct check when troubleshooting management-plane or remote-access login problems.

Local disk space

Why it fails: Local disk space reflects logging or image storage on the appliance, not the quality of the WAN path carrying traffic. It is tempting because disk exhaustion does degrade device operation, and would be the right check when troubleshooting failed upgrades, logging or software image staging.

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.

User management.

Why it fails: User management is under Administration.

Policy configuration.

Why it fails: Policy configuration is under the Configuration menu.

Software image repository.

Why it fails: Repository is under Maintenance.

Hardware-less branch deployments

Why it fails: Prisma SD-WAN branch sites still require an ION appliance or virtual instance to terminate tunnels and enforce policy; the design changes topology, not the need for branch hardware. It tempts because virtual ION instances remove physical appliances in some deployments, but the stem asks about hub-and-spoke benefits.

Infinite bandwidth at the branch

Why it fails: Hub-and-spoke aggregates branch traffic through central hubs, so branch circuits still cap throughput at their subscribed rate; no design grants limitless bandwidth. It tempts because hub concentration can reduce the number of expensive dedicated links and improve aggregate utilisation across sites.

Enable ECMP across the MPLS and internet interfaces so both circuits forward PCI traffic simultaneously for higher availability

Why it fails: ECMP would spread PCI-scoped flows across both circuits at once, which contradicts the requirement for deterministic primary and secondary behavior. It also complicates inline inspection because return traffic and flow state could land on different paths, and Prisma SD-WAN path selection for a backup design is expressed through path groups, not by forcing equal-cost forwarding.

Configure a NAT pool on the internet interface and advertise it into the MPLS routing domain so the firewall sees a single source address

Why it fails: NAT translation does not provide deterministic path preference, and advertising an internet-side NAT pool into the MPLS domain would create asymmetric routing and confuse return-path selection. The inspection requirement is met by steering traffic to the firewall through a service link, not by rewriting addresses to collapse the two transports into one apparent path.

Apply a QoS policy that marks PCI traffic as real-time and maps it to the MPLS interface only

Why it fails: QoS marking influences queueing and scheduling treatment; it does not by itself pin traffic to a specific WAN interface or provide failover behavior. Prisma SD-WAN path selection is governed by path groups and policy sets, so relying on a QoS class to force PCI traffic onto MPLS would leave the design without a defined failover mechanism when MPLS degrades.

Review the OMP routes to ensure the voice prefix is advertised with the correct TLOC.

Why it fails: OMP routes advertise reachability but do not enforce application-aware routing decisions. The policy uses SLA metrics to choose among available TLOCs. While OMP is important for route propagation, it does not verify that the policy is selecting the correct path based on SLA. The issue is likely in the policy application, not route advertisement.

Check the syslog on the branch router for messages about policy failures.

Why it fails: Syslog may contain errors, but application-aware routing does not typically log policy decisions or failures at a granular level. The absence of syslog messages does not confirm the policy is working. The most reliable verification is through vManage statistics and BFD/SLA status, not syslog. Syslog is more useful for control plane or interface errors.

Run a packet capture on the voice VLAN to analyze the RTP stream.

Why it fails: Packet capture can show the actual traffic but does not directly indicate why the policy chose a particular path. It is useful for deeper analysis but not the first step to verify policy application. The policy decisions are based on SLA metrics and BFD, so checking those is more direct. Packet capture would not show the policy's path selection logic.

Alarms

Why it fails: Alarms show active notifications about faults or thresholds, but they do not provide a comprehensive view of all control connections or data plane tunnels. While alarms might indicate issues, they are not the dedicated screens to verify the overall health of control and data plane connectivity.

Interface Statistics

Why it fails: Interface Statistics provide bandwidth, error, and discard counters for physical and logical interfaces. While useful for performance monitoring, they do not directly show the status of control connections or data plane tunnels, so they are not the primary screens to verify control and data plane health.

Application Awareness

Why it fails: Application Awareness shows recognized applications and their traffic characteristics, which is useful for policy verification but does not indicate control connection or data plane tunnel status. It is not the right screen to confirm fabric health after an upgrade.

The vSmart controller is running a software version older than the WAN edge device.

Why it fails: While version compatibility matters for overall fabric health, an out-of-sync indicator specifically reflects a mismatch between the device's applied configuration or policy and the intended state. A version difference alone does not directly produce the out-of-sync state described, making this a less relevant verification step here.

The device's clock is not synchronized with an NTP server.

Why it fails: Time synchronization affects certificate validation and logging, but it does not by itself cause a configuration or policy out-of-sync state. Since the control connection is reported as up, NTP drift is not the condition that explains the mismatch between the device and the intended configuration in this scenario.

The device's certificate has expired and it is operating in a degraded mode.

Why it fails: An expired certificate would typically break or prevent the control connection entirely rather than leave it up with an out-of-sync policy state. Since the scenario states the control connection appears up, certificate expiry is not the condition that explains the out-of-sync status in this case.

Configure a GRE tunnel between the ION device and the Prisma Access service infrastructure.

Why it fails: A GRE tunnel is not the supported mechanism for Service Connection to Prisma Access. While GRE can carry traffic, it lacks the integrated policy, path selection, and log correlation features of a Service Connection. Using GRE would not meet the unified SASE integration requirements.

Manually export Prisma Access logs and import them into the Prisma SD-WAN controller.

Why it fails: Manual log export and import is not part of the Unified SASE integration. The unified portal automatically correlates logs from both products when they are in the same tenant. Manual processes are error-prone and do not provide real-time correlation.

Deploy a Cloud SWG explicit proxy at the branch and point all traffic to it.

Why it fails: A Cloud SWG explicit proxy inspects web traffic but does not provide the SD-WAN integration or the Service Connection needed for Prisma Access inspection of all traffic. It also does not automatically correlate logs with Prisma SD-WAN in the same way as a Service Connection.

The local ISP's routing tables

Why it fails: ISP routing tables are carrier BGP data used for internet path selection; they carry no user identity and cannot map a session to a user for policy enforcement. They are tempting because routing underpins connectivity, but user-based policy requires identity sources such as Cloud Identity Engine, GlobalProtect and the SASE policy engine.

A custom user agent installed on the ION device

Why it fails: ION devices are SD-WAN edge appliances that forward traffic and apply network policy; they do not host a custom user agent for identity collection. It is tempting because IONs participate in the SASE fabric, but user-based policy depends on identity providers and GlobalProtect agents, not an agent on the ION itself.

Physical port speed

Why it fails: Physical port speed is a fixed interface capability, not a measurement of application traffic traversing the SD-WAN. Monitoring requires per-application metrics such as loss, latency, jitter and throughput gathered from the overlay. Port speed would be relevant when sizing WAN circuit capacity or diagnosing link negotiation faults.

Device power consumption

Why it fails: Device power consumption reflects hardware or facility status and carries no information about application delivery across the SD-WAN fabric. Application monitoring depends on overlay measurements like latency, jitter, packet loss and bandwidth per application. Power consumption would be correct when monitoring branch device health or environmental conditions.

User social media activity

Why it fails: User social media activity is unrelated to network telemetry and cannot indicate how an application performs across the SD-WAN. Monitoring relies on overlay metrics such as latency, jitter, loss and throughput measured per application flow. Social media activity would be relevant to HR or security awareness matters, not performance monitoring.

Internet Speed Test

Why it fails: The Internet Speed Test measures WAN circuit throughput from a branch device; it is not part of the Prisma SD-WAN Controller interface. It would be the right tool when validating link performance after provisioning, not for identifying interface components.

Hardware installation manual

Why it fails: A hardware installation manual documents physical appliance mounting, cabling and power requirements; it is not a software interface component of the Prisma SD-WAN Controller. It is tempting because such manuals genuinely accompany branch CPE deployment, and would be the right reference when racking a new device, but the question asks about Controller interface elements.

Physical server room temperature

Why it fails: Physical server room temperature is a facilities metric, not a Prisma SD-WAN Controller interface component. It is tempting because environmental monitoring genuinely matters for on-premises hardware, and would be the right concern when validating data-centre conditions for physical appliances — but the Controller interface comprises software elements such as dashboards, APIs and configuration views.

Enable syslog forwarding of all severity informational messages to a collector and alert on any message volume increase, since degradation increases log volume.

Why it fails: Log volume is not a reliable proxy for transport health. Many benign events generate informational messages, while silent brownouts can produce almost no logging. Alerting on volume would generate noise and would not reliably detect per-transport latency or loss degradation before users are impacted.

Schedule a daily report of interface byte counters and treat any counter deviation from the previous day as a transport degradation event.

Why it fails: Byte counters show throughput, not quality. A transport can carry traffic normally in volume while suffering high latency and jitter, which counters cannot reveal. Daily granularity also cannot detect degradation quickly enough to act before users are impacted, so this fails both parts of the requirement.

Rely on the OMP session state between the branch routers and the controllers, since a degraded transport will always tear down the OMP session and raise an alarm.

Why it fails: OMP sessions ride over the control connections and can remain up even while the data path on a given transport is severely degraded. A brownout with high latency and loss typically does not tear down OMP, so this approach would miss the degradation the requirement is meant to catch before users notice.