Multi-Account Governance
The organization is the security control plane
A bank does not give every teller a key to the vault; it puts the vault in one guarded room and lets the rest of the building stay productive. AWS Organizations is that guarded room for a multi-account estate. It groups AWS accounts into a tree of organizational units (OUs) beneath a single management account, the account that created the organization and the only one that can attach organization policies, invite or remove accounts, and enable services across the whole org. The management account also owns consolidated billing[1], which is why an organization can run in two modes: consolidated-billing-only, or all features enabled, which is required before you can use service control policies, resource control policies, or declarative policies.
Why you keep the management account empty
The management account is special in a way that is load-bearing for the exam: a service control policy (SCP) never restricts the management account[2] or its root user, and the same exemption holds for resource control policies. Any workload you place there runs above your own guardrails. The standard pattern is therefore to treat the management account as a thin control plane that does nothing but administer the organization, and to push every real workload, plus the operation of security tooling, down into member accounts and a small number of dedicated accounts (a log archive account, an audit or security account).
Inheritance follows the tree
Policies attach at three levels: the organization root, an OU, or an individual account. A policy attached high in the tree is inherited by everything below it, so an SCP placed on the root applies to every current and future member account. This is the mechanism behind "attach the Region-deny guardrail at the root so new accounts are covered automatically." Where you attach a policy is itself a design decision: broad guardrails go near the root, exceptions go on the specific OU or account that needs them.
SCPs, RCPs, and declarative policies: three guardrails, three jobs
The single most testable idea in this subtopic is that the three organization policy types do different jobs and none of them grants access. An SCP[2] caps the maximum permissions of identities (IAM users and roles) in member accounts. A resource control policy (RCP)[3] caps the maximum permissions on resources in member accounts. Both are authorization policies: the effective permission is the intersection of what the SCPs allow, what the RCPs allow, and what the identity-based and resource-based policies grant. If any layer denies, the request is denied; if no layer grants, the request is also denied. Guardrails set the ceiling, IAM still has to open the door.
SCP is the principal side, RCP is the resource side
Think of one authorization fence with two faces. The SCP face asks "is this principal in my org allowed to make this call at all?" The RCP face asks "is anyone, including a principal outside my org, allowed to touch this resource?" That second framing is the reason RCPs exist: an over-permissive S3 bucket policy or KMS key policy could grant a cross-account principal access that no SCP would ever see, because the SCP only governs your own identities. An RCP closes that gap. The classic RCP requires that any access to your S3, STS, KMS, SQS, or Secrets Manager resources comes from a principal in your own organization (aws:PrincipalOrgID), or that connections use TLS. RCPs apply to a defined subset of services[3] (S3, STS, KMS, SQS, Secrets Manager, DynamoDB, CloudWatch Logs, and others), not every service.
Declarative policies enforce configuration, not authorization
A declarative policy[4] is a different animal. SCPs and RCPs regulate API calls; a declarative policy pins an account-level setting to a desired value and enforces it in the service's control plane, not at the authorization layer. You declare "EBS encryption-by-default is on" or "VPC block-public-access is on" once, and the setting is maintained even when the service ships a brand-new API that could otherwise change it. This is the "set once and forget" property, and it is why declarative policies are the right tool when you must keep a baseline true over time rather than block a specific call. Two more distinctions matter for the exam: declarative policies do govern service-linked roles (SCPs and RCPs do not), and detaching a declarative policy rolls the attribute back to its previous state. The same organization-policy machinery also carries backup policies, tag policies, and AI services opt-out policies (which stop AWS AI services such as Amazon Bedrock and Amazon Rekognition from using your content to improve those services).
Two exemptions you must memorize
Neither SCPs nor RCPs touch the management account or its resources, and neither restricts service-linked roles. If a question asks you to constrain the management account with an SCP, the premise is wrong; the answer is to remove workloads from the management account, not to write a tighter SCP.
Control Tower: the opinionated landing zone
If Organizations is the raw control plane, AWS Control Tower is the curated package on top of it. Starting a brand-new multi-account environment by hand means manually creating a log archive account, an audit account, a baseline of guardrails, and a repeatable way to vend new accounts. Control Tower[5] does all of that as a managed landing zone: it sets up the shared accounts, applies a baseline of controls, and gives you Account Factory to provision governed accounts on demand.
Controls come in three behaviors and three guidance levels
Control Tower controls (the term "guardrail" is the older name for the same thing) are classified two ways. By behavior: a preventive control stops a non-compliant action before it happens and is implemented as an SCP or RCP; a detective control reports drift after the fact and is implemented as an AWS Config rule; a proactive control checks resources against policy before they are provisioned and is implemented as a CloudFormation hook. By guidance: mandatory controls are always on and cannot be disabled, strongly recommended controls follow AWS best practice, and elective controls let you opt into stricter behavior. A common exam scenario gives you a data-residency requirement; the answer is the Region-deny control, which is a preventive control that uses the same aws:RequestedRegion deny pattern you would write by hand in an SCP.
Account Factory and AFT for scale
Account Factory provisions new accounts with the baseline already applied, so a vended account lands inside an OU under the right controls instead of being a blank, ungoverned account. When you need that vending to be fully infrastructure-as-code and pipeline-driven, Account Factory for Terraform (AFT) wraps Account Factory in a Terraform pipeline. The deeper IaC and StackSets mechanics for deploying resources across those accounts belong to secure deployment; here the point is only that Control Tower gives you a governed account on day zero.
Delegated administration and centralized root access
Two patterns keep the powerful management account out of day-to-day operations. The first is delegated administration: rather than run GuardDuty, Security Hub, AWS Config, IAM Access Analyzer, or Detective from the management account, you register a member account (usually the audit or security account) as the delegated administrator for that service. The delegated admin then configures the service, auto-enrolls member accounts, and views findings org-wide, while the management account only enables trusted access. There is one well-known exception worth holding: for IAM Identity Center[6], the Identity Center instance must always live in the management account; a delegated administrator can manage most things but cannot alter permission sets used for access to the management account itself.
Centralized root access removes the standing credential
The second pattern is new in this exam version. Historically every member account had its own root user with long-term credentials that were hard to inventory and monitor. Centralized root access[7] splits the problem into two capabilities. Central management of root credentials lets the management account or a delegated administrator delete a member account's root password, access keys, signing certificates, and MFA device, so the member account simply has no standing root credential to steal or misuse. Central root sessions let an authorized central account perform the handful of genuinely root-only tasks through a short-lived, task-scoped session (a maximum 15-minute session authorized to do only that one task) instead of a permanent credential.
What the privileged session is actually for
The canonical root-only tasks the central session handles are recovery scenarios: deleting a misconfigured S3 bucket policy that denies all principals (locking everyone out of the bucket), and deleting an SQS queue resource-based policy that denies all principals. You enable the two capabilities with EnableOrganizationsRootCredentialsManagement and EnableOrganizationsRootSessions. As with SCPs and RCPs, the management account's own root user is governed differently; centralized root access is about removing root from the member accounts and brokering the rare privileged action centrally. The broader incident workflow these recovery tasks feed into lives in incident response planning.
Exam-pattern recognition
Security Specialty questions on this subtopic almost always test whether you can pick the right policy type for a stated goal, so map the verb in the stem to the mechanism.
Map the goal to the policy type
When the stem says "prevent any IAM user or role in member accounts from doing X" (leaving the organization, using a non-approved Region, disabling CloudTrail), the answer is an SCP, usually a deny attached at the root or an OU. When the stem says "ensure our S3 buckets / KMS keys can only be accessed by principals in our own organization, even if a bucket policy is too open," the answer is an RCP with an aws:PrincipalOrgID condition, because an SCP cannot see a cross-account principal reaching a resource. When the stem says "guarantee EBS encryption-by-default stays on (or VPC public access stays blocked) across all current and future accounts, even as the service changes," the answer is a declarative policy, not an SCP, because you are enforcing a durable configuration rather than denying an API call.
Watch the management-account and SLR distractors
A recurring trap offers an SCP to "restrict the management account" or to "block a service-linked role." Both are wrong by design: SCPs and RCPs exempt the management account and do not constrain service-linked roles. If you truly need to constrain an SLR's behavior, a declarative policy is the only org-policy that governs SLRs. Another distractor pairs Control Tower's Region-deny control against a hand-written SCP as if they were different answers; they implement the same aws:RequestedRegion pattern, so the discriminator is usually "managed and auditable in a landing zone" (Control Tower) versus "fully custom" (raw SCP).
Centralized-root and delegated-admin cues
When the scenario describes an S3 bucket or SQS queue locked out by a deny-all resource policy and asks how to recover without leaving long-term root credentials lying around, the answer is a central, task-scoped root session, not "log in as the member-account root." When the scenario wants GuardDuty or Security Hub findings aggregated and operated outside the management account, the answer is to register a delegated administrator, not to run the service from the management account. The Config and Audit Manager mechanics behind those detective findings are covered in compliance evaluation.
AWS Organizations policy types compared
| Dimension | SCP | RCP | Declarative policy |
|---|---|---|---|
| What it governs | Identities (IAM users/roles) in member accounts | Resources in member accounts | An AWS service's account-level configuration |
| Mechanism | Caps maximum API permissions for principals | Caps maximum API permissions on resources | Enforces desired config in the service control plane |
| Grants permission? | No, guardrail only | No, guardrail only | No, it sets configuration |
| Affects management account? | No | No | Yes, where attached |
| Governs service-linked roles? | No | No | Yes |
| Typical use | Region deny, block leaving org | Require same-org or HTTPS-only access to S3/KMS/STS | EBS encryption default, VPC block public access, IMDSv2 |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- An SCP caps what identities can do, it never grants access
A service control policy sets the maximum permissions for IAM users and roles in member accounts, so a principal can only do something an SCP allows AND an IAM policy grants. Because it is a ceiling and not a grant, attaching an SCP that allows an action does nothing on its own; you still need an identity-based or resource-based policy to actually permit it. Attach SCPs at the org root or an OU and inheritance covers every current and future account below.
Trap Treating an Allow in an SCP as if it granted the permission; the identity still has no access until an IAM policy grants it.
- SCPs never restrict the management account or its root user
Service control policies apply to every principal in member accounts, including each member account's root user, but they have no effect on the management account or its root. This is why the management account is kept empty of workloads: anything running there sits above your own guardrails. The fix for a management-account risk is to move the workload into a member account, not to write a tighter SCP.
Trap Writing an SCP to restrict the management account; SCPs exempt it entirely, so the policy has no effect there.
- Use an RCP to guard resources, the resource-side complement to SCPs
A resource control policy caps the maximum permissions on resources in member accounts, closing a gap SCPs cannot: an over-permissive S3 bucket or KMS key policy could grant access to a principal outside your organization that no SCP governs. The canonical RCP requires that access to your S3, STS, KMS, SQS, or Secrets Manager resources come from a principal in your own org via an aws:PrincipalOrgID condition, or that connections use TLS. Like SCPs, RCPs only set a ceiling and need all features enabled in Organizations.
Trap Reaching for an SCP to stop a cross-account principal from reading your bucket; an SCP only governs your own identities, so it never sees the external principal, an RCP does.
- RCPs cover only a subset of services and skip the management account
Resource control policies apply to a defined list of services such as S3, STS, KMS, SQS, Secrets Manager, DynamoDB, and CloudWatch Logs, not every AWS service, so confirm the service is in scope before relying on one. Like SCPs, RCPs do not affect resources in the management account and do not restrict service-linked roles. An RCP on a member account that is a delegated administrator still applies to that account's resources.
- Effective permission is the intersection of guardrails and grants
Whether a request succeeds is the logical intersection of what the SCPs allow, what the RCPs allow, and what the identity-based and resource-based policies grant. Any explicit deny at any layer wins, and a missing grant means denied even when every guardrail allows. Guardrails set the outer boundary; IAM still has to open the door inside it.
- Declarative policies pin a durable configuration, not an API allow/deny
Where SCPs and RCPs decide whether an API call is authorized, a declarative policy enforces a desired account-level setting in the service's control plane and keeps it there even when the service ships a new API that could change it. You declare intent once, such as EBS encryption-by-default on or VPC block-public-access on, and Organizations maintains it for current and future accounts. Detaching the policy rolls the attribute back to its previous state.
Trap Using an SCP to keep EBS encryption-by-default on; an SCP can only deny specific API calls, so it cannot guarantee the setting survives a new service feature the way a declarative policy does.
- Declarative policies are the only org policy that governs service-linked roles
SCPs and RCPs do not restrict service-linked roles, but declarative policies do, because they enforce configuration at the service level rather than at API authorization. So when a requirement must hold even against service-managed behavior, a declarative policy is the right org-policy tool. This is also why declarative policies, unlike SCPs and RCPs, affect the management account where attached.
Trap Assuming an SCP can constrain a service-linked role; SCPs exempt SLRs, so only a declarative policy reaches them.
- Organizations also carries backup, tag, and AI opt-out policies
Beyond the authorization policies, the same Organizations machinery distributes backup policies, tag policies, and AI services opt-out policies inherited down the OU tree. The AI services opt-out policy stops AWS AI services such as Amazon Bedrock and Amazon Rekognition from storing or using your content to improve those services, applied org-wide instead of per account. Tag policies standardize tag keys and values; backup policies centrally enforce AWS Backup plans.
- Deny non-approved Regions with an aws:RequestedRegion SCP
The standard way to confine an organization to approved Regions is an SCP that denies actions when aws:RequestedRegion is not an approved value, attached at the root or OU so future accounts inherit it. You must exempt global services such as IAM, STS, CloudFront, Route 53, and Organizations because they have no Regional endpoint, and you cannot deny access to your home Region. Control Tower's built-in Region deny control implements exactly this pattern.
Trap Applying the Region-deny SCP without exempting global services like IAM and STS; those calls have no Region and would be blocked, breaking the account.
3 questions test this
- A security architect is configuring AWS Control Tower for an organization that operates only in the eu-west-1 and eu-central-1 Regions for…
- A healthcare company is implementing AWS Organizations with three OUs: Workloads, Sandbox, and Security. The company must ensure that…
- A multinational financial services company is deploying a multi-account strategy using AWS Organizations. The security team must ensure…
- Control Tower is the opinionated landing zone on top of Organizations
Control Tower automates a multi-account landing zone: it provisions the shared accounts (management, log archive, audit), applies a baseline of controls, and vends new governed accounts through Account Factory. Reach for Control Tower when you want a governed baseline out of the box; use raw Organizations when you need fully custom control with no opinionated structure. Account Factory for Terraform (AFT) wraps Account Factory in a Terraform pipeline for infrastructure-as-code account vending.
- Control Tower controls come in preventive, detective, and proactive behaviors
A preventive control stops a non-compliant action before it happens and is implemented as an SCP or RCP; a detective control reports drift after the fact and is implemented as an AWS Config rule; a proactive control checks resources against policy before they are provisioned and is implemented as a CloudFormation hook. Matching the behavior to the requirement is the testable point: stop it (preventive), find it later (detective), or block it at deploy time (proactive).
Trap Picking a detective control to stop a non-compliant action; a Config rule only reports drift after the fact, you need a preventive SCP/RCP to actually block it.
- Control Tower controls have mandatory, strongly recommended, and elective levels
By guidance level, mandatory controls are always on and cannot be disabled, strongly recommended controls follow AWS best practice, and elective controls let you opt into stricter behavior. This guidance level is independent of the preventive/detective/proactive behavior axis, so a control is described by both, for example a strongly recommended detective control.
- Run security services from a delegated administrator, not the management account
AWS recommends keeping the management account free of workloads, so day-to-day operation of GuardDuty, Security Hub, AWS Config, IAM Access Analyzer, and Detective is delegated to a dedicated security or audit account. That delegated administrator configures the service, auto-enrolls members, and views findings org-wide, while the management account only enables trusted access. This shrinks the blast radius of the most powerful account.
Trap Operating GuardDuty or Security Hub from the management account; AWS guidance is to delegate it to a security account so the management account stays workload-free.
6 questions test this
- A multinational company operates workloads across 15 AWS accounts in an AWS Organization spanning four AWS Regions. The security team needs…
- A security engineer needs to configure IAM Access Analyzer to identify Amazon S3 buckets and AWS KMS keys that are accessible by principals…
- A multinational company is implementing IAM Access Analyzer across their AWS Organizations environment. The security team wants to…
- A company has implemented AWS Organizations with 50 member accounts across multiple AWS Regions. The security team must identify all…
- A security engineer at a company with 50 AWS accounts in AWS Organizations discovers that several Amazon S3 buckets have been…
- A security team at a multinational company needs to evaluate compliance posture across 50 AWS accounts spanning five AWS Regions. They want…
- IAM Identity Center's instance must stay in the management account
IAM Identity Center supports a delegated administrator member account, but the Identity Center instance itself must always reside in the management account. The delegated administrator can manage most things but cannot alter permission sets used for access to the management account; only an Identity Center administrator in the management account can change those.
Trap Assuming a delegated administrator can move the IAM Identity Center instance out of the management account; the instance must remain there even with delegation.
- Centralized root access removes standing root credentials from member accounts
Central management of root credentials lets the management account or a delegated administrator delete a member account's root password, access keys, signing certificates, and MFA device, so no long-term root credential exists to be stolen or misused. You enable it with the EnableOrganizationsRootCredentialsManagement action. The management account's own root user is governed separately and is not removed this way.
- Recover a locked-out resource with a short task-scoped root session
After removing standing root credentials, genuine root-only tasks run through a central root session: a short-lived, task-scoped session of at most 15 minutes authorized to perform only that one action, enabled with EnableOrganizationsRootSessions. The canonical uses are recovery: deleting a misconfigured S3 bucket policy that denies all principals, and deleting an SQS queue resource-based policy that denies all principals. This replaces logging in as the member account root with a permanent credential.
Trap Recovering a deny-all bucket policy by logging in as the member account root; centralized root access removes that standing credential, so the recovery path is a 15-minute task-scoped root session from the central account.
- Map the exam stem's goal to the right policy type
When the goal is to limit what identities in member accounts may do, the answer is an SCP; when it is to protect resources from over-broad or cross-org access, the answer is an RCP with aws:PrincipalOrgID; when it is to keep a service setting true over time, the answer is a declarative policy. Reading the verb in the stem (limit identities, protect resources, pin a setting, recover root) is the fastest discriminator on this subtopic.
Trap Choosing an SCP for a resource-protection goal because both are deny policies; an SCP cannot see an external principal accessing your resource, so the resource case needs an RCP.
- An organization needs all features enabled for guardrail policies
SCPs, RCPs, and declarative policies require an organization with all features enabled, not the consolidated-billing-only mode. Consolidated billing alone gives you combined invoicing and volume discounts but none of the authorization or configuration guardrails. Switching to all features is a one-way move that member accounts must approve.
- An external-access analyzer is Regional, so create one per Region
IAM Access Analyzer external-access analysis only evaluates resource policies in the Region where the analyzer is enabled, so multi-Region coverage requires an analyzer in each Region with resources. Set the organization as the zone of trust to flag only access from outside the org, and run it from a delegated administrator to view findings org-wide without the management account.
Trap Assuming a single analyzer covers every Region: an analyzer in us-east-1 never produces findings for resources in another Region.
4 questions test this
- A security engineer needs to configure IAM Access Analyzer to identify Amazon S3 buckets and AWS KMS keys that are accessible by principals…
- A company has implemented AWS Organizations with 50 member accounts across multiple AWS Regions. The security team must identify all…
- A security engineer at a company with 50 AWS accounts in AWS Organizations discovers that several Amazon S3 buckets have been…
- A company is implementing IAM Access Analyzer across its AWS Organizations environment. The company has accounts in multiple AWS Regions…
- Archive rules auto-mark expected Access Analyzer findings as intended
An archive rule with criteria such as a trusted account ID or resource type automatically marks matching external-access findings as intended, and choosing 'create and archive active findings' applies it to existing findings too. Access Analyzer suggests the default criterion 'Public access is false' so a rule never silently archives findings for genuinely public resources.
- Unused-access analyzers can exclude accounts and tagged identities
An IAM Access Analyzer unused-access analyzer supports two exclusion lists: specific AWS account IDs to skip entirely, and tag key-value pairs that exempt matching IAM users and roles (for example break-glass roles tagged Purpose=Emergency-Access) from generating unused-access findings.
- Access Analyzer policy validation flags iam:PassRole with a wildcard resource as a security warning
Policy validation sorts findings into errors, security warnings, general warnings, and suggestions. iam:PassRole on Resource "*" is a security warning because passing any role enables privilege escalation; security warnings call out overly permissive statements rather than syntax problems.
- CfCT applies CloudFormation customizations on Control Tower lifecycle events
Customizations for AWS Control Tower (CfCT) is the AWS-published solution that uses a CloudFormation manifest, StackSets, and SCPs to configure accounts, triggered by Control Tower lifecycle events such as CreateManagedAccount. It is the low-overhead choice for automating post-Account-Factory setup without Terraform.
Trap Reaching for Account Factory for Terraform (AFT) when no Terraform is wanted: AFT is the Terraform/GitOps path, while CfCT is the CloudFormation-native one.
- AFT provisions and customizes Control Tower accounts through a Terraform GitOps pipeline
Account Factory for Terraform (AFT) runs from a dedicated AFT management account and provisions Control Tower accounts from account-request Terraform files in a repo (GitOps). After provisioning it applies aft-global-customizations to every account and aft-account-customizations to accounts whose request names a matching customization; failures surface on the aft-failure-notifications SNS topic.
3 questions test this
- A large enterprise is standardizing on AWS Control Tower to manage their multi-account environment. The infrastructure team uses Terraform…
- A company is deploying AWS Control Tower Account Factory for Terraform (AFT) and needs to understand the repository structure for…
- A multinational corporation is implementing AWS Control Tower with Account Factory to establish governance across their organization. The…
- Enroll existing accounts into Control Tower with the Enroll account action
Pre-existing accounts join Control Tower governance through the Enroll account action in Account Factory, which deploys the baseline (Config, CloudTrail, Identity Center access, SCPs) into a registered OU. Each account must already have the AWSControlTowerExecution role trusting the management account, and any existing Config recorder and delivery channel must be removed first because Control Tower creates its own.
- Fix Control Tower drift by moving the account back and running Reset
Control Tower reports drift when its managed resources change outside Control Tower, such as an account moved between OUs through Organizations or a Control-Tower SCP edited by hand. The remediation is to move the account back to its registered OU through Control Tower and run the Reset action to re-apply the baseline and SCPs.
Trap Editing the drifted SCP or OU directly in Organizations to undo it: changes made outside Control Tower keep the landing zone in drift instead of clearing it.
- SAML authenticates users but SCIM is what provisions them into Identity Center
With an external IdP, SAML 2.0 only handles sign-in; new users and groups appear in IAM Identity Center only when SCIM v2.0 automatic provisioning is configured. Identity Center rejects multivalue attributes over SCIM, so each attribute such as email or phone must map to a single value or the sync fails.
Trap Assuming working SAML federation also creates accounts: without SCIM, newly added IdP users never provision and cannot access AWS.
3 questions test this
- A company is migrating from a legacy identity management solution to AWS IAM Identity Center with Okta as an external identity provider.…
- A multinational company uses AWS Organizations to manage over 200 AWS accounts. The company has Okta as its corporate identity provider and…
- A company has configured AWS IAM Identity Center with Microsoft Entra ID (Azure AD) as the external identity provider using SAML 2.0…
- The Identity Center SCIM access token lasts one year with rotation reminders
A SCIM access token generated in IAM Identity Center is valid for one year. When it is within 90 days of expiry, AWS posts reminders in the Identity Center console and the AWS Health Dashboard so you can rotate it; if it expires, provisioning synchronization stops.
- Identity Center has two separate session durations: portal and permission set
The AWS access portal session duration (set in Identity Center settings, up to 90 days) controls how long a user stays signed in to the portal, while each permission set's session duration (1 to 12 hours) caps a console/role session inside an account. Set them independently to allow a long portal sign-in but short account sessions.
- Pin accounts in the org by denying LeaveOrganization at the Root
A guardrail that keeps member accounts from detaching or disabling service integration is an SCP that denies organizations:LeaveOrganization (and organizations:DisableAWSServiceAccess) attached to the Root, where it inherits to all current and future accounts. Because a deny in SCPs is inherited by everything beneath the attach point, attaching it one OU too high blocks sibling OUs you meant to leave alone.
Trap Attaching a targeted deny to a parent OU instead of the intended child OU: the deny flows down to every child OU and account, not just the one you wanted to restrict.
- Exempt one role from an SCP deny with an ArnNotLike PrincipalArn condition
To let a specific role (for example a SecurityAuditRole) keep performing actions an SCP otherwise denies org-wide, add a condition to the Deny statement using ArnNotLike on aws:PrincipalArn for that role's ARN, so the deny applies to everyone except the excluded principal.