Trust Policies and Who Can Assume

A trust policy is the document attached to a role that defines exactly which principals are permitted to assume it. It is the gatekeeper: even if a permission policy grants powerful access, no one can use the role unless the trust policy names them. On the exam, trust-policy mistakes are a frequent cause of both broken access and dangerous over-permissioning.

The Principal element of a trust policy can reference:

• AWS — an account, user, or role ARN (Amazon Resource Name).
• Service — an AWS service such as lambda.amazonaws.com.
• Federated — a SAML provider or web identity provider.

Choosing the right principal type and being specific is essential to avoid granting more trust than intended.

Cross-account assumption requires both sides to agree. The role's trust policy in the target account must allow the calling principal, and that principal must have an identity policy permitting sts:AssumeRole on the role's ARN. Missing either half blocks the request. This two-way handshake is a classic exam trap.

This trust policy lets a specific role in account 111122223333 assume the role. Naming an exact ARN rather than the whole account is tighter and safer.

Specifying a principal as arn:aws:iam::ACCOUNT:root trusts the entire account: any principal there that also has sts:AssumeRole permission can assume the role. This is broad. Where possible, name the exact user or role ARN to follow least privilege and shrink the trust surface.

Trust policies support Condition blocks that tighten who can assume and how. Common keys include sts:ExternalId (to stop the confused-deputy problem), aws:MultiFactorAuthPresent (require MFA), and aws:SourceIp. Conditions let you grant assumption only under specific, verifiable circumstances.

A powerful pattern is requiring MFA before a sensitive role can be assumed. The trust policy condition checks that the calling session was authenticated with MFA. This means even a stolen long-term credential cannot assume the privileged role without the second factor, raising the bar for attackers significantly.

Some roles are service-linked roles, predefined by AWS with a trust policy you cannot edit. They let a service manage resources on your behalf with exactly the trust AWS requires. Recognizing them matters because their permissions and trust are tightly controlled and tied to the service's lifecycle.

Trusting an internal principal (same account) is generally lower risk than trusting an external account or a third-party SaaS vendor. For external trust, always combine a specific principal with conditions like ExternalId. Treat every external trust statement as an entry point an attacker would love to exploit.

IAM Access Analyzer automatically reviews trust policies and resource policies to find roles that can be assumed by external accounts or the public. It flags unintended cross-account or public trust so you can tighten it. Reviewing Access Analyzer findings is a recommended, exam-relevant control for catching over-broad trust.

To design trust safely: name the most specific principal possible, add conditions such as ExternalId and MFA where appropriate, prefer roles over account-root trust, and review with Access Analyzer. Remember the trust policy answers who, while permission policies answer what; both must align for access to work and stay least-privilege.

Test your trust-policy knowledge.

A trust policy defines which principals may assume a role and is the gatekeeper regardless of permission policies. Cross-account assumption needs a two-way handshake: trust policy plus the caller's sts:AssumeRole permission. Prefer specific principal ARNs over account-root, add conditions like ExternalId and MFA, and audit with IAM Access Analyzer.