Cross-Account Security Controls and Identity Federation

Cross-account security controls are the architectural patterns, policy layers, and centralized services that let a solutions architect enforce least privilege, detect threats, and prove compliance across every account in an AWS Organization — not just one account at a time. On the SAP-C02 exam, Task 1.2 "Prescribe security controls" tests whether you can combine cross-account IAM roles, KMS key policies, SCPs, permission boundaries, and the delegated-administrator features of GuardDuty, Security Hub, AWS Config, Macie, Audit Manager, and IAM Access Analyzer into a coherent, auditable security model. Cross-account security controls are where multi-account governance (the account structure) and workload security (the guardrails inside each account) meet, and the exam punishes candidates who mix up which layer is enforcing what.

This Pro-depth guide walks through every cross-account security control you will see on SAP-C02: trust policy mechanics with aws:PrincipalOrgID, aws:SourceAccount, and the ExternalId confused-deputy defence; KMS key policies that grant cross-account usage alongside the grant mechanism; the three-layer authorization model (SCP, identity policy, resource policy, permission boundary, session policy) and its evaluation order; organization-scoped deployment of GuardDuty, Security Hub, Config, and Macie with delegated administrators; and IAM Access Analyzer's three complementary jobs — external access detection, unused access detection, and policy generation — operating inside an organization zone of trust. By the end you will be able to look at a 200-account scenario and prescribe the exact combination of cross-account security controls the question is asking for.

What Are Cross-Account Security Controls?

Cross-account security controls are the set of identity, resource-policy, and centralized-detection mechanisms that an AWS customer uses to enforce a uniform security posture across multiple AWS accounts inside an AWS Organization. They operate at four distinct layers: the identity layer (IAM roles, trust policies, permission boundaries, Identity Center permission sets), the resource layer (KMS key policies, S3 bucket policies, resource-based policies on Lambda/SNS/SQS/Secrets Manager), the preventive layer (Service Control Policies on OUs), and the detective/aggregation layer (GuardDuty, Security Hub, Config, Macie, Access Analyzer with delegated administrators).

Why Cross-Account Security Controls Matter for SAP-C02

Single-account IAM knowledge from SAA-C03 is not enough for the professional exam. SAP-C02 Task 1.2 question stems almost always place the scenario in a 50-plus account Organization with shared services, security tooling, log archive, and workload OUs. The exam tests whether you can prescribe cross-account security controls that enforce the requirement without requiring per-account manual configuration. That phrase — "without per-account manual configuration" — is the dead giveaway that the answer involves delegated administrators, organization-wide aggregators, or RAM-shared KMS keys.

Where Cross-Account Security Controls Sit in the Landing Zone

In a Control Tower or custom landing zone, cross-account security controls live primarily in two accounts: the Security/Audit account (GuardDuty delegated admin, Security Hub aggregator, Config aggregator, Macie admin, Access Analyzer organization analyzer, Audit Manager) and the Log Archive account (centralized S3 buckets with bucket policies granting cross-account writes from member CloudTrail and Config). Both accounts are shielded by SCPs so workload administrators cannot tamper with security findings or log destinations.

Plain-Language Explanation: Cross-Account Security Controls

Cross-account security controls sound abstract, but three everyday analogies make them concrete. Each analogy surfaces a different property of cross-account security controls, so read all three.

Analogy 1 — The Apartment Complex Security System (Building / Property Analogy)

Picture a 200-unit apartment complex. Each apartment is an AWS account; the building is the AWS Organization; the management company is the management account. Cross-account security controls are the building-wide systems the management company runs so that safety does not depend on each tenant installing their own.

In this building, the master key system is cross-account IAM roles — a facilities manager has one credential that, with the right trust, opens any unit's mechanical room. The trust policy is the written rule saying which apartments' locks the master key accepts; the ExternalId is the second factor that the facilities company types in so that if a disgruntled ex-employee steals the master key alone, it still will not open any doors. The building alarm monitoring centre is GuardDuty with delegated admin — one central desk receives every smoke alarm, motion sensor, and door-forced event from every apartment. The compliance board in the lobby is Security Hub — a scorecard that shows "3 of 200 apartments failed the smoke-detector inspection." The maintenance inspector is AWS Config with conformance packs — it walks every apartment checking that every unit's fire extinguisher is charged. The records clerk is Audit Manager — collecting evidence that can be handed to the city inspector. Finally, the unused-key auditor is IAM Access Analyzer unused-access — every month someone reviews which building staff still have master keys they have not used in 90 days and cancels them.

Analogy 2 — The Open-Book Exam With Proctored Stations (Exam / Testing Analogy)

Imagine a nationwide certification exam with a testing station in every city. Each city is an AWS account; the national exam board is the management account; the student is a workload. Cross-account security controls are how the national board enforces uniform integrity without visiting every station.

The proctor credential is a cross-account IAM role that any authorized exam administrator can assume — the trust policy says "I trust the national board account," aws:PrincipalOrgID says "but only if the caller is still inside our official organization," and ExternalId stops a third-party vendor from confused-deputy-attacking the station. The exam rules book is the SCP — the national board hands every city a binder that says "you may not run tests outside these regions; you may not disable the camera; you may not deploy new exam formats without approval." The live invigilator network is GuardDuty — every city's cameras stream into one monitoring room run by the security team with delegated admin rights. The end-of-day scoresheet is Security Hub FSBP/PCI compliance — each city gets graded against the same rubric, and the aggregator shows the national board a single view. The pattern-recognition auditor scanning each station's answer sheets for leaked PII is Macie. The record-keeping requirement for regulators is Audit Manager, automatically packaging evidence from CloudTrail, Config, and Security Hub into SOC 2 / PCI / HIPAA frameworks. Together these cross-account security controls let the national board prove integrity across hundreds of stations without a single in-person visit.

Analogy 3 — The Electrical Grid Substation Network (Infrastructure / Utility Analogy)

Imagine a regional power utility with 150 substations. Each substation is an AWS account. Cross-account security controls are the protection schemes that let a single operations centre run all 150 without a human at each site.

The substation access badges are cross-account IAM roles, with the trust policy determining which employees from the operations centre can assume them. Permission boundaries are the hard circuit-breaker rating on an employee's badge — even if someone writes a broader job description, the badge physically cannot pass more current than the boundary allows. SCPs are the regulatory safety code imposed by the utility commission on every substation regardless of what local operators want — nobody may bypass lockout-tagout, nobody may operate outside licensed regions. KMS key policies are the keys to the protected equipment cabinets; a cabinet key can be explicitly loaned to another substation (cross-account key policy) or delegated via a grant mechanism (KMS Grants for short-lived delegation to another AWS service). The SCADA grid monitoring system is GuardDuty, Security Hub, and Config aggregators combined — every substation's sensor readings flow into one control room. The unused authorization sweep is Access Analyzer unused access — badges that have not opened any cabinet in 90 days get revoked automatically. Together these cross-account security controls make 150 substations operable as one secure grid.

The Three-Layer Authorization Model — SCP vs IAM vs Permission Boundary vs Resource Policy

The single most asked cross-account security controls concept on SAP-C02 is the evaluation order when multiple policy types apply to the same API call. Memorise it cold.

Layer 0 — SCP at the Organization Level

Service Control Policies are attached to the root, an OU, or an account. SCPs never grant permissions; they define the maximum permissions available to principals in the affected accounts. If the SCP denies s3:DeleteBucket, no identity policy, no permission boundary, and no resource policy can restore it. The management account is exempt from SCPs — a common trap where candidates assume SCPs apply universally.

Layer 1 — Permission Boundaries on the Principal

A permission boundary is an IAM managed policy attached to a user or role that caps the permissions that identity policies can grant. Like SCPs, permission boundaries grant nothing on their own. They are how a central security team lets workload developers create their own IAM roles without being able to escalate privilege — the developer's IAM role attaches a permission boundary that says "roles you create must never grant IAM admin, CloudTrail disable, or organizations:LeaveOrganization."

Layer 2 — Identity Policy (IAM Policy on the Principal)

Identity policies attached to the calling user or role are the main grant surface. The effective permission is the intersection of the identity policy, SCP, and permission boundary, with any explicit Deny in any layer being decisive.

Layer 3 — Resource Policy on the Target

Resource-based policies (S3 bucket policy, KMS key policy, SNS topic policy, SQS queue policy, Lambda resource policy, Secrets Manager secret policy) grant access to a principal even without an identity policy on that principal's side — for same-account access. For cross-account access, both sides must allow: the calling account's identity policy must permit the action, and the target account's resource policy must permit the caller.

Layer 4 — Session Policy on AssumeRole

When a principal calls sts:AssumeRole, the caller can pass an inline session policy that further restricts the assumed role's permissions for that session only. Session policies are the intersection of the role's permissions and the session policy — they cannot expand permissions.

The Canonical Evaluation Example

Consider a Lambda function in the dev account trying to read an S3 object in the data account, where the object is encrypted with a KMS key in the data account:

• The dev account SCP must not deny s3:GetObject or kms:Decrypt.
• The Lambda execution role (identity policy) must allow s3:GetObject on the bucket ARN and kms:Decrypt on the key ARN.
• The bucket policy in the data account must allow the Lambda role principal to s3:GetObject.
• The KMS key policy in the data account must allow the Lambda role principal to kms:Decrypt.
• If the data-account SCP denies s3:GetObject from outside the organization, the caller must be inside the organization (which it is, via aws:PrincipalOrgID).

Five policies. All five must simultaneously say yes. Any single explicit Deny kills the request.

Cross-Account IAM Role Architecture

The cross-account IAM role is the atomic unit of cross-account security controls. Every federated login, every CI/CD pipeline spanning accounts, every third-party SaaS integration ultimately calls sts:AssumeRole on a role in the target account.

Anatomy of a Trust Policy

A trust policy is the resource policy attached to an IAM role. It specifies which principals (IAM users, IAM roles, AWS services, SAML providers, web identity providers, or entire accounts) may call sts:AssumeRole on this role. The action is always sts:AssumeRole (or sts:AssumeRoleWithSAML, sts:AssumeRoleWithWebIdentity). The Principal element is what distinguishes a same-account from a cross-account trust.

Trust Policy Conditions for Cross-Account Security Controls

Three condition keys are the workhorses of cross-account trust policy hardening:

aws:PrincipalOrgID restricts the caller to any principal inside a specific AWS Organization. Setting "aws:PrincipalOrgID": "o-abc123xyz" means the role can be assumed only by callers whose home account is a member of that organization. This is the single most important guardrail for cross-account IAM roles shared inside an Organization — it prevents a role from being assumable even if the trust policy accidentally whitelists an external account.

aws:SourceAccount and aws:SourceArn matter for AWS-service trust. When an AWS service (S3 bucket notifications, SNS, EventBridge) assumes a role to call into your account, adding a SourceAccount condition prevents the confused-deputy problem where another customer's S3 bucket could trigger actions in your account. For service-to-service cross-account access, always pin aws:SourceAccount to the account hosting the triggering resource.

sts:ExternalId is the defence against the confused-deputy attack in third-party SaaS scenarios. A monitoring vendor needs to assume a role in your account to read CloudWatch metrics. Without ExternalId, the vendor's shared role could be tricked by another customer into assuming your role. You generate a unique ExternalId, share it with the vendor, and require it in the trust policy. Now your role only accepts sts:AssumeRole calls that carry that specific ExternalId value, preventing cross-tenant spoofing.

ExternalId — The Confused-Deputy Defence

The confused-deputy problem works like this: a third-party SaaS vendor hosts a single IAM user (their side) that they use to AssumeRole into all their customers' accounts. If attacker Alice knows customer Bob's role ARN and can trick the vendor into calling AssumeRole with Bob's ARN, the vendor's trust (from Bob's perspective) succeeds — the vendor's account is whitelisted. ExternalId closes this gap: Bob's trust policy requires a unique secret value, and the vendor stores that value per-customer. Alice cannot produce Bob's ExternalId, so the trick fails.

ExternalId is required only for third-party access; for inside-the-same-organization cross-account roles, aws:PrincipalOrgID is the right defence. Mixing them up is a common SAP-C02 trap — the exam will ask "is ExternalId needed for a role assumed by another account in the same Organization?" and the answer is no.

Principal-Based vs Resource-Based Cross-Account Access

Some AWS services support resource-based policies that grant cross-account access directly without requiring a trust-policy-based role assumption: S3, KMS, SNS, SQS, Lambda, Secrets Manager, API Gateway, ECR, EventBridge, CodeArtifact, Backup vaults, Glacier, and EFS. Other services require a role assumption: DynamoDB, RDS, EC2, Systems Manager Parameter Store Standard tier. The architectural choice matters — resource policies scale to many callers without cutting one role per caller, but roles provide session-level auditability (each AssumeRole call appears in CloudTrail with a unique session).

KMS Key Policies and Cross-Account Encryption

KMS is the service where cross-account security controls get especially tricky because KMS requires the key policy to explicitly allow external principals — unlike most AWS services where an IAM policy alone suffices for same-account access.

KMS Key Policy Fundamentals

Every KMS key has exactly one key policy. By default, the key policy contains only the root of the owning account as a trusted principal, meaning IAM policies in that account can delegate usage. For cross-account use, you must add the external account (or a specific role in it) to the key policy. Both the external account's identity policy AND the key policy in the owning account must permit the KMS action.

Canonical Cross-Account KMS Pattern

A data-lake account owns a KMS key encrypting objects in S3. A consumer account needs to decrypt those objects. The key policy adds a statement like: "Principal": {"AWS": "arn:aws:iam::CONSUMER-ACCOUNT:role/DataReaderRole"}, "Action": ["kms:Decrypt", "kms:DescribeKey"]. The consumer account also attaches an identity policy to DataReaderRole granting the same actions on the key ARN. When Lambda in the consumer account reads an object, S3 transparently calls KMS Decrypt; the call traverses both policies, and both must allow.

KMS Grants for Service-Level Delegation

KMS Grants are short-lived delegations typically issued by AWS services (EBS, RDS, Aurora, DynamoDB, FSx) when they need to decrypt on behalf of an IAM user. Grants avoid key-policy edits for every service interaction. Grants are revokable and retireable, auditable in CloudTrail, and constrain the allowed operations (encryption context, grant constraints). On the SAP-C02 exam, Grants appear in scenarios where an Aurora Global Database replica in another region needs encryption access without editing the key policy every time a new replica is added.

KMS Multi-Region Keys (MRK)

Multi-Region Keys are KMS keys with the same key ID across regions. An object encrypted in us-east-1 with an MRK can be decrypted in us-west-2 with the replica MRK because they share key material. MRKs are essential for DR patterns requiring cross-region replication of encrypted data. The key policy is per-replica, so cross-account grants must be set in each region. Do not confuse MRKs with KMS Grants — MRKs solve geography, Grants solve delegation.

KMS Key Policy Interaction With SCPs

An SCP denying kms:Decrypt at the organization level prevents any principal in the affected accounts from decrypting, even if the key policy allows. This is exploited deliberately in sensitive-data SCPs: deny kms:Decrypt on keys tagged Classification=Restricted unless the principal is in the security OU. The SCP is the outer guardrail, the key policy is the inner permission.

SCP vs IAM vs Resource Policy — Cross-Account Decision Guide

When designing cross-account security controls, you will repeatedly choose which layer enforces a given rule. The correct layer depends on whether the rule is preventive or detective, organization-wide or workload-specific.

Use SCPs For Organization-Wide Prevention

SCPs are right when the rule applies to an entire OU regardless of any workload. Canonical uses: deny region outside approved list, deny disabling CloudTrail/Config/GuardDuty, deny iam:DeleteRole on roles tagged SecurityManaged, deny use of root account credentials, deny deploying outside a tagged boundary. SCPs guarantee these rules are unbreakable by workload administrators.

Use Permission Boundaries For Delegated Role Creation

Permission boundaries are right when you want to let developers create IAM roles for their own Lambda or EC2 workloads without being able to create privilege-escalating roles. The boundary caps what any created role can do. The developer's role attachment policy grants iam:CreateRole and iam:PassRole but only for roles that attach the mandated boundary (enforced with iam:PermissionsBoundary condition).

Use Identity Policies For Per-Principal Permissions

Identity policies are the default grant surface. Assign them via Identity Center permission sets for human users, via IAM roles attached to Lambda/EC2/ECS for workload identities, and via service-linked roles for AWS services.

Use Resource Policies For Multi-Account Sharing

Resource-based policies (S3 bucket, KMS key, SNS topic, SQS queue, Lambda, Secrets Manager) are right when one resource must be accessed by many principals from different accounts without creating N identity policies. Combined with aws:PrincipalOrgID, a resource policy can open to all of an organization's accounts in one statement.

Combined Pattern For Production

A typical production multi-account security design uses all four: SCPs prevent catastrophic actions organization-wide, permission boundaries cap delegated self-service, identity policies grant day-to-day permissions, and resource policies enable cross-account sharing. On the SAP-C02 exam, the correct answer is usually a multi-layer combination — watch for choices that rely on a single policy type when multiple are needed.

GuardDuty Multi-Account With Organizations

GuardDuty is the threat-detection pillar of cross-account security controls. In a multi-account environment, GuardDuty must be enabled in every account in every region where workloads run, and findings must flow to a central security team. Without the Organizations integration, operating GuardDuty at scale is impractical.

GuardDuty Delegated Administrator

From the management account, you designate one member account (typically the Security/Audit account) as the GuardDuty delegated administrator. That delegated admin can then enable GuardDuty across every account in the organization in any region, without operating from the management account for day-to-day tasks. The separation keeps the management account minimally used — a core landing-zone principle.

Auto-Enable for New Accounts

Once the delegated admin is set, you toggle "auto-enable for new accounts" per region. Any new account added to the Organization (via Account Factory or manual invite) automatically has GuardDuty enabled in that region at account-join time. This solves the sprawl problem — without auto-enable, security teams must remember to enable GuardDuty on every new account manually.

Multi-Account Findings Aggregation

All member-account findings flow into the delegated admin account's GuardDuty console. The security team sees findings with member-account context (AccountId tag on every finding), can create organization-wide suppression rules, and push all findings into Security Hub or an EventBridge bus for SIEM integration.

GuardDuty Protection Plans — Enable per Region

GuardDuty has additional protection plans: Malware Protection for EC2 (scans EBS volumes after suspicious findings), S3 Protection (analyses S3 data events), EKS Protection (audit log anomaly detection on EKS), Lambda Protection (monitors Lambda invocation patterns), RDS Protection (anomalous database login patterns). Each protection plan is enabled independently and has its own pricing. In organization mode, the delegated admin can enforce which protection plans are auto-enabled on new members.

Cross-Region GuardDuty Considerations

GuardDuty is a regional service. Enabling it in one region does not give coverage in another. Organization-wide deployment means the delegated admin iterates all required regions and sets auto-enable in each. A common cost optimization is to enable GuardDuty only in regions where you actually run workloads — pairing this with an SCP that denies non-approved regions makes the coverage model complete.

Security Hub Multi-Account and Cross-Region Aggregation

Security Hub is the compliance-scoring and finding-aggregation service. In a multi-account Organization, Security Hub combines two orthogonal dimensions: multi-account aggregation (via delegated admin) and cross-region aggregation (via an aggregation region). Both must be designed deliberately.

Security Hub Delegated Administrator

As with GuardDuty, a Security account is designated Security Hub delegated admin. That account can enable Security Hub across all member accounts in selected regions, and enable or disable security standards (AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark, PCI DSS, NIST SP 800-53) organization-wide.

Cross-Region Aggregation — The Aggregation Region

Security Hub in one chosen aggregation region (for example us-east-1) can pull findings from Security Hub in every other region in every linked account. The aggregation region becomes the single pane of glass for all of the organization's AWS-region footprint. Any update to a finding (status change, note added) in the aggregation region synchronizes back to the source region.

The aggregation region is a design decision. Choose a region with low latency to your security operations centre, a region that supports every Security Hub feature you need, and a region that already hosts your SIEM pipeline. us-east-1 is the common default because it has the longest feature tenure.

Security Standards — FSBP, CIS, PCI, NIST

Security Hub runs automated compliance standards. The four SAP-C02 examinable standards are:

• AWS Foundational Security Best Practices (FSBP) — AWS's own curated 200-plus controls. Enable by default.
• CIS AWS Foundations Benchmark (v1.4 / v3.0) — industry-standard CIS controls mapped to AWS.
• PCI DSS — payment-card industry controls for workloads processing card data.
• NIST SP 800-53 Rev. 5 — US federal standard, required for FedRAMP and many government contracts.

Each standard produces pass/fail findings per resource per control. Security Hub computes a compliance score per standard and an aggregate "security score." Organization-wide enablement guarantees every account scores on the same rubric.

Integrating Findings from GuardDuty, Inspector, Macie, Access Analyzer

Security Hub natively ingests findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, AWS Firewall Manager, AWS Config (conformance pack findings), AWS Systems Manager Patch Manager, and AWS Health. All findings normalize to AWS Security Finding Format (ASFF). Third-party findings (CrowdStrike, Palo Alto, Trend Micro, etc.) also land in Security Hub via the partner integration catalog.

Custom Actions and EventBridge Automation

Security Hub custom actions emit to EventBridge when an analyst clicks an action on a finding. Automation rules (a newer Security Hub feature) allow attribute-based automatic finding updates — for example, automatically suppress findings tagged Environment=Sandbox or escalate CRITICAL findings to a PagerDuty EventBridge destination.

Security Hub vs GuardDuty — Scope Reminder

GuardDuty detects threats. Security Hub aggregates findings and scores compliance. On the exam, scenarios mentioning "central dashboard," "compliance score," "FSBP standard," or "aggregate findings from GuardDuty and Inspector" point to Security Hub. Scenarios mentioning "unusual API activity," "compromised credentials," or "crypto-mining" point to GuardDuty. Both are typically enabled in the same Security account.

AWS Config Multi-Account — Aggregators and Conformance Packs

AWS Config records configuration state over time. In a multi-account context, Config plays two roles: central evaluation of compliance against rules and conformance packs, and aggregation of Config data for a single-pane-of-glass compliance dashboard.

Config Aggregator — Organization-Wide Compliance View

A Config aggregator is a resource created in one account and region that pulls configuration items and compliance state from all member accounts in all regions of an AWS Organization. The aggregator is read-only; it does not evaluate rules on the aggregated data. Its job is visualization and querying.

Set up path: in the management account (or a delegated admin account after designating Config delegated admin), create an aggregator with "source: My organization," select aggregation regions, and authorize via Organizations trust. Within minutes the aggregator dashboard shows resources, compliance counts, and non-compliance drill-downs across every account.

Config Rules — Managed and Custom

Config Rules evaluate configuration items against desired state. Managed rules (150-plus) cover common requirements: s3-bucket-public-read-prohibited, encrypted-volumes, rds-storage-encrypted, iam-root-access-key-check. Custom rules run a Lambda function for arbitrary logic. Rules deployed per account produce compliance status; aggregation rolls them up.

Conformance Packs — Deploy Many Rules as One Unit

A conformance pack is a YAML template bundling multiple Config rules and remediation actions. AWS provides pre-built conformance packs for PCI DSS, HIPAA, NIST 800-53, CIS, FedRAMP, operational best practices, and more. You deploy a conformance pack to an account (single-account pack) or to an organization (organization conformance pack) — in the organization case, every member account receives and evaluates the same pack.

Organization conformance packs are the cross-account security controls pattern for compliance frameworks. A single deploy from the management account or Config delegated admin rolls PCI DSS conformance to 100 member accounts. Every account reports the same rules against the aggregator, and the security team sees one compliance view.

Auto-Remediation with SSM Automation

Config Rules can trigger Systems Manager Automation runbooks on non-compliant findings — for example, automatically enable S3 default encryption on any bucket found without it. Org-wide conformance packs combined with SSM automation runbooks build a closed-loop detect-and-remediate cross-account security control.

Config vs Security Hub Overlap

Config and Security Hub both detect non-compliant configurations, which causes candidate confusion. The distinction: Config is configuration state over time (history, drift, change timeline) with rule evaluation; Security Hub is security-finding aggregation with compliance scoring that consumes Config conformance pack findings as one input. They are complementary, not competitive. In a landing zone, both are enabled: Config for configuration forensics and rule evaluation, Security Hub for the scorecard.

Macie Organization-Wide

Macie discovers sensitive data in S3. In a multi-account context, Macie operates identically to GuardDuty and Security Hub: a delegated administrator enables Macie across all member accounts.

Macie Delegated Admin Pattern

The Security account is designated Macie delegated admin. From there, you enable Macie in every member account in every region you need, and auto-enable for new accounts. All member findings flow to the delegated admin's Macie console.

Automated Sensitive-Data Discovery

Macie runs two types of job: automated sensitive data discovery (a continuous, sample-based scan at the organization level — new feature that reduces manual job management) and scheduled classification jobs (you configure specific buckets and cadence). Automated discovery is the recommended baseline; jobs are for deep scans of specific high-risk buckets.

Managed Data Identifiers and Custom Data Identifiers

Managed data identifiers cover 100-plus categories: credit card numbers, AWS access keys, SSNs by country, passport numbers, driver license numbers, healthcare identifiers. Custom data identifiers let you define regex patterns for organization-specific sensitive data (employee ID format, internal case IDs).

Macie Findings Into Security Hub

Macie findings (sensitive data detected, S3 bucket policy misconfiguration, public bucket with sensitive data) flow into Security Hub automatically, appearing alongside GuardDuty and Inspector findings in the aggregator account's dashboard. Macie is the only AWS security service that scans S3 object content for sensitive data — no other AWS service does data classification this way.

Cost Consideration — Sampling vs Full Scan

Macie scanning is priced per object scanned. Full scans of petabyte-scale data lakes are expensive. Automated sensitive-data discovery samples intelligently to cap cost. For cost-bound organizations, the pattern is automated discovery by default with targeted jobs on high-risk buckets (PII-handling, regulated data).

AWS Audit Manager — Automated Evidence Collection for Cross-Account Compliance

AWS Audit Manager automates evidence collection against prebuilt compliance frameworks and custom frameworks. It is the service that answers the question "can you prove to an auditor that every account in our Organization met control X.Y over the past quarter?"

What Audit Manager Does

Audit Manager assembles evidence from CloudTrail (user activity), AWS Config (configuration compliance), Security Hub (security findings), and manual attachments. It maps this evidence to controls inside prebuilt frameworks (SOC 2, PCI DSS, HIPAA, GDPR, FedRAMP, ISO 27001, AWS Well-Architected, AWS Foundational Security Best Practices) or custom frameworks you define.

Multi-Account Assessments

Audit Manager assessments scope to specified accounts and regions. In Organizations mode, a delegated admin assessment automatically includes every member account. Evidence is collected continuously during the assessment period and packaged into an audit report exportable as PDF or structured data.

Frameworks and Controls

Prebuilt frameworks include SOC 2 Type 2, PCI DSS v3.2.1 and v4.0, HIPAA Security Rule, GDPR, NIST 800-53, NIST CSF, CIS, FFIEC, and the AWS Well-Architected Framework. Each framework has hundreds of controls, and each control specifies evidence sources. Audit Manager handles the mapping so you do not manually correlate CloudTrail events to SOC 2 CC6.1.

Audit Manager vs Security Hub vs Config — The Boundaries

Security Hub scores current compliance. Config records current and historical configuration. Audit Manager packages both into audit-ready evidence against framework controls for external reporting. On the exam, if the scenario says "auditor asking for evidence," "SOC 2 report preparation," or "continuous compliance evidence collection," the answer is Audit Manager.

IAM Access Analyzer — Three Jobs in One Service

IAM Access Analyzer is the cross-account security control that detects identity and resource-policy risk. In 2023–2024, Access Analyzer expanded from one job to three complementary jobs. All three matter on the SAP-C02 exam.

Job 1 — External Access Findings (Original Function)

Access Analyzer scans resource-based policies (S3 buckets, IAM roles' trust policies, KMS keys, Lambda functions, Secrets Manager secrets, SQS queues, SNS topics, EFS filesystems, ECR repositories, RDS snapshots, EBS snapshots) for policies that grant access to principals outside the zone of trust. The zone of trust is either the current account or — crucially for cross-account security controls — the entire AWS Organization.

When you create an organization-level analyzer from the delegated admin account, the zone of trust becomes the whole Organization. Access Analyzer then surfaces only truly external findings — resource policies exposing data to accounts outside the Organization. This dramatically reduces false-positive noise compared to per-account analyzers where every legit intra-org resource policy would appear as external.

Job 2 — Unused Access Findings (2023 Addition)

Unused access analyzers identify IAM users, IAM roles, access keys, and permissions that have not been used within a configurable tracking period (default 90 days). Three finding types:

• Unused IAM user/role — the principal has not authenticated in N days.
• Unused access key — the key has not been used.
• Unused permissions — a role has been used, but some of its granted IAM actions have never been called.

These findings drive least-privilege cleanup. The security team sees "Role X has s3:* but has only ever used s3:GetObject and s3:PutObject" — granting a starting point for tightening the policy.

Job 3 — Policy Generation (Inline From CloudTrail)

Access Analyzer can generate a least-privilege IAM policy based on an IAM role's actual CloudTrail activity over a specified window. You pick a role, pick a time range, and Access Analyzer produces a policy statement listing exactly the actions and resources the role accessed. This is the practical tool for right-sizing an existing role from broad permissions to least privilege without guesswork.

Organization Analyzer — The Right Zone of Trust

Per-account analyzers work, but multi-account organizations should use an organization-level analyzer created from the Access Analyzer delegated admin (typically the Security account). Only the organization analyzer treats intra-org cross-account access as internal, showing only external (outside-org) findings. Per-account analyzers see every sibling account as "external," producing noise that obscures real issues.

Archive Rules — Suppressing Expected Findings

Some external access is intentional (a monitoring vendor's cross-account role is expected). Archive rules auto-suppress matching findings so they do not clutter the active list. Archive rules match on criteria like account ID, resource type, or principal ARN.

Access Analyzer vs Security Hub

Access Analyzer findings flow into Security Hub, so the delegated admin sees them alongside GuardDuty and Inspector findings. But Access Analyzer is also a standalone service with its own console and its own three job types. On the exam, if the scenario says "find S3 buckets accessible from outside the organization," "find IAM roles that have never been used," or "generate a least-privilege policy from actual usage," the answer is Access Analyzer — specifically, the external access job, the unused access job, and the policy generation job respectively.

Centralized Patch and Vulnerability Compliance at Scale

Cross-account security controls extend beyond identity and findings to patching and vulnerability management.

Systems Manager Patch Manager Across Accounts

Patch Manager in a multi-account setup uses patch baselines defined centrally and applied via State Manager associations to EC2 fleets across accounts. Combined with Organizations, you can target "all EC2 instances in Production OU" with a Linux patch baseline and an update schedule. Compliance reports flow into Security Hub and can be evidence-collected by Audit Manager.

Inspector v2 for Organization-Wide Vulnerability Scanning

Amazon Inspector v2 supports the same delegated-admin model as GuardDuty. From the Inspector delegated admin account, you enable Inspector across all member accounts for EC2, ECR, and Lambda scanning. Findings flow to Security Hub with CVE IDs, CVSS scores, and fix availability.

The Patch + Scan + Detect Loop

The integrated cross-account security controls vulnerability loop: Inspector detects CVEs → Security Hub aggregates → Patch Manager applies patches via State Manager → Inspector rescans and confirms remediation → Audit Manager collects evidence. All coordinated from the Security account without workload-team intervention.

AWS Certificate Manager (ACM) and Private CA for Cross-Account TLS

Private CAs in AWS Certificate Manager issue internal TLS certificates for microservices. In a multi-account environment, the CA hierarchy is typically hosted in a shared services or security account and shared with workload accounts via AWS RAM.

Sharing a Private CA With AWS RAM

The Private CA resource can be shared via Resource Access Manager to specific accounts, OUs, or the entire Organization. Workload accounts can then issue certificates from the shared CA for their own ALBs, API Gateways, internal services, without each workload running its own CA infrastructure.

Public Certificates via ACM

ACM public certificates are account-local and free. They cannot be shared cross-account directly (except by re-provisioning in each account). For public-facing services in many accounts, the pattern is ACM per account; for internal microservice mTLS, the pattern is shared Private CA.

Scenario Pattern — Developer Self-Service Without Privilege Escalation

A classic SAP-C02 scenario: "Developers in member accounts need to deploy Lambda functions, including creating execution roles. They cannot be granted IAM admin. The security team must prevent privilege escalation." Solve it with cross-account security controls layering.

The Layered Answer

• Permission boundary named DeveloperWorkloadBoundary defines the maximum for any role developers create (allows read on service quotas, Lambda invoke, CloudWatch Logs, specific S3 prefixes; denies IAM, Organizations, anything privilege-escalating).
• Developer role granted iam:CreateRole, iam:PutRolePolicy, iam:AttachRolePolicy, iam:PassRole — but with a condition "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT:policy/DeveloperWorkloadBoundary". Developers can only create roles that attach the boundary.
• SCP at the workload OU denies disabling CloudTrail, disabling GuardDuty, deleting the boundary policy, deleting the security account's Config aggregator — immutable guardrails.
• Access Analyzer organization analyzer watches for any resource policy exposing data outside the org, catching developer mistakes.

The result: developers have Lambda self-service, cannot escalate, cannot tamper with security tooling, and any accidental data exposure is detected.

Scenario Pattern — Detecting CloudTrail Disablement Across 100 Accounts

Scenario: "The security team must be alerted within minutes if any member account disables CloudTrail." Multiple cross-account security controls can solve this; the exam tests which is best.

Option Comparison

• SCP denying cloudtrail:StopLogging and cloudtrail:DeleteTrail — preventive, immutable. This is the first-line answer.
• GuardDuty Stealth:IAMUser/CloudTrailLoggingDisabled finding — detective, automatic once GuardDuty is enabled org-wide. Finding flows to Security Hub and EventBridge.
• Config Rule cloud-trail-enabled — detective, with optional auto-remediation SSM runbook to re-enable CloudTrail.
• CloudWatch Events / EventBridge rule on CloudTrail management events — detective, requires an Organizations CloudTrail to capture across accounts.

The right design uses SCP as the preventive guardrail (makes the bad action impossible) plus GuardDuty and Config as the detective backups (catches edge cases and enforces org-wide evidence). A pure detection-only answer is weaker than prevention + detection combined.

Cross-Account Security Controls — Cost and Operational Trade-Offs

Every cross-account security control has a cost. On the SAP-C02 exam, questions sometimes require balancing coverage against cost.

GuardDuty Cost Model

GuardDuty charges per CloudTrail event analysed and per VPC Flow Log / DNS log volume. Additional protection plans (Malware Protection, S3 Protection, EKS Protection, Lambda Protection, RDS Protection) are priced separately. Organization-wide deployment multiplies cost by account count but is almost always worth it given the value of threat detection.

Security Hub Cost Model

Security Hub charges per finding ingested and per compliance standards evaluation. Cross-region aggregation does not multiply ingestion cost — findings ingested once in source region are replicated to aggregation region without re-charge.

Config Cost Model

Config charges per configuration item recorded and per rule evaluation. Conformance pack rules cost per evaluation; organization conformance packs multiply by member account count.

Macie Cost Model

Macie automated sensitive-data discovery is priced per GB of S3 data evaluated (with sampling). Scheduled jobs are priced per object scanned. Macie is typically the costliest cross-account security control for large data lakes — automated discovery plus targeted jobs are the cost-managed pattern.

Access Analyzer Cost Model

External access findings are free. Unused access findings are priced per IAM role monitored per month. Policy generation is free. The unused access tier is a deliberate cost signal for organizations managing thousands of roles.

Audit Manager Cost Model

Audit Manager is priced per resource evaluated per month per active assessment. Stop unused assessments to cap cost; schedule high-cost frameworks only during audit preparation windows.

Common Exam Traps for Cross-Account Security Controls

Trap 1 — Permission Boundary Grants Permission

Wrong. Permission boundaries cap permissions; they never grant them. An identity policy must still explicitly allow an action for it to be permitted — the boundary only limits what the identity policy can grant.

Trap 2 — SCP Applies to Management Account

Wrong. SCPs exempt the management account. This is why best practice is to keep the management account free of workloads and operate via delegated administrators in the Security account.

Trap 3 — Access Analyzer Finds All Cross-Account Access Issues

Partial. Access Analyzer external-access findings analyse resource-based policies, not IAM identity policies. A cross-account IAM role assumption through a trust policy IS a resource-based policy on the role, so Access Analyzer catches it. But Access Analyzer does not analyse every conceivable cross-account path; it is scoped to resource policies on supported services.

Trap 4 — KMS Key Policy Alone Grants Cross-Account Access

Wrong. Cross-account KMS access requires the key policy to allow AND the caller's identity policy to allow. Same-account access works with just one, but cross-account needs both.

Trap 5 — ExternalId for Intra-Organization Access

Wrong. ExternalId defends against the third-party confused deputy. Intra-organization cross-account roles should use aws:PrincipalOrgID, not ExternalId. The exam will test this specifically.

Trap 6 — Security Hub Generates Its Own Threat Findings

Partial. Security Hub does generate compliance-standard findings (FSBP, CIS), but for threat detection it is an aggregator consuming GuardDuty findings. Candidates who answer "Security Hub" for a threat-detection question miss the correct answer, GuardDuty.

Trap 7 — Macie Scans RDS or EFS

Wrong. Macie is S3-only. For sensitive data in other stores, use database activity streams, third-party DLP, or copy to S3 for Macie scanning.

Trap 8 — Config and Security Hub Are the Same

Wrong. Config records configuration state over time and evaluates Config rules. Security Hub aggregates findings and scores compliance, consuming Config conformance pack findings as one input among many (GuardDuty, Inspector, Macie, Access Analyzer). Both are enabled together.

Trap 9 — One Access Analyzer Config Covers All Three Jobs

Wrong. External access analyzer and unused access analyzer are separate configurations. Policy generation is invoked on demand per role. You configure the three independently, and they are priced differently.

Trap 10 — Delegated Admin Is the Same as Management Account

Wrong. The delegated admin is a separately designated member account (usually the Security or Audit account). The management account performs the delegation but is not itself the operating account for day-to-day security tooling.

Key Numbers and Must-Memorize Cross-Account Security Controls Facts

Trust Policy Condition Keys

aws:PrincipalOrgID for intra-org. aws:SourceAccount and aws:SourceArn for service-to-service. sts:ExternalId for third-party SaaS. aws:PrincipalOrgPaths for OU-scoped trust.

KMS Cross-Account

Key policy + IAM policy both required for cross-account. Grants for service delegation. MRKs for multi-region same-key-ID replication.

Policy Evaluation

Explicit Deny beats any Allow. SCP + permission boundary + identity policy + resource policy must all allow for cross-account access.

GuardDuty Organizations

Delegated admin from Security account. Auto-enable new accounts per region. Six data sources and protection plans (CloudTrail, VPC Flow, DNS + Malware, S3, EKS, Lambda, RDS protection).

Security Hub

Delegated admin. Cross-region aggregation region chosen once. FSBP, CIS, PCI DSS, NIST 800-53 standards. ASFF normalization.

Config Aggregator and Conformance Packs

Aggregator = read-only cross-account-cross-region view. Organization conformance packs deploy to all member accounts in one API call.

Macie

S3-only. Automated sensitive-data discovery (sample-based, always-on) or scheduled jobs (specific buckets). Delegated admin same as GuardDuty.

Audit Manager

Frameworks for SOC 2, PCI DSS, HIPAA, NIST 800-53, GDPR, FedRAMP, ISO 27001, AWS Well-Architected. Evidence from CloudTrail, Config, Security Hub, manual upload.

IAM Access Analyzer Three Jobs

External access (resource policies), unused access (stale principals and permissions), policy generation (from CloudTrail activity). Organization-level analyzer for org zone of trust.

FAQ — Cross-Account Security Controls Top Questions

Q1 — What is the difference between aws:PrincipalOrgID and sts:ExternalId, and when should I use each?

aws:PrincipalOrgID is an AWS-managed condition key used in trust policies to restrict role assumption to principals in a specific AWS Organization. Use it for all intra-organization cross-account roles. If an account leaves the organization, its principals can no longer assume the role — automatic revocation. sts:ExternalId is a customer-specified unique value used in third-party SaaS scenarios to prevent the confused-deputy attack. The third party supplies the ExternalId on every AssumeRole call; the trust policy requires it. Use ExternalId only for third-party access, not for cross-account roles within your own organization.

Q2 — If I enable Security Hub with cross-region aggregation, do I still need GuardDuty in every region?

Yes. GuardDuty is the detector; Security Hub is the aggregator. You need GuardDuty enabled in every region where workloads run so that threats there are detected. Security Hub cross-region aggregation only relocates findings — it does not perform detection. Enable GuardDuty in every used region with auto-enable on new members, then point Security Hub cross-region aggregation to a single consolidation region.

Q3 — How do I grant a Lambda in account A access to an S3 bucket in account B encrypted with a KMS key in account B?

Five policies must align: (1) Account A SCP does not deny s3:GetObject or kms:Decrypt; (2) Lambda execution role identity policy allows both actions on the bucket and key ARNs; (3) Account B bucket policy allows the Lambda role principal to s3:GetObject; (4) Account B KMS key policy allows the Lambda role principal to kms:Decrypt and kms:DescribeKey; (5) Account B SCP does not deny either action from org members. Any missing allow returns AccessDenied. The most commonly forgotten element is the KMS key policy, because KMS requires explicit key-policy allow for cross-account use.

Q4 — What is the difference between a permission boundary and an SCP, and do I need both?

A Service Control Policy is attached to an Organizations OU or account and caps what any principal in the affected accounts can do — including root. SCPs are organization-wide preventive guardrails. A permission boundary is an IAM managed policy attached to a specific IAM user or role that caps what that principal's identity policies can grant — critical when delegating role creation to developers so they cannot create roles with more permissions than the boundary allows. Yes, you typically use both: SCP for org-wide immutable rules (region restrictions, no-CloudTrail-disable), permission boundary for per-principal delegation (developer-created roles must attach the boundary). They operate independently and stack.

Q5 — How does IAM Access Analyzer unused-access differ from Access Advisor or Credential Report?

Access Advisor shows when services were last accessed by a principal — useful for ad-hoc investigation but per-service granular view. Credential Report is an account-wide CSV of IAM users with last-used dates. Access Analyzer unused-access is an always-on, organization-wide continuous analyzer producing findings for unused roles, unused access keys, and unused permissions inside used roles. It scales to 100-plus accounts and feeds Security Hub. For point-in-time deep-dive, use Access Advisor; for ongoing cleanup at organizational scale, use Access Analyzer unused access.

Q6 — Can Macie scan sensitive data in RDS or DynamoDB?

No. Macie only scans Amazon S3. For RDS, rely on Database Activity Streams plus CloudTrail plus query auditing. For DynamoDB, rely on attribute-level design (don't store sensitive data in DynamoDB, or encrypt fields client-side with KMS envelope encryption). For EFS, there is no native sensitive-data scanner. The pattern for non-S3 stores is either avoid storing sensitive data there, or implement DLP at the application layer.

Q7 — If the management account is exempt from SCPs, how do I prevent an attacker with management-account credentials from causing damage?

Multiple defences: (1) Enable root-account MFA on the management account and store the credentials in a vault (physical safe) — the root account should be used almost never. (2) Enable AWS Organizations SCP on all other accounts so even if management-account credentials leak, the blast radius is narrow (the management account itself does not typically hold workloads). (3) Use Identity Center for all human access — no IAM users in the management account. (4) Enable CloudTrail Organizations trail to an immutable Log Archive bucket with vault lock. (5) Set GuardDuty to alert on root-account usage findings. The philosophy is defence in depth: make the management account minimally used, and detect any deviation immediately.

Q8 — What is the difference between AWS Config Rules and Security Hub Security Standards?

Config Rules evaluate AWS resource configuration against desired state and produce compliance status per resource per rule. Security Hub Security Standards (FSBP, CIS, PCI, NIST) are curated bundles of security best practices, many of which are backed by Config Rules under the hood. Security Hub adds normalized finding format, aggregation across accounts and regions, and a compliance score per standard. You typically enable both: Config Rules for fine-grained custom compliance logic and historical drift visibility, Security Hub Standards for out-of-the-box industry-standard compliance scoring across the organization.

Q9 — How do organization conformance packs differ from per-account conformance packs?

A per-account conformance pack deploys rules to one Config-enabled account. An organization conformance pack (deployed from the Organization management account or Config delegated admin) automatically deploys the same rules to every member account selected, with updates and deletions propagating too. This is how the security team rolls PCI DSS conformance to 100 workload accounts in one deployment. For the SAP-C02 exam, if the scenario says "apply consistent compliance rules to all member accounts," the answer is organization conformance pack.

Q10 — What is the right delegated-admin pattern for a landing zone?

Canonical landing zone has two non-management accounts handling security: the Security/Audit account and the Log Archive account. The Security account is designated delegated admin for GuardDuty, Security Hub, Config (aggregator + conformance packs), Macie, Inspector v2, IAM Access Analyzer, and Audit Manager. The Log Archive account owns the centralized CloudTrail and Config delivery bucket with object lock / vault lock. Workload teams operate in their own OU-scoped accounts with no direct access to the Security or Log Archive accounts — guardrails enforced via SCPs. This pattern is the reference architecture every SAP-C02 scenario implicitly assumes.

Further Reading — Official AWS Documentation for Cross-Account Security Controls

For depth beyond SAP-C02 scope, the authoritative AWS sources are: IAM User Guide (especially policy evaluation logic and role trust policies), AWS Organizations User Guide (SCPs, delegated administrators), KMS Developer Guide (key policies, grants, multi-region keys), GuardDuty User Guide (organizations integration), Security Hub User Guide (cross-region aggregation, standards), AWS Config Developer Guide (aggregators, conformance packs), Macie User Guide (organization management), Audit Manager User Guide, and IAM Access Analyzer User Guide (all three job types).

The AWS Security Reference Architecture (SRA) whitepaper is mandatory reading for SAP-C02 — it codifies the Security account / Log Archive account / delegated admin pattern for all the cross-account security controls in this guide. The AWS Well-Architected Security Pillar whitepaper is the conceptual anchor. AWS re:Inforce recorded sessions from the last two years cover every delegated-admin feature with real customer architectures.

Summary — Cross-Account Security Controls Decision Tree

On exam day, when you see a cross-account security controls scenario, run this decision tree:

1. Is the rule about preventing an action organization-wide? → SCP.
2. Is the rule about capping what a delegated developer can grant? → Permission boundary.
3. Is the scenario about cross-account role assumption for intra-org? → IAM role with aws:PrincipalOrgID in trust policy.
4. Is the scenario about third-party SaaS access? → IAM role with sts:ExternalId in trust policy.
5. Is the scenario about cross-account KMS access? → Both key policy and IAM policy must allow; Grants for service-level.
6. Is the scenario about threat detection across accounts? → GuardDuty with delegated admin, auto-enable new accounts.
7. Is the scenario about compliance scoring across accounts and regions? → Security Hub with delegated admin + aggregation region.
8. Is the scenario about configuration compliance across accounts? → AWS Config aggregator + organization conformance packs.
9. Is the scenario about sensitive data in S3 across accounts? → Macie with delegated admin.
10. Is the scenario about finding resource policies exposing data outside the org? → IAM Access Analyzer organization analyzer, external access findings.
11. Is the scenario about stale IAM roles and unused permissions? → IAM Access Analyzer unused access findings.
12. Is the scenario about generating a least-privilege policy from actual usage? → IAM Access Analyzer policy generation.
13. Is the scenario about audit evidence for SOC 2 / PCI / HIPAA? → AWS Audit Manager.
14. Is the scenario about centralized patching? → Systems Manager Patch Manager with Organizations + Inspector v2.

Master these fourteen branches and you will answer every cross-account security controls question on SAP-C02 Task 1.2 correctly. Cross-account security controls reward architectural thinking more than single-service recall — study how the layers combine, and the right cross-account security controls design will always fall out.