Cortex Cloud Platform: tenancy, onboarding and access design
Domain 1 covers the Cortex Cloud platform itself: how the product is delivered, onboarded, scoped and delegated. The exam probes deployment and design decisions - tenant and region choice, cloud account onboarding methods, the account group and namespace model, RBAC and API keys - rather than policy content, which belongs to the posture domain.
One product, two heritage consoles
Cortex Cloud, the successor to Prisma Cloud, is sold as modules that map to a CNAPP: cloud security posture (CSPM), cloud workload protection (CWPP), cloud infrastructure entitlement (CIEM), data security (DSPM), application security (ASPM) and cloud detection and response. Many screens and naming conventions still come from the two original consoles: the API-based posture console (inventory, RQL, compliance) and the Compute console (Defenders, runtime policies, WAAS). Knowing which console owns a given feature is a recurring exam theme.
Onboarding cloud accounts
- AWS: a cross-account IAM role created by CloudFormation or Terraform, deployed as a StackSet with service-managed permissions to cover an AWS Organization; an external ID is required; least privilege is read-only unless auto-remediation is needed.
- Azure: an app registration plus service principal, scoped at management group level for multi-subscription visibility.
- GCP: a service account granted at folder or organization level.
- Agentless workload scanning is configured separately from onboarding and relies on snapshot and scan-machine permissions.
Scoping and identity
Account groups are the top-level boundary for users, alert rules and reporting. Namespaces narrow what a user sees using cloud accounts, regions, tags or resource groups. RBAC ships fixed roles; the Build and Deploy (DevOps) role is the one intended to hold CI/CD access keys.
Worked example
A customer with 60 AWS accounts wants posture plus CI/CD scanning. Design: designate a delegated admin account, deploy the StackSet with a read-only role at the organization root, onboard the organization once in the tenant, place all accounts in a single account group, create a namespace limited to production tags for the application team, and issue a separate Build and Deploy key to the CI system. Verify by running an RQL config query that counts resources per account before handover.
Traps
Assuming the tenant region can be changed later - it cannot. Granting write permissions just in case; posture onboarding does not need them. Confusing account groups with namespaces. Forgetting that Compute console data and posture data are correlated but not identical.