Troubleshooting practice questions

You are configuring SSO for Prisma Cloud Enterprise Edition using SAML 2.0 with Okta as the Identity Provider. After completing the configuration, users attempting to log in receive an 'Invalid SAML Assertion' error. Which troubleshooting step should you perform first?

Trap 1: Change the Prisma Cloud tenant region from US to EU.

Tenant region determines data residency and console endpoint, not assertion signature or attribute validation, so moving it cannot resolve the error. It is tempting because region mismatches do break some integrations, but SAML failures stem from certificate, audience URI or attribute mapping misalignment between Okta and Prisma Cloud.

Trap 2: Reinstall the Prisma Cloud Compute Defender on all AWS EC2…

Defenders run workload protection inside compute instances and have no bearing on SAML assertion validation, which occurs between Okta and the Prisma Cloud console. Reinstalling them is tempting when alerts suggest agent or workload issues, but an authentication failure at the identity-provider layer never involves Defender components.

Trap 3: Regenerate the user API Access Keys in Settings > Access Keys.

API access keys authenticate programmatic calls to the Prisma Cloud API; browser SSO sessions rely on the SAML trust relationship instead, so regenerating them changes nothing. It is tempting because keys are a common credential-rotation task, but the assertion error originates in the Okta-to-Prisma Cloud SAML configuration.

A
Change the Prisma Cloud tenant region from US to EU.
Why it fails: Tenant region determines data residency and console endpoint, not assertion signature or attribute validation, so moving it cannot resolve the error. It is tempting because region mismatches do break some integrations, but SAML failures stem from certificate, audience URI or attribute mapping misalignment between Okta and Prisma Cloud.
B
Reinstall the Prisma Cloud Compute Defender on all AWS EC2 instances.
Why it fails: Defenders run workload protection inside compute instances and have no bearing on SAML assertion validation, which occurs between Okta and the Prisma Cloud console. Reinstalling them is tempting when alerts suggest agent or workload issues, but an authentication failure at the identity-provider layer never involves Defender components.
C
Verify that the SAML signing certificate and Entity ID match between Okta and the Prisma Cloud SSO configuration.
A mismatch between the SAML signing certificate or Entity ID on Okta and Prisma Cloud invalidates the assertion signature, producing this exact error. Verifying both values first confirms the most common configuration fault before deeper diagnosis.
D
Regenerate the user API Access Keys in Settings > Access Keys.
Why it fails: API access keys authenticate programmatic calls to the Prisma Cloud API; browser SSO sessions rely on the SAML trust relationship instead, so regenerating them changes nothing. It is tempting because keys are a common credential-rotation task, but the assertion error originates in the Okta-to-Prisma Cloud SAML configuration.

Question 2mediummultiple choice

You are troubleshooting a newly onboarded Azure subscription where Prisma Cloud is failing to ingest asset inventory. Upon checking the Azure Activity Log, you notice that API throttling limits are frequently reached. Which mechanism does Prisma Cloud use to manage Azure API rate limits?

Trap 1: Manual throttling intervals configured per subscription in the…

Prisma Cloud does not rely on manually configured per-subscription throttling intervals; it manages Azure API rate limits automatically through adaptive mechanisms. It is tempting because manual throttling settings exist in some platforms, and would be correct where an administrator must cap request rates for a specific tenant or integration.

Trap 2: Delegating all asset discovery requests to an external Azure Event…

Azure Event Grid is an event-routing service, not an asset-discovery delegation mechanism, and Prisma Cloud does not outsource discovery to an external Event Grid subscription. It is tempting because Event Grid genuinely suits reactive, event-driven architectures, and would be correct for triggering workflows on Azure resource-change events.

Trap 3: Deploying a local proxy instance inside an Azure Virtual Network to…

A local proxy caching API responses is not how Prisma Cloud manages Azure throttling; it adds infrastructure without addressing request-rate governance. It is tempting because caching reduces repeated calls, and would be correct where read-heavy workloads repeatedly fetch identical data and latency reduction, not rate-limit compliance, is the goal.

A
Manual throttling intervals configured per subscription in the Prisma Cloud System settings.
Why it fails: Prisma Cloud does not rely on manually configured per-subscription throttling intervals; it manages Azure API rate limits automatically through adaptive mechanisms. It is tempting because manual throttling settings exist in some platforms, and would be correct where an administrator must cap request rates for a specific tenant or integration.
B
Automatic back-off and retry logic implemented within the Prisma Cloud collector service.
Prisma Cloud's collector service handles Azure API throttling by implementing automatic back-off and retry logic, spacing out requests when rate limits are hit. This mechanism prevents failed ingestion and avoids worsening throttling, directly addressing the constraint observed in the Activity Log.
C
Delegating all asset discovery requests to an external Azure Event Grid subscription.
Why it fails: Azure Event Grid is an event-routing service, not an asset-discovery delegation mechanism, and Prisma Cloud does not outsource discovery to an external Event Grid subscription. It is tempting because Event Grid genuinely suits reactive, event-driven architectures, and would be correct for triggering workflows on Azure resource-change events.
D
Deploying a local proxy instance inside an Azure Virtual Network to cache API responses.
Why it fails: A local proxy caching API responses is not how Prisma Cloud manages Azure throttling; it adds infrastructure without addressing request-rate governance. It is tempting because caching reduces repeated calls, and would be correct where read-heavy workloads repeatedly fetch identical data and latency reduction, not rate-limit compliance, is the goal.

Question 3mediummultiple choice

A cloud security engineer is troubleshooting an AWS IAM role used by Prisma Cloud for resource discovery. The role has a trust policy that specifies the Prisma Cloud AWS account as the principal and includes an sts:ExternalId condition. However, Prisma Cloud cannot assume the role. Which of the following is the MOST likely cause?

Trap 1: The IAM role's permissions policy does not grant sts:AssumeRole to…

The permissions policy attached to the role defines what the role can do after assumption, not who can assume it. The trust policy controls the principals allowed to assume the role. Since the trust policy already specifies the Prisma Cloud account and the external ID condition, the lack of sts:AssumeRole in the permissions policy is not the cause of the assumption failure.

Trap 2: The role's maximum session duration is set to 1 hour, which is…

Session duration affects how long temporary credentials remain valid, not whether the role can be assumed initially. Prisma Cloud can operate within a 1-hour session by refreshing credentials. While longer sessions may be desirable, a 1-hour duration would not prevent the initial AssumeRole call from succeeding.

Trap 3: The Prisma Cloud account is not listed as a trusted principal in…

The permissions policy does not contain principal elements; it only specifies allowed actions and resources for the role. Trust relationships are defined exclusively in the trust policy. Therefore, checking the permissions policy for a trusted principal is incorrect and would not resolve the assumption failure.

A
The IAM role's permissions policy does not grant sts:AssumeRole to the Prisma Cloud account.
Why it fails: The permissions policy attached to the role defines what the role can do after assumption, not who can assume it. The trust policy controls the principals allowed to assume the role. Since the trust policy already specifies the Prisma Cloud account and the external ID condition, the lack of sts:AssumeRole in the permissions policy is not the cause of the assumption failure.
B
The role's maximum session duration is set to 1 hour, which is insufficient for Prisma Cloud to complete its discovery.
Why it fails: Session duration affects how long temporary credentials remain valid, not whether the role can be assumed initially. Prisma Cloud can operate within a 1-hour session by refreshing credentials. While longer sessions may be desirable, a 1-hour duration would not prevent the initial AssumeRole call from succeeding.
C
The external ID configured in Prisma Cloud does not match the value specified in the role's trust policy condition.
The sts:ExternalId condition in the trust policy must exactly match the external ID that Prisma Cloud uses when assuming the role. If they differ, AWS denies the AssumeRole request. This is the most common misconfiguration when the principal is correct but assumption still fails, making it the most likely cause here.
D
The Prisma Cloud account is not listed as a trusted principal in the role's permissions policy.
Why it fails: The permissions policy does not contain principal elements; it only specifies allowed actions and resources for the role. Trust relationships are defined exclusively in the trust policy. Therefore, checking the permissions policy for a trusted principal is incorrect and would not resolve the assumption failure.

Question 4hardmultiple choice

A security engineer is troubleshooting why Prisma Cloud Compute Defenders deployed on an ECS Fargate cluster are not reporting connection status back to the Prisma Cloud Console. Which architecture requirement for Fargate defenders is likely missing?

Trap 1: The ECS task execution role lacks permissions to access Amazon S3.

Fargate Defenders report status over outbound network connections to the Console, not via S3; the execution role governs image pulls and log writes. S3 permissions would matter for tasks reading or writing bucket data, so it is tempting when troubleshooting IAM, but it does not affect Console connectivity.

Trap 2: The security group blocks inbound port 22 from the Prisma Cloud…

Fargate defenders communicate outbound to the Console; they do not accept inbound SSH, so blocking port 22 is irrelevant to reporting status. Restricting inbound port 22 is correct when hardening administrative access to EC2 instances, not for enabling outbound Console connectivity from Fargate tasks.

Trap 3: AWS CloudTrail is disabled in the Fargate region.

CloudTrail records AWS API activity for auditing; it plays no part in Defender-to-Console reporting, which relies on outbound network reachability and correct Console credentials. Enabling CloudTrail would be right when you need API-level audit trails, not for fixing Defender connectivity.

A
The ECS task execution role lacks permissions to access Amazon S3.
Why it fails: Fargate Defenders report status over outbound network connections to the Console, not via S3; the execution role governs image pulls and log writes. S3 permissions would matter for tasks reading or writing bucket data, so it is tempting when troubleshooting IAM, but it does not affect Console connectivity.
B
The Defender sidecar container was not added to the ECS task definition.
Fargate tasks cannot host host-level daemons, so each task definition must include the Prisma Cloud Defender as a sidecar container to gain runtime visibility. Without that sidecar, no Defender runs inside the task, so no connection status reaches the Console. Adding it satisfies Fargate's per-task deployment constraint.
C
The security group blocks inbound port 22 from the Prisma Cloud Console.
Why it fails: Fargate defenders communicate outbound to the Console; they do not accept inbound SSH, so blocking port 22 is irrelevant to reporting status. Restricting inbound port 22 is correct when hardening administrative access to EC2 instances, not for enabling outbound Console connectivity from Fargate tasks.
D
AWS CloudTrail is disabled in the Fargate region.
Why it fails: CloudTrail records AWS API activity for auditing; it plays no part in Defender-to-Console reporting, which relies on outbound network reachability and correct Console credentials. Enabling CloudTrail would be right when you need API-level audit trails, not for fixing Defender connectivity.

Question 5hardmultiple choice

You are troubleshooting a Prisma Cloud Compute deployment where container vulnerability scans are failing because Defenders cannot download image layers from a private registry. The private registry requires token-based authentication. Where must the registry credentials be configured in Prisma Cloud Compute?

Trap 1: In the AWS CloudFormation onboarding template for the host account.

CloudFormation provisions host infrastructure, not Defender registry authentication. Prisma Cloud Compute stores registry credentials centrally in the Console's credential store, which Defenders retrieve when pulling layers. The template is tempting because it configures onboarding, but it cannot supply token-based registry authentication.

Trap 2: Hardcoded into the environment variables of every deployed…

Hardcoding credentials into each daemonset YAML scatters secrets across every host and breaks central rotation. Prisma Cloud Compute stores registry credentials once in the Console, and Defenders retrieve them automatically. Daemonset variables are tempting for quick local testing, but they cannot satisfy token-based authentication at scale.

Trap 3: In the Prisma Cloud Enterprise SaaS Console under Settings > Cloud…

Defenders pull image layers directly, so credentials must be set in the Compute Console under Defenders > Defenders, not the Enterprise SaaS registry settings used for cloud account scanning. The SaaS registry path is tempting because it authenticates registry scans, but it does not supply the Defender's own pull credentials.

A
In the AWS CloudFormation onboarding template for the host account.
Why it fails: CloudFormation provisions host infrastructure, not Defender registry authentication. Prisma Cloud Compute stores registry credentials centrally in the Console's credential store, which Defenders retrieve when pulling layers. The template is tempting because it configures onboarding, but it cannot supply token-based registry authentication.
B
Hardcoded into the environment variables of every deployed Container Defender daemonset YAML.
Why it fails: Hardcoding credentials into each daemonset YAML scatters secrets across every host and breaks central rotation. Prisma Cloud Compute stores registry credentials once in the Console, and Defenders retrieve them automatically. Daemonset variables are tempting for quick local testing, but they cannot satisfy token-based authentication at scale.
C
In the Prisma Cloud Compute Console under Compute > Defend > Vulnerabilities > Registries.
Defenders pull image layers directly from the registry, so credentials must be stored centrally in the Console under Compute > Defend > Vulnerabilities > Registries. Configuring them there lets Defenders authenticate with the token-based private registry and complete layer downloads for scanning.
D
In the Prisma Cloud Enterprise SaaS Console under Settings > Cloud Accounts > Registries.
Why it fails: Defenders pull image layers directly, so credentials must be set in the Compute Console under Defenders > Defenders, not the Enterprise SaaS registry settings used for cloud account scanning. The SaaS registry path is tempting because it authenticates registry scans, but it does not supply the Defender's own pull credentials.

Read the full network assurance explanation →

Question 6hardmulti select

An administrator is troubleshooting why a Prisma Cloud Serverless Defender deployed on AWS Lambda is not reporting runtime telemetry. Which THREE factors must be verified? Select the three correct answers.

Trap 1: Verify that an EC2 Host Defender daemonset is running on the…

Lambda runs on AWS-managed infrastructure with no customer-accessible hypervisor nodes, so no EC2 Host Defender daemonset can be installed there. It tempts because Host Defender daemonsets are the standard Prisma Cloud protection for EC2 instances and Kubernetes nodes, which is a genuinely different compute model.

Trap 2: Ensure the Lambda function execution role has permissions to modify…

CloudTrail records AWS API activity, not Lambda runtime behaviour, so granting the execution role permission to modify those logs does nothing for Defender telemetry. It tempts because CloudTrail is a genuine AWS audit source, but the Defender requires outbound network access and correct function configuration instead.

A
Verify that an EC2 Host Defender daemonset is running on the underlying AWS Lambda hypervisor nodes.
Why it fails: Lambda runs on AWS-managed infrastructure with no customer-accessible hypervisor nodes, so no EC2 Host Defender daemonset can be installed there. It tempts because Host Defender daemonsets are the standard Prisma Cloud protection for EC2 instances and Kubernetes nodes, which is a genuinely different compute model.
B
Check that the runtime environment variables (such as ⁠ RT_CONSOLE_ADDR ⁠ and authentication tokens) are correctly set on the Lambda function.
Serverless Defender requires runtime environment variables such as RT_CONSOLE_ADDR and authentication tokens to locate the console and authenticate. If these are missing or incorrect on the Lambda function, the defender cannot establish its reporting channel, so telemetry never reaches Prisma Cloud.
C
Ensure the Lambda function execution role has permissions to modify AWS CloudTrail logs.
Why it fails: CloudTrail records AWS API activity, not Lambda runtime behaviour, so granting the execution role permission to modify those logs does nothing for Defender telemetry. It tempts because CloudTrail is a genuine AWS audit source, but the Defender requires outbound network access and correct function configuration instead.
D
Ensure the Prisma Cloud Serverless Defender layer is correctly attached to the Lambda function configuration.
The Serverless Defender runs as a Lambda layer, so if that layer is absent from the function's configuration, no runtime instrumentation executes and telemetry never reaches Prisma Cloud. Verifying layer attachment confirms the Defender is actually deployed alongside the function code.
E
Verify that the Lambda function has outbound network connectivity (via VPC NAT Gateway or internet gateway) to reach the Prisma Cloud Console.
The Defender must reach the Prisma Cloud Console to upload runtime telemetry. In a VPC-attached Lambda, that requires a NAT gateway for private subnets or an internet gateway, since removing default connectivity silently blocks outbound reporting.

Question 7mediummultiple choice

A security engineer is troubleshooting a Web Application and API Security (WAAS) rule that is not inspecting HTTPS traffic flowing into a Kubernetes Ingress controller. What is the most likely cause?

Trap 1: The WAAS rule was configured with the action set to 'Prevent'…

Prevent versus Alert governs whether matching traffic is blocked or merely logged; neither affects whether the rule inspects encrypted HTTPS. Alert mode is tempting when diagnosing silent rules, but TLS interception or decryption configuration is what enables inspection of encrypted flows.

Trap 2: The Host Defender license does not include Web Application Firewall…

Host Defender is endpoint protection and its licensing is unrelated to WAAS inspection of ingress traffic; the likely cause is that the Ingress controller's TLS is terminated before WAAS sees it, or the rule is not attached to that workload. It is tempting because licence gaps do disable features.

Trap 3: Prisma Cloud WAAS only supports unencrypted HTTP traffic on port 80.

WAAS inspects TLS-decrypted traffic, so port 80-only HTTP is false; the real cause is usually missing TLS decryption or certificate trust between the Ingress controller and WAAS. It is tempting because WAAS does inspect plain HTTP, which would be the answer if the stem described unencrypted port 80 traffic.

A
The WAAS rule was configured with the action set to 'Prevent' instead of 'Alert'.
Why it fails: Prevent versus Alert governs whether matching traffic is blocked or merely logged; neither affects whether the rule inspects encrypted HTTPS. Alert mode is tempting when diagnosing silent rules, but TLS interception or decryption configuration is what enables inspection of encrypted flows.
B
TLS termination occurs at the Ingress controller, and the WAAS proxy or defender has not been configured to inspect traffic after TLS termination or at the application pod level.
When the Ingress controller terminates TLS, traffic reaching the backend pods is plaintext HTTP, so a WAAS proxy inspecting only the encrypted stream sees nothing. Inspection must occur after termination or at the application pod level.
C
The Host Defender license does not include Web Application Firewall features.
Why it fails: Host Defender is endpoint protection and its licensing is unrelated to WAAS inspection of ingress traffic; the likely cause is that the Ingress controller's TLS is terminated before WAAS sees it, or the rule is not attached to that workload. It is tempting because licence gaps do disable features.
D
Prisma Cloud WAAS only supports unencrypted HTTP traffic on port 80.
Why it fails: WAAS inspects TLS-decrypted traffic, so port 80-only HTTP is false; the real cause is usually missing TLS decryption or certificate trust between the Ingress controller and WAAS. It is tempting because WAAS does inspect plain HTTP, which would be the answer if the stem described unencrypted port 80 traffic.