Hard Difficulty Questions

Configure a compliance report to scan the cloud provider

Why it fails: A compliance report only observes and reports posture; it cannot enforce key rotation or expiry, so keys older than 90 days persist. It is tempting because compliance reporting genuinely suits evidence gathering and audit trails, and would be correct where visibility rather than enforcement is the requirement.

Create a network policy to block older keys

Why it fails: Network policies filter traffic by IP, port and protocol; they cannot evaluate IAM access key age or revoke credentials. It is tempting because network policies genuinely enforce segmentation controls, and would be correct when restricting which workloads or subnets may communicate with a resource.

Use the Cloud Provider Console to set an expiration

Why it fails: The cloud provider console sets expiry per key manually, which does not scale and cannot guarantee no user holds a permanent key beyond 90 days. It is tempting because native consoles genuinely manage individual credentials, and would be correct for ad hoc rotation of a single key rather than an enforced policy.

Vulnerability Report

Why it fails: The Vulnerability Report lists detected CVEs and software weaknesses on scanned assets, containing no configuration attribute showing whether RDS encryption at rest is enabled. It is tempting because it is a compliance-style report, but that is for patch and vulnerability management, not configuration posture evidence.

Alert Summary Report

Why it fails: The Alert Summary Report aggregates triggered policy alerts over a period, reflecting events rather than current resource configuration, so it cannot evidence encryption state at a point in time. It is tempting because alerts derive from the same policies, but that is for tracking violations over time.

Asset Inventory report

Why it fails: Asset Inventory lists resources and configuration attributes, but it is not a compliance-evaluation report, so it cannot evidence that encryption at rest is enabled against a framework requirement. It is tempting because inventory does surface RDS metadata; it would be the right choice for simply enumerating deployed RDS instances, not for point-in-time compliance validation.

Creating an IAM user with long-term keys

Why it fails: Long-term IAM access keys are permanent credentials, directly contradicting the requirement for temporary access without permanent users. The tempting appeal is simplicity and familiarity, but IAM users with access keys are the correct choice only for persistent programmatic identities you fully control, not external auditors.

Giving them your root password

Why it fails: Sharing the root password grants unrestricted, permanent account control with no scoping, expiry or auditability, violating least privilege and the temporary-access requirement. It is tempting as a quick way to give broad access, but root credentials are correct only for the few account-level tasks that genuinely require them.

Configuring a site-to-site VPN

Why it fails: A site-to-site VPN only establishes encrypted network connectivity between sites; it grants no AWS identity, permissions or temporary credentials. It is tempting because it sounds security-focused, but a VPN is correct when you need private network transport, not delegated, time-bound access for an external auditor.

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.

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.

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.

Reviewing physical datacenter floor plans

Why it fails: Cloud-native threat modelling examines identities, IAM policies, APIs, serverless functions, containers and shared-responsibility boundaries; physical floor plans are irrelevant because the provider secures the datacentre. It is tempting as classic threat modelling often maps physical access, but that layer sits outside the customer's control. The correct step enumerates cloud attack surfaces.

Updating local workstation antivirus

Why it fails: Cloud-native threat modelling focuses on IAM, APIs, containers and serverless attack paths; endpoint antivirus on local workstations falls outside the cloud workload boundary. It is tempting because antivirus is a familiar security control, but it does not address cloud service misconfiguration or identity abuse. The correct step enumerates cloud-native attack surfaces.

Ordering new network hardware

Why it fails: Cloud-native threat modelling addresses identity, API, container and serverless attack surfaces under the shared-responsibility model; hardware procurement is a provider concern and irrelevant to design analysis. It is tempting because on-premises threat modelling historically included network hardware, but cloud infrastructure is abstracted. The correct step maps cloud-specific trust boundaries and IAM permissions.

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.

Vulnerability Scan

Why it fails: Vulnerability Scan inventories software flaws and missing patches on hosts and images, giving no view of runtime connection topology between workloads. It is the correct capability when the goal is prioritising CVE remediation rather than tracing anomalous lateral traffic.

Auto-Remediation

Why it fails: Auto-Remediation executes corrective actions on already-detected misconfigurations; it consumes findings rather than producing the network flow telemetry needed to spot suspicious east-west traffic. It suits enforcing guardrails automatically once a policy violation has been identified.

IAM Security

Why it fails: IAM Security analyses identity permissions, entitlement sprawl and effective access, so it maps who can reach what, not live connection paths between workloads. It is the right capability for detecting excessive privileges or risky role assignments rather than visualising network flows.

Update the AWS Security Group to block all inbound traffic

Why it fails: Blocking inbound traffic leaves the containerised process running and reachable outbound, so no memory or filesystem artefacts are captured for examination. It is tempting because Security Groups are the standard AWS network control, and would be correct for cutting off an external attacker's access, not for forensic acquisition.

Restart the container to clear memory

Why it fails: Restarting the container discards the running process's memory and any resident malware, erasing the volatile evidence forensic analysis requires. It is tempting as a quick remediation step, and would be correct when restoring a known-good service state, but it destroys exactly the artefacts Prisma Cloud Compute would capture.

Delete the EC2 instance immediately to stop the breach

Why it fails: Terminating the instance destroys volatile memory, container filesystem state and network connections before any evidence is captured, defeating the forensic goal entirely. It is tempting as breach containment, and would be right when stopping active exfiltration outweighs evidence preservation, but here analysis is the stated objective.

Encrypting the data stored within the application

Why it fails: In SaaS the customer remains responsible for classifying and encrypting its own data, including choosing encryption keys where customer-managed keys are offered. It is tempting because the provider encrypts data at rest on its infrastructure, which is a provider task, but application-level data encryption stays with the tenant.

Configuration of user access roles

Why it fails: User access role configuration stays with the SaaS customer, who decides which of its staff may use which features. It is tempting because the provider manages the identity platform and role definitions, but assigning roles to the tenant's own users is a customer administrative task, not a provider one.

Vulnerability Logs

Why it fails: Vulnerability logs record CVEs and misconfiguration findings against hosts, images and workloads, containing no caller identity or API request context. They would be the right source for triaging an unpatched package, but identifying the principal behind suspicious API calls requires audit or CloudTrail-style activity logs.

Flow Logs

Why it fails: Flow logs capture network metadata such as source and destination IPs, ports and bytes transferred, which can show exfiltration traffic but not the authenticated identity issuing API calls. They suit network-path investigations; attributing API activity to a specific principal requires audit logs recording the caller's identity.

Compliance Logs

Why it fails: Compliance logs report posture against benchmarks and regulatory controls, such as failed CIS checks, rather than per-request API activity. They are the correct source for audit-readiness reporting, but they do not record which identity invoked an API, so they cannot attribute the exfiltration calls.

User biography

Why it fails: RQL requires a resource or data type, filtering criteria and selected fields; a user biography is descriptive HR content, not a query component. It is tempting because user attributes such as department or manager appear in identity queries, but biography text is never an essential structural element.

System uptime

Why it fails: RQL queries are built from a data type, filter conditions and fields to return; uptime is a monitored metric, not a query element. It is tempting because availability data is frequently queried in cloud security reporting, so it feels relevant, but it belongs in the results, not the query structure.

It will automatically whitelist all current connections.

Why it fails: Learning is a deliberate process, it doesn't happen just by enabling block.

It will automatically switch to alert mode.

Why it fails: Prisma Cloud respects the configured mode.

It will have no effect.

Why it fails: It will start blocking immediately.

Delete Account

Why it fails: Delete Account is an identity lifecycle operation performed in a directory or IAM console, not an action an alert rule can invoke on a monitored resource. It is tempting because alert rules can trigger automated responses, yet those act on the monitored workload, not on user accounts in Microsoft Entra ID.

Reboot VM

Why it fails: Reboot VM is a compute management operation issued through the cloud provider's instance controls, not an action available inside an alert rule's action list. It is tempting because alert rules do automate remediation, but they target monitoring, notification and workload-level responses rather than virtual machine power state.

Format Disk

Why it fails: Format Disk is not an alert-rule action; it is a destructive disk operation performed through OS or storage tooling, and no alerting platform exposes it as a response. It is tempting because alert rules do offer remediation actions, but those are scoped to notification, tagging or workload control rather than low-level disk formatting.

Cloud Workload Protection

Why it fails: Cloud Workload Protection provides runtime defense for containers, hosts, and serverless functions, but it does not include web application firewall capabilities. It focuses on process, file, and network monitoring, not on inspecting HTTP traffic for OWASP threats. Therefore, it does not meet the requirement for web application protection.

Container Runtime Defense

Why it fails: Container Runtime Defense monitors container behavior for suspicious processes and network activity but does not analyze HTTP requests for web vulnerabilities. It cannot detect or block OWASP Top 10 attacks like SQL injection, as it operates at the process level, not the application layer. Therefore, it does not satisfy the requirement.

Host Vulnerability Management

Why it fails: Host Vulnerability Management scans host operating systems for vulnerabilities but does not inspect web traffic or protect against application-layer attacks. It is not designed for web application security and would not provide protection against OWASP Top 10 threats. Thus, it is not the appropriate module for this scenario.

Container image vulnerability scan results for outdated packages.

Why it fails: Vulnerability scanning identifies known CVEs in images but does not detect active crypto-mining behavior at runtime. Mining attacks can be deployed via previously clean images or through runtime exploits. While important, it is not a runtime detection method for active mining processes.

File integrity monitoring of system binaries under `/usr/bin`.

Why it fails: While file integrity monitoring is useful for detecting unauthorized changes to system binaries, it is not the primary runtime capability for detecting crypto-mining attacks. Mining attacks often involve new binaries or scripts, not necessarily modifying existing ones. It may provide indirect indicators but is not as direct as process or network monitoring.

Kubernetes API server audit logs for suspicious `create pod` events.

Why it fails: Audit logs can reveal suspicious deployment activity, but crypto-mining attacks typically occur within existing containers. Monitoring API server logs is more about control plane security and does not directly detect runtime mining behavior. It is not a runtime capability of Prisma Cloud Compute for workload protection.

network from vpc.flow_logs where ...

Why it fails: This is for network traffic.

scan from images where ...

Why it fails: This is for container images.

audit from cloud.audit_logs where action = 'Admin'

Why it fails: Audit logs track activity, not static configuration state.

Azure Monitor activity log

Why it fails: The Azure Monitor activity log records control-plane operations such as role assignments and resource creation, but it does not capture data-plane operations like reading or writing blobs. It would not show which identities accessed blob content or what operations they performed on the data.

Azure Defender for Storage alerts

Why it fails: Azure Defender for Storage generates security alerts for suspicious activities, but it does not provide a complete audit trail of all access and operations. It is a threat detection service, not a forensic logging solution, so it cannot reliably show every identity and operation over a 14-day period.

Azure Storage analytics logging (classic)

Why it fails: Classic Storage analytics logging is a legacy feature that provides some logging for blobs, tables, and queues, but it lacks detailed identity information and is being deprecated in favor of Azure Storage diagnostic settings in Azure Monitor. It also does not integrate with modern query and alerting capabilities.

Host Security

Why it fails: Focuses on the node, not the image.

Runtime Security

Why it fails: Focuses on active containers, not image build history.

Compliance Reporting

Why it fails: Focuses on posture, not image forensics.

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.