Prisma Cloud Interview Q&A — CSPM, CWPP, CIEM & Code-to-Cloud

A CNAPP (Cloud-Native Application Protection Platform) unifies the tools you'd otherwise buy separately for cloud security. Prisma Cloud bundles CSPM (posture/config), CWPP (workload/runtime protection), CIEM (identity entitlements), IaC and Code Security (shift-left scanning of Terraform/CloudFormation/K8s), WAAS (web app and API security), and Data Security / DSPM (data classification and exposure).

The point of a CNAPP is correlation: instead of six dashboards, one platform links a code finding to the running asset and the over-privileged identity that can reach it.

The Console is the brain — the management plane (SaaS for Enterprise Edition, or self-hosted in Compute Edition). It holds policies, scan results, the UI and the API. A Defender is the agent you deploy onto the workload (host, container node, serverless wrapper) that does the actual scanning and runtime enforcement, then reports back.

Defenders pull policy from the Console and push telemetry up. In Compute Edition the Defender connects to the Console over a WebSocket on TCP 8084, while the UI/API listens on 8083. The Defender always initiates the connection — that detail matters for firewall questions.

Agent-based (Defender) gives you real-time runtime defense, drift detection, WAAS inline protection and per-process visibility — but you must deploy and maintain it. Agentless scanning takes a snapshot of the disk/volume (via cloud APIs) to find vulnerabilities and compliance issues with zero install, ideal for unmanaged or legacy VMs.

In a real estate, I'd say: agentless for breadth and fast coverage of everything Aditya's team can't touch, agent-based for the crown-jewel workloads that need live protection. Agentless cannot do runtime enforcement — that's the trade-off. Most mature shops at a Mumbai bank run both: agentless everywhere, Defenders on production.

You add the account under Settings → Cloud Accounts and run the provided CloudFormation Template (CFT), which creates an IAM role that Prisma Cloud assumes cross-account via sts:AssumeRole with an external ID. For read-only posture you grant the SecurityAudit-style policy; for remediation and Data Security you grant additional write permissions.

For org-wide coverage at a place like Infosys, you onboard the AWS Organization (management account) so new member accounts are auto-discovered. Azure uses an App Registration / service principal, GCP a service account, OCI a dynamic group. Same idea everywhere: a scoped role Prisma Cloud assumes.

Code-to-cloud means Prisma Cloud follows a risk from where it's born to where it lives. A misconfiguration written in Terraform (caught by IaC scanning), the image built in CI (caught by image scanning), and the running resource in AWS (caught by CSPM) are the same object at different stages — Prisma Cloud links them.

It matters because fixing a public bucket in the Terraform module stops it recurring across every deploy, while fixing it only in the console is whack-a-mole. In an interview, say you'd trace a runtime alert back to the offending repo and PR so Rahul's dev team fixes the source, not just the symptom.

CSPM is largely agentless and API-driven. Prisma Cloud assumes the IAM role and pulls resource configs via cloud provider APIs on a polling cycle, and — where available — subscribes to near-real-time event streams (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) so config changes are evaluated within roughly a minute or two rather than waiting for the next full scan.

For a panel, the nuance is: scheduled scans give completeness, the event stream gives speed. If CloudTrail isn't wired into the onboarding, you lose the fast path and a public-bucket change might only surface on the next poll. That's a common gap I'd check first when a Hyderabad SOC complains alerts are 'slow'.

Palo Alto has been folding Prisma Cloud's CNAPP capabilities into Cortex Cloud, unifying posture and runtime cloud security with the broader Cortex detection-and-response stack. For an interview, be precise: the capabilities — CSPM, CWPP, CIEM, IaC/Code Security, WAAS, DSPM — are preserved and continuous; the branding and console packaging are converging.

Don't oversell it. Say you track the platform by capability, not marketing name, and that existing Prisma Cloud tenants keep working through the transition. That shows you read release notes and aren't reciting a two-year-old training deck.

A config policy evaluates the configuration of a cloud resource against a rule and flags it if it's non-compliant — for example "S3 bucket allows public read" or "security group allows 0.0.0.0/0 on port 22". Each policy carries a severity, a compliance mapping and an RQL query that defines the matching resources.

Prisma Cloud ships hundreds of default policies; you can clone and tune them or write custom ones. Config policies are point-in-time state checks — different from network policies (flow-based) and audit event policies (activity-based), which is a distinction panels like to test.

Out of the box Prisma Cloud maps findings to frameworks like CIS Benchmarks (per cloud), PCI-DSS, NIST 800-53 / CSF, ISO 27001, HIPAA, SOC 2 and GDPR, among others. Each policy is tagged to one or more controls, so the Compliance dashboard shows a percentage-passing score per standard.

You can also build a custom compliance standard — say a Chennai ITES wants its own internal baseline — and attach existing or custom policies to its controls. The selling point to an auditor is one-click evidence per control.

RQL (Resource Query Language) is Prisma Cloud's SQL-like query language for cloud data. You use it in the Investigate tab for ad-hoc hunting and as the engine behind custom config, network and audit policies. A config query starts with config from cloud.resource where ... and filters on the resource's JSON config.

Example: config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-s3api-get-bucket-acl' AND json.rule = 'publicAccessBlockEnabled is false'. There are four query types — config, network, event and iam — and knowing which prefix to use is half of writing good RQL.

Three distinct objects. (1) A policy detects a violation via RQL. (2) An alert rule is scoped to specific accounts/regions and decides which policies generate alerts there and what happens — notifications, integrations, and optionally auto-remediation. (3) Remediation runs the policy's remediation command (a CLI/API call) to fix the resource.

The gotcha — and a favourite panel trap — is that auto-remediation only fires if the policy is remediable AND the alert rule has auto-remediation enabled AND Prisma Cloud's IAM role has write permission. Miss any one and the alert stays open while the bucket stays public, exactly Sneha's scenario.

The Asset Inventory is the normalized catalogue of every discovered resource across all onboarded clouds, with a pass/fail posture score and filters by account, region, service and tag. It's your single source of truth for 'what do we even have running?'

Config drift is detected when a resource's live state diverges from a known-good baseline — most powerfully when Prisma Cloud compares the deployed resource against its IaC definition (code-to-cloud drift). If Priya's Terraform says the bucket is private but the live bucket is public, that's drift, and it points straight at a manual console change someone made out-of-band.

I'd tune, not silence. First, scope alert rules tightly — separate prod from dev so a public bucket in a sandbox doesn't page anyone. Second, fix severity inflation: clone noisy default policies and re-rate or disable ones that don't apply. Third, use resource lists and tagging to exclude sanctioned exceptions rather than dismissing alerts one by one.

Then route by severity — only high/critical to PagerDuty, the rest into a Jira queue for weekly review. Finally, attack the source: if 200 alerts come from one bad Terraform module, fix the module so the next deploy is clean. The goal is fewer, truer alerts — never blanket suppression that hides a real breach.

Auto-remediation is great for low-blast-radius, unambiguous fixes — disabling public access on a non-prod bucket, enabling default encryption, closing an obviously wrong SG rule. The risk is a 'fix' that breaks a legitimate flow: auto-closing port 443 because a policy mis-scoped could take down Karthik's payment service.

My rule: auto-remediate reversible, well-understood, non-prod or clearly-bad findings; require human approval (manual, or a SOAR playbook with an approval step) for production and anything that touches networking or IAM. Always confirm the remediation command and that the IAM role is scoped to only that action — over-broad write permission is its own risk.

Four common ones. Container Defender runs as a privileged container (typically a DaemonSet on each Kubernetes node) and protects containers on that host. Host Defender runs as a service directly on a VM/bare-metal host with no containers. Serverless Defender is a library/layer embedded into a function (AWS Lambda, Azure Functions) for runtime protection. App-Embedded Defender wraps a single app/container where you can't install a full host agent — Fargate, for example.

Match the Defender to the runtime: DaemonSet for EKS/AKS nodes, host for plain EC2, serverless for Lambda, app-embedded for Fargate.

Prisma Cloud scans container images for vulnerabilities (CVEs), compliance issues and embedded secrets — at three points: in CI (via the twistcli tool or a plugin, before push), in the registry (scheduled scans of ECR/ACR/GCR/Harbor), and at runtime (deployed images already running). It maps each CVE to severity, fixed-version and whether it's actually in a running container.

The value is shift-left: catch the vulnerable base image when Aman builds it in CI, fail the pipeline, and it never reaches the registry — far cheaper than patching it in production later.

A vulnerability scan finds known CVEs in the OS packages and application dependencies inside an image or host — it answers "what unpatched flaws exist here?" A compliance scan checks configuration and hardening against benchmarks (CIS Docker, CIS Kubernetes, custom checks) — it answers "is this built and run the way our standard says?"

Concretely: a vuln finding is OpenSSL CVE-2024-xxxx, fixed in 3.0.13; a compliance finding is container running as root or Docker daemon TLS not enabled. Panels ask this because candidates blur them — both matter, but they come from different rule engines and have different fixes.

For each image, the Defender learns a model during an initial period — the expected processes, file activity, outgoing network connections and (for K8s) capabilities. After learning, it switches to protect mode and flags or blocks anything outside that model: an unexpected /bin/sh spawning, a write to a binary directory, or an outbound connection to a new IP.

The four pillars are process, file system, network and, for containers, the system-call/capability model. The strength of this approach is it catches zero-days by anomaly — you don't need a signature for a reverse shell if the model never saw that process before.

CNNF is Prisma Cloud's layer-3/4 microsegmentation for containers. It learns the normal east-west traffic between your services — which container talks to which, on which ports — and builds a connection model. You can then visualise the service-to-service map and enforce: alert or block any flow that wasn't in the learned model.

In practice, if a compromised front-end container at a Bangalore ITES suddenly tries to talk directly to the database container it never spoke to before, CNNF flags or drops it. It's the runtime network model that complements the process/file models — segmentation without writing manual iptables rules.

WAAS (Web Application and API Security) is Prisma Cloud's app-layer protection delivered by the Defender, inline in front of the container/host app. It covers OWASP Top 10, API protection (schema enforcement from an OpenAPI spec), bot protection, DoS controls and custom rules — and crucially it auto-discovers APIs from observed traffic.

Versus a traditional appliance WAF: WAAS is workload-native and moves with the container as it scales or reschedules, so you're not hairpinning traffic to a central appliance. For a microservices app at a Mumbai bank, that means protection per-service without re-architecting the network — but you must ensure the Defender is actually in the request path, or WAAS sees nothing.

Prisma Cloud registers as a Kubernetes admission webhook. When a pod is created, the API server calls Prisma Cloud, which evaluates the request against OPA (Open Policy Agent) Rego policies and returns allow/deny — so you can block, say, a deployment that runs as root, pulls an unscanned image, or carries critical CVEs before it ever schedules.

The senior nuance: admission control is preventive and only as good as your webhook reliability — a misconfigured failurePolicy can either block all deployments if Prisma Cloud is down (fail-closed) or wave everything through (fail-open). For Divya's prod cluster I'd start fail-open with alerting, prove the policies are clean, then move critical namespaces to fail-closed.

CIEM (Cloud Infrastructure Entitlement Management) tackles over-permissioning — the gap between what an identity can do and what it actually needs. In AWS/Azure/GCP, permissions come from layers of roles, groups, inline and managed policies, resource policies and SCPs, so nobody can eyeball the real access.

CIEM computes the net effective permissions across all those layers and surfaces risks: unused privileges, admin-level roles, identities that can escalate, and access to sensitive data. The goal is right-sizing to least privilege — answering "what can this service account at Wipro actually reach?" with a real number, not a guess.

Net effective permissions is the actual, resolved set of actions an identity can perform after combining every grant and deny across the IAM model — managed + inline policies, group memberships, assumed roles, resource-based policies, permission boundaries and (in AWS Orgs) SCPs.

It's hard because these layers interact: an allow can be cancelled by a boundary or SCP, a role can be assumed transitively, and a resource policy can grant access the identity's own policies don't show. CIEM resolves all of that into one answer. In an interview, give the killer example: a developer who looks read-only but, through an assumable role, can actually delete production data — that's the chain CIEM exposes.

Prisma Cloud's Code Security scans Infrastructure-as-Code — Terraform, CloudFormation, Kubernetes manifests, Helm, ARM/Bicep, Serverless — for misconfigurations before deploy. The engine under the hood is Checkov, Palo Alto's open-source IaC scanner (originally Bridgecrew). It runs locally in CLI/CI or as the managed Code Security module.

So when Vikram opens a PR adding an S3 bucket without encryption, Checkov flags it on the PR, the developer fixes it in the same change, and the bad config never reaches AWS. The interview point: same policy logic shifted left — you catch the issue as code, where it's cheapest to fix, instead of as a CSPM alert in production.

You connect Prisma Cloud to GitHub/GitLab/Bitbucket/Azure DevOps via an app/token. It then scans on PR (posting checks/comments), on push, and on a schedule across the whole repo — covering IaC misconfigs, vulnerable open-source dependencies (SCA), license issues and secrets (hard-coded API keys, tokens, passwords) using pattern + entropy detection.

In CI you add twistcli or the Checkov step so a finding can fail the build. The senior framing: scanning is only useful if it has teeth — a secret detected in a commit by Neha should block the merge and trigger rotation, not just file a low-priority ticket nobody reads.

Take a public S3 bucket. Code: Checkov flags the Terraform resource missing block_public_access on the PR. Build/registry: not applicable for a bucket, but for a workload the image CVE would surface here. Cloud: CSPM detects the live bucket is public; CIEM shows which identities can read it; Data Security shows it holds PII.

Prisma Cloud links these as one issue and can point you to the exact repo, file and line that created it. The power: instead of remediating the live bucket (which redeploys public again next sprint), you fix the Terraform module once. That's the code-to-cloud trace — and being able to narrate it end-to-end is what gets an L3 offer.

Several layers. SCA finds vulnerable and malicious open-source packages in your dependencies and generates an SBOM. CI/CD security scans the pipeline itself for risks — exposed secrets in pipeline config, over-privileged runners, unpinned actions, missing branch protection. Image provenance and base-image scanning catch a poisoned upstream image.

The mature answer ties it together: supply-chain risk isn't just "is this library vulnerable" — it's the whole path from a dependency, through a CI runner, to a signed artifact. I'd point to pinning dependencies and actions by digest, scanning the pipeline config, and enforcing that only scanned, signed images pass admission control downstream.

Work the path the Defender takes. (1) Network: the Defender initiates an outbound WebSocket to the Console — in Compute Edition on TCP 8084. Confirm the host/node can reach the Console FQDN on that port; a proxy or security group blocking egress is the usual culprit. (2) DNS/cert: the Defender must resolve the Console name and trust its cert — a SAN mismatch or untrusted CA drops the connection.

(3) Defender health: check the Defender logs/container status on the node (is it crash-looping, out of resources?). (4) Clock skew: large time drift breaks TLS. (5) Token/version: an expired install token or a Defender far newer/older than the Console can refuse to connect. Nine times out of ten at a real shop it's egress filtering on 8084.

First, the query type and time range — a config question won't return audit events, and event/network queries are time-bound; widen the window. Second, account scope: your user or the query may be limited to accounts that don't contain the resource, or the cloud account isn't onboarded/has a permission gap so the resource was never ingested.

Third, API/attribute names: RQL is exact — wrong api.name or a typo'd json.rule path returns empty, not an error. I'd simplify to config from cloud.resource where cloud.type = 'aws' first, confirm data flows, then add filters back one at a time. Empty usually means scope or syntax, not 'no findings'.

Confirm coverage first: is there a Defender (or agentless config) actually targeting that asset, and is it connected? For registry scans, check the registry is configured under Defend → Vulnerabilities → Images → Registry, the scan scope/credentials are valid, and the scan schedule has run. For runtime, the image must be on a node with a healthy Defender.

Also check collections and scope rules — a scope that excludes a namespace or repo silently drops it from results. And capacity: very large registries hit scan limits or rate limits. The pattern: missing results almost always trace to coverage (no Defender), scope (filtered out), or credentials (can't reach the registry) — verify in that order.

Agentless takes snapshots via cloud APIs, so the failures cluster around permissions and reachability. (1) The onboarding role lacks the snapshot/volume permissions — agentless needs more than read-only CSPM. (2) Encrypted volumes with a customer-managed KMS key Prisma Cloud's role can't use to decrypt the snapshot. (3) Networking: in hub/target scan mode, the scanner can't reach the target subnet, or required egress is blocked.

(4) Unsupported OS/filesystem on those specific VMs, or a regional limit. I'd pull the agentless scan error in the Console — it usually names the failing step — and check the KMS key policy first, since CMK access is the most common silent blocker at a place like HCL.

Methodically. (1) Confirm the CFT actually completed — a rolled-back stack leaves no role; re-run and watch CloudFormation events. (2) Verify the role's trust policy trusts Prisma Cloud's account and the external ID matches exactly — a copy-paste slip here breaks sts:AssumeRole. (3) Check the attached permissions cover what you onboarded for — write/Data Security needs more than read-only.

(4) For org onboarding, the role must exist in member accounts too (via StackSets), not just the management account. (5) SCPs or a permission boundary at the org level can deny the actions even though the role 'has' them. Use the Console's account status detail and the AWS IAM policy simulator to pinpoint the denied action rather than guessing.

Under Settings → Integrations you connect Splunk/QRadar/Sentinel (often via webhook or a syslog/SQS feed), ServiceNow/Jira for ticketing, Slack/Teams/email for notifications, PagerDuty for paging, and SOAR (XSOAR/Cortex) for playbooks. Then alert rules route specific policies/severities to specific integrations — that routing is where you control noise.

The design caution: don't fan every alert to every channel, or you recreate alert fatigue in three new tools. Send critical/high to PagerDuty + SOAR for auto-triage, medium to a Jira queue, low to a Slack channel for awareness. And for compliance, push the full stream to the SIEM for retention while keeping the human-facing channels curated. Integration value comes from routing, not volume.