Hard Difficulty Questions

Generate an API Access Key in the logging account and hardcode it into the AWS CloudFormation template parameters.

Why it fails: Prisma Cloud onboarding uses cross-account IAM roles, not long-lived access keys; hardcoding credentials in a template exposes them and breaks the assumed-role model. API keys suit programmatic access to the Prisma Cloud API itself, not AWS account onboarding.

Install a Compute Defender on the EC2 instance hosting the S3 bucket.

Why it fails: S3 is a managed object storage service and cannot host compute defenders.

Enable VPC Flow Logs to replicate directly to the Prisma Cloud Console public IP address.

Why it fails: VPC Flow Logs capture network traffic metadata and cannot be delivered to an external console IP; CloudTrail monitoring needs S3 bucket access instead. Flow Logs would be relevant when analysing network-level traffic within a VPC.

Enable AWS Shield Advanced on the account

Why it fails: AWS Shield Advanced provides DDoS protection at the network and transport layers, leaving the overly permissive inline IAM policy untouched. It is tempting as an AWS security service, but Shield Advanced addresses volumetric attacks, whereas the finding requires editing the policy to scope s3 actions to specific resources.

Convert the IAM user into an IAM group

Why it fails: Grouping the user changes identity management, not the policy document itself; the wildcard grant on '*' persists and Prisma Cloud keeps flagging it. Groups suit organising permissions at scale, but remediation here requires editing the inline policy to scope actions and resources explicitly.

Delete the entire AWS account and recreate it

Why it fails: Deleting and recreating the account removes the offending policy but also destroys all workloads, data and configurations, far exceeding the required remediation. It is tempting as a guaranteed clean slate, yet the finding calls only for amending the inline policy's resource scope.

Configuring a scheduled CSV report export sent via SMTP to the SQS endpoint email address.

Why it fails: Scheduled CSV exports over SMTP deliver batch files to a mailbox, not asynchronous event-driven messages to an SQS queue; SQS accepts API calls, not inbound email. It is tempting because scheduled reporting genuinely suits periodic compliance summaries for auditors, but it cannot push individual alerts in near real time.

AWS CloudTrail log shipping via S3 bucket notifications.

Why it fails: CloudTrail records AWS API activity, not Prisma Cloud compliance alerts, and S3 notifications cannot deliver them to SQS in the required format. It is tempting because CloudTrail plus S3 event notifications is a standard AWS-native audit pipeline, but it never carries third-party security findings.

Installing a Compute Defender directly on the SQS queue endpoint.

Why it fails: Compute Defender is a host-based agent installed on workloads, not on a managed queue endpoint; SQS exposes no host on which to install it. It is tempting because Defender agents do forward runtime events onward, but that applies to compute instances, not to brokering Prisma Cloud alerts into SQS.

The credit card number density found inside the container layers

Why it fails: Credit card number density is a data-loss-prevention concern, not a vulnerability threshold criterion; Prisma Cloud Compute rules use severity, CVSS, package type and fix status. It is tempting because Prisma Cloud does detect sensitive data in images, but that belongs to DLP policies, not vulnerability thresholds.

The geographic region where the container registry is hosted

Why it fails: Registry hosting region is not a vulnerability attribute; Prisma Cloud Compute thresholds use severity, CVSS score, package type and fix status. It is tempting because geography matters for data residency and compliance scoping, but vulnerability rules evaluate the image's packages and findings, not where the registry is hosted.

Kernel patch level compliance reports for Jira database nodes.

Why it fails: Kernel patch level compliance reports are host-hardening telemetry, not integration credentials, so they play no part in connecting Prisma Cloud to Jira. The distractor tempts because Prisma Cloud does surface kernel and patch compliance data, but that belongs in vulnerability and compliance dashboards, not in the ticketing webhook configuration.

Local root SSH private key for the Jira server operating system.

Why it fails: Jira integration uses API tokens or OAuth credentials over HTTPS; a root SSH key for the Jira host operating system is never requested and would grant excessive access. It is tempting because SSH keys authenticate to servers, but Prisma Cloud needs application-level API access, not OS login.

Attached an App-Embedded Defender to the Terraform binary executable.

Why it fails: App-Embedded Defender instruments running container workloads, not a Terraform binary, and cannot parse HCL to detect insecure container settings. It suits runtime protection of containerised applications. IaC template scanning requires a dedicated scanner integrated into the build pipeline before deployment.

Deployed a DaemonSet Defender inside the GitHub Actions runner container pool.

Why it fails: A DaemonSet Defender runs on cluster nodes to protect runtime workloads; GitHub Actions runners are not a Kubernetes cluster, and runtime agents cannot evaluate Terraform source. DaemonSet deployment suits protecting container hosts. Pre-deployment IaC scanning needs a pipeline-integrated scanner, not a node agent.

Configured a Prisma Cloud CSPM webhook to listen for git push events.

Why it fails: A CSPM webhook reacts to repository events for posture findings; it does not scan Terraform source for insecure container configuration before deployment. CSPM covers cloud resource posture, not IaC template analysis. Prisma Cloud's IaC scanning capability, invoked through the CI pipeline, performs that check.

Set up a CloudTrail log metric filter that triggers an IAM policy rollback.

Why it fails: A CloudTrail metric filter reacts to logged API activity, so it cannot evaluate Security Group ingress rules or remediate them; it also rolls back IAM policies, not security group rules. Metric filters suit alerting on specific API calls, such as detecting when a policy is modified.

Enable Trusted Advisor auto-fix within Prisma Cloud Global Settings.

Why it fails: Trusted Advisor offers checks and recommendations, not an auto-fix engine inside Prisma Cloud; no such Global Settings toggle exists. It is tempting because Trusted Advisor flags unrestricted SSH ingress, but remediation requires a Prisma Cloud alert rule bound to a remediation workflow, not a Trusted Advisor setting.

Configure an AWS SQS queue to poll Prisma Cloud alerts and apply an inline SCP to revoke the rule.

Why it fails: SCPs constrain IAM principals' permissions; they cannot revoke an ingress rule inside a Security Group, and SQS polling adds latency without remediation capability. SQS queues suit decoupled alert forwarding, but the workflow needs Prisma Cloud's native remediation action against the offending rule.

Container runtime rules that enforce a read-only root filesystem.

Why it fails: Enforcing a read-only root filesystem is a runtime defense setting that restricts filesystem writes, but it does not prevent a container from running as the root user. This control addresses a different security concern (immutability) and would not satisfy the requirement to block root containers. It is a plausible but incorrect distractor because it is a container hardening measure.

Runtime defense rules that detect and block processes running as root.

Why it fails: Runtime defense rules operate after a container is already running; they can detect and alert on or block suspicious process behavior, but they do not prevent a container from starting as root. The requirement is to prevent containers from running as root in the first place, which is a preventive control better handled at admission time or via pod security policies.

A Kubernetes Pod Security Policy (PSP) that sets runAsNonRoot: true.

Why it fails: Pod Security Policies are a Kubernetes-native feature, not a Prisma Cloud Compute capability. While PSPs can enforce runAsNonRoot, the question asks specifically for Prisma Cloud Compute capabilities. Moreover, PSPs are deprecated in recent Kubernetes versions and replaced by Pod Security Admission, so relying on them is not aligned with current Prisma Cloud Compute functionality.

The Microsoft Entra ID enterprise application must be assigned to the user.

Why it fails: If the user can authenticate and is redirected to Prisma Cloud, the application assignment in Microsoft Entra ID is already working. Assigning the app controls who can use it, but the error occurs after successful authentication. While assignment is necessary, it is not the missing configuration here because the user reached the console. Thus, this is not the most likely cause of the access denied error.

The Prisma Cloud console must be configured to trust the Microsoft Entra ID signing certificate.

Why it fails: Trusting the signing certificate is required for SAML assertion validation. If it were missing, authentication would fail earlier with a signature validation error, not an access denied after redirect. Since the user successfully authenticates and reaches the console, the certificate is already trusted. Therefore, this is not the missing configuration causing the access denied error.

The user's email domain must be added to the allowed domains list in Prisma Cloud.

Why it fails: Allowed domains restrict which email domains can authenticate. If the domain were not allowed, the user would be blocked before or during authentication, not after reaching the console. The scenario states the user exists and authenticates successfully, so domain restriction is not the issue. Hence, this is not the most likely missing configuration.

TCP 443

Why it fails: TCP 443 is typically used for HTTPS web access to the Console UI, not for Defender-Console communication. While some components may use 443 for secure API calls, the Defenders use a dedicated port for their connection. Thus, 443 is not the required port for Defender-to-Console traffic.

TCP 8081

Why it fails: TCP 8081 is used by the Console for its internal communication and is not the port that Defenders use to connect. Defenders connect to the Console on a different port. Therefore, opening 8081 is not necessary for Defender-Console communication.

TCP 8083

Why it fails: TCP 8083 is used by the Defender to communicate with the Console for management and intelligence updates, but it is not the primary port for Defender-to-Console communication. The primary communication uses a different port. Therefore, this is not one of the required ports.

Switch the Defender from privileged mode to unprivileged mode using rootless containers.

Why it fails: Rootless mode changes privilege separation for the runtime, not the scanner's CPU consumption during scheduled image scans. The mitigation is to throttle or reschedule scanning, or exclude production hosts from scan windows. Rootless deployment addresses container escape risk, not resource contention from scanning.

Disable vulnerability scanning entirely and rely solely on compliance checks for host filesystems.

Why it fails: Disabling vulnerability scanning removes the detection capability entirely, leaving images unscanned and defeating the defender's purpose. It is tempting because it immediately eliminates the CPU spike, but the correct mitigation is throttling scan concurrency, scheduling scans outside peak hours, or excluding production hosts from scheduled scans.

Restart the defender pod every 10 minutes using an external cron job.

Why it fails: Frequent restarts interrupt scans mid-execution, leaving images unscanned and potentially corrupting scan state; throttling scan concurrency or scheduling scans outside peak hours reduces CPU load instead. Restarting is tempting as a quick remedy for a hung defender, but that scenario involves a stalled process, not scheduled scan load.

The Google Cloud Billing Account ID and project number.

Why it fails: Billing account and project identifiers are used for Google Cloud account onboarding and cost visibility, not Defender registration; the installer needs the Compute Console hostname plus a registration token or service account key, so these billing parameters leave the Defender unable to locate or authenticate to the Console.

The AWS IAM Role ARN and external ID parameters.

Why it fails: GCE instances authenticate to Prisma Cloud Compute using a service account or registration token, not AWS IAM credentials; the AWS IAM Role ARN and external ID parameters only apply when onboarding AWS accounts or Defenders running on EC2, so supplying them here leaves the Defender unable to register with the Compute Console.

The Kubernetes API server cluster endpoint URL.

Why it fails: Defender registration requires the Compute Console address and a registration token or cloud credentials, not a Kubernetes API endpoint; the cluster endpoint URL is supplied only when deploying containerised Defenders into a Kubernetes cluster, so on plain GCE instances it provides nothing the installer can use to reach the Console.

Container vulnerability scans only support compiled languages like Go and C++; interpreted languages require runtime defense.

Why it fails: Prisma Cloud does scan interpreted-language packages such as pip-installed Python; the real cause is usually that the image layer still contains the vulnerable version or the fix was not rebuilt. It is tempting because runtime defence exists, but it does not replace image scanning.

The Prisma Cloud Console requires a manual sync of the National Vulnerability Database before Python CVEs update.

Why it fails: Prisma Cloud continuously pulls NVD and vendor advisory data automatically, so a manual sync is not a prerequisite for Python CVE updates. It is tempting because stale vulnerability metadata genuinely causes unresolved findings, and would be the right answer if the console showed an outdated feed rather than a package Prisma cannot map to a fixed version.

The image was scanned using an outdated twistcli version that does not support Python package scanning.

Why it fails: Twistcli scans Python packages in all supported releases; an outdated CLI would fail to detect the package entirely, not detect it and withhold the fix. It is tempting because scanner version mismatches do cause stale results, and would be correct if the CVE were missing from the report rather than present but unresolved.

network from vpc.flow where source.user = 'IAM' and destination.port = 443

Why it fails: Network flow queries traffic packets, not IAM metadata or user login dates.

event from cloud.audit where cloud.type = 'aws' and operation = 'ConsoleLogin' and mfa = false

Why it fails: An event query tracks authentication attempts, whereas static configuration properties like MFA device presence and user passwords require resource config RQL.

config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-ec2-instance' and securityGroup.rules.port = 22

Why it fails: This query evaluates EC2 security groups, not IAM user properties.

event from azure.audit where operation = 'Microsoft.Compute/disks/write'

Why it fails: This is an audit event query, whereas evaluating static configuration state requires 'config from cloud.resource'.

config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-storage-account' and supportsHttpsTrafficOnly is false

Why it fails: This query checks Azure storage account encryption/HTTPS settings, not Azure Virtual Machine disk encryption.

config from cloud.resource where cloud.type = 'azure' and api.name = 'azure-vm-disk' and encrypted = false

Why it fails: The resource API name 'azure-vm-disk' is incorrect; Azure virtual machines and their disks are evaluated under the VM compute API.

event from cloud.audit where operation = 'CreatePolicy' and result = 'FAIL'

Why it fails: Audit events track actions, whereas static evaluation of policy documents requires config RQL.

config from cloud.resource where cloud.type = 'aws' and api.name = 'aws-s3-bucket' and public is true

Why it fails: This checks S3 bucket public exposure, not IAM policies.

network from vpc.flow where protocol = 'TCP' and port = 443

Why it fails: Network queries inspect traffic flows, not IAM JSON policy structures.

Google Cloud Identity and Access Management (IAM) Admin API

Why it fails: While IAM is used for permissions, resource inventory discovery primarily depends on the Cloud Asset and Resource Manager APIs.

Google Cloud Kubernetes Engine API only

Why it fails: Enabling only GKE API would limit asset discovery exclusively to container clusters, ignoring IAM, storage, and compute instances.

Google Cloud Billing Budgets API

Why it fails: Billing APIs are used for cost management, not cloud security posture inventory discovery.

config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-iam-get-user' and accessKey1LastUsed < 90

Why it fails: Config RQL queries resource configuration metadata, but access key usage timestamps are evaluated via identity telemetry or specific IAM entity attributes.

config from cloud.resource where cloud.type = 'aws' AND resource.type = 'AWS IAM User' AND credential.age.days > 90

Why it fails: Credential age refers to creation date, not last used activity.

event from cloud.audit where cloud.type = 'aws' AND operation = 'ListUsers' and time > 90d

Why it fails: Event RQL queries runtime audit logs for actions taken, whereas dormant identity discovery requires config state inspection.

Deploy a Prisma Cloud DaemonSet Defender directly onto the Fargate tasks.

Why it fails: Fargate runs each task in its own isolated micro-VM with no host access, so a DaemonSet Defender cannot be scheduled or share the kernel. It is tempting because Prisma Cloud Defenders protect EC2-backed ECS clusters, where daemon scheduling onto hosts is possible.

Install the Twistlock Serverless Layer into each container task definition manually via AWS Lambda.

Why it fails: Twistlock's serverless layer is a Defender embedded for AWS Lambda functions, not ECS Fargate tasks, and Lambda cannot inject layers into task definitions. It is tempting because serverless protection exists, but it targets Lambda runtimes rather than Fargate container images.

Enable VPC Flow Logs to capture container payload vulnerabilities.

Why it fails: VPC Flow Logs capture IP-level metadata (source, destination, ports, bytes), never container payloads or image contents, so vulnerabilities cannot be detected. It is tempting as a network visibility tool, but image scanning requires inspecting the image itself before task instantiation.

Encrypting all unencrypted AWS EBS volumes in real-time using inline proxy interception.

Why it fails: Prisma Cloud Data Security performs agentless discovery and classification of sensitive data; it does not intercept storage I/O to encrypt volumes. Inline proxy encryption describes a separate data-security control, relevant when the requirement is remediating unencrypted volumes rather than scanning.

Acting as a CASB inline reverse proxy for SaaS applications like Office 365.

Why it fails: Prisma Cloud Data Security scans cloud storage for sensitive data; it is not an inline CASB reverse proxy mediating SaaS traffic. That proxy role belongs to a CASB product, which would be chosen when the requirement is controlling user sessions to Office 365.

Running active penetration tests against database endpoints.

Why it fails: Prisma Cloud Data Security is a posture and discovery tool; it does not execute exploitation attempts against database endpoints. Active penetration testing is a distinct offensive discipline, chosen when the requirement is validating exploitable weaknesses rather than identifying where sensitive data resides.