Onboarding Cloud Accounts and Cloud-Native Security
What this domain tests
This domain tests how you connect cloud environments to Prisma Cloud and how you organize them for visibility. Expect questions on read-only onboarding, account groups, organization-level onboarding, and the difference between a cloud account and an account group.
Core rules and concepts
- Onboard AWS with a CloudFormation template or StackSet that creates a read-only role; onboard Azure with a service principal; onboard GCP with a service account.
- Use least privilege. CSPM needs read-only API access, not write access to your resources.
- Account groups group cloud accounts for policy scope, alert routing, and RBAC. A cloud account is the actual connected provider account.
- Organization onboarding can connect many AWS accounts through AWS Organizations; individual accounts can still be grouped for scoping.
- Credential rotation and permission validation are part of operational hygiene.
Worked example
An AWS organization has 40 accounts. The team wants posture coverage without creating 40 manual roles. Reasoning: use organization-level onboarding with a CloudFormation StackSet to deploy the read-only role across accounts. Then place accounts into account groups by environment or business unit so policies and alerts apply to the right scope.
Traps that cost marks
Do not grant write permissions for CSPM. Do not confuse an account group with an enterprise group. Do not assume onboarding one account automatically covers every account in an organization unless organization onboarding is configured. Do not ignore region coverage or credential expiry.