SSE-ENGINEER Practice Questions

To meet the customer’s requirements, GlobalProtect and Remote Networks should be used as

follows:

GlobalProtect: This enables secure access for mobile users, ensuring internet filtering, data center

connectivity, and access to branch locations.

Remote Networks: This is used to provide security and connectivity for branch locations, ensuring

internet filtering and data center access.

Service Connections: These allow both mobile users and branch locations to securely connect to the

data center for internal resources.

This configuration ensures that mobile users and branch locations can securely access the internet

while maintaining a segregated and secure connection to internal resources. It also aligns with

Prisma Access's best practices for security enforcement, traffic filtering, and centralized

management.

Updating the Cloud Services plugin in Prisma Access does not disrupt existing traffic flows because

the upgrade process is designed to be seamless and transparent. Prisma Access ensures high

availability by maintaining active sessions and policies while applying the update in the background.

This allows ongoing connections to continue without interruptions, minimizing impact on user

experience.

After configuring domain-based split tunneling for zoom.us, the expected behavior can be confirmed

by checking the routing table on the client machine. If split tunneling is correctly configured, the

traffic for zoom.us should be routed outside the GlobalProtect VPN tunnel, while other traffic follows

the tunnel path. Reviewing the routing table ensures that only the intended traffic is excluded from

the tunnel, confirming that the split tunnel configuration is working as expected.

Prisma Access applies security rules in a hierarchical order, where rules at higher levels take

precedence over those at lower levels. If a more permissive rule is placed higher in the hierarchy, it

may allow traffic before the restrictive Web Security rule is evaluated. To resolve this, the engineer

should reorder the rules to ensure the restrictive Web Security rule is positioned higher in the

hierarchy so it is applied before any broader or conflicting rules.

Palo Alto Networks best practices and the behavior of Strata Cloud Manager (SCM) dictate that

predefined or default objects, including profile groups like "Default Prisma Profile," cannot be

directly modified. These default objects serve as baseline configurations and are often locked to

prevent accidental or unintended changes that could impact the overall security posture.

The intern's experience of the options being greyed out when selecting "Default Prisma Profile" is a

direct indication of this immutability of default objects.

Therefore, the correct action is to:

Create a new Profile Group: The intern should create a new profile group within the appropriate

configuration scope (likely GlobalProtect, given the task).

Configure the new Profile Group: In this new profile group, the intern can select the desired Anti-

Spyware Profile (which might be an existing custom profile or a new one they create).

Modify Security Rules: The security rules currently using the "Default Prisma Profile" in the

GlobalProtect folder need to be modified to use this newly created profile group.

Let's analyze why the other options are incorrect based on official documentation:

A . Request edit access for the GlobalProtect scope. While having the correct scope permissions is

necessary for making any changes within GlobalProtect, it will not override the inherent immutability

of default objects like "Default Prisma Profile." Edit access will allow the intern to create new objects

and modify rules, but not directly edit the default profile group.

B . Change the configuration scope to Prisma Access and modify the profile group. The image shows

that "Default Prisma Profile" has a "Location" of "Prisma Access." However, even within the Prisma

Access scope, default profile groups are generally not directly editable. The issue is not the scope but

the fact that it's a default object.

D . Modify the existing anti-spyware profile, because best-practice profiles cannot be removed from a

group. The question is about changing the profile group, not the individual Anti-Spyware Profile.

While "best-practice" profiles might be part of default groups, the core issue is the inability to modify

the default group itself. Creating a new group allows the intern to choose which Anti-Spyware Profile

to include.

In summary, the fundamental principle in Palo Alto Networks management is that default objects are

typically read-only to ensure a consistent and predictable baseline. To make changes, you need to

create custom objects.

In an Explicit Proxy deployment where no agent can be used on the endpoint, SAML (Security

Assertion Markup Language) is the supported authentication method for mobile users. SAML allows

authentication via an Identity Provider (IdP) without requiring an agent on the endpoint, making it

ideal for web-based authentication in cloud and remote access environments. It enables Single Sign-

On (SSO) and secure authentication without direct integration with LDAP or Kerberos, which typically

require an agent or local network presence.

The "400 Bad Request" error when attempting SAML authentication through the Cloud Identity

Engine (CIE) suggests a misconfiguration in the SAML metadata. This typically occurs when the

endpoint URLs, certificates, or entity IDs do not match between Cloud Identity Engine and the IdP

portal. To resolve this, verify that:

The SAML metadata uploaded to Cloud Identity Engine matches the configuration from the IdP.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Palo_Alto_Networks_SSE-Engineer/page_27_img_1.jpg

The ACS (Assertion Consumer Service) URL, Entity ID, and certificate are correctly set.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Palo_Alto_Networks_SSE-Engineer/page_27_img_2.jpg

There are no incorrect or expired certificates in the Cloud Identity Engine and IdP configuration.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Palo_Alto_Networks_SSE-Engineer/page_27_img_3.jpg

By ensuring the SAML metadata is properly configured in both systems, authentication should

proceed without errors.

Palo Alto Networks AI Access Security integrates with Enterprise Data Loss Prevention (DLP)

capabilities to control sensitive data within AI applications like ChatGPT. The most effective way to

prevent users from uploading financial information is to:

Define an Enterprise DLP rule: This rule would be configured to identify content that matches

patterns or keywords associated with financial information (e.g., credit card numbers, bank account

details, tax identifiers, financial statements).

Apply the DLP rule to the AI Access Security policy: This policy would be specifically configured to

inspect traffic to and from ChatGPT. When the DLP rule detects a user attempting to upload content

containing financial information, it can take a defined action, such as blocking the upload.

Let's analyze why the other options are incorrect based on official documentation:

A . Apply File Blocking to stop file uploads containing financial information. While File Blocking can

prevent the upload of certain file types, it is not content-aware. It cannot inspect the content of a file

to determine if it contains financial information. Therefore, it's not a granular or effective solution for

this specific requirement.

C . Add the ChatGPT domains using URL Filtering to block uploads containing financial information.

URL Filtering controls access to specific websites or categories of websites. While you could

potentially block access to ChatGPT entirely, it does not provide the capability to inspect the content

being uploaded to a permitted domain and prevent the transfer of sensitive financial data.

D . Apply a vulnerability profile to stop attempts to exploit system flaws or gain unauthorized access

to financial systems. Vulnerability profiles are designed to detect and prevent attempts to exploit

known security vulnerabilities in systems. They are not designed to inspect the content of user

uploads for sensitive data like financial information. While important for overall security, they do not

directly address the requirement of preventing financial data uploads to ChatGPT.

Therefore, configuring an Enterprise DLP rule within AI Access Security is the correct and most

effective method to prevent users from uploading financial information to ChatGPT by inspecting the

content of the uploads.

When the "Overlapping Subnets" checkbox is selected during the Remote Network onboarding

process in Prisma Access, the deployment enables Private Application access using Prisma Access for

Users (ZTNA or Private Access). This feature is designed to handle scenarios where multiple sites use

the same IP subnet by leveraging NAT (Network Address Translation) and segmentation to avoid

conflicts.

Since overlapping subnets can create routing challenges for direct remote network-to-remote

network communication, Prisma Access does not support Remote Network-to-Remote Network or

Mobile User communication in this case. Private application access is supported as Prisma Access

correctly routes requests based on application-layer intelligence rather than IP-based routing.

When onboarding to Prisma Access, using Dedicated IP addresses helps address concerns about the

time required to update SaaS-allowed IP lists. With dedicated egress IPs, the customer receives fixed,

predictable IP addresses that do not change dynamically. This eliminates the need to frequently

update SaaS providers' allowlists, ensuring seamless access to cloud applications without

interruptions due to IP address changes.