NGFW And Cloud Delivered Security Services Architecture practice questions

Disable WildFire forwarding globally and rely entirely on local URL Filtering categorization to block unknown malware across all vsys instances.

Why it fails: URL Filtering does not perform file detonation or generate custom malware signatures.

Configure the global WildFire public cloud connection with strict API keys that drop files submitted by virtual system 2.

Why it fails: The global public cloud does not natively segregate custom verdicts between different enterprise tenants based purely on standard API keys without private infrastructure.

Create a single decryption exclusion rule for all tenants to prevent file submission timeouts to the shared public WildFire cloud.

Why it fails: Excluding traffic from decryption prevents WildFire from inspecting encrypted file transfers.

Configure a custom decryption profile to bypass SSL decryption entirely for all traffic originating from voice and video VLANs.

Why it fails: Bypassing decryption for voice and video VLANs leaves encrypted C2 channels uninspected, so malicious callbacks pass undetected. It tempts because excluding latency-sensitive media from decryption preserves call quality, yet the requirement demands deep inspection; selective decryption with exemptions for trusted media endpoints satisfies both.

Disable Threat Prevention on voice and video zones to minimize packet processing overhead while relying solely on layer-4 stateful inspection.

Why it fails: Disabling Threat Prevention on voice and video zones leaves those flows with only layer-4 stateful inspection, so C2 callbacks tunnelled over permitted voice or video protocols pass uninspected. It is tempting because latency-sensitive real-time media genuinely suffers from deep packet inspection, and selective decryption or application override would be the right approach for encrypted media that cannot be inspected.

Set the TCP Three-Way Handshake timeout to the maximum value to ensure complete session establishment before triggering malware scans.

Why it fails: Extending the TCP three-way handshake timeout delays session teardown for half-open connections; it does not trigger or improve malware scanning, which inspects payloads after session establishment. It is tempting because handshake timeouts are a genuine tuning control for asymmetric routing and SYN flood resilience, where lengthening the timer would be the correct choice.

Disable all WildFire and Anti-Spyware profiles to force the firewall to run entirely in software-accelerated CPU bypass mode.

Why it fails: Disabling CDSS profiles eliminates threat inspection entirely, which defeats the security goal.

Convert all security rules from Layer-7 App-ID matching to Layer-3 IP-subnet matching to force hardware packet acceleration.

Why it fails: Layer-3 subnet matching removes App-ID, so the firewall cannot identify applications and offloads sessions to hardware acceleration, defeating CDSS inspection. App-ID rules are what force deep inspection; subnet rules suit coarse allow/deny where content visibility is not required.

Configure an explicit static route directing all data center traffic through the management CPU plane.

Why it fails: Routing traffic through the management CPU plane cannot restore content inspection; offloading is controlled by session settings such as application override or hardware offload configuration on the data plane. It is tempting because static routes do steer traffic, but the management plane is not the inspection path.

Disable SSL Forward Proxy globally and rely solely on Threat Prevention signatures running on encrypted sessions.

Why it fails: Global decryption removal blinds inspection to every TLS session, including unpinned traffic needing visibility, and encrypted Threat Prevention signatures cannot inspect payloads. Selective bypass for pinned banking applications preserves inspection elsewhere. Global disabling suits environments where no decryption is legally or technically permissible.

Install the firewall's enterprise root CA certificate into the Windows Certificate Store of every banking server on the internet.

Why it fails: Banking servers are third-party internet endpoints, so their Windows Certificate Store cannot be modified; pinning validates the pinned key, not a trusted root, so installing a CA certificate there changes nothing. It is tempting because distributing a root CA to managed clients is exactly how forward-proxy decryption works for internal endpoints you control.

Enable SSH Proxy on port 443 to translate SSH tunnels into standard HTTPS web sessions.

Why it fails: SSH Proxy on port 443 carries SSH traffic disguised as HTTPS; it neither decrypts TLS nor resolves pinning, and banking applications speak HTTPS, not SSH. It is tempting because port 443 egress is often permitted, making SSH Proxy the right choice when tunnelling SSH through restrictive firewalls.

Disable WildFire forwarding and configure a static EDL blocking all file extensions (.exe, .pdf, .zip).

Why it fails: Disabling WildFire forwarding stops cloud verdict lookups entirely, and a static EDL blocks by extension regardless of verdict, so unknown files are blocked rather than allowed. It is tempting as a deterministic blocklist, but it would be correct where policy forbids any cloud submission of files.

Set the WildFire analysis profile action to 'Reset-Both' for all unknown file types, effectively blocking all file downloads.

Why it fails: Reset-Both blocks sessions on an unknown verdict, contradicting the requirement to permit downloads while cloud analysis runs. It is tempting because Reset-Both is the correct action for sessions already confirmed malicious; the profile needs a separate unknown-verdict action that allows the download and submits the file for WildFire analysis.

Configure a Decryption Profile to drop all sessions containing binary file headers.

Why it fails: A Decryption Profile governs SSL/TLS inspection behaviour such as certificate checks and unsupported protocol versions; it cannot act on WildFire verdicts or file types. It is tempting because decryption is a prerequisite for inspecting encrypted downloads; verdict-based blocking requires the WildFire analysis profile's per-verdict actions instead.

Application Override automatically converts all UDP packets into reliable TCP streams.

Why it fails: Application Override only reclassifies traffic to a specified application; it does not rewrite transport protocols or convert UDP to TCP. It is tempting because some proxies perform protocol conversion, but Application Override leaves packet headers and transport semantics untouched.

Application Override requires a valid WildFire subscription to function on the dataplane.

Why it fails: Application Override operates purely on signature matching in the dataplane and needs no WildFire licence; WildFire is a separate cloud sandboxing subscription. It is tempting because WildFire is often bundled in security profiles, but Application Override functions independently of it.

Application Override automatically forces SSL decryption on all matched traffic regardless of decryption policy.

Why it fails: Application Override changes App-ID classification only; it does not alter decryption policy, so traffic is decrypted solely per the existing SSL decryption rules. It is tempting because decryption is often needed for App-ID accuracy, but the override itself never forces it.

Enabling SNMP polling on the firewall management interface to drop suspicious MAC addresses.

Why it fails: SNMP is a monitoring protocol, not an inline threat blocking mechanism.

A global Static NAT rule translating all outbound traffic to a sinkhole IP address.

Why it fails: Translating all outbound traffic to a sinkhole breaks legitimate business internet traffic.

Configuring an explicit Security Policy rule with source 'Any' and destination 'Malicious-IP-Group' set to allow.

Why it fails: Allowing malicious IPs explicitly defeats the security objective.

Encrypted local Microsoft Access database files uploaded via USB thumb drive.

Why it fails: EDLs pull text lists from web servers, not local MS Access files via USB.

Raw binary executable (.exe) files executed directly on the firewall management CPU plane.

Why it fails: EDLs do not execute binary files.

Enabling DNS Security with automated command-and-control domain block lists

Why it fails: DNS Security inspects domain resolutions, not file payloads, so it cannot halt a session mid-download when WildFire's inline ML flags zero-day content. It is tempting because DNS sinkholing genuinely blocks command-and-control callbacks after detection, which suits post-infection containment scenarios rather than the session-layer, pre-completion file blocking this requirement demands.

Deploying a local WF-500 appliance in private cloud mode with a 15-minute polling interval

Why it fails: WildFire inline blocking requires the firewall's on-box signature lookup to hold the session until verdict; a WF-500 in private cloud mode forwards samples for offline analysis and returns verdicts on a polling cycle, so the download completes before any verdict arrives. It suits retrospective detonation and reporting, not session-layer prevention.

Enabling WildFire Analysis on the Security Rulebase with standard public cloud forwarding

Why it fails: Standard public cloud forwarding sends files to WildFire for verdicts after transfer, so blocking occurs post-download, not at the session layer mid-transfer. It suits near-real-time detection where slight delay is acceptable, not instant inline prevention.

Standard Decryption Profile with SSH Proxy enabled

Why it fails: A decryption profile governs cipher, protocol and certificate validation settings for inspected TLS traffic; SSH Proxy applies to outbound SSH sessions, not SaaS tenant identity. It is tempting because decryption exposes the SaaS traffic for inspection, yet tenant-level allow/block requires identifying the tenant domain within the SaaS application, which decryption alone cannot enforce.

GlobalProtect Clientless VPN with portal customization

Why it fails: Clientless VPN portals publish internal web applications to remote users; they do not classify outbound SaaS sessions by tenant. It is tempting because portal customisation implies access control, but that control governs inbound remote access to internal resources, not granular corporate-versus-personal tenant enforcement for internal clients reaching external SaaS.

External Dynamic Lists based on URL category feeds

Why it fails: External Dynamic Lists match URLs against category or reputation feeds, which cannot distinguish a corporate tenant from a personal tenant on the same SaaS domain. It is tempting because EDLs offer dynamic, centralised URL blocking, but tenant-level granularity requires application identification and tenant-aware policy, not URL category membership.

Static signature matching based strictly on pre-compiled MD5 file hashes

Why it fails: Advanced Threat Prevention moves beyond simple static hash matching to behavioral and inline inspection.

Local management plane database storage for historical threat telemetry

Why it fails: Telemetry and logs are typically offloaded to Cortex Data Lake rather than stored primarily on the local management plane.

Manual packet capture configuration for every individual vulnerability signature

Why it fails: Packet capture is automated and managed globally or via profile settings, not manually configured per signature.

Direct SNMPv2 trap broadcasting from XSIAM to individual firewall data planes

Why it fails: SNMPv2 is an old monitoring protocol, not the mechanism used for distributing dynamic threat intelligence feeds.

Manual USB firmware flashing of indicator database updates on every firewall

Why it fails: Threat intelligence updates are automated continuously through cloud services, never via manual USB flashing.

Active Directory group membership SID tokens

Why it fails: Active Directory group memberships are handled by User-ID agents, not External Dynamic Lists.

Local ESXi hypervisor VM memory dump files

Why it fails: Hypervisor memory dumps are not a supported format or source for External Dynamic Lists.

WildFire hybrid cloud with local caching

Why it fails: WildFire hybrid cloud is not a valid deployment model. WildFire offers public cloud, private cloud, and hybrid cloud (which combines both) but local caching is not a feature. This option is fictitious and does not provide the required on-premises analysis for sensitive files.

WildFire public cloud with file size limits

Why it fails: WildFire public cloud sends all eligible files to Palo Alto Networks cloud for analysis. It does not allow keeping sensitive files on-premises; file size limits only affect which files are submitted, not where they are analyzed. This option fails to address the data privacy concern because sensitive files would still leave the enterprise network.

WildFire API-only integration with third-party sandbox

Why it fails: WildFire API allows submission of files for analysis but does not provide an on-premises analysis option. Using a third-party sandbox is not part of WildFire architecture. This option fails to keep sensitive files on-premises and does not leverage WildFire's native capabilities for local analysis.

Deploy the VM-Series as a transparent bridge between the application subnet and the internet gateway by using AWS PrivateLink.

Why it fails: AWS PrivateLink is designed for private connectivity to services, not for inserting a transparent bridge for outbound internet traffic. VM-Series does not operate as a transparent bridge in AWS; it functions as a routed gateway. Using PrivateLink would not inspect traffic to the internet and would not meet the requirement of inspecting all outbound traffic.

Deploy the VM-Series in a centralized security VPC and use AWS Transit Gateway to route all traffic from the application subnet through the security VPC.

Why it fails: This approach adds significant complexity and requires modifying subnet associations and route tables to direct traffic through the Transit Gateway. It also introduces additional hops and potential latency. While it provides centralized inspection, it does not minimize changes to existing route tables as required; the application subnet's route table must be changed to point to the Transit Gateway.

Deploy the VM-Series in the same subnet as the application tier and configure the application instances to use the VM-Series as a default gateway.

Why it fails: Placing the firewall in the same subnet as the application tier does not ensure all traffic passes through it unless the application instances' default gateway is changed to the firewall's IP. This requires reconfiguring each instance's network settings, which is not minimizing changes to route tables and may not be feasible at scale. It also creates a single point of failure and potential asymmetric routing issues.

WildFire appliance

Why it fails: WildFire appliance is not required for Prisma Access. Prisma Access includes cloud-based WildFire analysis as part of its security subscription, so no on-premises appliance is needed. The appliance is used for private cloud WildFire deployments, which are separate from Prisma Access architecture.

Panorama management

Why it fails: Panorama management is not strictly required for Prisma Access, as Prisma Access can be managed through the Prisma Access cloud management portal. While Panorama can be used for centralized management, it is not an essential component for connectivity. The question asks for components essential for secure connectivity, not management.

Cortex Data Lake

Why it fails: Cortex Data Lake is not essential for Prisma Access connectivity. It is used for log storage and analytics, but Prisma Access can function without it. While it enhances visibility, it is not a connectivity component. The essential components are those that enable secure tunnels and policy enforcement.

VM-Series firewall

Why it fails: VM-Series firewalls are virtualized NGFWs that can be deployed in private or public clouds. They are not typically deployed at branch offices unless there is a virtualization platform. A physical firewall is more appropriate for a branch office with direct internet access.

WildFire appliance

Why it fails: A WildFire appliance is for on-premises malware analysis, not for enforcing web filtering or threat prevention at a branch. It does not provide firewall capabilities. The architect needs a full NGFW to enforce security policies at the branch.

Prisma Access

Why it fails: Prisma Access provides cloud-delivered security for mobile users and branches, but it is typically used when centralized policy enforcement in the cloud is desired. For a branch with direct internet access, a local firewall may be more cost-effective and provide similar security. However, Prisma Access could be a valid option, but it is not the most direct solution for local internet breakouts.

Cortex Data Lake

Why it fails: Cortex Data Lake is a logging and analytics service that stores logs and provides visibility, but it does not perform file analysis or generate threat intelligence. It can be used for correlation, but it is not required to achieve the stated goals. The core requirement is file analysis and intelligence sharing, which are provided by WildFire and DNS Security.

GlobalProtect

Why it fails: GlobalProtect is a remote access VPN solution that provides secure connectivity for users. It is not a threat analysis or intelligence sharing component. It does not analyze files or share threat intelligence across enforcement points. Therefore, it is not required for the stated goals.

URL Filtering

Why it fails: URL Filtering is a security service that controls access to websites based on categories and threat intelligence. It is not specifically required for file analysis or zero-day malware detection. While it contributes to overall security, it does not provide the file sandboxing or intelligence sharing needed to meet the stated goals.

Cortex XDR

Why it fails: Cortex XDR is an endpoint detection and response solution that focuses on endpoint telemetry and analytics. It does not provide inline network threat prevention or URL filtering for east-west traffic between VMs. While it can integrate with NGFWs, it is not a firewall solution and cannot enforce network security policies in the data center. The scenario requires an inline NGFW with cloud-delivered security services.

Prisma Access

Why it fails: Prisma Access is a cloud-delivered secure access service edge (SASE) platform designed to protect mobile users and branch offices, not east-west traffic within a data center. It provides security for remote networks and users, but it does not natively inspect traffic between VMs in a private data center. The scenario requires east-west data center protection, which is better served by VM-Series firewalls with cloud-delivered subscriptions.

WildFire standalone appliance

Why it fails: A WildFire standalone appliance provides advanced malware analysis and sandboxing, but it does not perform inline threat prevention or URL filtering for network traffic. It is a detection tool that integrates with NGFWs, not a replacement for them. The architect needs an inline security enforcement point for east-west traffic, which WildFire alone cannot provide.

Logging Service requires that each managed firewall forwards logs directly to an external syslog server, which then sends them to Panorama.

Why it fails: Logging Service is a cloud-based service that collects logs directly from managed firewalls, not via an external syslog server. Firewalls send logs to the Logging Service, and Panorama can query these logs. This option incorrectly describes an indirect forwarding mechanism that is not part of the Logging Service architecture. The Logging Service is designed for scalability and does not rely on external syslog servers.

Panorama can manage firewalls in multiple regions only if they are all running the same PAN-OS version and have identical hardware models.

Why it fails: Panorama can manage firewalls with different PAN-OS versions and hardware models, although some features may require specific versions. While it is best practice to keep versions consistent, it is not a strict requirement. This statement is false because Panorama supports heterogeneity to a degree. The architect can manage mixed environments, though feature compatibility should be verified.

Panorama in Management-Only mode can still enforce security policies on managed firewalls without the need for a separate Logging Service.

Why it fails: Panorama in Management-Only mode can push policies to managed firewalls, but it does not provide logging aggregation. For centralized logging, the Logging Service (or an on-premises Log Collector) is required. Management-Only mode does not include log collection capabilities. This statement is false because it implies policy enforcement without logging, but the question asks about both policy consistency and log aggregation; the latter is not satisfied.