Sandbox accounts show zero resources after an AWS Organizations onboarding
Your customer runs 42 AWS accounts under AWS Organizations: 12 production accounts in the prod OU, 22 in nonprod, and 8 in sandbox. You onboarded them with the Prisma Cloud cross-account IAM role deployed as a CloudFormation StackSet from the management account, using the external ID generated in the console, and mapped OUs to four account groups inside one enterprise group. All 42 accounts report status "connected". EC2, S3 and Lambda resources appear for production and nonprod, but every sandbox account shows zero resources, and the sandbox team confirms it runs workloads in us-west-2 and eu-west-1. Two additional sandbox accounts were created last week in a new OU that did not exist at onboarding time, and they do not appear in the console at all. CloudTrail and VPC flow log visibility is missing for 10 production accounts, and the security lead wants agentless scanning enabled for production only, plus a written statement of the extra access that requires.
1. In what order do you diagnose the two symptoms - eight "connected" sandbox accounts with no resources, and two brand-new accounts that never appear - and what exactly do you check at each step?
Read the worked answer
Reasoning frame: "Connected" tells you the trust path works - the role exists, the external ID matches, and sts:AssumeRole succeeds. It tells you nothing about whether the role can read the right APIs in the right regions. So separate the failure into three layers and work top-down: scope → permissions → collection.
1. Scope (most likely, cheapest to check). Account groups in Prisma Cloud carry a region selection. If the sandbox account group was created with the default region set, Prisma Cloud never calls the sandbox regions and the accounts look empty while remaining "connected". Confirm us-west-2 and eu-west-1 are enabled for that account group. Also confirm all 8 sandbox account IDs are actually members of that group and not parked in nonprod.
2. Effective permissions. Assume the role from a shell and replay a read call the way Prisma Cloud would (ec2:DescribeInstances, s3:ListAllMyBuckets). An SCP, permissions boundary, or a stale role version that predates a service's read actions will produce a connected account with partial or zero inventory. This also explains partial inventories in other accounts.
3. Collection health. Check last successful scan time per account and re-run onboarding validation before escalating to support.
4. New accounts. These are a different failure: if CloudFormation StackSet automatic deployment is not enabled for the new OU, no role instance exists, so onboarding cannot even be attempted. Confirm the StackSet deployment targets and autoDeployment setting, deploy to the new OU, then onboard.
Lead with the region check, because it explains eight accounts at once without touching IAM.
2. Design onboarding governance so a newly created account is protected and visible on day one, and explain how you would structure account groups for 42 (and later 100+) accounts.
Read the worked answer
The problem to solve: the current design depends on a human remembering two steps (deploy stack, onboard account) in the right order. Both should be removed.
Role deployment. Use a service-managed CloudFormation StackSet targeted at the Organizations root or at OUs, with automatic deployment enabled so every new account in a targeted OU receives the role on creation. Turn on "retain stacks" so deleting an account from an OU does not orphan IAM roles silently. Keep one template version under source control; drift from a six-month-old template is how accounts end up "connected" but half-blind.
Account visibility. Trigger onboarding from the same pipeline that creates accounts (an EventBridge/Step Functions hook after account creation) using the Prisma Cloud API, or run a scheduled reconciliation that lists Organizations accounts and compares them with Prisma Cloud cloud accounts, alerting on the delta. Do not rely on the console to notice.
Account group structure. Model account groups on who consumes the findings and what action they take, not on the org chart:
prod-pci,prod-general- split so alert routing and compliance scopes differ.nonprod,sandbox- noisy by design, routed differently. An account can belong to multiple account groups, so useprod-pciplusprod-allrather than forcing one bucket per account. Keep enterprise groups for hard tenancy boundaries only (business units, regulated entities, MSSP customers), because resource and policy scoping gets harder to reason about as you multiply them.
Encode the standard. A short onboarding checklist executed by the pipeline, plus a monthly reconciliation report, is what turns this from tribal knowledge into a control.
3. The security lead asks for agentless scanning on production only and CloudTrail/flow log visibility on the 10 accounts that lack it. What additional access and configuration does each require, and what tradeoffs do you present?
Read the worked answer
Agentless scanning. Prisma Cloud reads EC2/EBS snapshots (and optionally instance metadata) and scans the disks out-of-band, so it needs ReadOnly-style permissions on EC2 snapshots/volumes, plus KMS permissions to use the customer-managed keys that encrypt the volumes - without a kms:CreateGrant/decrypt path, encrypted volumes scan as unreadable. It also needs a supported region footprint.
Tradeoffs to state explicitly:
- Cost: snapshots and cross-region data movement are billed to the customer; scope matters more than people expect.
- Data exposure: disk snapshots may contain secrets and PII, which is a legal/DPO conversation, not just a security one.
- Key policy changes: KMS key policy edits are high-blast-radius; do them per key with review.
- Coverage gaps: agentless is point-in-time. It does not replace runtime behaviour detection, so do not let it be sold as an alternative to a Defender where runtime protection is required.
Flow logs and CloudTrail. These are not something Prisma Cloud can turn on by itself in a well-governed account; the customer must enable them (VPC flow logs to CloudWatch/S3, CloudTrail to S3/CloudWatch), and the Prisma Cloud role needs read access to the destination buckets and log groups, including the bucket policy granting the role. Decide the destination model first: a central log-archive account requires cross-account bucket policies.
Sequencing: enable flow logs where they already exist and fix the read permissions first (fast win), then roll out new flow logs account by account with cost estimates. Present a per-account cost and data-residency table rather than a single blanket recommendation.