Cloud Workload Protection practice questions

Install a Host Defender directly onto the AWS Lambda underlying hypervisor host.

Why it fails: Lambda runs on AWS-managed infrastructure, so no customer-accessible hypervisor host exists to install Host Defender onto. Host Defender protects virtual machines and hosts you control; serverless runtime protection instead uses a lightweight in-function sensor or the vendor's serverless defender.

Configure a VPC endpoint to tunnel all Lambda stdout logs to the Prisma Cloud Console.

Why it fails: A VPC endpoint forwards Lambda stdout logs; it provides no runtime behavioural enforcement, so malicious function execution continues unblocked. Log shipping suits centralised observability, whereas serverless runtime defence requires an in-process agent or embedded sensor.

Attach an Amazon Inspector agent to the Lambda function execution role.

Why it fails: Amazon Inspector assesses EC2 and container images for vulnerabilities; it has no Lambda runtime agent and attaching anything to an execution role grants permissions rather than inspecting invocations. Prisma Cloud's serverless runtime protection is the correct feature when code-layer modification is prohibited.

Reconfigure the EC2 instance metadata service from IMDSv1 to IMDSv2.

Why it fails: IMDS version affects how instances retrieve credentials, not outbound traffic on port 8084, so it cannot explain the dropped packets. It is tempting because IMDSv2 hardens instance metadata, and would be correct when addressing SSRF-style credential theft rather than connectivity.

Verify that AWS Shield Advanced is enabled on the VPC containing the EC2 instances.

Why it fails: Shield Advanced provides DDoS protection at the network edge; it does not open the outbound path to the console on port 8084. It is tempting because it is an AWS security service associated with VPCs, and would be correct when defending internet-facing resources against volumetric attacks rather than diagnosing blocked egress.

Check if AWS CloudTrail is logging API calls for the EC2 instances.

Why it fails: CloudTrail records AWS API activity and has no bearing on Host Defender traffic to the console. Port 8084 is Prisma Cloud's outbound communication channel, so the administrator must verify the console's IP allowlist, DNS resolution and any proxy or inspection device dropping those packets.

Serverless Defender layer.

Why it fails: Serverless Defender instruments functions in AWS Lambda, Azure Functions or Google Cloud Functions, so it cannot install on a plain Linux host. It is the right pick when protecting event-driven function code without managing a host agent. A standalone VM needs the host-based Defender instead.

DaemonSet Defender.

Why it fails: DaemonSet Defenders deploy one pod per Kubernetes node, so they cannot install on a host without Kubernetes or Docker. They suit cluster-wide coverage where every node needs a Defender, whereas a standalone Linux VM requires the single-host Defender type.

Container Defender for ECS Fargate.

Why it fails: Container Defender for ECS Fargate secures tasks orchestrated by AWS ECS, requiring that container runtime; a standalone Linux VM runs neither Kubernetes nor Docker, so no container workload exists to protect. It is tempting because Fargate Defender suits serverless container estates, but here the host needs a host-based Defender instead.

Enable AWS IAM Role restriction policies within the Prisma Cloud CSPM module.

Why it fails: IAM role restriction policies audit and remediate overly permissive roles; they do not intercept network traffic to the instance metadata endpoint. That protection comes from runtime defence or workload firewall rules, which would be correct where the requirement is blocking live metadata calls.

Deploy an AWS VPC Endpoint for the Amazon EC2 Metadata Service.

Why it fails: A VPC endpoint only routes traffic addressed to the metadata service through a private path; it does not block a workload from reaching 169.254.169.254, which is link-local and never leaves the instance. It is tempting as private connectivity, but Prisma Cloud's container runtime defence blocks that access.

Set up a Web Application and API Security (WAAS) rule to inspect SQL injection attacks.

Why it fails: WAAS rules inspect inbound HTTP traffic for application-layer payloads such as SQL injection; metadata service requests go to a link-local IP over HTTP from the workload itself, never traversing that inspection path. WAAS is correct for protecting published web applications, not workload egress.

Enable AWS Certificate Manager to issue certificates for all pods automatically.

Why it fails: AWS Certificate Manager issues certificates for AWS load balancers and services, not per-pod identities, and provides no micro-segmentation. It is tempting because ACM is the natural certificate authority for AWS-hosted TLS endpoints, but Prisma Cloud's container mTLS and micro-segmentation are delivered through the Defend > Access Control capability.

Configure AWS Security Groups for Pods to enforce IP-level filtering.

Why it fails: Security Groups for Pods enforce IP and port filtering at the AWS VPC layer, providing neither workload identity certificates nor mTLS between services. Prisma Cloud's container network micro-segmentation and mTLS are delivered through its CNI-based defender, not native AWS security groups.

Deploy Prisma Cloud WAAS as a sidecar proxy on every Kubernetes pod.

Why it fails: WAAS sidecars provide web application and API protection, not mTLS identity or micro-segmentation. It is tempting because sidecars can intercept traffic, but Prisma Cloud's container-defender and service-discovery components enforce mTLS and segmentation without per-pod proxies.

Navigate to Cloud Security > Governance > Alert Rules.

Why it fails: CSPM alert rules handle posture management findings, not Compute vulnerability alerts.

Navigate to Defend > Vulnerabilities > Images > Email Settings.

Why it fails: Vulnerability defend rules configure blocking/alerting actions within the console, external integrations are handled under system management.

Navigate to Runtime > Audits > Webhooks.

Why it fails: Runtime audits have specific log forwarding settings, not general system notification routing.

DNS zone transfer records and domain registrar registration dates.

Why it fails: DNS records are outside the scope of container workload radar.

AWS billing costs and cloud provider monthly expenditure forecasts.

Why it fails: Billing and cost management are handled by cloud financial management tools, not Radar.

Active IAM user password expiration dates and MFA status.

Why it fails: IAM user details are tracked in CSPM posture views, not Compute Radar.

AWS IAM policy wildcard permissions and multi-factor authentication enforcement.

Why it fails: IAM and MFA policies are evaluated by Prisma Cloud CSPM, not Compute compliance checks.

GitHub repository branch protection rule enforcement and pull request approvals.

Why it fails: GitHub branch rules are managed via developer tools and code security posture management.

Attach an AWS IAM policy named 'PrismaCloudDefender' to the EC2 instance metadata.

Why it fails: IAM policies grant permissions, not software installation capability.

Configure an AWS CloudWatch alarm to trigger the Prisma Cloud agent download.

Why it fails: CloudWatch alarms cannot install software on EC2 instances.

Enable AWS Inspector, which natively includes the Prisma Cloud Defender runtime.

Why it fails: AWS Inspector is a separate native service and does not include Prisma Cloud Defenders.

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.

Host runtime rule with network egress monitoring and a denied IP list

Why it fails: Host runtime rules can monitor network activity, but a denied IP list is not the right construct for detecting reverse shells to unapproved external addresses. The team needs a model that learns or defines expected outbound connections and alerts on deviations. A static denied list would miss unknown external addresses, so it does not meet the requirement.

Compliance check that verifies iptables rules are present on each host

Why it fails: A compliance check reports whether iptables rules exist but does not detect active reverse shell connections. Even a host with correct firewall rules could have an allowed or misconfigured path for egress. This option verifies configuration rather than behavior, so it does not satisfy the detection requirement.

Container runtime policy scoped to the host's Docker daemon

Why it fails: Container runtime policies apply to containers, not to the host operating system processes. A reverse shell originating from a host process would not be covered by a container policy. This option misidentifies the workload type and would leave host-level network behavior unmonitored.

AWS Lambda function policy in IAM that denies s3:PutObject to unapproved buckets

Why it fails: IAM policies can restrict S3 actions, but they are not a Prisma Cloud Compute capability and would require managing AWS-native policies rather than the vendor's runtime protection. The question specifies using Prisma Cloud Compute without code changes, so an IAM-only control does not meet the stated tooling requirement.

Admission Control policy on the Kubernetes cluster hosting the Lambda functions

Why it fails: AWS Lambda functions do not run on a Kubernetes cluster in this scenario, so an Admission Control policy is inapplicable. Admission Control governs Kubernetes workload creation, not serverless function runtime behavior. This option misidentifies the platform and would not enforce the required S3 egress restriction.

Vulnerability scan of the Lambda deployment package during CI/CD pipeline execution

Why it fails: Scanning the deployment package identifies vulnerable libraries but does not enforce runtime network restrictions. A function could contain no known CVEs yet still attempt to write to an unapproved bucket. This option addresses a different risk and does not provide the runtime blocking the team requires.

Deploy the Defender as a Kubernetes DaemonSet on the Docker host.

Why it fails: A DaemonSet is a Kubernetes construct and requires a Kubernetes cluster. The scenario describes a Docker host, not a Kubernetes node, so a DaemonSet cannot be used. Even if Kubernetes were present, the DaemonSet Defender still relies on host-level monitoring for full runtime visibility, but the deployment method itself is invalid here.

Deploy the Defender as a sidecar container in each application pod.

Why it fails: A sidecar container runs alongside a specific application container and monitors only that container's traffic and processes. It cannot provide host-wide runtime behavioral data for all containers, and it is not applicable to plain Docker hosts without orchestration. Short-lived batch jobs would also need their own sidecar, which is impractical.

Deploy the Defender as a Docker container with the --privileged flag and mount the Docker socket.

Why it fails: Running the Defender as a privileged container with the Docker socket mounted gives it access to the host, but it does not automatically monitor other containers' runtime behavior unless additional host mounts and capabilities are configured. Moreover, short-lived batch jobs may start and finish before the containerized Defender can attach, and restarting the Docker daemon is often required to apply the necessary mounts, which the scenario forbids.

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.

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.

Apply a Prisma Cloud WAAS rule for Kubernetes to inspect inbound HTTP requests for SQL injection.

Why it fails: WAAS inspects inbound HTTP payloads for web exploits such as SQL injection, leaving outbound command-and-control traffic untouched. It is the right control for protecting a published web application; blocking egress to a known malicious IP requires a Container Defender runtime rule, such as a custom network egress rule.

Create a Kubernetes NetworkPolicy blocking egress traffic on ports 80 and 443 for all namespaces.

Why it fails: A blanket NetworkPolicy blocking ports 80 and 443 across all namespaces halts legitimate web and API egress while still permitting the C2 channel on other ports. NetworkPolicy suits broad namespace segmentation; detecting and blocking a specific known malicious IP needs a Container Defender runtime egress rule.

Enable Compliance Explorer rules to audit unauthorized listening ports inside the container filesystem.

Why it fails: Compliance Explorer audits configuration against benchmarks and reports listening ports; it neither inspects outbound connections nor enforces blocking. It suits posture auditing and compliance reporting, whereas preventing a pod reaching a known command-and-control IP requires a Container Defender runtime network egress rule.

Enable Azure Defender for Containers to forward image digests to the Prisma Cloud Console.

Why it fails: Azure Defender for Containers scans within Azure and reports its own findings; it does not perform Prisma Cloud registry scanning. It is the right choice when you want native Azure threat detection for running clusters rather than pre-deployment image assessment.

Deploy a DaemonDefender on the Azure Container Registry managed control plane nodes.

Why it fails: DaemonDefender runs as a host-based defender on cluster nodes, so it cannot scan registry images that are never deployed. It is tempting because it protects running containers, and would be correct for runtime workload protection on Kubernetes nodes, not registry scanning.

Use twistcli scan on the Azure Portal cloud shell using local credentials.

Why it fails: Running twistcli in the Azure Portal cloud shell uses local credentials and cannot authenticate to Prisma Cloud's registry scanning service, so images in ACR are never assessed. Twistcli is intended for local CI pipelines or on-premises registries where a Console address and token are supplied directly.

The WAAS rule was configured with the action set to 'Prevent' instead of 'Alert'.

Why it fails: Prevent versus Alert governs whether matching traffic is blocked or merely logged; neither affects whether the rule inspects encrypted HTTPS. Alert mode is tempting when diagnosing silent rules, but TLS interception or decryption configuration is what enables inspection of encrypted flows.

The Host Defender license does not include Web Application Firewall features.

Why it fails: Host Defender is endpoint protection and its licensing is unrelated to WAAS inspection of ingress traffic; the likely cause is that the Ingress controller's TLS is terminated before WAAS sees it, or the rule is not attached to that workload. It is tempting because licence gaps do disable features.

Prisma Cloud WAAS only supports unencrypted HTTP traffic on port 80.

Why it fails: WAAS inspects TLS-decrypted traffic, so port 80-only HTTP is false; the real cause is usually missing TLS decryption or certificate trust between the Ingress controller and WAAS. It is tempting because WAAS does inspect plain HTTP, which would be the answer if the stem described unencrypted port 80 traffic.

Apply an AWS IAM Service Control Policy to restrict pushing container images to Amazon ECR.

Why it fails: IAM Service Control Policies govern which AWS API actions an account or principal may call; they cannot inspect image contents for CVEs. Tempting because SCPs can deny ecr:PutImage pushes, but that blocks all pushes regardless of vulnerability, whereas Prisma Cloud's CI/CD scanning gates the pipeline on actual CVE severity.

Set up a Kubernetes Admission Controller webhook to block pods with vulnerable base images.

Why it fails: An admission webhook evaluates pods at cluster admission, after the pipeline has already built and pushed the image, so it cannot block the CI/CD stage itself. Tempting because it enforces policy at deploy time, which suits runtime cluster hardening, but the question asks where Prisma Cloud gates the pipeline.

Enable runtime audit mode on the Host Defender to terminate processes matching high-severity CVEs.

Why it fails: Host Defender runtime audit observes and terminates processes on running hosts, which is post-deployment detection and response, not pipeline prevention. Tempting because it acts on CVE-matching behaviour, but the requirement is blocking high-severity CVEs before deployment, which Prisma Cloud's CI/CD scan enforces.

Attach the Prisma Cloud defender image directly as a volume mount to every application deployment.

Why it fails: Mounting the defender image as a volume inside application pods runs it as a container filesystem layer, not a managed workload; the control plane schedules no defender object and cannot scale or reconcile it. Sidecar injection suits per-pod instrumentation, not cluster-wide defender rollout.

Manually SSH into every worker node and install the defender binary as a systemd service.

Why it fails: SSH installation as a systemd service places the defender outside Kubernetes, so the control plane neither schedules nor reconciles it, and node replacement loses it. Configuration management suits stable pet servers, not elastic cluster nodes requiring automated, control-plane-managed rollout.

Configure a cron job on the master node to execute docker run for the defender image hourly.

Why it fails: A host-level cron invoking docker run bypasses the Kubernetes control plane entirely, so the defender is unmanaged, unscheduled and invisible to the API server. Cron jobs suit scheduled batch tasks declared as Kubernetes objects, not node-level agent installation.