Scenario practice questions

A CloudSec-Pro administrator is configuring log streaming to a third-party SIEM. The SIEM requires that logs be delivered in near real-time and that the administrator can filter which log types are sent to reduce noise. Which CloudSec-Pro log streaming configuration should be used?

Trap 1: Set up a syslog forwarder on a virtual machine that pulls logs from…

A custom syslog forwarder introduces latency and operational overhead. It also relies on polling the API, which is not near real-time and may hit rate limits. This approach lacks native filtering and can miss logs during downtime, making it unsuitable for a production SIEM integration.

Trap 2: Export logs to an S3 bucket and have the SIEM pull from there on a…

Batch export to S3 is not near real-time; it introduces delays and requires the SIEM to poll the bucket. It also lacks native filtering, so all logs are exported, increasing noise. This method is better for archival than for real-time SIEM ingestion.

Trap 3: Configure a webhook integration with a JSON payload and use alert…

Webhooks are typically used for alert notifications, not for streaming raw audit logs. They may not provide the full fidelity or volume of logs required by a SIEM, and filtering via alert rules would only send alerts, not the comprehensive log data needed for correlation and retention in the SIEM.

A
Set up a syslog forwarder on a virtual machine that pulls logs from the CloudSec-Pro API.
Why it fails: A custom syslog forwarder introduces latency and operational overhead. It also relies on polling the API, which is not near real-time and may hit rate limits. This approach lacks native filtering and can miss logs during downtime, making it unsuitable for a production SIEM integration.
B
Export logs to an S3 bucket and have the SIEM pull from there on a schedule.
Why it fails: Batch export to S3 is not near real-time; it introduces delays and requires the SIEM to poll the bucket. It also lacks native filtering, so all logs are exported, increasing noise. This method is better for archival than for real-time SIEM ingestion.
C
Configure a webhook integration with a JSON payload and use alert rules to filter events.
Why it fails: Webhooks are typically used for alert notifications, not for streaming raw audit logs. They may not provide the full fidelity or volume of logs required by a SIEM, and filtering via alert rules would only send alerts, not the comprehensive log data needed for correlation and retention in the SIEM.
D
Use the CloudSec-Pro log streaming feature with a supported SIEM integration and apply log type filters.
CloudSec-Pro provides native log streaming to popular SIEMs (e.g., Splunk, Microsoft Sentinel) with configurable filters for log types such as audit, alert, and compliance. This delivers logs in near real-time and allows the administrator to exclude noisy log types, meeting both requirements efficiently.

Question 2mediummultiple choice

A security team wants to detect and prevent container escapes that abuse the Docker daemon socket inside a running Kubernetes pod. They have deployed Prisma Cloud Compute Defenders on all nodes. Which runtime policy should they configure to alert on processes that attempt to connect to /var/run/docker.sock?

Trap 1: WAAS policy with a custom rule for socket connections.

WAAS policies are designed to inspect HTTP and HTTPS traffic for web application attacks, not raw Unix socket connections. The Docker daemon socket is a local file system socket, not an HTTP request, so WAAS cannot see or block this activity. Using WAAS here would leave the container escape completely undetected because the traffic never traverses the WAAS proxy.

Trap 2: Compliance policy with a custom check for open ports.

Compliance policies assess configuration against benchmarks such as CIS, but they do not monitor live process behavior. A custom check for open ports would not identify a process connecting to a Unix socket, because the socket is not a network port. This approach cannot detect the escape attempt in real time, making it unsuitable for the described threat.

Trap 3: Vulnerability policy with a CVE exception for the Docker daemon.

Vulnerability policies scan images and hosts for known CVEs but do not monitor runtime process activity. Even if a CVE related to Docker exists, the policy would only report the vulnerability, not detect the actual connection to the socket. This scenario requires runtime behavioral detection, which vulnerability scanning does not provide, so the escape attempt would go unnoticed.

A
WAAS policy with a custom rule for socket connections.
Why it fails: WAAS policies are designed to inspect HTTP and HTTPS traffic for web application attacks, not raw Unix socket connections. The Docker daemon socket is a local file system socket, not an HTTP request, so WAAS cannot see or block this activity. Using WAAS here would leave the container escape completely undetected because the traffic never traverses the WAAS proxy.
B
Compliance policy with a custom check for open ports.
Why it fails: Compliance policies assess configuration against benchmarks such as CIS, but they do not monitor live process behavior. A custom check for open ports would not identify a process connecting to a Unix socket, because the socket is not a network port. This approach cannot detect the escape attempt in real time, making it unsuitable for the described threat.
C
Vulnerability policy with a CVE exception for the Docker daemon.
Why it fails: Vulnerability policies scan images and hosts for known CVEs but do not monitor runtime process activity. Even if a CVE related to Docker exists, the policy would only report the vulnerability, not detect the actual connection to the socket. This scenario requires runtime behavioral detection, which vulnerability scanning does not provide, so the escape attempt would go unnoticed.
D
Container and host runtime policy with a process rule matching the docker.sock path.
Prisma Cloud Compute container runtime policies include process rules that can match executable paths and arguments. By creating a rule that triggers when a process accesses /var/run/docker.sock, the Defender detects the escape attempt and can alert or block based on the configured action. This directly addresses the scenario because the policy inspects runtime process behavior on the node.

Question 3mediummulti select

A security team is migrating an on-premises application to AWS. The application will run on Amazon EC2 instances behind an Application Load Balancer. The team must document the security tasks that remain the customer's responsibility under the AWS shared responsibility model. Which TWO of the following are customer responsibilities in this scenario? (Choose two.)

Trap 1: Patching the underlying hypervisor that supports the EC2 instances

The hypervisor is part of AWS's managed infrastructure. AWS is responsible for patching and securing the hypervisor to ensure isolation between tenants. Customers do not have access to the hypervisor and cannot patch it. This is a provider responsibility in all cloud models. Selecting this option confuses a provider task with a customer task.

Trap 2: Maintaining the physical security of the AWS datacenter where the…

Physical security of AWS datacenters is always AWS's responsibility. Customers have no access to these facilities and cannot implement physical controls. AWS manages access controls, surveillance, and environmental safeguards. Assigning this to the customer is incorrect and would be impossible to fulfill. This option describes a provider task.

Trap 3: Managing the physical network cabling within the AWS region

Physical network cabling is part of AWS's infrastructure and is managed entirely by AWS. Customers have no visibility or control over the physical network. This includes cabling, switches, and routers within AWS regions. Assigning this to the customer is incorrect and reflects a misunderstanding of the shared responsibility model. This is a provider responsibility.

A
Configuring security groups to control inbound and outbound traffic to the instances
Security groups are virtual firewalls that the customer configures to allow or deny traffic. AWS provides the security group functionality, but the customer defines the rules. This is a critical customer responsibility to restrict access to EC2 instances. Misconfigured security groups are a common cause of data breaches. The customer must regularly review and update these rules based on least privilege.
B
Patching the underlying hypervisor that supports the EC2 instances
Why it fails: The hypervisor is part of AWS's managed infrastructure. AWS is responsible for patching and securing the hypervisor to ensure isolation between tenants. Customers do not have access to the hypervisor and cannot patch it. This is a provider responsibility in all cloud models. Selecting this option confuses a provider task with a customer task.
C
Maintaining the physical security of the AWS datacenter where the EC2 instances run
Why it fails: Physical security of AWS datacenters is always AWS's responsibility. Customers have no access to these facilities and cannot implement physical controls. AWS manages access controls, surveillance, and environmental safeguards. Assigning this to the customer is incorrect and would be impossible to fulfill. This option describes a provider task.
D
Managing the physical network cabling within the AWS region
Why it fails: Physical network cabling is part of AWS's infrastructure and is managed entirely by AWS. Customers have no visibility or control over the physical network. This includes cabling, switches, and routers within AWS regions. Assigning this to the customer is incorrect and reflects a misunderstanding of the shared responsibility model. This is a provider responsibility.
E
Patching the guest operating system on the EC2 instances
In IaaS, the customer is responsible for the guest operating system, including patching, updates, and security configurations. AWS manages the hypervisor and physical host, but the EC2 instance's OS is under customer control. This includes applying OS patches, managing user accounts, and configuring host-based firewalls. Failing to patch the guest OS can lead to vulnerabilities that AWS cannot remediate.

Question 4easymultiple choice

Which of the following is a benefit of using Prisma Cloud for multi-cloud environments?

Trap 1: Automatic removal of cloud accounts

Prisma Cloud onboards, monitors and governs cloud accounts; it never deletes them automatically. Tempting because automated remediation of misconfigured resources is a genuine capability, but it would be correct only if the question concerned deleting cloud resources, not accounts.

Trap 2: Managing cloud hardware

Prisma Cloud secures workloads, configurations, identities and data across cloud environments; physical hardware remains the provider's responsibility under the shared responsibility model. Tempting because infrastructure management sounds adjacent to cloud security, but it would be correct only for a tool that provisions or manages physical hosts.

Trap 3: Replacing native cloud security tools

Prisma Cloud complements and correlates native cloud security services across providers rather than replacing them; native tools remain the enforcement plane. It is tempting because a single pane of glass sounds like consolidation, but it would be correct only if the platform's purpose were to displace provider-native controls.

A
Automatic removal of cloud accounts
Why it fails: Prisma Cloud onboards, monitors and governs cloud accounts; it never deletes them automatically. Tempting because automated remediation of misconfigured resources is a genuine capability, but it would be correct only if the question concerned deleting cloud resources, not accounts.
B
Managing cloud hardware
Why it fails: Prisma Cloud secures workloads, configurations, identities and data across cloud environments; physical hardware remains the provider's responsibility under the shared responsibility model. Tempting because infrastructure management sounds adjacent to cloud security, but it would be correct only for a tool that provisions or manages physical hosts.
C
Replacing native cloud security tools
Why it fails: Prisma Cloud complements and correlates native cloud security services across providers rather than replacing them; native tools remain the enforcement plane. It is tempting because a single pane of glass sounds like consolidation, but it would be correct only if the platform's purpose were to displace provider-native controls.
D
Unified visibility across all cloud providers
Prisma Cloud ingests configuration and traffic data from AWS, Azure, Google Cloud and others into one console, giving a single pane of glass. This unified visibility satisfies the multi-cloud benefit by removing per-provider tooling silos.

Question 5hardmultiple choice

A compliance officer needs to generate a report showing all AWS EC2 instances that have been running for more than 90 days without the required 'Environment' tag. The report must be exportable to CSV and scheduled to run weekly. Which Prisma Cloud feature should be used to accomplish this?

Trap 1: Use the Compliance Dashboard and apply a filter for missing tags.

The Compliance Dashboard shows posture against benchmarks but does not allow custom queries for specific conditions like running duration and missing tags. It also lacks scheduling and CSV export capabilities. It is intended for high-level compliance visibility, not granular, scheduled reporting on custom criteria.

Trap 2: Create a custom RQL query in the Investigate tab and export the…

While a custom RQL query can identify non-compliant instances, the Investigate tab does not provide scheduling or automated CSV export. It is designed for ad-hoc exploration. The requirement includes weekly scheduling and export, which are not supported in that interface. A different feature is needed for recurring, exportable reports.

Trap 3: Set up an Alert Rule with a custom RQL query and configure email…

Alert Rules trigger notifications based on events or query results but do not generate exportable CSV reports or provide scheduling for report delivery. They are for real-time alerting, not for producing periodic compliance reports. The requirement for a CSV export and weekly schedule is not satisfied by an alert rule.

A
Configure a Report in the Reports section with a custom RQL query and a weekly schedule.
The Reports section allows creating custom reports based on RQL queries. You can define the query to filter EC2 instances by running duration and missing 'Environment' tag, set the output format to CSV, and schedule it to run weekly. This directly meets all requirements: custom criteria, export, and scheduling.
B
Use the Compliance Dashboard and apply a filter for missing tags.
Why it fails: The Compliance Dashboard shows posture against benchmarks but does not allow custom queries for specific conditions like running duration and missing tags. It also lacks scheduling and CSV export capabilities. It is intended for high-level compliance visibility, not granular, scheduled reporting on custom criteria.
C
Create a custom RQL query in the Investigate tab and export the results manually.
Why it fails: While a custom RQL query can identify non-compliant instances, the Investigate tab does not provide scheduling or automated CSV export. It is designed for ad-hoc exploration. The requirement includes weekly scheduling and export, which are not supported in that interface. A different feature is needed for recurring, exportable reports.
D
Set up an Alert Rule with a custom RQL query and configure email notifications.
Why it fails: Alert Rules trigger notifications based on events or query results but do not generate exportable CSV reports or provide scheduling for report delivery. They are for real-time alerting, not for producing periodic compliance reports. The requirement for a CSV export and weekly schedule is not satisfied by an alert rule.

Question 6mediummultiple choice

A security team has onboarded an AWS account into Prisma Cloud and wants to detect IAM users whose access keys have never been rotated. They have already enabled the IAM permissions required for Prisma Cloud to read credential reports. Which Prisma Cloud feature should they use to generate an alert when an access key exceeds 90 days of age?

Trap 1: Prisma Cloud Compute's host vulnerability scanner, configured to…

Prisma Cloud Compute focuses on workload and host protection, not cloud IAM credential lifecycle management. It scans operating system packages and container images for vulnerabilities. It has no visibility into AWS IAM access key metadata such as creation dates, so it cannot detect keys older than 90 days.

Trap 2: Cloud Trail log analysis with a saved query that filters for…

CloudTrail records API activity but does not maintain a persistent inventory of access key ages. A saved query would only show when keys were created, not continuously evaluate their current age. It cannot generate a recurring alert when a key crosses the 90-day boundary, so it fails the continuous monitoring requirement.

Trap 3: AWS Config managed rule 'access-keys-rotated' configured directly…

The AWS Config managed rule can detect unrotated keys, but the scenario specifically asks for a Prisma Cloud feature. Using AWS Config alone bypasses the centralized visibility and alerting that Prisma Cloud provides. The requirement is to generate the alert within Prisma Cloud, so an AWS-native-only control does not meet the stated objective.

A
Prisma Cloud Compute's host vulnerability scanner, configured to flag credentials stored on EC2 instances.
Why it fails: Prisma Cloud Compute focuses on workload and host protection, not cloud IAM credential lifecycle management. It scans operating system packages and container images for vulnerabilities. It has no visibility into AWS IAM access key metadata such as creation dates, so it cannot detect keys older than 90 days.
B
Cloud Trail log analysis with a saved query that filters for CreateAccessKey events older than 90 days.
Why it fails: CloudTrail records API activity but does not maintain a persistent inventory of access key ages. A saved query would only show when keys were created, not continuously evaluate their current age. It cannot generate a recurring alert when a key crosses the 90-day boundary, so it fails the continuous monitoring requirement.
C
AWS Config managed rule 'access-keys-rotated' configured directly in the AWS console, with no integration to Prisma Cloud.
Why it fails: The AWS Config managed rule can detect unrotated keys, but the scenario specifically asks for a Prisma Cloud feature. Using AWS Config alone bypasses the centralized visibility and alerting that Prisma Cloud provides. The requirement is to generate the alert within Prisma Cloud, so an AWS-native-only control does not meet the stated objective.
D
IAM security policy with a rule that checks access key age and triggers an alert when the key is older than 90 days.
Prisma Cloud IAM security policies are designed to evaluate identity configurations against defined conditions. A policy can inspect the CreateDate of an access key and raise an alert when the calculated age exceeds the 90-day threshold. This directly satisfies the requirement to detect unrotated keys without manual scripting.

Question 7mediummulti select

A security administrator is configuring Prisma Cloud to monitor IAM activity across multiple AWS accounts in an organization. They want to ensure that Prisma Cloud can detect when a new IAM user is created with console access and when an existing user's permissions are escalated. Which two Prisma Cloud capabilities should they enable to meet these requirements? (Choose two.)

Trap 1: Prisma Cloud Compute's runtime defense module, which monitors…

Runtime defense monitors processes and system calls on hosts and containers. It does not observe IAM API calls or identity configuration changes. While useful for workload security, it cannot detect new IAM users or permission escalations, so it does not meet the stated requirements.

Trap 2: Prisma Cloud's data security posture management (DSPM) module,…

DSPM focuses on discovering and classifying sensitive data stored in cloud services. It does not monitor IAM activity or identity configuration. While important for data protection, it has no role in detecting new IAM users or permission escalations, making it irrelevant to the scenario.

Trap 3: Cloud network firewall policies that restrict outbound traffic from…

Network firewall policies control traffic flow and do not provide identity governance. They cannot detect the creation of IAM users or changes to permissions. Restricting traffic to IAM endpoints might affect API calls but does not give the visibility needed to alert on identity events.

A
IAM activity monitoring that ingests CloudTrail events to track identity-related API calls such as CreateUser and AttachUserPolicy.
IAM activity monitoring ingests CloudTrail events and surfaces identity-related API calls. This allows detection of events like CreateUser with console access enabled and policy attachment that escalates permissions. It provides the event-level visibility needed to identify both scenarios in near real time.
B
Prisma Cloud Compute's runtime defense module, which monitors process execution on EC2 instances.
Why it fails: Runtime defense monitors processes and system calls on hosts and containers. It does not observe IAM API calls or identity configuration changes. While useful for workload security, it cannot detect new IAM users or permission escalations, so it does not meet the stated requirements.
C
Prisma Cloud's data security posture management (DSPM) module, which classifies sensitive data in S3 buckets.
Why it fails: DSPM focuses on discovering and classifying sensitive data stored in cloud services. It does not monitor IAM activity or identity configuration. While important for data protection, it has no role in detecting new IAM users or permission escalations, making it irrelevant to the scenario.
D
IAM security policies that evaluate identity configurations against conditions, such as users with console access and inline policies granting administrative privileges.
IAM security policies evaluate the current state of identities against defined conditions. They can flag users with console access enabled and detect policies that grant excessive privileges. This complements activity monitoring by providing configuration-based detection of risky identity states.
E
Cloud network firewall policies that restrict outbound traffic from VPCs to known IAM endpoints.
Why it fails: Network firewall policies control traffic flow and do not provide identity governance. They cannot detect the creation of IAM users or changes to permissions. Restricting traffic to IAM endpoints might affect API calls but does not give the visibility needed to alert on identity events.