Permissions Boundaries, Delegated Administration, and Least Privilege at Scale

Why "AdministratorAccess in the member account" is not a scale strategy

After you federate humans and you can AssumeRole across accounts, SAP-C02 still asks who is allowed to create the next IAM user or role. If application developers in a NonProd account hold unbounded iam:*, they can create a user with a full AdministratorAccess policy, mint access keys, and walk around every permission set you designed in IAM Identity Center. Permissions boundaries exist so you can delegate IAM administration inside an account without handing over the account. Service control policies (SCPs) exist so the organization can cap every principal in a member account, including those developers and including a delegated administrator account. They solve different problems. Independent OpenExamPrep teaching treats them as stacked guardrails, not synonyms.

How the evaluation stack actually works

AWS documents that a request affected by an identity-based policy, a permissions boundary, and an SCP is allowed only if all three allow it. Session policies join that intersection when the caller is a role session. An explicit deny in any of those documents wins. None of SCPs, permissions boundaries, or resource control policies (RCPs) grant access. Someone still has to attach an identity policy or a resource policy that allows the action.

SCPs do not affect the management account. They do affect member accounts that you register as delegated administrators. That is why a Security Tooling delegated admin is still inside the Security OU's SCPs. If you need a permission that the Security OU SCP denies, you change the SCP or you do that rare task in the management account — you do not "override" the SCP with a wider identity policy.

Permissions boundaries for developers who must not create unbounded IAM users

A permissions boundary is a managed policy that you attach to a user or role with iam:PutUserPermissionsBoundary / iam:PutRolePermissionsBoundary. It does not, by itself, allow s3:PutObject. If the boundary allows s3:* and ec2:* but not iam:CreateUser, then even an identity policy that allows iam:CreateUser fails. AWS's own Shirley example is exactly that: an identity policy allowing iam:CreateUser is useless until the boundary also allows it.

The delegation pattern Northwind needs in NonProd is the Zhang/María pattern from the IAM User Guide, applied to federated developer roles rather than long-lived IAM users:

1. Create a customer managed policy NorthwindDevBoundary that allows the services developers may ever use (Amazon S3, Amazon EC2, Amazon CloudWatch, AWS Lambda, Amazon DynamoDB, and tightly scoped IAM self-service) and that explicitly denies high-risk resources if needed.
2. Put that policy on the developer permission set as the permissions boundary Identity Center provisions onto the member-account role.
3. If developers must create application roles or, in a legacy corner, IAM users, allow iam:CreateRole / iam:CreateUser (and attach/put policy APIs) only with "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT:policy/NorthwindDevBoundary" }.
4. Deny iam:DeleteUserPermissionsBoundary and iam:DeleteRolePermissionsBoundary, and deny iam:CreatePolicyVersion on the boundary policy itself so nobody edits the cap.

If a developer skips the boundary in the console, CreateUser fails. That is the feature, not a misconfiguration. New identities they do create inherit the same cap, so they cannot mint a sibling AdministratorAccess user. You can still attach IAMFullAccess as an identity policy to a delegated admin; the boundary is what makes that attachment safe.

Two Professional nuances from AWS's boundary evaluation notes:

• You cannot apply a permissions boundary to a service-linked role.
• Implicit denies in a boundary do not always stop a same-account resource-based allow. AWS's Secrets Manager example: if a secret resource policy allows secretsmanager:GetSecretValue for Nikhil, and the boundary does not mention Secrets Manager (implicit deny) and does not explicitly deny it, Nikhil can still read the secret. An explicit deny in the boundary on that secret still wins. If the exam stem hinges on a secret or bucket policy that names the user, do not claim the boundary silently erases every resource policy.

Also avoid NotPrincipal with Deny on resource policies for principals that have boundaries; AWS warns that combination denies those principals unexpectedly. Use ArnNotEquals on aws:PrincipalArn instead.

SCPs versus boundaries versus Identity Center permission sets

Teams mix these three because all of them contain JSON and the word "allow." Keep the jobs separate:

• SCP: "No principal in the Prod OU can call iam:CreateUser or disable CloudTrail," including Identity Center roles and delegated admins in that OU. The management account is out of scope.
• Permissions boundary: "This developer role, in this account, cannot exceed S3/Lambda even if someone attaches AdministratorAccess."
• Permission set: "When Mira signs in through the access portal to NonProd, she gets the developer role (with that boundary) and not the security-audit role."

A common wrong answer is "attach an SCP that allows iam:CreateUser so developers can create users." SCPs never grant. Another is "the boundary replaces the SCP." A developer with a wide boundary still cannot perform an action the Prod OU SCP denies.

Delegated administration and the Security OU

IAM Identity Center's organization instance always resides in the management account. Delegated administration registers one member account whose users can perform most Identity Center administrative tasks: assigning users and groups to applications and to member accounts, managing permission sets for those accounts. Benefits AWS documents: fewer people need management-account access, and identity work can live with the Security OU.

Constraints you should be ready to use in a scenario:

• The delegated administrator cannot alter permission sets provisioned in the management account. Use dedicated permission sets for management-account access, and change them only from the management account.
• Assign users, not groups, to management-account permission sets. Group membership is often controlled by an IdP administrator who is not your AWS break-glass process. Anyone who can edit that group can add themselves to the most privileged account in the organization.
• If Active Directory is the identity source, locate the directory in the delegated administrator member account. The delegated admin cannot complete an AD source that lives only in the management account.
• Limit Identity Store write APIs and sso-directory:CreateBearerToken from the delegated account with an SCP when an external IdP is the source of truth, so a local admin cannot mint SCIM tokens or rewrite group membership.

Other security services (IAM Access Analyzer, GuardDuty, Security Hub, AWS Config aggregators) have their own delegated administrator registrations. Putting those in the same Security Tooling account is the usual Security OU shape. That does not move Organizations itself, and it does not make SCPs apply to the management account.

Break-glass when the IdP is dark

AWS lists emergency access as a remaining reason to have IAM users: you cannot reach the identity provider and you must still act. Professional design is a tiny set of IAM users (or a dedicated break-glass account) with:

• Hardware or otherwise tightly controlled MFA.
• Credentials in a physical or offline vault, not in the same IdP that just failed.
• Identity policies that are enough to restore federation (Identity Center, DNS, the IdP's AWS integrations) and not enough to be a standing AdministratorAccess lifestyle.
• SCPs that still apply if the user is in a member account; if break-glass must bypass a workload-OU SCP, the user lives in an account those SCPs do not crush — which is why some programs keep break-glass in a dedicated account with a narrower SCP, not in Prod.
• Logging: CloudTrail organization trail already writing to Log Archive, so the emergency session is reviewable.

Break-glass IAM users are not an excuse to create IAM users for the 3,000-person workforce. When Entra ID is healthy, those humans still come through IAM Identity Center.

IAM Access Analyzer: unused access and external access

IAM Access Analyzer is how you prove the story after you ship boundaries and resource policies.

External access analyzers use logic-based reasoning on resource-based policies. You pick a zone of trust: one account, or the whole organization. Findings appear when a supported resource is shared with a principal outside that zone — another account, a federated principal, or anonymous. Supported types include S3 buckets and directory buckets, IAM roles (trust policies), KMS keys, Lambda functions and layers, SQS, Secrets Manager secrets, SNS, EBS/RDS snapshots, ECR, EFS, and DynamoDB tables and streams. External analyzers are Regional: enable them in each Region where you have those resources. After the first pass, new or changed policies are typically analyzed within about 30 minutes; some S3 multi-Region access point changes can take up to six hours; if a notification is missed, the next periodic scan is within 24 hours. You can rescan a finding with StartResourceScan. Previewing a policy before you attach it is the way to see public or cross-account access before production.

Unused access analyzers continuously watch IAM users and roles for unused roles, unused user passwords, unused access keys, and unused services and actions (via last-accessed information). Findings are not Region-scoped the way S3 external findings are; you do not need one unused analyzer per Region for the same account set. Service-linked roles are not analyzed for unused access and are not included in the billed role count. Unused analysis is charged per analyzer per month based on users and roles analyzed — create them with intent, not once per Region by habit.

Internal access analyzers (separate) tell you which principals inside the zone can reach selected business-critical resources. Policy validation and custom policy checks catch grammar and "does this grant new access?" problems while you edit JSON. Policy generation from CloudTrail can draft a tighter identity policy from what a role actually called — useful after a messy AdministratorAccess era, not a substitute for a boundary on day one.

Register Access Analyzer's delegated administrator in Security Tooling so Security OU staff review findings without living in the management account. Pair external findings with the KMS and Secrets resource policies from the previous section: a secret that names a vendor role you forgot is exactly an external-access finding.

Enterprise scenario: bounded developers in NonProd

Northwind's NonProd OU has an SCP that denies iam:CreateUser except on a path used by a small identity-automation role. Application developers federate with the AppDeveloper permission set. That permission set attaches NorthwindDevBoundary as a permissions boundary and allows iam:CreateRole only when the new role also receives NorthwindDevBoundary. Developers can ship a Lambda execution role. They cannot create an IAM user with AdministratorAccess and no boundary; CreateUser fails both the SCP and the iam:PermissionsBoundary condition. Identity engineers work in Security Tooling as Identity Center delegated administrators. Management-account access is a dedicated permission set assigned to two named humans, not to the aws-platform-admins Entra group. Break-glass IAM users with MFA sit in a vault for IdP outages. An organization-zone external access analyzer in every active Region watches the Log Archive bucket and Security Tooling keys; a single unused access analyzer flags roles nobody assumed in the configured window.

Exam traps: using an SCP to grant CreateUser; attaching a permissions boundary to a service-linked role; assuming SCPs apply to the management account; letting a delegated admin edit management-account permission sets; assigning an Entra group to management-account AdministratorAccess; treating Cognito as break-glass; expecting one external analyzer in us-east-1 to see eu-west-1 bucket policies; deleting AWSServiceRoleForSSO because unused access did not flag it.