Designing Secure Access: IAM Best Practices, Roles, and AWS Organizations

Every access design starts from the same baseline: harden the root user, require MFA for people, and grant only the permissions each identity needs. The root user of each account is hardened first: enable MFA on it, delete any root access keys, and stop using it for daily work — create a separate administrative identity (with its own MFA) for console and CLI administration. When a scenario mentions that administrators "sign in with the root user" or that "root access keys are embedded in a script," that detail is the vulnerability the question wants fixed, regardless of what else is going on.

Root exists for a short list of root-only tasks that no IAM policy can delegate, for example: changing the account's root email or password, closing the account, restoring permissions when the only IAM administrator has locked themselves out, and editing or deleting an S3 bucket policy (or SQS queue policy) that denies every principal. That last one matters in design questions: a bucket policy with an explicit deny for * also blocks every IAM administrator, and no larger IAM policy can out-allow it — only root can remove it.

Centralized root access for member accounts

In an AWS Organization, every member account historically had its own root password to vault and protect. Centralized root access management (an IAM feature, enabled from the management account or a delegated administrator with trusted access for IAM) lets you delete the root credentials of member accounts and stop new member accounts from getting them. When a root-only task is still needed — such as unlocking a bucket policy that denies everyone — an authorized principal in the management account or the delegated administrator account calls sts:AssumeRoot with a narrowly scoped task policy (for example S3UnlockBucketPolicy) and gets a short-lived root session in that one member account for that one task. That is stronger and far less work than keeping dozens of root passwords and MFA devices.

MFA: registered is not the same as enforced

For human IAM identities the baseline is MFA everywhere — but a registered MFA device only protects you if a policy requires it. The IAM password policy has no MFA setting; MFA is enforced through the global condition key aws:MultiFactorAuthPresent in the policy that authorizes the action:

• For role assumption, put the condition in the role's trust policy (allow sts:AssumeRole only when aws:MultiFactorAuthPresent is true). That is where "who may assume this role, and how" is decided.
• For a "deny unless MFA" statement, use BoolIfExists, not Bool. Requests signed with a user's long-term access keys carry no aws:MultiFactorAuthPresent key at all. With Bool and "false", a missing key does not match, so the deny never applies and the CLI call gets through; BoolIfExists treats the missing key as a match and denies it.
• For "recent MFA", use aws:MultiFactorAuthAge, the number of seconds since the MFA sign-in, with NumericLessThan (for example 3600 for "within the last hour"). Present answers whether MFA happened; Age answers how long ago.

Least privilege and the shared responsibility line

Least privilege at Associate level is a design discipline: scope policies to the specific actions, resources and conditions a workload needs. An application that reads one DynamoDB table gets dynamodb:GetItem on that table's ARN, not dynamodb:* on *. Broad grants such as AdministratorAccess or wildcard resources are almost always the marker of a wrong answer when a tighter option exists; the tooling for getting there is covered below.

Under the shared responsibility model, AWS operates IAM, STS and Organizations as services, but every identity you create, every policy you write, MFA enforcement, offboarding leavers and every trust relationship are the customer's side of the line. The same holds for leaked credentials: if an access key is exposed publicly, AWS may notify you and attach an AWS managed quarantine policy that blocks some high-risk actions, but deactivating and deleting the key, giving the application credentials that are not in source code, and reviewing AWS CloudTrail for what the key did (and undoing it) remain your job. The quarantine policy is a safety net, not a remediation.

A flexible authorization model gives permissions to groups and roles, uses customer managed policies for anything you need to reuse and control, and keeps individual users free of directly attached policies. Attaching policies user-by-user is an operational-overhead trap: put users with the same job into a group (developers, testers, auditors), attach the policy to the group, and change access in one place when the job changes.

Policies come in three kinds, and questions hinge on their differences:

So "the same permissions on several roles, editable by us, with the ability to roll back a bad change" is a customer managed policy using its versions; inline copies would have to be edited role by role, and an AWS managed policy cannot be changed at all.

Two structural facts complete the model. An IAM group is not a principal: you cannot name a group in a role's trust policy or a resource-based policy. To let a group assume a role, set the role's trust policy to trust the account (the account ARN as principal), then attach a policy to the group that allows sts:AssumeRole on that role's ARN — members gain the right through the group. And roles, not users, are the unit of elevated access: a modest daily identity plus a role to switch into beats standing administrator rights (see role switching below).

You cannot design layered access controls without an intuition for how AWS evaluates a request. The logic you need for the exam compresses to three rules. First, everything is implicitly denied by default — a request is only allowed if some applicable policy explicitly allows it. Second, an explicit deny overrides every allow, no matter where the allow lives. Third, when multiple guardrail layers apply — SCPs, permissions boundaries, session policies — the effective permissions are the intersection: an action must be allowed at every applicable layer to succeed.

Within a single account, identity-based policies (attached to users, groups, roles) and resource-based policies (attached to resources like S3 buckets, SQS queues, KMS keys, Lambda functions) are evaluated together as a union: an allow in either is enough, provided nothing denies it. This is why a bucket policy can grant access to a principal whose identity policy says nothing about S3 — and why an explicit deny in a bucket policy blocks even an account administrator. Across accounts the rule tightens: both sides must agree, which the next sections build on.

A permissions boundary is a managed policy attached to a user or role (never a group) that sets the maximum permissions that identity can have. Like an SCP, a boundary never grants anything — the effective permissions are the intersection of the boundary and the identity policies. A boundary also governs only what the identity's sessions can do; it does not decide who may assume a role. A requirement such as "only MFA-authenticated users may assume this role" belongs in the role's trust policy, not in its boundary.

The classic use case is delegated role creation: developers may create IAM roles for their applications, but cannot use that right to escalate their own privileges. A boundary only works if it is enforced, which takes three statements in the developers' policy:

• Allow iam:CreateRole (and attaching policies) only with a condition that iam:PermissionsBoundary equals the ARN of the approved boundary policy — a role created without that boundary is denied.
• Deny iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion and iam:DeletePolicy on the boundary policy's ARN, so developers cannot rewrite the cap itself.
• Deny iam:DeleteRolePermissionsBoundary (and changing a boundary to a different policy), so developers cannot take the boundary off a role after creating it.

Miss any of the three and the delegation leaks: a developer creates an unbounded role, edits the boundary policy to *, or detaches it.

On the exam, this section is the debugging toolkit. When a scenario says a user "has an allow policy but still gets access denied," hunt for the explicit deny — in an SCP, a boundary, or a resource policy. When it asks how to let teams self-serve IAM without risking escalation, the answer is permissions boundaries — enforced with the iam:PermissionsBoundary condition and protected against edits and removal. And when two options differ only in that one relies on "removing allows" and the other adds an explicit deny for a must-never-happen action, the explicit deny is the stronger, intended control.

You rarely know the exact permissions a workload needs on day one, so AWS gives you tools to start broader and tighten with evidence. The tools differ in whether they look backwards at what was used or forwards at what a policy would allow:

Policy generation, unused access and last accessed data are all retrospective: they cannot stop a bad policy from shipping. Custom policy checks (along with Access Analyzer's policy validation) are the preventive step that runs before deployment. When a scenario asks for least privilege with the least effort, the managed analysis beats hand-reading CloudTrail logs every time.

The single most reliable decision rule in Task 1.1: anything that can use an IAM role should use an IAM role, never long-lived access keys. A role is an identity with permissions but no permanent credentials. When a trusted principal assumes it, AWS STS issues temporary credentials — an access key, secret key, and session token — that expire automatically. There is nothing to rotate, nothing to leak into a Git repository, and nothing to revoke user-by-user after an incident. Access keys, by contrast, live until someone deletes them, and scenarios that mention keys "stored in application code," "in a configuration file," or "shared between developers" are describing the problem the correct answer eliminates.

The pattern you will see most is the EC2 instance role: attach a role to an instance via an instance profile, and applications on it retrieve automatically rotated temporary credentials from the instance metadata service. The same principle extends everywhere compute runs — Lambda execution roles, ECS task roles — so "application on AWS compute needs AWS API access" always resolves to a role, and any option that creates an IAM user with access keys for a workload is wrong.

Amazon ECS has two roles that are easy to confuse. The task execution role is used by the ECS agent and Fargate on your behalf — to pull container images from Amazon ECR and send logs to CloudWatch Logs. The task role (taskRoleArn in the task definition, trusting ecs-tasks.amazonaws.com) is the one your application code uses to call AWS services such as DynamoDB or S3. Adding application permissions to the execution role does not reach the code; set a task role and deploy a new task definition revision.

Workloads outside AWS — on-premises servers, other clouds — can avoid access keys too. IAM Roles Anywhere lets a workload that holds an X.509 certificate exchange it for temporary role credentials: the setup has three parts — a trust anchor (which certificate authority to trust: AWS Private CA or your own CA's certificate), an IAM role whose trust policy names the Roles Anywhere service principal, and a profile that says which roles a session may receive. On the machine, the AWS-provided credential helper signs the request with the certificate's private key and returns temporary credentials. It is the answer when servers outside AWS "must not store long-term access keys."

Role switching applies the same mechanism to humans. Instead of giving an administrator standing full access, you give them a modest daily identity plus permission to assume a privileged role when needed — via sts:AssumeRole, gated by the role's trust policy and optionally an MFA condition. Every assumption is a distinct, loggable event in CloudTrail, which gives you an audit story that standing permissions cannot match. Roles also power federation: AssumeRoleWithSAML signs in workforce users from an external identity provider, and AssumeRoleWithWebIdentity does the same for mobile and web app users authenticated by an OIDC provider — the mechanism underneath Amazon Cognito identity pools.

The exam probes this with "most secure" and "least overhead" constraints. Rotating access keys more often is never the best answer when a role can remove the keys entirely; the option that eliminates long-lived credentials beats every option that merely manages them better.

A role session lasts from one hour (the default) up to the role's maximum session duration, which you can set up to 12 hours — with one important exception. Role switching for humans means a user with a modest daily identity calls sts:AssumeRole (or switches role in the console) into a privileged role when needed. While the session lasts, the role's permissions replace the user's — they are not added together — so an action the user could do but the role cannot fails until the user switches back.

Role chaining

Role chaining is using one role session to assume another role. That includes assuming a role from an IAM Identity Center permission set session or from an EC2 instance role, because those credentials are themselves role sessions. A chained session is limited to one hour, whatever the target role's maximum session duration says, and a chained AssumeRole call that requests more than 3,600 seconds fails — it is not silently shortened. Long-running automation that chains must request 3,600 seconds or less and re-assume the role when the credentials expire.

Session name, session tags and source identity

Each assumption shows up in CloudTrail, but the caller chooses the role session name on every call, so it is a weak audit key. Source identity is the stronger one: set once — by the identity provider in the SourceIdentity SAML attribute, or on the first AssumeRole call — it cannot be changed for the rest of the session, persists through role chaining, and is logged in CloudTrail for every action. Roles that accept it must allow sts:SetSourceIdentity in their trust policy. Session tags, by contrast, pass attributes for attribute-based access control; they are not designed as an immutable record of who acted.

Revoking access to a role

Editing or deleting a role's trust policy stops new assumptions, but credentials already issued stay valid until they expire. To cut off sessions that are already running, use the role's revoke active sessions action: IAM attaches an inline policy that denies every action for credentials issued before that moment (an aws:TokenIssueTime condition). Do both when a trusted party must lose access immediately.

When account A needs to reach a resource in account B, you have two mechanisms, and SAA-C03 loves to make you choose. Option one: account B creates a cross-account IAM role whose trust policy names account A (or a specific principal in it) as trusted; principals in A call sts:AssumeRole and operate in B with the role's permissions. Both sides must agree — B's trust policy admits the caller, and A must allow its principal to perform the assume call. Put the role in the account that owns the resources, and give each target account its own role for hub-and-spoke automation. Option two: account B attaches a resource-based policy directly to the resource — a bucket policy, SQS queue policy, KMS key policy, or Lambda function policy — granting account A's principal access to that resource.

The decision hinges on a nuance worth stating precisely. When you assume a role, you temporarily give up your original permissions and take on the role's permissions instead — you become a different principal. With a resource-based policy, you keep your own identity and permissions and simply gain access to the remote resource on top of them. That difference is decisive in the classic Lambda scenario: a function in account A must read a queue or bucket in account B and write results to resources in its own account, in the same invocation. If the function assumes a role in B, it loses access to account A's resources mid-flight. The clean answer is a resource-based policy in B granting the function's execution role access — the function keeps its home permissions and reaches across in one identity.

Next decision input: does the target service support resource-based policies at all? Many do — S3 buckets, SQS queues, SNS topics, KMS keys, Lambda functions, Secrets Manager secrets, ECR repositories, API Gateway APIs, EventBridge event buses, and DynamoDB tables and streams, among others. Many do not: there is no resource policy on an EC2 instance, an RDS database or a CloudFormation stack, so describing or managing them from another account requires a role in the target account. A role is also the better fit when the external party needs many actions across many resources rather than one resource.

A resource policy alone is not always enough when the data is encrypted. A secret in Secrets Manager encrypted with the AWS managed key aws/secretsmanager cannot be shared across accounts, because you cannot edit an AWS managed key's key policy. Cross-account secret access therefore needs two grants that each name the outside principal: the secret must be protected by a customer managed KMS key (whose key policy you control and can extend to the other account), and the secret itself needs a resource policy permitting retrieval. Either grant alone fails — the resource and the key must both say yes.

Third-party vendors and the external ID

When the external party is a third-party SaaS vendor (a monitoring or cost tool), the pattern is a cross-account role whose trust policy names the vendor's AWS account and requires an external ID through the sts:ExternalId condition key. It defends against the confused deputy: the vendor assumes roles for many customers from the same account, so a different customer could give the vendor your role ARN and trick it into acting on your account. The external ID ties each role to one customer relationship, but only if the vendor generates a unique value per customer and shows it during onboarding. A value the customer chooses, or a guessable one such as the customer's account ID, can be reused by another customer and defeats the defence.

The obvious alternatives fail for structural reasons. An IP-address condition cannot tell the vendor's customers apart, because every request — legitimate or confused — comes from the same vendor infrastructure. An MFA condition cannot work for a vendor's automated, unattended assume calls. And shared access keys are the anti-pattern the whole design exists to avoid.

Two trust-policy details that break things

When a trust policy names a specific role or user ARN, IAM stores that principal's unique principal ID, not the name. If the trusted role is deleted and recreated with the same name, the trust no longer matches — the policy shows an ID beginning with AROA instead of the ARN — until someone edits the trust policy, enters the ARN again and saves it. Separately, accounts that AWS Organizations creates come with OrganizationAccountAccessRole, which has AdministratorAccess and trusts the management account. It is an administrative break-in path, not a template for automation: pointing a pipeline in another account at it means editing its trust policy and giving that pipeline full administrator rights, so create a purpose-built, least-privilege role instead.

Creating an IAM user per employee per account does not scale and does not survive an audit: credentials multiply, offboarding means chasing users across accounts, and nothing ties access back to the HR system. The design answer for human workforce access is federation — your people authenticate against one identity source, and AWS trusts that source to vouch for them, issuing temporary role credentials via STS rather than storing passwords in IAM.

AWS IAM Identity Center (the successor to AWS Single Sign-On) is the service the exam expects you to reach for. It provides a single sign-on portal across all accounts in an AWS Organization. You define permission sets (collections of policies that Identity Center provisions as roles in each target account) and create account assignments: one assignment is a user or group + a permission set + an account. Because assignments are per account, the same group can get different access in different accounts — for example a full developer permission set on development accounts and a read-only one on production accounts — without writing a separate policy per account. Employees get one credential, MFA in one place, and offboarding becomes a single disable at the identity source.

Identity Center has exactly one identity source, and choosing it is a common question:

The trap is choosing the default Identity Center directory when an existing directory already holds the workforce: that duplicates every user and makes offboarding a two-place job. "Use the existing on-premises AD and do not create a second directory" points to AD Connector.

You should also recognize the older building blocks, because scenarios and distractors still use them: SAML 2.0 federation directly to IAM lets an IdP call AssumeRoleWithSAML against a per-account IAM identity provider and role — workable, but you configure it account by account, which is exactly the overhead Identity Center removes. "When to federate a directory service" has a simple answer shape: the company already has AD or another corporate IdP, so you federate it — preferably through Identity Center — rather than recreate identities in AWS.

Keep one boundary crisp: Identity Center is for your workforce accessing AWS accounts and business applications. Customers of your consumer-facing web or mobile app are not workforce — they belong to Amazon Cognito, covered under Task 1.2. On the exam, "employees," "multiple accounts," and "existing Active Directory / corporate IdP" together mean IAM Identity Center; any answer minting IAM users at scale, or asking you to manage per-account SAML trust when Identity Center is on offer, is there to be eliminated on operational-overhead grounds. Consumer sign-up and social sign-in with temporary AWS credentials for the app is the Cognito pattern: a user pool for sign-in and an identity pool to exchange tokens for credentials.

At Associate level, multiple accounts are the default architecture, not an edge case: separate accounts isolate workloads and blast radius, cap the impact of compromised credentials, and cleanly separate production from development and security tooling from application teams. AWS Organizations is the service that binds them — one management account creates the organization, member accounts join it, and you get consolidated billing and centralized policy control. Accounts are grouped into organizational units (OUs), which can nest, and you design OUs around policy needs (Production, Sandbox, Security) rather than org charts, because OUs are where guardrails attach.

Those guardrails are service control policies (SCPs), and their semantics are the most-tested fact in this section: an SCP never grants a permission — it only sets the maximum available permissions for the accounts it applies to. Think of it as a filter: a principal's effective permissions are the intersection of what its IAM policies allow and what the SCPs permit. Attaching an SCP full of allows to an account gives its users nothing until an IAM policy grants those actions. SCPs attached to an OU inherit down to every account and nested OU beneath it, which is what makes them guardrails: deny leaving the organization, deny disabling CloudTrail, deny regions you don't operate in — once, at the OU, for everything below.

Precision points the exam checks:

• SCPs do affect member accounts' root users, which is why "prevent even administrators in member accounts from doing X" resolves to an SCP. (Resource control policies, below, also restrict member root users on supported resources, and centralized root access can remove member root credentials altogether.)
• SCPs do not affect the management account at all — no SCP applies to it, root or otherwise. That is a reason to keep workloads out of the management account and a fact distractors invert.
• SCPs do not restrict service-linked roles. An SCP that denies ec2:TerminateInstances stops your users and roles, but EC2 Auto Scaling still terminates instances on scale-in, because it acts through its service-linked role.
• SCPs follow your principals, wherever the resource lives. A member-account role that calls a bucket in a partner's account is still limited by its SCPs, and the partner's bucket policy cannot override them. That is how a data-perimeter SCP works: deny S3 actions unless aws:ResourceOrgID equals your organization ID, and your principals cannot write to buckets outside the organization.
• The reverse is not true: an SCP attached only to the OU of the account that owns a resource does not restrict principals in other accounts that a resource policy lets in. Organization-wide guardrails must be attached where they cover every member account (the root or every relevant OU) — or, for resource-side protection, use an RCP.

Restricting Regions with an SCP

The standard Region guardrail is an SCP that denies requests when aws:RequestedRegion is not one of the approved Regions (StringNotEquals). Written as a plain deny on every action, it breaks global services such as IAM, CloudFront, Route 53, AWS Organizations and AWS Support, whose requests are handled in a single Region (us-east-1 for most of them). Write the deny with NotAction instead of Action: the statement then covers every action except the global ones you enumerate, so Regional services stay locked to the approved Regions while IAM, CloudFront and Route 53 keep working. Simply adding us-east-1 to the approved list is the wrong fix — it would also open that Region to Regional resources. If one role (a network team's role, say) needs to work in every Region, add an exception inside the conditions — ArnNotLike on aws:PrincipalARN matching that role — rather than exempting a whole account. An IAM policy cannot do this job, because account administrators can edit IAM; they cannot edit an SCP.

Resource control policies (RCPs)

SCPs fence in your principals. Resource control policies (AWS Organizations, November 2024) fence in your resources: they set the maximum permissions available on resources in member accounts — for a set of supported services that includes S3, STS, KMS, SQS and Secrets Manager — no matter who calls, including principals from outside the organization. Like SCPs, they never grant, do not apply to the management account, and do not restrict service-linked roles.

Scenario-wise, SCP questions wear a uniform: "ensure that no user in any account, including administrators, can …" — disable security tooling, use an unapproved region, delete audit resources. IAM policies can't do it (a member admin could edit them); an SCP on the right OU can. If the scenario is about who may reach your resources from outside the organization, the answer is an RCP. Conversely, if a question asks how to give a team access to something, an SCP is never the answer — it cannot grant.

AWS Organizations gives you the raw machinery — accounts, OUs, SCPs — but wiring a well-architected multi-account environment out of it by hand means designing the OU layout, baselining logging and audit accounts, writing the guardrail SCPs, and building an account-creation pipeline yourself. AWS Control Tower packages that work: it sets up a landing zone, a pre-configured, best-practice multi-account environment built on top of Organizations, with a defined OU structure and dedicated accounts for log archive and audit out of the box.

Control Tower manages compliance through controls, historically called guardrails, with three behaviours you must be able to tell apart:

"Stop it at the API," "find what is already wrong" and "catch it in the template before deployment" map to preventive, detective and proactive respectively — and a requirement covering both new and existing resources often needs a proactive and a detective control together. Control Tower also provides Account Factory, a standardized, self-service way (published as a product in AWS Service Catalog) to provision new accounts that arrive pre-enrolled in the guardrails and baseline configuration, replacing hand-built account setup.

The Organizations-versus-Control-Tower decision is about what the scenario emphasizes. If it needs a specific mechanism — consolidated billing, an SCP to restrict actions — Organizations vocabulary answers it directly. If it describes a company about to scale from a few accounts to many and asks for a governed multi-account environment with the least effort to set up and operate, or mentions provisioning new accounts that are compliant from day one, Control Tower is the answer: it is the managed, opinionated layer, and hand-rolling the same governance with raw Organizations is the higher-overhead distractor. Control Tower uses Organizations underneath, so the two are complementary, not competing — a nuance that eliminates answer options framing them as either/or.

Expect Control Tower questions to be recognition-level: match "landing zone," "Account Factory," and preventive, detective and proactive controls to their definitions, and pick Control Tower whenever governed account vending at scale is the requirement.

Most Task 1.1 questions reduce to one of two lookups: who needs access, and through what mechanism? — or — what restriction is needed, and at which layer? Internalize these two tables and the majority of scenarios become pattern-matching.

The second lookup separates the policy layers that restrict, grant, or cap permissions:

Effective permissions are always the intersection of the applicable layers, with any explicit deny winning outright. When answer options mix these layers, ask two questions: does this option need to grant (then only an IAM policy can), and does it need to bind people who could otherwise change the rules (then it must be an SCP or RCP, set above their account).

Scenario 1. A company runs 40 AWS accounts in AWS Organizations. Security requires that no one in any development account — including account administrators — can disable AWS CloudTrail or create resources outside eu-west-1. What is the most effective way to enforce this?

Reasoning: The requirement is a restriction that must bind administrators. An IAM policy in each account fails immediately: member-account admins have iam:* and can edit or detach whatever you deploy. A permissions boundary fails for the same reason at a different layer — it applies per identity, and admins control identities. The phrase "including administrators" plus "any account" is the SCP signature. One guardrail policy on the OU can carry two deny statements: one blocking the CloudTrail stop-and-delete actions, and a Region statement keyed on aws:RequestedRegion that is scoped with NotAction so global services are left out of it. It inherits to every account in the OU, constrains even member-account root users, and no principal inside those accounts can lift it — because SCPs are managed from the organization, above the accounts they govern.

Scenario 2. An application running on EC2 instances in account A must read objects from an S3 bucket in account B, and write the processed output to a DynamoDB table in its own account. The company wants the least complex solution with no long-lived credentials. What do you recommend?

Reasoning: "No long-lived credentials" removes every option involving IAM users or access keys, so the instances need an instance role in account A — that part is fixed. The interesting choice is how the role reaches account B's bucket. If it assumes a role in account B, it takes on that role's permissions and temporarily loses its own — including the DynamoDB write access in account A — forcing awkward credential juggling inside one processing flow. The cleaner design: account B attaches a bucket policy granting s3:GetObject to account A's instance role, and the role's own identity policy carries the S3 read and DynamoDB write permissions. One identity, both sides of the job, nothing to rotate. This is the resource-based-policy-over-role rule earning its keep.

Scenario 3. A third-party cost-optimization SaaS needs read access to billing and usage data across a company's accounts. The vendor asks each customer to "create an IAM user and send us the access keys." What should the architect do instead?

Reasoning: Shipping access keys to an external party is the anti-pattern the question exists to punish — keys are long-lived, unauditable in the vendor's hands, and revocation is manual. The correct design: create a cross-account IAM role with a read-only, least-privilege policy, set its trust policy to the vendor's AWS account, and require the vendor-generated, customer-unique external ID in the trust condition (sts:ExternalId) so another customer of the vendor cannot induce it to assume your role — the confused-deputy defense. The vendor assumes the role with STS and receives only temporary credentials; you can stop new assumptions at any moment by editing one trust policy, and revoke sessions already issued with the role's revoke-active-sessions action.