Troubleshooting Scenario Questions

config from cloud.resource where network.connection = '...'

Why it fails: RQL's config construct reads resource configuration state, and network.connection is not a configuration property, so the query returns nothing. Config queries suit auditing settings such as exposed ports or public IP assignments, not reconstructing a past connection between two resources.

event from cloud.event where type = 'network'

Why it fails: Filtering events by type = 'network' returns every network event across the estate, not the specific connection between two resources. It would suit broad traffic auditing, but the stem requires correlating a named source and destination pair, which this query cannot isolate.

None of the above

Why it fails: A valid RQL query exists that targets the specific connection, so dismissing all options is wrong. 'None of the above' is tempting when query syntax looks unfamiliar, but it would be correct only if every listed query failed to reference the source, destination, or connection attributes required.

The Compliance dashboard filtered by AWS CIS controls

Why it fails: The Compliance dashboard shows pass/fail status for controls, not individual API calls or their context. It is designed for posture management, not for forensic investigation of specific events. The analyst would not find the detailed API call information here.

The Alerts page filtered by the suspicious API name

Why it fails: The Alerts page shows triggered alerts based on policies, but it may not contain the raw API call details such as source IP and full user identity. Alerts are generated after policy evaluation and might not provide the granular context needed. The analyst needs to query the raw log data, which is better suited for the Investigate tab.

The Asset Inventory filtered by the affected resource

Why it fails: The Asset Inventory provides a list of resources and their configurations, but it does not show historical API calls or user identities. It is useful for understanding what resources exist, but not for tracing who did what and when. The analyst needs event-level data, which the inventory does not provide.

Investigate > Cloud Resources

Why it fails: Cloud Resources lists ingested assets, but it shows resources already discovered rather than confirming whether the account itself was onboarded successfully. It tempts because missing resources appear here, yet verifying account ingestion requires the account inventory or onboarding status view, not the resource listing.

Alerts > Overview

Why it fails: Alerts Overview displays generated findings, which presupposes successful ingestion and resource evaluation. It tempts because absent alerts suggest something is wrong, yet an uningested account simply generates nothing, so the alert queue cannot distinguish ingestion failure from a clean environment; verify account onboarding directly.

Policies > Compliance

Why it fails: Compliance policies evaluate already-ingested resources against rules, so they cannot confirm whether the account was onboarded at all. It tempts because policy failures surface missing coverage, but an uningested account produces no policy results; account ingestion status must be checked first.

Restart the Prisma Cloud instance

Why it fails: Restarting Prisma Cloud cannot make a misconfigured IAM policy match events; the policy engine evaluates rules against logs, so the alert logic itself must be inspected. It is tempting because restarting a service clears transient faults, and that would be the right move for a stalled console or unresponsive API, not a silent policy.

Delete and recreate the cloud account

Why it fails: Deleting and recreating the cloud account destroys the very configuration under investigation and cannot reveal why the IAM policy fails to trigger an alert. Account recreation is a last-resort remediation for irrecoverable corruption, not a diagnostic first step.

Check if the Defender is running

Why it fails: Microsoft Defender for Cloud monitors posture and threats; it does not evaluate IAM policy conditions or generate alerts for IAM policy violations. Defender is the correct check when investigating workload or resource-level security findings, not IAM policy alerting failures.

Compute Defender console port

Why it fails: Compute Defender console port is a host-defender connectivity setting, unrelated to CloudTrail, which is ingested through AWS APIs and S3, not a Defender console channel. It is tempting because port validation is the right first step when Compute Defenders fail to register with the console.

The Alert severity threshold settings

Why it fails: Alert severity thresholds govern which findings raise notifications, not log ingestion, so tuning them cannot restore missing CloudTrail data. It is tempting because severity settings are a visible Prisma Cloud configuration, and they would be the right focus when alerts fire too often or too rarely.

The local agent status on the EC2 instances

Why it fails: CloudTrail is an AWS control-plane service delivering API activity to S3 or CloudWatch; no agent runs on EC2 instances for it, so local Defender status is irrelevant. It is tempting because agent health is the correct first check when host-based Compute logs, rather than CloudTrail, go missing.

Enable EBS encryption by default in the region and rely on it to re-encrypt the existing snapshot.

Why it fails: Enabling account-level default encryption only affects new volumes and snapshots created after the setting is applied. It does not retroactively encrypt or unshare existing snapshots. The shared snapshot remains readable by the external account, so this action does not contain the incident and may create a false sense of remediation.

Stop the EC2 instance and detach the root EBS volume.

Why it fails: Stopping the instance and detaching the volume does not revoke the external account's access to the already-shared snapshot. The snapshot is an independent S3-backed object copied from the volume at a point in time, so the exposure persists even after the volume is detached. This action also causes an availability outage without closing the actual data leak channel identified in the audit logs.

Rotate the IAM access keys of the account that created the snapshot.

Why it fails: Rotating IAM keys may limit future unauthorized API calls, but it does not revoke the snapshot share that is already in place. The external account does not need the original creator's keys to use a snapshot that has been shared with it. The data remains accessible for volume creation until the snapshot permission itself is removed.

Disable vulnerability scanning.

Why it fails: This is a security risk and not the primary way to manage resource performance.

Delete the Defender and reinstall it.

Why it fails: This is a reactive step that doesn't solve the underlying resource issue.

Increase the log level to 'Debug'.

Why it fails: This will increase memory usage, not help.

To view compliance benchmarks

Why it fails: Compliance benchmarks are viewed under the Compliance page, which maps resource posture to standards; Investigate instead queries and correlates runtime events and alerts. Compliance reporting is the correct task when assessing posture against CIS or PCI DSS.

To add new cloud accounts

Why it fails: Adding cloud accounts happens in Settings under onboarding, not on Investigate, which searches and visualises existing event and alert data. Onboarding is the correct task when connecting a new AWS, Azure or GCP account for scanning.

To configure alert notifications

Why it fails: Alert notifications are configured under Settings, not on the Investigate page, which queries and correlates ingested events and alerts. Notification configuration is the correct task when defining where and how Prisma Cloud sends its findings.

Stop the instance, detach the EBS volume, and create a snapshot for offline analysis.

Why it fails: Stopping the instance destroys volatile memory contents, including running processes, network connections, and encryption keys held in RAM. Detaching and snapshotting the EBS volume preserves disk data but loses volatile evidence. This approach is suitable for disk forensics but fails the requirement to preserve volatile memory.

Create an AMI of the instance and launch a copy in an isolated VPC for analysis.

Why it fails: Creating an AMI captures disk state but not volatile memory, and the process may require the instance to be stopped depending on configuration. Launching a copy in an isolated VPC does not recover RAM contents from the original instance. This approach preserves disk artifacts but fails the volatile memory requirement.

Reboot the instance and capture the boot logs to analyze for indicators of compromise.

Why it fails: Rebooting clears volatile memory and may trigger destructive actions by malware or cause loss of ephemeral data. Boot logs contain limited forensic value and do not preserve memory contents. This action compromises the volatile evidence rather than preserving it, making it inappropriate for memory forensics.