IAM Permission Boundaries & STS
Recap: From Federated Identity to Federated Authorization
Day 4 established that IAM Identity Center replaces long-lived per-account IAM users with permission sets mapped to SAML federation from an external IdP such as Entra ID or Okta, auto-provisioning an IAM role into each assigned account. That solved the identity half of the problem: who a human is, and how they prove it once instead of forty times. It did not solve the authorization half. A permission set still resolves to an IAM role with attached policies, and those policies are still written by humans who occasionally write them too broadly.
Today extends that thread rather than replacing it. Federation answers "which role does this person get in this account"; permission boundaries answer "what is the worst thing that role could ever do, regardless of what someone attaches to it later." The two compose: an Identity Center permission set can carry a boundary, and the roles that permission set is allowed to create can be forced to carry one too. The same short-lived credential machinery that makes federation work — STS — is also what makes cross-account and workload identity work, which is why the two topics sit on the same day.
Foundations You'll Need Today
Today's material sits on top of a handful of IAM ideas that the rest of this curriculum treats as already known. If you have not spent time in the IAM console, the words "policy," "role," and "trust policy" can blur together, and the day will read as a wall of jargon. Here is the grounding, in the order the day builds on it.
Policies: the rules that say what is allowed
Every action anyone takes in AWS — reading an object from a storage bucket, starting a server, creating a user — is checked against a set of rules before it is allowed to happen. Those rules are written as JSON documents called policies, and each policy is essentially a list of statements saying "this action on this resource is allowed" or "this action on this resource is denied." The important part for today is how the rules combine. AWS starts from a default of deny everything, then looks for an explicit allow. If it finds one, the action is permitted — unless some other applicable policy contains an explicit deny, in which case the deny wins no matter how many allows exist. That "deny beats allow, and silence means deny" behavior is the foundation every other control in this day is built on.
Users, roles, and why roles are the modern default
An IAM user is a permanent identity with a name and, usually, a long-lived password or access key that does not expire on its own. An IAM role is different: it is an identity that nobody logs into directly. Instead, a role is something a person or a program temporarily becomes, and while they are wearing it they get whatever permissions the role carries. The advantage is that the credentials handed out for a role expire automatically after a set period, so a leaked credential is only useful for a short window rather than forever. This is why the rest of the curriculum keeps steering you away from creating IAM users for workloads and toward roles instead.
Trust policies: who is allowed to become the role
A role has two separate sets of rules attached to it, and confusing them is the single most common source of IAM mistakes. The first is the trust policy, which answers "who is allowed to assume this role in the first place?" The second is the permission policy, which answers "once someone has assumed it, what are they allowed to do?" A role that grants access to a database but whose trust policy names the wrong account is useless, because nobody who needs it can get in. A role whose trust policy is wide open but whose permission policy is narrow is a different kind of problem: too many people can get in, but they cannot do much once they are there. Today's material cares about both, because a delegation model has to get the "who" and the "what" right at the same time.
STS: the service that hands out temporary credentials
When someone assumes a role, something has to actually issue the temporary credentials they will use. That something is AWS Security Token Service, usually shortened to STS. You will see it referenced through API calls that all start with "AssumeRole" — the exact variant depends on how the caller proved who they were, whether that was a normal AWS identity, a corporate login system, or a Kubernetes cluster. The credentials STS returns come with an expiry time baked in, which is what makes the whole role model safer than long-lived keys. Today's scenarios lean on STS constantly, because almost every cross-account or workload-identity pattern on the exam is really a question about which AssumeRole variant applies.
Permission boundaries: a ceiling, not a grant
The last idea is the one this day is named after. A permission boundary is a policy you attach to a user or role that sets the maximum it could ever be allowed to do, no matter what other policies get attached to it later. The mental image worth holding onto is a ceiling above a floor: the ordinary permission policies decide what the entity is allowed to do, and the boundary decides the highest it can ever reach. A boundary can only ever take permissions away, never add them, so attaching one to a role that has no permissions at all does not magically give it any. That asymmetry — boundaries restrict but never grant — is the detail the exam returns to again and again.
With that grounding, here is why permission boundaries and STS exist as a pair, and what problem they actually solve.
1. Why This Is on the Exam
Permission boundaries exist because of a specific organizational shape that shows up constantly in SAP-C02 scenarios: a central platform or security team that wants to delegate IAM administration to application teams without handing over the ability to escalate to full account control. The naive answer — give the app team an IAM policy that allows iam:CreateRole and hope they write good policies — fails the moment someone creates a role with AdministratorAccess attached. The exam tests whether you know the mechanism that makes delegation safe rather than merely discouraged.
This maps most directly to Domain 1 (Design Solutions for Organizational Complexity), specifically the task statements around designing a multi-account strategy and applying least-privilege access controls across accounts. It also bleeds into Domain 2 whenever a scenario involves a workload assuming a role to reach another account's resources, because the same STS primitives are in play. The recurring exam pattern is a scenario that describes a delegated administrator, a CI/CD pipeline that creates roles, or a third-party SaaS integration, and asks which control prevents privilege escalation. The distractor set is usually populated with things that sound like controls but are not: MFA enforcement, CloudTrail alerting, SCPs applied to the wrong account, or a Deny statement that has to be maintained on every future role.
STS shows up for a different reason. Almost every cross-account and workload-identity pattern on the exam resolves to a call to one of the AssumeRole* APIs, and the exam expects you to know which variant applies to which trust relationship. A Lambda function in account A reading a bucket in account B uses AssumeRole. A Kubernetes pod using IRSA uses AssumeRoleWithWebIdentity. A human arriving through a corporate IdP uses AssumeRoleWithSAML. Getting the variant wrong is a common way to lose a question that otherwise looks straightforward.
What makes this topic worth a full day rather than a paragraph is that boundaries and STS are the two halves of the same story. Boundaries constrain what a role can do; STS is how the role is obtained in the first place. A scenario that asks you to design a safe delegation model usually requires both: a boundary that caps the delegated admin, and a trust policy that scopes who can assume the roles being created.
2. How Permission Boundaries Actually Evaluate
The single most useful mental model is that a permission boundary is not a grant and not a filter applied after the fact. It is a second policy that participates in the same evaluation as the identity-based policy, and the effective permission is the intersection of the two. For an action to be allowed, it must be allowed by an identity-based policy (or a resource-based policy, in the cases where those apply) and it must also be allowed by the boundary. If either side is silent, the action is denied. If either side contains an explicit Deny, the action is denied regardless of what the other side says.
That intersection behavior is what makes boundaries useful for delegation. A delegated admin can attach AdministratorAccess to a role they create, and the role will still be unable to do anything the boundary does not permit. The boundary is the ceiling; the attached policy is the floor. The role's actual capability lives somewhere between them, and the boundary is the part the delegator controls. This is why the pattern is sometimes described as "you can hand out any policy you like, because I decide the maximum."
There is an important asymmetry to internalize: a boundary can only ever reduce permissions, never add them. If a role has no identity-based policy granting s3:GetObject, adding a boundary that allows s3:GetObject does not grant it. This trips people up because the boundary looks like a policy and is written in the same JSON, but it is evaluated as a constraint rather than a source of authority. The exam occasionally offers a distractor that treats a boundary as a grant, and the correct answer is always that it cannot be.
STS sits underneath all of this as the credential-issuing service. When a principal calls AssumeRole, STS evaluates the target role's trust policy to decide whether the caller is allowed to assume it, then returns a set of temporary credentials with a session duration and a session name. Those credentials are themselves subject to the role's identity policies and boundary — the boundary does not disappear because the caller arrived via STS. The trust policy and the boundary are separate controls answering separate questions: the trust policy answers "who may become this role," and the boundary answers "what may this role do once assumed."
Session policies add a third layer worth knowing about. When you call AssumeRole you can pass an inline session policy that further restricts the resulting session, and the effective permissions become the intersection of the role's identity policies, the boundary, and the session policy. This is how a single role can be safely shared by many callers with different needs — the role defines the maximum, and each caller narrows it further at assume time. For the exam, the key point is that session policies can only restrict, never expand, exactly like boundaries.
3. The Core Decision Boundary: Boundary vs. Trust Policy vs. SCP
Most scenario questions in this area hinge on which control is the right tool for the stated problem, and the three candidates are easy to conflate because they all look like "a policy that limits something." The fork is about scope and subject. An SCP applies to every principal in an account or OU and is enforced by AWS Organizations. A permission boundary applies to a single IAM user or role and travels with that entity. A trust policy applies to a single role and governs who may assume it, not what it may do afterward.
The practical test is to ask what the scenario is trying to constrain. If the requirement is "no one in this OU may use any region except two," that is an SCP, because it must apply to principals that do not exist yet. If the requirement is "this delegated admin may create roles, but none of those roles may ever touch IAM or Organizations," that is a boundary, because the constraint must attach to entities created in the future by a specific principal. If the requirement is "only this specific Lambda execution role may read this bucket," that is a trust policy plus a resource policy, because the question is about who, not what.
| Control | Applies to | Answers | Can it grant? | Typical exam trigger |
|---|---|---|---|---|
| SCP | All principals in an account/OU | What is the org-wide ceiling? | No | "Across all accounts in the OU" |
| Permission boundary | One IAM user or role | What is this entity's ceiling? | No | "Delegated admin creates roles" |
| Trust policy | One role | Who may assume this role? | Yes (it is the gate) | "Cross-account access" |
| Session policy | One STS session | What may this session do? | No | "Same role, narrower per caller" |
| Identity policy | One IAM user or role | What is this entity allowed? | Yes | "Attach a policy to the role" |
The second fork, once you have settled on a boundary, is whether the boundary is enforced by convention or by condition. A boundary that the delegated admin is merely asked to attach is not a control; it is a suggestion. The enforceable version adds a condition to the delegated admin's own policy requiring that iam:PermissionsBoundary be present and equal to a specific boundary ARN on every CreateRole and CreateUser call. Without that condition, the delegated admin can simply omit the boundary and create an unbounded role. This distinction between "we told them to" and "the API rejects the call otherwise" is exactly the kind of thing the exam probes.
4. Configuration Modes and Their Tradeoffs
There are three broad ways to structure delegated IAM administration, and they differ in how much trust they place in the delegate and how much maintenance they impose on the delegator. The first is no delegation at all: the central team creates every role, and application teams file tickets. This is the most controlled and the least scalable, and it is the correct answer only when the scenario explicitly says the organization is small or the roles are few. It fails the moment the scenario mentions dozens of teams or a self-service requirement.
The second is delegation with a mandatory boundary, which is the pattern this day is about. The central team publishes one or more boundary policies, grants application teams a role that can create IAM entities, and attaches a condition that forces the boundary onto everything they create. The tradeoff is that the boundary must be designed well enough to cover legitimate use cases without being so permissive that it defeats the purpose. A boundary that allows iam:* is not a boundary. A boundary that allows nothing but s3:* will break teams that need to create roles for Lambda, ECS, and Step Functions. Getting this right is a design exercise, not a checkbox.
The third is delegation through a pipeline or IaC tool rather than through human IAM permissions. Instead of granting humans iam:CreateRole, you grant a CI/CD role the ability to deploy CloudFormation or Terraform that creates roles, and the templates themselves carry the boundary. This shifts the control from an IAM condition to a code review process. It is often the better answer in mature organizations because the boundary becomes visible in the template and reviewable in a pull request, but it requires the scenario to mention an existing pipeline or IaC practice. If the scenario describes humans clicking in the console, the condition-based approach is the answer.
Within the boundary itself there are two design styles worth distinguishing. A permissive boundary lists the services the delegate is allowed to touch and denies everything else implicitly by omission. A restrictive boundary starts from a broad allow and adds explicit Deny statements for the dangerous actions — iam:*, organizations:*, account:*, and anything that could be used to remove the boundary itself. The restrictive style is easier to maintain because new AWS services are allowed by default, but it is riskier because a new service that grants indirect privilege escalation will be allowed until someone notices. The permissive style is safer but requires updating every time a team adopts a new service. Most exam scenarios that describe a security-conscious organization are pointing at the restrictive style with explicit denies on IAM and Organizations.
5. Sizing, Limits and Quotas
The numbers that matter here are mostly about how many policies and how much policy text you can attach, because boundaries consume the same quotas as ordinary managed policies. An IAM user or role can have a limited number of managed policies attached, and a permission boundary counts as one of them even though it is set through a separate API parameter. That means adding a boundary to a role that already has the maximum number of attached policies will fail, which is a real operational trap when retrofitting boundaries onto existing roles.
Managed policy size is capped, and the boundary is a managed policy, so a boundary that tries to enumerate every allowed action across every service will hit the limit. This is the practical argument for the restrictive style described above: a boundary that denies a short list of dangerous actions is far smaller than one that allows a long list of safe ones. Inline policies have their own separate size limit, and session policies passed to STS are also size-limited, which matters when you are trying to narrow a session at assume time.
| Item | Practical constraint | Why it bites |
|---|---|---|
| Managed policies per role | Small fixed count | Boundary consumes a slot; retrofits fail on already-full roles |
| Managed policy size | Fixed character limit | Favors deny-list boundaries over allow-list boundaries |
| Inline policy size | Separate, smaller limit | Session policies and inline grants compete for the same budget |
| STS session duration | Bounded by role max session duration | Long-running jobs need a refresh strategy, not a longer session |
| Role trust policy size | Same policy size limit | Many principals in one trust policy eventually needs conditions instead |
Session duration deserves its own note because it is a frequent source of production incidents. Temporary credentials expire, and when they do, every call made with them fails with an expired-token error. The maximum session duration is a property of the role, and the caller can request anything up to that maximum. A workload that runs longer than the maximum must refresh its credentials before expiry, which is why the AWS SDKs and the instance metadata service handle refresh automatically for the common cases. Hand-rolled credential caching that ignores expiry is a classic cause of intermittent, hard-to-reproduce failures.
Finally, there is a quota dimension that is easy to miss: the number of roles and policies in an account is bounded, and a delegation model that creates a new role per team per environment per service will consume that budget faster than expected. Boundaries do not change this, but they do make it safe to let teams create their own roles, which accelerates the consumption. Organizations that delegate IAM creation usually pair it with a naming convention and a periodic cleanup job for orphaned roles.
6. Failure Modes and What They Look Like in Production
The most common failure is the silent one: a boundary was supposed to be attached and was not, because the condition enforcing it was written incorrectly or omitted. The symptom is not an error — it is that everything works, including the thing that was supposed to be blocked. This is why the enforcement condition deserves a test: create a role without the boundary using the delegated admin credentials and confirm the call is rejected. If it succeeds, the control is decorative.
The second failure is the opposite: a boundary that is too tight and breaks legitimate workloads in ways that are hard to diagnose. The error surface is an AccessDenied on an action the team believes they have permission for, because their identity policy allows it and the boundary does not. The diagnostic move is to check the boundary first, not the identity policy, because teams almost always look at the policy they wrote and forget the ceiling above it. CloudTrail records the denied call with the principal and action, and the IAM policy simulator can show which policy in the chain produced the deny.
The third failure is credential expiry in a long-running process. The symptom is a burst of failures at a regular interval — often exactly the session duration — followed by recovery if the process retries with fresh credentials, or permanent failure if it cached them. The first diagnostic move is to check whether the failing calls cluster around a fixed period after the process started. If they do, it is expiry, not permissions.
The fourth failure is a trust policy that is too broad. A role whose trust policy allows an entire account, or worse, uses a wildcard principal, can be assumed by any principal in that account that has sts:AssumeRole permission. This is not a boundary problem, but it is the same class of problem: a control that was meant to be narrow and is not. The symptom is unexpected principals appearing in CloudTrail as having assumed the role, which is exactly what you would alert on.
The fifth failure is the confused deputy, where a service is tricked into acting on behalf of a principal it should not. The standard mitigation is an external ID in the trust policy for third-party access, and source-account or source-ARN conditions for service principals. A scenario that describes a SaaS vendor assuming a role in your account without an external ID is describing this failure mode, and the fix is in the trust policy, not the boundary.
7. Operational and SRE Angle
From an operations perspective, the interesting property of boundaries and STS is that they change the shape of your alerts. A boundary violation is not a performance signal; it is a security signal, and it belongs in a different alerting path than latency or error rate. The practical approach is to route AccessDenied events that originate from a boundary rather than an identity policy into a security channel, because they usually indicate either a misconfigured workload or someone probing for permissions they do not have. Both are worth a human look, but neither should page the on-call engineer at 3 a.m.
Credential expiry, by contrast, is an availability concern and belongs in the normal SRE tooling. The metric to watch is the rate of ExpiredToken errors, which should be zero in a healthy system because the SDKs refresh automatically. A non-zero rate means something is caching credentials by hand, and the fix is to remove the custom caching rather than to lengthen the session. This is a good example of an SLO implication that is easy to miss: a workload can be perfectly healthy from a latency standpoint and still be one expiry cycle away from a partial outage.
The runbook shape for a suspected boundary problem is short and worth writing down before you need it. First, identify the principal from the CloudTrail event. Second, list the identity policies attached to it and the boundary attached to it. Third, compare the denied action against both. Fourth, if the action is legitimately needed, decide whether the fix belongs in the identity policy (the team's own policy was incomplete) or in the boundary (the boundary is too tight for a legitimate use case). That last decision is a governance decision, not an operational one, and it should route to whoever owns the boundary rather than being fixed ad hoc by the on-call engineer.
There is also a change-management angle. Boundaries are shared infrastructure: one boundary policy may be attached to hundreds of roles across an organization. Editing it is a high-blast-radius change, and it should go through the same review as an SCP change. A useful practice is to version boundaries and roll changes out to a non-production OU first, because a boundary that accidentally denies a commonly used action will break every role that carries it simultaneously.
8. Edge Cases and Exam Gotchas
The first gotcha is that a boundary cannot grant permissions. Any answer option that describes a boundary as a way to give a role access is wrong, no matter how plausible the surrounding scenario sounds. The boundary is a ceiling, and ceilings do not lift floors.
The second is that boundaries do not apply to resource-based policies in the way people expect. A role with a restrictive boundary can still be granted access by a resource policy on an S3 bucket or a KMS key, because resource-based policies are evaluated on the resource side and the boundary constrains the principal's identity-based permissions. This is a subtle point and it is exactly the kind of thing a hard exam question is built on. If the scenario requires that a principal be unable to access a resource even when the resource policy allows it, the boundary alone may not be sufficient.
The third is that the management account of an AWS Organization is not subject to SCPs, which means an SCP-based control cannot be used to constrain it. If a scenario asks how to limit what a principal in the management account can do, the answer is a boundary or an identity policy, not an SCP. This connects back to Day 1's point about keeping the management account workload-free.
The fourth is the difference between AssumeRole and AssumeRoleWithWebIdentity. The former is for AWS principals and federated users who have already been authenticated by STS; the latter is for OIDC tokens from an external identity provider, which is what IRSA uses. A scenario describing a Kubernetes service account that needs S3 access is describing IRSA, and the answer involves an OIDC provider registered with IAM and a trust policy with a sub condition on the service account.
The fifth is that a boundary attached to a role does not automatically apply to roles that role creates. The boundary is a property of the entity, not a heritable trait. If you want created roles to carry a boundary, you must enforce it with a condition on the creating principal's policy. This is the single most commonly missed detail in this topic.
The sixth is that session policies and boundaries stack. If a role has a boundary and the caller passes a session policy, the effective permissions are the intersection of all three. An exam question that describes a caller who "narrowed" their session and still cannot perform an action is usually testing whether you know that narrowing can only reduce, never restore, permissions the boundary removed.
9. This vs. the Controls It Gets Confused With
The comparison that matters most is boundary versus SCP, because both are ceilings and both are written as JSON policies. The difference is scope and enforcement point. An SCP is enforced by Organizations at the account boundary and applies to every principal in the account, including principals that do not exist yet. A permission boundary is enforced by IAM at the principal level and applies only to the entity it is attached to. If the requirement is org-wide, use an SCP. If the requirement is per-principal and must survive delegation, use a boundary. If the requirement is both, use both — they compose without conflict, and the effective permission is the intersection of all applicable ceilings.
| Requirement | Pick | Why not the other |
|---|---|---|
| Cap every account in an OU to two regions | SCP | A boundary would have to be attached to every principal individually |
| Let a team create roles but never with IAM access | Boundary + enforcement condition | An SCP would also constrain the team's own role, which is broader than needed |
| Allow a specific external account to read one bucket | Bucket policy + trust policy | Neither a boundary nor an SCP expresses "who" |
| Give one role different effective permissions per caller | Session policy at assume time | A boundary is fixed per role and cannot vary by caller |
| Prevent a compromised workload from touching IAM | Boundary on the workload role | An SCP would affect unrelated principals in the same account |
The second comparison is boundary versus identity policy, which is really a question of ownership. The identity policy is written by whoever owns the workload and expresses what the workload needs. The boundary is written by whoever owns the security posture and expresses what no workload should ever be able to do. Keeping those two authorship roles separate is the entire point of the mechanism, and a scenario that describes a central team trying to control application teams' blast radius without reviewing every policy they write is describing exactly this split.
The third comparison is STS versus long-lived IAM users, which is less a choice than a default. Temporary credentials from STS are the recommended mechanism for anything that can use them, and long-lived access keys are the fallback for the shrinking set of cases that cannot. A scenario that offers "create an IAM user with an access key" as an option for a workload is almost always offering a distractor, and the correct answer is a role assumed via STS.
Hands-on Lab: A Delegated Admin That Cannot Escalate
The goal is to build a delegated IAM administrator whose ability to create roles is real but bounded, and then to prove the bound holds by attempting the escalation it is supposed to prevent. Work in a sandbox account, not a production one, because the lab deliberately creates a principal with iam:CreateRole.
1. Write the boundary policy. Create a customer-managed policy named DeveloperBoundary. Start from a statement that allows a broad set of services the teams legitimately need — s3:*, dynamodb:*, lambda:*, logs:*, ec2:Describe* — and then add explicit Deny statements for iam:*, organizations:*, account:*, and cloudtrail:DeleteTrail. The denies are the important part; the allows exist so the boundary does not break ordinary workloads. Note the policy ARN, because the next step references it.
2. Create the delegated admin role. Create a role named DelegatedIamAdmin with a trust policy that allows your own account to assume it. Attach an identity policy that grants iam:CreateRole, iam:AttachRolePolicy, iam:PutRolePolicy, iam:PassRole, and iam:ListRoles. Do not attach the boundary to this role — the delegated admin is not the entity being bounded; the roles it creates are.
3. Add the enforcement condition. Edit the delegated admin's identity policy so that the iam:CreateRole statement carries a condition requiring iam:PermissionsBoundary to equal the ARN of DeveloperBoundary. The condition key is iam:PermissionsBoundary and the operator is StringEquals. This is the step that turns the boundary from a convention into a control.
4. Prove the control works. Assume DelegatedIamAdmin and attempt to create a role without specifying a permissions boundary. The call should fail with an AccessDenied that names the condition. Then create the same role with the boundary ARN supplied, and confirm it succeeds.
5. Prove the boundary holds. Attach AdministratorAccess to the role you just created, then assume it and attempt iam:CreateUser. It should fail, because the boundary denies iam:* even though the attached policy allows it. This is the demonstration that the delegation is safe: the delegate can hand out any policy they like, and the ceiling still holds.
6. Test the session-policy layer. Assume the bounded role again, this time passing an inline session policy that denies s3:DeleteObject. Confirm that an S3 delete fails, then confirm that removing the session policy does not restore any iam:* action — the boundary still applies. This makes the intersection behavior concrete.
7. Clean up and record. Delete the created role, the delegated admin role, and the boundary policy. Write down the two ARNs and the condition key you used, because the exam expects you to recognize this pattern from a scenario description rather than from the JSON.
Scenario Question Drills
Q1. A delegated admin role can create IAM roles for developers. How do you prevent them from creating a role with AdministratorAccess?
Q2. A role has a permission boundary that allows only s3:* and dynamodb:*. Its identity policy grants AdministratorAccess. What can the role actually do?
Q3. A security team wants to guarantee that no principal in an entire OU can disable CloudTrail, including principals created next month. What should they use?
Q4. A Kubernetes pod running on EKS needs to read from an S3 bucket without any long-lived credentials stored in the cluster. Which STS API and configuration applies?
Q5. A team attaches a permission boundary that allows s3:GetObject to a role that has no identity policy at all. What happens when the role calls GetObject?
Q6. A third-party SaaS vendor needs to assume a role in your account to read a specific S3 prefix. What should the trust policy include to prevent the confused deputy problem?
Q7. A long-running batch job that assumes a role starts failing every hour with ExpiredToken errors, then recovers on retry. What is the most likely cause?
Q8. A role has a permission boundary denying iam:*. A bucket policy grants that role s3:GetObject on a bucket in another account. Can the role read the object?
Q9. A platform team wants application teams to create their own IAM roles via a CI/CD pipeline, with the boundary enforced by the pipeline templates rather than by IAM conditions. What is the main tradeoff of this approach?
Q10. A role's trust policy allows an entire external AWS account to assume it. What is the risk, and what is the fix?
Q11. A role has a boundary allowing s3:* and an identity policy allowing s3:* and dynamodb:*. A caller assumes the role with a session policy allowing only s3:GetObject. What can the session do?
Q12. A security review finds that a delegated admin created a role without a permission boundary, even though the team's policy was supposed to require one. What is the most likely root cause?
Q13. Which statement about permission boundaries and SCPs is correct?
Q14. A workload in account A needs to read a DynamoDB table in account B. The table's resource policy grants the workload's role access. What else is required?
Q15. A team wants a single role that different callers can assume with different effective permissions, without creating a separate role per caller. What is the right mechanism?
Peek into Tomorrow
Everything today assumed the network already existed. Boundaries and STS decide who may act and what they may do, but they say nothing about where the resources being acted upon actually live, or who owns the VPC they sit in. That gap becomes concrete the moment an organization decides it wants one centrally managed network rather than a VPC per account, because the central network account then has to hand out pieces of its own infrastructure to accounts that do not own it.
The open question is how a central network account shares a subnet with an application account without giving that account control of the VPC, and without the two accounts needing to peer or merge route tables. The same question applies to a Transit Gateway that one account owns and many accounts attach to, and to Route 53 Resolver rules that need to be visible across the organization. Tomorrow's topic answers it with a sharing primitive that sits alongside the identity controls you built today — and the interesting part is how the shared resource's owner retains control while the consumer gets just enough access to launch into it.
Sources
- AWS IAM User Guide — Permissions boundaries for IAM entities
- AWS IAM User Guide — Policy evaluation logic
- AWS IAM User Guide — IAM roles terminology and concepts
- AWS IAM User Guide — Creating a role for OpenID Connect federation
- AWS STS API Reference
- AWS IAM User Guide — IAM and AWS STS quotas
- AWS IAM User Guide — The confused deputy problem
- Amazon EKS User Guide — IAM roles for service accounts
- AWS Well-Architected Framework — Security Pillar