PCCSE cheat sheet
PCCSE · Keep the key ideas within reach.
Prisma Cloud Overview and Architecture
Prisma Cloud is delivered as a SaaS control plane with a Console UI/API, Defenders for compute runtime enforcement, and agentless scanning that uses cloud provider APIs.
Core modules include CSPM for misconfiguration, CIEM for identity and entitlement, DSPM for data security, CWPP for compute, code security, and CI/CD security.
The Console web UI listens on TCP 8083; Defenders connect outbound to the Console or Defender Manager on TCP 8084.
Defenders are the data plane for runtime protection; agentless scanning is the data plane for posture and vulnerability scanning without agents.
RQL is the common query language for investigation and config policy definitions across cloud resource inventory.
Cloud accounts are scoped into account groups; enterprise groups provide hierarchical policy and RBAC boundaries.
Defender Manager is optional and sits between large Defender fleets and the Console to proxy connections and distribute upgrades.
Prisma Cloud APIs use service accounts or access keys; compute APIs use access keys generated in the Compute Console.
Onboarding Cloud Accounts and Cloud-Native Security
AWS onboarding creates a cross-account IAM role with an external ID; the role ARN is stored as a Prisma Cloud credential.
Azure onboarding uses an app registration and service principal; assign Reader and Security Reader at subscription scope.
GCP onboarding uses a service account with read-only roles such as Viewer and Security Reviewer at project or organization scope.
Organization onboarding covers existing and future accounts; standalone onboarding covers one account at a time.
Account groups scope policies, alert rules, and RBAC; an account belongs to one account group.
Credentials can be reused across accounts with the same trust relationship; permissions must be validated after creation.
Agentless scanning requires additional read permissions for snapshots and disk access; runtime protection requires Defender outbound connectivity.
Onboarding status shows healthy or error; permission errors are resolved by updating the role or service principal and revalidating.
Policy Configuration and Management
A policy contains name, type, severity, rule or RQL, compliance mappings, remediation, labels, and enabled or disabled status.
Config policies use RQL of the form: config from cloud.resource where cloud.type = 'aws' and api.name = '...' and json.rule = ...
Policy types include config, audit event, network, identity and access, data, vulnerability, malware, and anomaly.
Severity levels are critical, high, medium, low, and informational; alert rules filter on severity.
Compliance standards include CIS, PCI DSS, HIPAA, SOC 2, NIST, and ISO 27001; one policy can map to multiple standards.
Policy exceptions suppress findings for scoped resources or accounts and should include expiration and justification.
Central policies are defined at tenant level and inherited; local policies are defined in an enterprise group and apply only there.
Test custom RQL in Investigate before saving it as a policy; remediation text can include CLI or API commands.
Monitoring, Alerts, and Investigation
Alert rules select which alerts trigger notifications by policy, severity, account group, resource type, and tags.
Supported notification integrations include email, Slack, Teams, PagerDuty, ServiceNow, webhook, syslog, S3, Azure Storage, and GCS.
Alert states are open, resolved, and dismissed; dismissal requires a reason and removes the alert from active triage.
Investigate runs RQL against asset inventory; queries can be saved, shared, and exported.
Alert details show resource configuration, policy violation, remediation guidance, timeline, and related graph context.
Risk score helps prioritize alerts using severity plus exposure and resource context.
Compliance dashboards report pass or fail by standard, account group, and resource; drill down to failing findings.
Asset inventory can be filtered by cloud type, account, region, and tags for investigation.
Compute Security (Host, Container, Serverless)
Defender types include Container, Host, Serverless, and App Embedded; deploy via DaemonSet, Helm, Docker, or OS packages.
Defenders need outbound TCP 8084 to Console or Defender Manager; they do not require inbound firewall openings.
Defender Manager proxies Defender traffic and manages upgrades for large fleets; the Console connects to Defender Manager.
Registry scanning connects to ECR, ACR, GCR, Docker Hub, Harbor, JFrog, or Quay and scans on push or schedule.
Admission control uses a Kubernetes ValidatingWebhookConfiguration to block pods that violate vulnerability or compliance policies.
Runtime policies cover process, network, file integrity, container drift, malware, vulnerability, and compliance.
Collections scope hosts, containers, images, and functions by labels, namespaces, or accounts for policy and RBAC.
Serverless protection uses Serverless Defenders or agentless scanning for AWS Lambda, Azure Functions, and GCP Functions.
Code Security and CI/CD Integration
Code Security connects to GitHub, GitLab, Bitbucket, and Azure DevOps to scan repositories and pull requests.
IaC scanning supports Terraform, CloudFormation, Kubernetes manifests, Helm, ARM, and Serverless Framework.
Build-time policies run in CI/CD or VCS scans; runtime policies run in cloud accounts and Defenders.
twistcli scans images and serverless functions; twistcli images scan --address --user is the basic pattern.
CI/CD integrations include Jenkins, GitHub Actions, GitLab CI, Azure DevOps, and CircleCI.
Code Security projects map repositories and branches; findings include fix pull request suggestions.
Use API access keys or service accounts with least privilege for CI/CD; do not embed user credentials.
A build can fail when findings meet or exceed the configured severity threshold.
Platform Administration (RBAC, Enterprise Groups, Integrations)
RBAC roles include System Admin, Account Group Admin, Account Group User, and Build and Deploy Security.
Enterprise groups are hierarchical; the tenant is the root and account groups sit beneath it; policy and RBAC inherit downward.
SAML 2.0 SSO integrates an identity provider; IdP groups can be mapped to Prisma Cloud roles.
Service accounts and access keys provide API-only identities; assign minimum roles and rotate keys.
Audit logs capture logins, policy changes, and API calls; export to SIEM via syslog, webhook, or storage.
Notification integrations include Slack, Teams, ServiceNow, PagerDuty, email, webhook, syslog, and storage buckets.
License usage is tracked by cloud accounts and compute credits; review it in the Console settings.
System Admin can create enterprise groups and assign account group roles; account group admins are scoped to their group.