Planning And Design practice questions

Enable IPSec, then configure interface

Why it fails: IPSec is part of the tunnel policy, not the interface definition.

Enable BGP, then configure WAN interface

Why it fails: Routing protocols are configured after physical interface definition.

Assign WAN interface to Transport group, then define IP

Why it fails: You must define the physical/logical interface first.

IPsec Key Exchange

Why it fails: This is for tunnel encryption, not gateway failover.

Static Route redistribution

Why it fails: Static routes are for routing, not gateway failover.

BGP Multi-homing

Why it fails: BGP handles path selection but not necessarily automated SD-WAN gateway failover logic.

Configuration > Sites > WAN Interfaces

Why it fails: This is for config, not tunnel status.

Policies > Security > Rules

Why it fails: This shows security policies, not tunnel health.

Network > Routing > BGP

Why it fails: This shows route tables, not tunnel status.

System Health Logs

Why it fails: System health covers hardware status, not policy decisions.

Controller Audit Logs

Why it fails: Audit logs track configuration changes, not traffic decisions.

Packet Capture

Why it fails: PCAP is for data analysis, not viewing policy decision history.

VPN Bypass

Why it fails: VPN bypass is not the standard feature name for local breakout.

Backhaul Traffic

Why it fails: Backhaul is the opposite of DIA.

Hub-Exit

Why it fails: This is a custom term, not the standard product feature name.

A separate management network

Why it fails: While recommended for security, it is not a requirement for the HA functionality.

Separate WAN links for each gateway

Why it fails: They can share links, though redundancy is better with separate ones.

Static IP addresses on all interfaces

Why it fails: DHCP is supported.

Negotiating new ISP contracts

Why it fails: Business task, not a technical design task.

Updating the firmware on end-user laptops

Why it fails: Out of scope for SD-WAN.

Painting the office walls

Why it fails: Irrelevant.

IPSec with NULL encryption and SHA-256 authentication

Why it fails: NULL encryption still carries the full IKE-derived IPSec header and ESP trailer, so overhead on the metered LTE link is not minimized. Prisma SD-WAN branch tunnels are inherently IPSec, and disabling encryption would also violate the fabric's confidentiality model for control and data traffic, making this design both heavier than necessary and unacceptable for production branch connectivity.

IPSec with tunnel mode and UDP encapsulation on port 4501

Why it fails: UDP encapsulation on port 4501 is the standard NAT-traversal mechanism used for Prisma SD-WAN tunnels, but it adds an extra UDP header to every packet. On a metered LTE circuit with hundreds of branches, that extra overhead increases byte counts and cost; it is required only when a NAT device blocks native ESP, not as a blanket design choice for all interfaces.

GRE with no additional security encapsulation

Why it fails: Prisma SD-WAN does not build branch-to-branch or branch-to-data-center tunnels using plain GRE. The fabric relies on standard-based IPSec for secure overlay tunnels, so a GRE-only design cannot be instantiated by the ION device and would not interoperate with the Controller's tunnel management or the fabric's path selection and health probing functions.

Enable dynamic multipoint VPN (DMVPN) on all branch routers to create on-demand tunnels between branches.

Why it fails: DMVPN is a Cisco technology and is not part of the Prisma SD-WAN solution. Even if it were available, DMVPN creates direct branch-to-branch tunnels, which violates the requirement that branches never communicate directly. This option mixes vendor technologies and does not meet the isolation policy, making it incorrect for this scenario.

Deploy the Prisma SD-WAN Controller in the bank's data center and have branches connect to it over the MPLS circuit only.

Why it fails: The Prisma SD-WAN Controller is a cloud-hosted service, not a customer-deployed appliance, so deploying it in the data center is not possible. Restricting management to MPLS would also eliminate the redundancy of the internet circuits and does not inherently prevent branch-to-branch communication. This option misconstrues the controller architecture and fails to address the isolation requirement.

Configure a full-mesh VPN topology between all branch sites using the MPLS circuit as the primary transport.

Why it fails: A full-mesh VPN would allow direct branch-to-branch communication, violating the requirement that branches never communicate directly. Although it could encrypt traffic, it does not satisfy the isolation policy and adds unnecessary complexity for 300 sites. The management traffic to the controller is separate from branch-to-branch tunnels, so this design does not meet the stated security requirements.

Use dynamic routing protocols to advertise routes from each ION device to the LAN core.

Why it fails: Dynamic routing can provide path redundancy, but it does not automatically provide a virtual gateway IP for hosts. Hosts would need to run a routing protocol or have their default gateway changed, which is not practical in most data center designs. Also, routing convergence can take time. The standard Prisma SD-WAN high availability design uses VRRP on the LAN side to provide a seamless failover for hosts, rather than relying solely on dynamic routing.

Connect both ION devices to the same LAN switch and rely on spanning tree for redundancy.

Why it fails: Connecting both ION devices to the same LAN switch creates a single point of failure at the switch. Spanning tree provides loop prevention, not device failover. If the switch fails, both ION devices lose LAN connectivity. The requirement is for high availability at the data center, which includes LAN switch redundancy. Therefore, this design does not ensure automatic failover if the switch or one ION device fails, and it does not address the need for a virtual gateway IP.

Configure each ION device with a separate default gateway and manually change host configurations during failover.

Why it fails: Manually changing host configurations during failover is not automatic and does not meet the requirement of no manual intervention. It also introduces human error and delay. A proper high availability design should provide a virtual gateway that hosts use, so failover is transparent. This option describes a manual process, which is the opposite of what is needed for automatic failover in a high availability data center deployment.

Use a Prisma SD-WAN appliance with zero-touch provisioning, where the store manager only powers on the device and connects the ISP and LTE links.

Why it fails: Although zero-touch provisioning reduces configuration effort, shipping a dedicated appliance to every one of 150 stores still adds hardware cost and logistics. The scenario emphasizes minimizing hardware footprint, so a dedicated device per store is less optimal than a software-based approach that leverages existing infrastructure or integrated platforms.

Deploy a hardware ION device at each store with both WAN interfaces configured manually by a field technician.

Why it fails: A hardware ION appliance at every store increases cost, shipping, and truck-roll requirements, and manual WAN configuration contradicts the goal of zero-touch provisioning for non-technical staff. While it can work technically, it fails the design constraints of minimal footprint and no on-site configuration, making it unsuitable for this 150-site retail rollout.

Deploy a virtual ION instance on a small hypervisor host at each store and pre-stage the WAN settings in the controller.

Why it fails: Running a virtual ION requires a hypervisor host, which adds cost and complexity at small retail sites, and still needs someone to install and cable the host. This violates the minimal footprint objective and does not eliminate on-site effort. It may suit larger branches or data centers, but not 150 tiny stores with non-technical staff.

Prisma SD-WAN Policy-Based Forwarding

Why it fails: Policy-based forwarding can direct traffic based on policies, but it is not specifically designed to integrate with cloud security services. CloudBlades provide the orchestration and integration needed for service chaining to security vendors. Policy-based forwarding alone would require manual configuration and lacks the automated integration of CloudBlades.

Prisma SD-WAN Quality of Service (QoS) policies

Why it fails: QoS policies manage bandwidth and prioritization but do not redirect traffic to external services. They operate within the SD-WAN fabric to ensure performance, not to enforce security inspection. Thus, they are not the correct component for redirecting internet-bound traffic to a cloud security service.

Prisma SD-WAN Application SLA profiles

Why it fails: Application SLA profiles are used to define performance thresholds for applications and influence path selection, but they do not redirect traffic to external security services. They are focused on ensuring application performance, not security inspection. Therefore, they do not meet the requirement of redirecting internet-bound traffic to a cloud security service.

Deploy a separate Prisma SD-WAN Controller for each region to distribute the management load.

Why it fails: Prisma SD-WAN uses a multi-tenant, cloud-hosted controller architecture that is designed to scale to thousands of sites without requiring separate controllers per region. Deploying multiple controllers would fragment policy management and increase complexity. The controller is highly available and can handle large deployments. While there may be multiple controller instances for redundancy, they operate as a single logical entity. Separate controllers per region would undermine policy consistency and increase operational overhead.

Enable direct internet breakout at every branch to reduce backhaul traffic to data centers.

Why it fails: Direct internet breakout is a valid design choice for optimizing cloud traffic, but it is not essential for scalability or policy consistency. In fact, if not managed properly, it can complicate security and policy enforcement. The question asks for design considerations essential for scalability and policy consistency, and direct internet breakout does not directly address either. It is more about traffic optimization and may be used in conjunction with hierarchical topology and centralized policy, but it is not a core requirement for scaling to thousands of sites.

Configure all branches in a full mesh topology to ensure direct connectivity between any two sites.

Why it fails: A full mesh topology does not scale well because the number of tunnels grows exponentially with the number of sites. For thousands of sites, this would create millions of tunnels, overwhelming the ION devices and the controller. It also complicates policy management because policies must be applied to every possible path. While full mesh provides direct connectivity, it is not suitable for large-scale deployments due to scalability and management overhead.

Dynamic multipoint VPN (DMVPN) with spoke-to-spoke tunnels

Why it fails: DMVPN allows direct spoke-to-spoke tunnels, which would bypass the data center firewall for branch-to-branch traffic. This violates the security requirement that branch-to-branch traffic be inspected by a firewall in the data center. Although DMVPN can be efficient, it does not provide the centralized inspection and policy enforcement required in this scenario.

Full mesh VPN with local internet breakout at each branch

Why it fails: A full mesh VPN with local internet breakout would allow direct branch-to-branch communication and direct internet access, bypassing the data center firewall. This violates the requirement for branch-to-branch traffic to be inspected by a firewall in the data center. It also increases complexity and may not minimize WAN bandwidth for data center-bound traffic, as it lacks centralized policy enforcement.

Split tunneling with cloud-based security service

Why it fails: Split tunneling directs some traffic directly to the internet, bypassing the data center firewall. While a cloud-based security service could inspect traffic, it would not ensure that branch-to-branch traffic goes through the data center firewall as required. This design also may not encrypt all traffic to the data center, and it does not align with the centralized inspection mandate.

Bandwidth Utilization

Why it fails: Bandwidth is for congestion, not loss-based failover.

Jitter

Why it fails: Jitter is a metric, but the requirement specifically mentions packet loss.

Round Trip Time (RTT)

Why it fails: RTT measures latency, not packet loss.

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.

Traffic Policing Rule

Why it fails: Traffic Policing Rule enforces bandwidth rate limits and marks or drops excess packets; it does not select among transport paths. It is tempting because it shapes traffic, but it suits rate-limiting abuse or guaranteeing bandwidth caps, not quality-based path selection.

NAT Control Policy

Why it fails: NAT Control Policy governs address translation and pool selection for outbound traffic; it carries no path-quality metrics or forwarding decisions. It is tempting because it is a policy construct, but it suits address-overlap or internet-bound translation scenarios, not sub-second application-aware failover.

Access Control List (ACL)

Why it fails: ACLs handle packet filtering, not path performance steering.

SNMP Traps

Why it fails: SNMP Traps push asynchronous alerts on threshold events; they do not provide continuous real-time health and performance monitoring of the fabric. They are tempting because they notify on faults, which suits event-driven alerting to an NMS rather than the live dashboard view needed during deployment.

CLI Debugging

Why it fails: CLI debugging inspects individual device state and control-plane events, giving no aggregated real-time view of the whole SD-WAN fabric. It is tempting because it exposes granular per-device detail, which is correct when isolating a fault on one element rather than monitoring overall deployment health.

Packet Capture (PCAP)

Why it fails: Packet Capture records packet-level traffic for deep troubleshooting of specific flows, not fabric-wide health and performance monitoring. It is tempting because it reveals detailed protocol behaviour, which is the right tool when diagnosing a suspected drop or malformed packet rather than viewing real-time fabric status.

Encryption key rotation

Why it fails: Encryption key rotation is handled by the controller's key management and IPsec/IKE mechanisms, not by CloudBlades, which hosts virtual network functions. It is tempting because security functions are central to Prisma SD-WAN, and would be correct if the question asked how tunnel keys are refreshed.

Hardware acceleration

Why it fails: Hardware acceleration is delivered by the physical branch appliance's data plane, not CloudBlades, which is a software platform for hosting virtual network functions. It is tempting because performance offload is an SD-WAN concern, and would be correct if the question asked how the appliance forwards packets at line rate.

Local breakout management

Why it fails: CloudBlades provides a platform for hosting and orchestrating virtual network functions at branch and cloud edges, not local internet breakout, which is handled by the branch element's breakout policy. It is tempting because breakout is an SD-WAN function, and would be correct if the question asked where direct internet traffic exits.

NAT Policy

Why it fails: NAT Policy translates source or destination addresses and ports, so it cannot evaluate identity attributes to permit or deny sessions. It is tempting because NAT policies also process traffic at the edge, but they rewrite headers rather than enforce user-based access rules; identity-aware firewalling is configured under Security Policy.

Routing Policy

Why it fails: Routing Policy governs path selection and forwarding decisions between sites, not identity-based access control, so it cannot enforce user- or group-aware permit/deny rules. It is tempting because routing policy does control traffic flow, but it matches on prefixes and next-hops; identity-aware firewalling belongs in the Security Policy section.

Quality of Service Policy

Why it fails: Quality of Service Policy classifies and marks traffic for bandwidth, priority and scheduling, so it cannot enforce identity-based permit or deny decisions. It is tempting because QoS also inspects flows, but it acts on performance treatment, not access control; identity-aware firewalling is mapped in the Security Policy section.