Prisma Cloud Configuration And Posture Management practice questions

Alert Suppression Rule

Why it fails: While similar, policy exceptions are the native mechanism for managing alerts per resource.

Alert Routing

Why it fails: Routing sends alerts to integrations, it does not silence them.

Resource Tagging

Why it fails: Tagging helps filter, but does not natively silence alerts.

Compute > Manage > Integrations

Why it fails: This is for runtime compute integrations, not CSPM integrations.

Alerts > Notifications

Why it fails: There is no direct menu named 'Notifications' under Alerts.

Policies > Alert Rules

Why it fails: Alert Rules define when to trigger an alert, not how to send it.

None of the above

Why it fails: The first option is the standard query format.

iam from cloud where mfa = 'disabled'

Why it fails: This syntax is not valid RQL.

config from cloud.resource where mfa.enabled = false

Why it fails: This query is generally used for cloud resource configuration, not IAM specific identity properties.

network from vpc where mfa.enabled = false

Why it fails: This is a network-based query, which is irrelevant to IAM settings.

SOC2

Why it fails: SOC2 is a standard but is not the primary 'benchmarking' report.

ISO 27001

Why it fails: ISO 27001 is supported but is a certification standard, not a benchmark.

NIST 800-53

Why it fails: While supported, CIS is the most common default benchmark.

config from cloud.resource where modifier.user = '...'

Why it fails: Config queries do not track the identity of the user who modified the resource.

activity from cloud.trail where user = '...'

Why it fails: This is not a valid RQL syntax.

iam from cloud where user = '...'

Why it fails: This does not query the resource modification event history.

Dashboard > Export

Why it fails: Dashboard > Export exports the widgets currently displayed, so it cannot filter high-severity alerts across a 30-day range unless those widgets are already configured that way. It would be correct for snapshotting an existing dashboard view, not for ad hoc report generation.

Settings > Compliance

Why it fails: Settings > Compliance holds configuration and policy controls, not alert data, so no report of high-severity alerts can be produced there. It would be correct for reviewing compliance posture or configuring retention and audit settings, not for querying alert history.

Alerts > Export

Why it fails: Alerts > Export is a raw alert-list export, not a filtered report builder; it does not natively scope results to high severity over a 30-day window. It would be correct for dumping the full alert queue to CSV for offline processing, not for producing a severity- and date-filtered report.

Saved search with a webhook notification

Why it fails: Saved searches are used to filter and display resources based on RQL queries, but they do not perform any remediation. A webhook notification can alert an external system, which might then take action, but that requires additional automation outside Prisma Cloud. This does not provide the built-in automatic remediation the team needs.

Compliance standard with auto-remediation enabled

Why it fails: Compliance standards in Prisma Cloud are used to assess and report on adherence to regulatory frameworks; they do not directly execute remediation actions. While compliance standards can trigger alerts, they lack the built-in capability to modify cloud resource configurations such as security group rules. Auto-remediation is handled by a different mechanism, so this choice does not meet the requirement.

Alert rule with a remediation action

Why it fails: Alert rules in Prisma Cloud define conditions for generating alerts and can include notifications, but they do not natively support automated remediation actions like removing a security group rule. Remediation requires a separate workflow or integration. Therefore, an alert rule alone cannot automatically remediate the unrestricted SSH access.

Use the logical AND operator (&&) between the two condition blocks.

Why it fails: The logical AND operator combines conditions, but Prisma Cloud Compute rule expressions use a domain-specific syntax where conditions are expressed as key-value pairs within a single expression, not as separate boolean blocks joined by &&. Using && here would not correctly correlate the container user and port attributes within the rule's evaluation model.

Create two separate rules, one for root user and one for port 22, and rely on Prisma Cloud to correlate the alerts.

Why it fails: Creating two separate rules would generate independent alerts, not a single correlated alert for containers meeting both conditions. Prisma Cloud does not automatically correlate separate rule alerts into a combined finding, so this approach would fail to detect only the containers that both run as root and expose port 22.

Use a single expression combining the attributes with a logical operator, such as runningAsRoot = true and port = 22.

Why it fails: While combining attributes is necessary, Prisma Cloud Compute rules use specific field names and operators in a structured expression. The generic 'runningAsRoot' and 'port' fields as written are not the exact attribute names recognized by the rule engine, so this expression would fail to evaluate correctly against container configurations.

Create a custom RQL policy that checks for KMS key rotation enabled on S3 buckets and add it to the existing alert rule.

Why it fails: While a custom RQL policy can check for KMS key rotation, the requirement is to enforce it. Prisma Cloud has a built-in policy for KMS key rotation that can be enabled. Creating a custom policy is unnecessary and may not provide the same level of detail or updates as built-in policies.

Use AWS Config rules to check for key rotation and integrate the findings into Prisma Cloud via API.

Why it fails: While integrating AWS Config findings is possible, it adds unnecessary complexity. Prisma Cloud already has native capabilities to check KMS key rotation directly from the cloud provider's configuration. This approach duplicates effort and may introduce latency.

Modify the 'S3 Bucket Encryption' policy to include a condition for key rotation.

Why it fails: Built-in policies cannot be modified to add conditions. They are maintained by Prisma Cloud. To enforce additional requirements, you would need to create a separate policy. Modifying a built-in policy is not possible and could lead to gaps in coverage.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-versioning' AND configuration.serverSideEncryption IS NULL

Why it fails: This query uses the versioning API, which returns versioning configuration, not encryption settings. The field configuration.serverSideEncryption would not be present in the versioning API response, so the query would not correctly identify buckets without encryption. The correct API must be used to retrieve encryption configuration.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND configuration.serverSideEncryption IS NULL

Why it fails: This query uses the API name for bucket ACL, which returns access control information, not encryption configuration. The field configuration.serverSideEncryption would not be populated from that API call, so the query would not accurately identify buckets lacking encryption. The correct API for encryption settings is different.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-policy' AND configuration.encryptionEnabled = false

Why it fails: The API 'aws-s3api-get-bucket-policy' returns bucket policy documents, not encryption settings. The field configuration.encryptionEnabled is not a valid attribute in the bucket policy response, so this query would not correctly identify unencrypted buckets. It would likely return no results or incorrect results.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-instances' AND json.rule = networkInterfaces[*].groups[*].groupName contains 'ssh'

Why it fails: This query searches for security group names containing 'ssh', which is not a reliable indicator of unrestricted SSH access. Security group names are user-defined and may not reflect actual rules. It does not examine the port or CIDR, so it fails to identify the specific misconfiguration.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-instances' AND json.rule = securityGroups[*].ipPermissions[*].fromPort = 22 AND securityGroups[*].ipPermissions[*].ipRanges[*].cidrIp = '0.0.0.0/0'

Why it fails: This query attempts to filter instances by their security groups, but the API 'aws-ec2-describe-instances' returns instance details, not the full security group rules. The security group rules are obtained via 'aws-ec2-describe-security-groups'. Therefore, this query will not correctly evaluate the ipPermissions field.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-security-groups' AND json.rule = ipPermissions[*].toPort = 22 AND ipPermissions[*].ipRanges[*].cidrIp = '0.0.0.0/0'

Why it fails: This query uses 'toPort' instead of 'fromPort'. For a rule allowing SSH, the fromPort and toPort are typically both 22, but using 'toPort' might miss rules where the port range is specified differently (e.g., 0-22). The correct field to check for a specific port is 'fromPort' when the rule is for that port.

configuration.versioning = false

Why it fails: This condition checks whether versioning is disabled, which is unrelated to the requirement. The policy should focus on public readability and encryption status. Adding a versioning condition would exclude buckets that are publicly readable and unencrypted but have versioning enabled, causing false negatives.

configuration.logging = false

Why it fails: This condition checks whether logging is disabled, which is not part of the specified criteria. While logging is a security best practice, it is not relevant to detecting publicly readable and unencrypted buckets. Including it would incorrectly filter out buckets that meet the actual requirement.

configuration.publicWrite = true

Why it fails: This condition checks for public write access, which is not part of the requirement. The administrator specified publicly readable and unencrypted, not publicly writable. Including this condition would narrow the results incorrectly and could miss buckets that are publicly readable but not publicly writable.

Add the policy to a policy set and apply the set to the account

Why it fails: Policy sets group policies for easier management, but they do not determine whether an individual policy is evaluated. A policy must be enabled regardless of set membership. Applying a set does not activate a disabled policy, so this step alone would not achieve continuous assessment.

Assign the policy to a compliance standard and enable the standard

Why it fails: Assigning a policy to a compliance standard affects reporting and compliance posture, but it does not control whether the policy is evaluated for findings. A policy can be enabled independently of compliance standards. The engineer must enable the policy itself, not rely on a standard to activate assessment.

Create an alert rule that references the policy and set it to trigger on all resources

Why it fails: Alert rules control notifications, not policy evaluation. Creating an alert rule does not cause the policy to be assessed against resources; the policy must be enabled for that. The engineer's goal is continuous assessment, which is governed by policy enablement, not alert rule configuration.

Account Group Read Only

Why it fails: Account Group Read Only is a role that provides read-only access to account groups, but it may not include permissions to view all alerts and compliance reports across the entire tenant. It is typically scoped to specific account groups and might not grant the comprehensive read-only access needed for a security analyst overseeing the whole environment.

System Admin

Why it fails: System Admin grants full administrative privileges, including the ability to modify configurations, manage users, and change policies. This role would violate the requirement to prevent configuration changes. Assigning System Admin to a read-only analyst would provide excessive permissions and pose a security risk.

Account and Cloud Provisioning Admin

Why it fails: Account and Cloud Provisioning Admin is a role focused on managing cloud accounts and provisioning, with permissions to add or modify accounts. It is not a read-only role and would allow configuration changes, which contradicts the requirement. This role is unsuitable for a security analyst needing only view access.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-login-profile' AND configuration.mfaEnabled = false AND configuration.consoleAccess = true

Why it fails: The API 'aws-iam-get-login-profile' retrieves the login profile for a user, which indicates console access, but it does not provide MFA status. MFA status is separate. This query would not correctly combine both conditions because the login profile API does not include MFA information.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-list-users' AND configuration.mfaEnabled = false AND configuration.consoleAccess = true

Why it fails: The API 'aws-iam-list-users' returns a list of users but does not provide MFA or console access details. The fields configuration.mfaEnabled and configuration.consoleAccess are not part of the list users response, so this query would not work as intended.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-user' AND configuration.mfaEnabled = false AND configuration.consoleAccess = true

Why it fails: The API 'aws-iam-get-user' returns user details but does not include MFA status or console access information. MFA status is obtained from a different API, and console access is indicated by login profile. Therefore, this query would not correctly filter users based on those attributes.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-role' AND json.rule = AssumeRolePolicyDocument.Statement[*].Principal.AWS contains 'arn:aws:iam::123456789012:root' AND json.rule = AssumeRolePolicyDocument.Statement[*].Condition.ExternalId exists

Why it fails: This query inverts the required condition by requiring an ExternalId to exist, so it would return roles that are actually protected by an ExternalId and miss the vulnerable ones. It also does not exclude service-linked roles, which would produce noise. The engineer needs the opposite condition and an exclusion for service-linked roles, making this option incorrect.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-role' AND json.rule = AssumeRolePolicyDocument.Statement[*].Principal.AWS equals 'arn:aws:iam::123456789012:root' AND json.rule = AssumeRolePolicyDocument.Statement[*].Condition.ExternalId not exists

Why it fails: The equals operator compares the entire Principal.AWS field to the ARN, but that field may be an array or contain multiple principals, so an exact match would fail to detect the targeted roles. Additionally, this option omits the exclusion for service-linked roles, which would generate false positives. The combination of an overly strict comparison and missing filter makes it unsuitable.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-list-roles' AND json.rule = AssumeRolePolicyDocument.Statement[*].Principal.AWS contains 'arn:aws:iam::123456789012:root' AND json.rule = AssumeRolePolicyDocument.Statement[*].Condition.ExternalId not exists AND json.rule = Path not contains '/aws-service-role/'

Why it fails: The API name 'aws-iam-list-roles' is not the correct Prisma Cloud API identifier for retrieving IAM role configuration; the correct API is 'aws-iam-get-role'. Using the wrong API name would cause the query to return no results or fail. Although the other conditions are appropriate, the incorrect API name invalidates the entire query.

Enabling the Prisma Cloud Compute agent on the RDS instances to monitor for encryption status and automatically apply encryption.

Why it fails: Prisma Cloud Compute agents are designed for workload protection on hosts and containers, not for managing RDS encryption settings. They cannot enable encryption on RDS instances. The agent-based approach would not remediate the storage-level configuration issue and is not applicable to managed database services.

Configuring a saved search in Prisma Cloud that lists unencrypted RDS instances and scheduling a daily email report to the security team.

Why it fails: A saved search provides visibility and reporting but does not perform any automated action. It cannot enable encryption on RDS instances. The engineer requires automatic remediation, so a passive reporting mechanism fails to meet the requirement. Saved searches are useful for monitoring but do not modify cloud resources.

Using the Prisma Cloud API to query for unencrypted RDS instances and then running an AWS Lambda function to enable encryption on each instance.

Why it fails: While the API and Lambda could achieve remediation, this requires custom development and does not leverage Prisma Cloud's built-in remediation capabilities. The question asks for a Prisma Cloud component, and the native policy remediation is the intended solution. This approach adds unnecessary complexity and maintenance overhead.

WITH

Why it fails: The WITH clause is used to specify additional attributes or relationships to include in the query results, but it does not logically combine conditions. It is not a logical operator. Using WITH would not ensure that both conditions are satisfied simultaneously; it would alter the output rather than filter based on multiple criteria.

OR

Why it fails: The OR clause returns resources that match at least one of the conditions. If used here, the query would return instances that either have a public IP or lack proper security group restrictions, which would include instances that do not meet both conditions. This would produce false positives and is not suitable for the requirement.

NOT

Why it fails: The NOT clause negates a condition. While it might be used within a condition to express 'not protected by a security group', it is not used to combine two separate conditions. The engineer needs to combine the public IP condition and the security group condition, so NOT alone does not achieve the logical AND required.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = logging.enabled equals false AND encryption.kmsKeyId exists

Why it fails: This query attempts to filter for buckets with logging disabled and a KMS key ID present, but the condition 'encryption.kmsKeyId exists' would select buckets that are encrypted with KMS, not those that are not encrypted. The analyst needs buckets that are not encrypted with KMS, so this query would return the opposite of the desired result.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = logging.enabled equals true AND encryption.kmsKeyId not exists

Why it fails: This query looks for buckets with logging enabled and no KMS key, which is not what the analyst needs. The requirement is to find buckets with logging disabled. Using 'logging.enabled equals true' would return buckets that have logging turned on, thus missing the target buckets.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = logging.enabled equals false OR encryption.kmsKeyId not exists

Why it fails: This query uses OR, which would return buckets that either have logging disabled or lack KMS encryption. The analyst needs buckets that satisfy both conditions simultaneously. Using OR would include buckets that have logging enabled but no KMS encryption, or logging disabled but KMS encryption, leading to an inaccurate result set.

To scope the resources monitored

Why it fails: Alert Notifications configures who is contacted and how when an alert fires — email recipients, webhooks, ticketing integrations. Scoping which resources the rule evaluates belongs to the rule's target or scope definition. Choosing this confuses delivery of the alert with the set of assets the rule monitors.

To define the policy severity

Why it fails: Alert Notifications handles recipient and channel delivery, not the severity assigned to a finding or rule. Severity is defined in the rule's detection or policy configuration. This option is tempting because severity often influences notification routing, but the section itself does not set the policy severity value.

To schedule scanning

Why it fails: Alert Notifications governs delivery of triggered alerts to recipients; scheduling of scans is configured in the scan or assessment schedule settings. Selecting this mistakes notification configuration for scan cadence. Notifications would be the right area only when specifying who receives an alert and through which channel.