Hard Difficulty 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.

Drop

Why it fails: The Drop action silently discards the packet without sending any response to either client or server. It does not send a TCP reset, so it fails the requirement to send a reset to both parties. Drop is used when you want to avoid revealing the firewall's presence, but it does not provide the reset behavior described in the scenario.

Deny

Why it fails: The Deny action blocks traffic by dropping the packet and sending a TCP reset to the client only (for TCP) or an ICMP unreachable (for UDP). It does not send a reset to both client and server. The requirement is to send a TCP reset to both sides, so Deny does not fully meet the requirement. It also logs the session, but the reset behavior is different.

Reset-Client

Why it fails: Reset-Client sends a TCP reset to the client only, not to the server. It blocks the traffic and notifies the client, but the server may continue to wait for a response or timeout. The requirement is to send a reset to both client and server, so Reset-Client is insufficient. This action is used when you want to reset only the client side.

The tunnel interface is not assigned to a security zone.

Why it fails: If the tunnel interface were not assigned to a security zone, the firewall would not know how to apply security policies, and the tunnel might not even come up. However, the scenario states the tunnel is up, which typically requires the interface to be in a zone. Additionally, without a zone, traffic would be dropped, but the more specific issue is likely policy. While zone assignment is critical, the tunnel being up suggests it is already assigned.

The IKE gateway is configured with the wrong pre-shared key.

Why it fails: An incorrect pre-shared key would prevent the IKE phase 1 from completing, and the tunnel would not come up. Since the tunnel is up, the pre-shared key must be correct. Therefore, this is not the cause of the traffic not passing. The issue is likely in the policy or routing after the tunnel is established.

The IPsec proposal is misconfigured, causing the tunnel to flap.

Why it fails: A misconfigured IPsec proposal would prevent the tunnel from being established or cause it to fail. The scenario states the tunnel is up, meaning IPsec phase 2 succeeded. Therefore, the proposal is not the issue. Tunnel flapping would be evident and is not mentioned. The problem is that traffic is not passing despite the tunnel being up.

Device > Administrators

Why it fails: Device > Administrators defines administrator accounts, roles and authentication profiles, but permitted source subnets are set under the interface management profile applied to the management interface. It tempts because the name suggests access control, and it would be correct for creating an admin account or assigning a role.

Device > Setup > Session

Why it fails: Device > Setup > Session holds global session timeout and TCP settings, not management-plane access restrictions. It tempts because session options sound security-related, and it would be correct when tuning idle timeout or maximum session limits rather than limiting which subnet may reach the management interface.

Policies > Security

Why it fails: Policies > Security holds traffic rules governing dataplane forwarding between zones, not management-plane reachability. It tempts because security policies are the usual tool for restricting traffic, and a security policy would be correct for controlling transit traffic rather than administrative access to the firewall itself.

The GlobalProtect portal is configured with the authentication method 'client certificate' only, and users have valid certificates installed.

Why it fails: If the portal is configured to use client certificate authentication, users would still need to present a valid certificate. If they have valid certificates, they would be authenticated, not able to connect without credentials. The scenario states users connect without providing credentials, which suggests authentication is not being enforced at all. Client certificate authentication would require a certificate, so this is not the cause.

The GlobalProtect gateway is configured with the authentication method 'pre-logon' and the pre-logon tunnel is being used.

Why it fails: Pre-logon authentication allows a tunnel to be established before user login, but it still uses machine certificate authentication. It does not allow users to connect without any credentials; the machine must have a valid certificate. After user login, the user is authenticated again. The scenario describes users connecting without providing credentials, which is not the same as pre-logon. Pre-logon requires machine certificates, so it is not the cause.

The GlobalProtect portal is configured with the authentication method 'LDAP' but the LDAP server is unreachable.

Why it fails: If the LDAP server is unreachable, authentication would fail, and users would not be able to connect. They would receive an error, not be able to connect without credentials. The scenario states users are able to connect without providing credentials, which implies authentication is not even being attempted. An unreachable LDAP server would cause a failure, not bypass authentication.

The server is using a decryption profile that bypasses policy for trusted update sites

Why it fails: Decryption profiles control how the firewall handles SSL decryption, such as blocking untrusted certificates or unsupported versions. They do not create policy exceptions that permit traffic. A decryption profile is referenced by a decryption policy rule, not by a security rule, and it cannot grant access to a server that has no matching security rule.

The firewall's content inspection engine automatically permits traffic to known software update repositories

Why it fails: The Content-ID engine inspects traffic for threats such as vulnerabilities, malware, and command-and-control signatures. It does not maintain an allow list of software update repositories that overrides security policy. Any traffic must first be permitted by a security rule before Content-ID inspection occurs, so this cannot explain the observed connectivity.

The DMZ zone has an implicit rule that allows all outbound traffic to the Untrust zone

Why it fails: There is no implicit allow rule for outbound DMZ traffic. The only implicit rules are intrazone-default, which allows same-zone traffic, and interzone-default, which denies traffic between zones. Outbound DMZ traffic to an external site is interzone and would be denied unless an explicit rule matches it, so this cannot be the explanation.

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.

Check the client's OS version.

Why it fails: The client's OS version would prevent the tunnel from establishing at all, yet the logs show authentication succeeded and a session was created before resetting. It is tempting because unsupported client platforms do break GlobalProtect connectivity, so version checks are routine during endpoint troubleshooting.

Check the authentication server status.

Why it fails: The logs already confirm the user authenticated successfully, so the authentication server is not the failing component; the reset occurs after authentication. It is tempting because authentication failures commonly block access, making the identity source the usual first suspect in login problems.

Restart the GlobalProtect service.

Why it fails: Restarting the service discards session state without revealing why an already-authenticated session resets, so the cause remains unidentified. It is tempting as a quick recovery step when GlobalProtect itself hangs or crashes, where a service restart genuinely restores connectivity.

The destination must always be an IP address object.

Why it fails: PBF forwards on source and destination criteria, but the destination may be a region, FQDN, or address group, not strictly an IP address object. Restricting to IP objects is tempting because static routing targets IP addresses, yet PBF's policy matching accepts broader object types.

PBF must be enabled at the global configuration level.

Why it fails: PBF is configured and enforced within individual security policy rules, not toggled by a global setting. A global enablement step is tempting because many features require activation, but PBF simply activates when a matching rule with a forwarding action is committed.

PBF can only be used on Layer 2 interfaces.

Why it fails: PBF operates on Layer 3 routed traffic, matching source and destination zones and addresses; Layer 2 interfaces cannot host the routing decision it overrides. Layer 2 is tempting because switching and forwarding sound related, but PBF requires routed interfaces to redirect traffic.

Source IP address.

Why it fails: SD-WAN path selection compares link metrics such as latency, jitter, packet loss and available bandwidth; a source IP address is a static identifier and never varies with link quality, so it cannot rank paths. It is tempting because source-based routing is a legitimate firewall function for policy-based forwarding, but that scenario concerns directing traffic by origin, not choosing the best-performing path.

Static cost metrics.

Why it fails: Static cost metrics assign fixed values that ignore live conditions, so the firewall cannot react to congestion, latency spikes or jitter across the available paths. They suit simple failover designs where a primary link is preferred until it drops entirely, rather than dynamic per-flow path selection driven by measured performance.

Interface priority only.

Why it fails: Interface priority alone cannot reflect live path conditions, so the firewall cannot react to latency, jitter or packet loss when choosing between SD-WAN links. It is tempting because priority ordering suits static failover, where a backup interface activates only when the primary drops — not dynamic per-flow path selection.

Disable SSL decryption for the proxy traffic.

Why it fails: This would prevent the firewall from seeing the actual threats.

Create a specific 'Proxy' zone and apply an App-ID policy.

Why it fails: This does not help with identifying the end host or content.

Configure the proxy as a 'Trusted' source in the Device > Setup menu.

Why it fails: This does not enable deep packet inspection of the proxied traffic.

Disable the security policy.

Why it fails: This would allow traffic but stop logging, the opposite of the goal.

Implement a Decryption Policy.

Why it fails: This is for inspecting encrypted traffic content, not just application monitoring.

Create a mirror port on the switch.

Why it fails: This is a network-layer solution outside the firewall configuration.

Block

Why it fails: Standard action to stop the threat.

Allow

Why it fails: 'Allow' is not an action in a threat profile, as threats are by definition blocked.

Monitor

Why it fails: 'Monitor' is not a valid action in the standard Vulnerability Protection profile.

The traffic is coming from a zone with no security profile assigned.

Why it fails: Security profiles do not affect policy match decisions.

The firewall is in Layer 2 mode and the MAC address table is full.

Why it fails: MAC table limitations result in flooding, not policy drops.

The App-ID is unidentified, causing a drop by the default cleanup rule.

Why it fails: App-ID unidentified traffic is handled by the interzone policy if configured, not intrazone.

Mobile User Connection

Why it fails: This is for GlobalProtect end-user devices.

Prisma Access Insights

Why it fails: This is a monitoring tool, not a connection type.

Remote Network Connection

Why it fails: This is for connecting branch offices to the cloud.

The 'Log at Session Start' option was not checked.

Why it fails: Log at Session Start records the session's beginning, not its conclusion, so enabling it adds an entry without producing the missing end record. Long-lived sessions exceed the log buffer or are aged out before session end. Log at Session End is correct for short flows where the end event fires promptly.

The log buffer is full.

Why it fails: Buffer exhaustion would drop entries across all sessions, including short ones, rather than selectively omitting long-lived sessions. The setting writes its record only when a session closes, so sessions still open at the logging interval appear absent; it suits short, frequently terminating flows.

The session is being decrypted.

Why it fails: Decryption does not suppress session-end logging; the log is generated when the session terminates, so a session that never closes produces no entry until it does. The setting is correct for auditing completed flows, but long-lived sessions need session-start logging or a timeout to capture activity.

URL Filtering Profile

Why it fails: URL filtering classifies web destinations by category or reputation, not by file extension, so it cannot block .exe downloads. It is tempting because it governs web traffic, and would be correct for blocking access to malicious or inappropriate sites rather than specific file types.

Data Filtering Profile

Why it fails: Data filtering inspects content patterns such as credit card or Social Security numbers within traffic, not file extensions. It is tempting because it examines payloads, and would be correct for preventing sensitive data from leaving the network rather than stopping .exe downloads.

Vulnerability Protection Profile

Why it fails: Vulnerability protection detects and blocks exploits targeting software flaws, not file types by extension. It is tempting because it inspects traffic for malicious behaviour, and would be correct for stopping exploitation attempts such as buffer overflows against unpatched services.

Execute 'request system software upgrade' on each firewall sequentially via CLI.

Why it fails: This is manual and does not leverage Panorama's orchestration.

Use an external script to trigger reboots.

Why it fails: While possible, it is not the native Panorama best practice for management.

Set the 'Maintenance Window' in Device Group settings.

Why it fails: Panorama does not have a global 'Maintenance Window' setting for automated reboots.

Enable 'Alert' as the only action.

Why it fails: Alert does not block or upload the file.

Disable 'Session Log' in the Security Profile.

Why it fails: Session logs should be enabled for auditability.

The local WebUI of the Prisma Access compute node.

Why it fails: Compute nodes in SASE are managed centrally, not via individual WebUIs.

The Cloud Service Plugin.

Why it fails: The plugin facilitates communication, but the policy management occurs in Panorama's GUI.

The Cloud Identity Engine.

Why it fails: CIE is used for user authentication and identity, not policy management.