Select Two (Multi-Select) Questions

Prisma Access service connection

Why it fails: A service connection is used to connect remote networks or data centers to Prisma Access, not for mobile user connectivity. Remote users connect via GlobalProtect, not service connections. Service connections are for site-to-site or data center integration, so they are not required for securing remote workers' traffic to the internet and SaaS applications.

Prisma Access mobile users license

Why it fails: The mobile users license is required for the service, but it is a licensing component, not a technical component that enables inspection or identity-based control. While necessary for the deployment, it does not itself perform traffic inspection or enforce policies. The question asks for components required to achieve the goals, and a license alone does not fulfill the technical requirements.

Cloud Identity Engine

Why it fails: Cloud Identity Engine can synchronize user identity from various directories, but it is not strictly required for Prisma Access to perform user-based policy enforcement. Prisma Access can integrate directly with directories or use GlobalProtect for user identification. While Cloud Identity Engine adds convenience for identity aggregation, it is not a mandatory component for the basic goals described.

Set up a DNS Security profile with a custom category for malicious domains.

Why it fails: A DNS Security profile with a custom category can block DNS queries to malicious domains, but it does not cover IP addresses and requires a different configuration approach. The requirement includes blocking IP addresses, which DNS Security does not handle. Therefore, this action alone is insufficient and not a required step for the described integration.

Configure a Decryption policy to inspect SSL traffic to malicious sites.

Why it fails: Configuring a Decryption policy is important for inspecting encrypted traffic, but it does not directly enable blocking of known malicious IPs and domains. Decryption is a separate function that allows content inspection; it is not part of the mechanism to consume and enforce an external threat intelligence feed. Thus, it is not a required action for this scenario.

Enable WildFire inline machine learning.

Why it fails: WildFire inline machine learning is used to detect unknown malware in files and is not related to blocking known malicious IPs and domains from an external threat intelligence feed. While WildFire provides threat intelligence, it does not automatically block IPs/domains from an external service. This action is not required for the stated goal.

Security policy hit counts

Why it fails: Security policy hit counts belong to policy and traffic monitoring views, not the Device Health report, which covers resource utilisation such as CPU, memory, disk and session counts. It is tempting because policy statistics are reported elsewhere in Panorama, but they are not part of device health telemetry.

Active user count

Why it fails: Device Health reports interface status, system resources and HA state, not session or user telemetry; active user counts appear in User Activity or ACC, not Device Health. It is tempting because user counts are a health-adjacent metric, but Panorama's Device Health covers hardware and connectivity only.

URL Filtering profile

Why it fails: URL Filtering profiles control access to websites based on URL categories, but they do not enforce user-specific or application-specific policies. They are used for web access control and are not a primary mechanism for least privilege in application access. They would not restrict access to specific users or ensure the correct application is used.

Service objects

Why it fails: Service objects define ports and protocols, but they do not provide user or application granularity. Using them alone would allow any application on those ports, violating least privilege. They are insufficient for enforcing access based on user and application identity.

Security profile group

Why it fails: A Security profile group applies threat inspection profiles to traffic, but it does not control who can access the application or which application is allowed. It is used for threat prevention, not for least privilege access control. It would not restrict access to specific users or applications.

Re-license every feature manually.

Why it fails: Licences are tied to the Panorama-managed device record and transfer to the replacement; manual re-licensing of every feature is unnecessary and risks mismatched entitlements. Manual licensing applies to standalone firewalls or genuinely new deployments without inherited entitlements.

Create a new Device Group for the replacement.

Why it fails: The replacement inherits the failed device's serial number and existing Device Group placement, so a new group would orphan it from the policies it must receive. New Device Groups are created when segmenting distinct policy sets, not when swapping hardware within an established hierarchy.

Reset the firewall to factory defaults.

Why it fails: A replacement firewall must retain or restore its configuration and licences to rejoin Panorama management; factory defaults wipe that state and force full re-onboarding. Resetting to defaults is correct when repurposing a device or clearing inherited misconfiguration before fresh deployment.

Firmware

Why it fails: Firmware is a software image upgrade, not a Dynamic Update; it replaces the PAN-OS version rather than refreshing threat signatures or content databases. It is tempting because firmware updates also arrive periodically and improve security, and would be correct when patching the platform itself rather than updating detection content.

External Dynamic Lists

Why it fails: External Dynamic Lists are a separate object type that firewalls query for IP or URL reputation; they are not a category of Dynamic Updates. It is tempting because EDLs refresh automatically from external feeds, and would be correct when configuring threat-intelligence-driven policy enforcement rather than updating the firewall's own content.

Certificate Revocation List

Why it fails: A Certificate Revocation List is a PKI artefact listing revoked certificates; it is not distributed as a Dynamic Update. It is tempting because CRLs also refresh on a schedule to keep validation current, and would be correct when configuring certificate validation or SSL decryption rather than updating firewall threat content.

The username of the person who downloaded the file.

Why it fails: WildFire Analysis records the file's SHA-256 hash, verdict, and sandbox behaviour, not the downloading user's identity. Attribution tempts because URL filtering and User-ID logs capture usernames, but WildFire analyses the submitted sample itself, independent of who transferred it.

The total bandwidth used by the file transfer.

Why it fails: WildFire Analysis logs report the verdict, file hash, and malware behaviour of submitted samples, not transfer throughput. Bandwidth accounting tempts because traffic logs record byte counts, but WildFire inspects file content in its sandbox, so volume statistics never appear in its verdict records.

The physical port number used for the upload.

Why it fails: WildFire Analysis logs contain the sample's hash, verdict, and observed malicious behaviour, not the switch port carrying the upload. Port mapping tempts because traffic and interface logs record ingress ports, but WildFire examines file content in its cloud sandbox, so physical transport details are absent.

Decryption Logs.

Why it fails: Decryption logs record which traffic the firewall successfully decrypted; a user failing to reach the internet may never have a decryption event, so these logs cannot establish the failure. They are tempting because decryption logs are essential when diagnosing TLS inspection or certificate-related blocking.

Config Logs.

Why it fails: Config logs record device configuration changes, not the live traffic needed to trace a failed connection. They are tempting because configuration drift often causes outages, making them the right choice when verifying whether a recent change altered routing or firewall rules.

Threat Logs.

Why it fails: Threat logs record detections from security services, not the session or interface data needed to trace a failed connection. They are tempting because a blocked exploit can sever connectivity, making them correct when investigating whether a security control dropped the user's traffic.

Log data files

Why it fails: Panorama's configuration export contains device groups, templates, objects and policies, not log records; logs live in the log database and are handled by separate export or log-forwarding functions. It is tempting because logs are exportable from Panorama, but they are not part of a configuration export.

Historical threat reports

Why it fails: Panorama's configuration export contains device groups, templates, rules and objects; historical threat reports are log data, exported separately through the reporting or log-export functions. Threat reports would be the correct selection only if the question asked about exporting logs or reports rather than configuration.

Direct root access to the management server.

Why it fails: Strata Cloud Manager is a multitenant SaaS platform, so customers never receive root shell access to its management infrastructure. Root access is tempting because on-premises Panorama appliances grant administrators full OS control for tuning and troubleshooting, which is precisely the operational model cloud management replaces.

Support for legacy PAN-OS versions 6.0 and below.

Why it fails: Strata Cloud Manager manages current PAN-OS releases and does not support legacy versions such as 6.0 and below. Legacy support is tempting because on-premises Panorama can keep managing ageing firewalls during long migration windows, which suits organisations unwilling to upgrade end-of-life devices promptly.

Ability to host custom local scripts.

Why it fails: Strata Cloud Manager runs vendor-managed infrastructure, so arbitrary local scripts cannot be installed on the management plane. Local scripting is tempting because on-premises Panorama permits custom scripts on the appliance itself, which suits organisations needing bespoke automation tied to their own hardware.

Service Connection

Why it fails: Service connections link Prisma Access to headquarters or data centre resources, not to roaming endpoints, so they do not protect mobile users directly. It is tempting because service connections are genuinely part of Prisma Access architecture, and would be the right answer for questions about connecting internal applications rather than mobile users.

Local Branch Firewall

Why it fails: A local branch firewall protects on-premises branch traffic and does not participate in Prisma Access mobile user protection, which relies on GlobalProtect, service connections and the security processing nodes. It is tempting because branch firewalls are central to Prisma SD-WAN and branch deployments, where they would be the correct component.

Configure 'DNS over HTTPS' to force all traffic through the firewall.

Why it fails: DNS over HTTPS encrypts queries between client and resolver, so the firewall cannot inspect or block malicious domains, defeating the profile's purpose. DoH is chosen when privacy from on-path observers matters, not when inline DNS security inspection is required.

Create a 'DNS Proxy' object for every zone.

Why it fails: A DNS Proxy object is created per firewall DNS proxy instance to forward queries, not per zone; creating one for every zone adds no malware filtering. It is the right choice when the firewall must resolve and forward client DNS requests on behalf of internal hosts.

Enable 'Packet Capture' for all DNS traffic.

Why it fails: Packet capture only records DNS traffic for later forensic analysis; it neither detects nor blocks malware-related queries in real time. It is the correct action when troubleshooting or evidencing suspicious DNS activity after an incident, not for enforcing a security profile.

Management interface

Why it fails: The management interface is an administrative access path for configuration and monitoring, not one of the parallel processing functions Single Pass performs on traffic. Those functions are networking, security, threat inspection and management processing streams. A management interface is relevant when describing out-of-band administrative access, not the Single Pass data plane.

Switching capacity

Why it fails: Single Pass Architecture defines parallel processing streams — networking, security, threat inspection and management — within one traversal, not fabric throughput. Switching capacity describes hardware forwarding performance, which is unrelated to how the architecture parses and inspects a packet once. Switching capacity would matter when sizing chassis throughput, not when describing Single Pass.

Delete all old logs to free up space.

Why it fails: Deleting logs frees storage but removes the audit trail needed to verify upgrade success and troubleshoot failures, and Panorama log retention is not a prerequisite for pushing firmware. Log pruning is tempting as routine housekeeping, yet it would be correct only when storage capacity itself is the constraint.

Disable all security policies.

Why it fails: Disabling security policies removes enforcement of traffic inspection and access control, leaving the estate exposed during the upgrade window. It is tempting as a way to avoid policy-related commit conflicts or dropped sessions while firewalls reboot, but Panorama lets you validate and push configuration without stripping protection.

Manually SSH into every firewall to check disk space.

Why it fails: Manually SSHing into every firewall does not scale across an enterprise and bypasses Panorama's centralised visibility. It is tempting because checking disk space locally confirms each device has room for the firmware image, yet Panorama's dashboard and health monitoring report storage across managed firewalls in one view.

A dedicated VPN concentrator in the data center

Why it fails: A dedicated VPN concentrator in the data center is not part of Prisma Access SASE architecture. Prisma Access provides cloud-based security and connectivity, eliminating the need for backhauling to a data center. This option contradicts the SASE model and is therefore incorrect.

Explicit proxy configuration on the remote user's device

Why it fails: Explicit proxy is not required for Prisma Access; it uses GlobalProtect or explicit proxy depending on the deployment. However, for remote users, GlobalProtect is typically used. Explicit proxy configuration on the device is not a required component for SASE with Prisma Access; it is an alternative access method. The scenario does not specify explicit proxy, so this is not required.

SD-WAN devices at branch offices

Why it fails: SD-WAN devices are used for branch connectivity, but the scenario focuses on remote users, not branches. While Prisma Access can integrate with SD-WAN, it is not a required component for remote user security and performance. This option is not relevant to the specified goal.

Zone Routing

Why it fails: Zone Routing is a routing construct, not a Security Profile type, so it cannot satisfy the question's requirement for valid profile categories. It is tempting because zone-based routing appears within security policy configuration, but that belongs to routing profiles rather than the profile types the exam expects.

Policy Optimizer

Why it fails: Policy Optimizer is a policy-analysis tool that identifies unused or overly permissive rules; it is not a Security Profile type. Security Profiles cover antivirus, anti-spyware, vulnerability protection, URL filtering, file blocking and similar inspection functions, so Policy Optimizer belongs to policy hygiene, not profile configuration.

Antivirus scanning

Why it fails: Antivirus scanning belongs to an Antivirus or WildFire profile, which inspects payload content, whereas URL Filtering acts on destination category and URL. Both attach to the same security policy rule, which makes the mix-up tempting. Antivirus scanning is correct when the requirement is malware inspection of transferred files.

File blocking

Why it fails: File blocking is configured in a File Blocking profile, which inspects file types and transfer directions, not in a URL Filtering profile, which categorises and controls web destinations. The tempting overlap is that both profiles are attached to the same security policy rule. File blocking is correct when the requirement names file-type enforcement.

User authentication list

Why it fails: Service Connections authenticate the tunnel via IPSec pre-shared keys and certificates, not a user authentication list; that list belongs to authentication profiles for portal or gateway access. It is tempting because authentication is central to Prisma Access, but it would be correct when configuring user access to GlobalProtect.

Prisma Access Gateway IP

Why it fails: The Service Connection is established from the remote network to Prisma Access using the service IP addresses and a pre-shared key; a gateway IP is not a required deployment input. It is tempting because gateways appear in Prisma Access topology, but they would be relevant when configuring GlobalProtect or remote user connectivity.

VLAN ID.

Why it fails: A VLAN ID is a Layer 2 segmentation tag applied to interfaces or subinterfaces; IKE Gateway configuration defines IKE version, peer IP, authentication and proposals at Layer 3. It is tempting because VPN traffic traverses VLAN-tagged interfaces, but the VLAN tag is set on the physical or logical interface, not the gateway object.

DHCP server scope.

Why it fails: A DHCP server scope assigns IP addresses to hosts; it plays no part in IKE Gateway configuration, which defines peer addresses, preshared keys or certificates, and proposals. It is tempting because VPN clients often obtain addresses via DHCP, but that occurs after tunnel establishment, not within the gateway object.

Disable 'App-ID' to prevent interference.

Why it fails: Disabling App-ID removes the application identification that Threat Prevention uses to select vulnerability signatures, so protection degrades rather than improves. It is tempting because App-ID inspection can consume processing resources, and disabling it would be reasonable on a firewall deliberately deployed purely as a static Layer 3/4 packet filter.

Manually restart the firewall after every update.

Why it fails: Threat Prevention pulls updated signatures dynamically without a restart, so rebooting the firewall adds no protection and causes needless outage. It is tempting because some legacy engines do require a service reload to load new content, making a restart the correct step in those older architectures.

Enable SSL Decryption for all traffic.

Why it fails: SSL Decryption is not required for Threat Prevention to match known vulnerability signatures on cleartext or already-inspected flows; enforcing it everywhere breaks certificate-pinned applications. It is tempting because decryption is genuinely needed to inspect encrypted traffic, and would be correct if the requirement explicitly covered HTTPS-borne exploits.