Identity & Access Boundary Bundle

Cross-Account Security Patterns, EC2 Instance Metadata Service v2 (IMDSv2), AWS Systems Manager Session Manager, and AWS STS mechanics — four topics that sit at the literal BOUNDARY where an identity crosses from one trust zone into another: account to account, instance to credential, operator to instance, and caller to assumed role. This is some of the most consistently and specifically tested material on the exam, and almost none of it has its own dedicated AWS service name — it's mechanism knowledge.

Identity — primary role Preventive — boundary enforcement Infrastructure Protection — IMDSv2

ExternalId

Confused deputy fix

1 hour

Max session duration when role-chaining

Hop limit 1

IMDSv2 default — blocks SSRF pivoting

Not logged

Session Manager port-forward/SSH content

The Core Mental Model — Four Different Boundaries, One Shared Question

"Who Is Actually On The Other Side Of This Trust Boundary?"

Cross-Account Patterns — when Account A's resource policy or role trust policy grants access to Account B, how do you make sure ONLY the intended Account B (and not some other AWS customer who happens to know the role ARN) can actually use it? This is the confused deputy problem, and ExternalId is the fix.
IMDSv2 — an EC2 instance's attached IAM role credentials are retrievable from the local metadata endpoint (169.254.169.254). If a web app on that instance has an SSRF vulnerability, an external attacker can trick the app into fetching those credentials FOR them — unless the metadata service requires a session token that SSRF payloads typically can't obtain.
Session Manager — when an operator needs shell access to an instance, how do you avoid open inbound ports, SSH key management, and bastion hosts entirely, while still getting a full audit trail of who connected and when?
STS mechanics — every temporary credential issued anywhere in AWS (federation, cross-account, instance roles) ultimately comes from STS. Understanding session duration limits, role chaining, and source identity tracking is what lets you reason correctly about scenarios spanning multiple other services already covered in this study set.

⚠️ The Recurring Exam Theme

These four topics rarely appear as their own standalone question — they show up EMBEDDED inside scenarios about other services (a Lambda function calling a third party's API, an EC2 instance running an internet-facing app, a help-desk engineer needing instance access, an enterprise federating into a partner's AWS account). The exam expects you to recognize the underlying mechanism even when the scenario is dressed up as something else entirely.

Exam Domain Mapping

Domain	Where This Bundle Shows Up
Identity & Access Management	The centerpiece — confused deputy, ExternalId, STS session mechanics, role chaining
Infrastructure Security	IMDSv2 enforcement, SSRF mitigation, Session Manager replacing SSH/bastion architecture
Threat Detection & Incident Response	CloudTrail-based accountability via source identity, detecting/responding to credential theft via SSRF
Management & Security Governance	Organization-wide IMDSv2 enforcement via Declarative Policies, centralized Session Manager logging

Decision Tree — Mental Model

Threat

A confused deputy being tricked into acting on an attacker's behalf across accounts; SSRF stealing EC2 instance-role credentials; SSH-based instance access requiring open ports, bastions, and key sprawl; uncontrolled role-chaining producing long-lived, untraceable sessions

↓

Security Goal

Verify the true identity crossing each trust boundary, and minimize standing exposure (open ports, long sessions, unauthenticated metadata access) at each one

↓

AWS Service / Mechanism

The Identity & Access Boundary Bundle

ExternalId — cross-account trust IMDSv2 — token-based metadata access Session Manager — port-less, key-less access STS — session duration, chaining, source identity

↓

Implementation

Require ExternalId on every third-party cross-account trust policy; enforce IMDSv2 account/org-wide with hop limit 1; remove port 22 from security groups in favor of Session Manager; require sts:SourceIdentity on sensitive role trust policies.

↓

Monitoring

CloudTrail records every AssumeRole call (with source identity, when set) and every Session Manager session start; instance metadata defaults can be audited via Config/Trusted Advisor.

↓

Remediation

Rotate the ExternalId if suspected leaked; revoke active sessions via the aws:TokenIssueTime condition pattern; force IMDSv2-only on a compromised instance; terminate an active Session Manager session.

Final Summary

Must Memorize

ExternalId exists specifically to solve the confused deputy problem in third-party cross-account role assumption
IMDSv2 requires a PUT-based session token; SSRF vulnerabilities typically can't set custom headers or issue PUT requests, which is WHY IMDSv2 blocks most SSRF-based credential theft
The IMDSv2 hop limit (default 1) is a separate, additional control from requiring tokens — it stops a stolen token from being relayed beyond the first network hop
Session Manager logs session METADATA (who/when) via CloudTrail always, but does NOT log session CONTENT for port forwarding or SSH-tunneled sessions specifically
Role chaining caps the session duration at a MAXIMUM of 1 hour, regardless of the role's own configured maximum session duration

Must Understand

Why sts:SourceIdentity persists across an entire role chain, giving CloudTrail-based accountability even after multiple AssumeRole hops
Lambda does NOT use the EC2 IMDS at all — IMDSv2 enforcement is irrelevant to Lambda's own credential model
The distinction triangle: ExternalId (cross-ACCOUNT trust) vs IMDSv2 (instance-LOCAL credential theft) vs Session Manager (operator ACCESS boundary)

Can De-prioritize

Exact SSM Agent version numbers required for specific port-forwarding features
Console UI navigation specifics
Full regex/character-limit specification for ExternalId or session tag values

Exam appearance probability: HIGH

Core Services — Deep Dive

Cross-Account Security Patterns High — confused deputy is a named, classic problem

The confused deputy problemA "deputy" (an AWS service or your account's role) is tricked by a malicious third party into misusing its OWN legitimate authority on the attacker's behalf — e.g., your role trusts "any principal that knows this ARN," and an unrelated AWS customer configures THEIR resource to reference your role ARN, fooling a service into acting for them using your permissions

The fix — ExternalIdA shared secret value that the THIRD PARTY must include in their AssumeRole call, required via a sts:ExternalId condition on your role's trust policy — without the correct ExternalId, the AssumeRole call fails even if the calling principal matches

When you need itSpecifically when a THIRD PARTY (a SaaS vendor, a partner) is assuming a role INTO your account on behalf of potentially many different customers — not needed for simple two-party, same-organization cross-account trust where you control both ends

Resource-based vs identity-based for cross-accountFor S3/KMS/SQS/SNS/Secrets Manager and similar resources, a RESOURCE-BASED policy alone can grant cross-account access without any role assumption at all. For services without resource-based policies (most others), cross-account access REQUIRES role assumption via STS

ExternalId constraints: minimum 2 characters, maximum 1,224 characters, alphanumeric plus a defined set of symbols (+ = , . @ : / -), no whitespace.
"A SaaS monitoring vendor needs to assume a role into our account to pull CloudWatch metrics, and they ALSO have hundreds of other customers using the exact same vendor-side role to assume into THEIR various accounts" → ExternalId is the standard mitigation, since without it, one customer's data could theoretically be exposed to another's session if the vendor's own system had a logic flaw confusing which customer's role to assume.

EC2 Instance Metadata Service v2 (IMDSv2) High — one of the most consistently tested EC2 topics

What IMDS providesTemporary IAM role credentials, instance identity documents, and user data — accessible from WITHIN the instance at 169.254.169.254

IMDSv1 weaknessResponds to a simple, unauthenticated HTTP GET — any process (including one tricked into making a request via SSRF) can retrieve the attached role's credentials with zero authentication

IMDSv2 fixRequires a session token, obtained via an HTTP PUT request with a custom header (X-aws-ec2-metadata-token-ttl-seconds) — most SSRF vulnerabilities only allow the ATTACKER to induce a GET request and cannot set custom headers or issue PUT requests, making IMDSv2 resistant to the classic SSRF-to-credential-theft chain

Hop limitA SEPARATE, additional control — default hop limit of 1 means the token response cannot travel through additional network hops, preventing a stolen token from being relayed out through a proxy, container bridge, or another intermediary

Enforcement scopeAccount-level default via modify-instance-metadata-defaults (--http-tokens required --http-put-response-hop-limit 1); per-instance via modify-instance-metadata-options; SCPs can deny launching instances without IMDSv2 required; Organization Declarative Policies (introduced December 2024) can enforce IMDSv2 as a non-overridable ORG-WIDE default

Lambda does NOT use EC2 IMDS at all — Lambda functions receive credentials through a completely different mechanism (the Lambda runtime environment). IMDSv2 enforcement is irrelevant to Lambda; this is a frequently-confused point.
Containerized workloads on EC2 (ECS on EC2, self-managed K8s): the default hop limit of 1 means the PUT token request is consumed at the FIRST hop (the container-to-host bridge), and the container itself never receives the token — for containers needing metadata access, the hop limit typically needs to be increased to 2 to let the request traverse the bridge interface.
Real-world consequence: the documented attack chain in numerous breaches (most famously Capital One in 2019, and a referenced 2026 incident) is RCE/SSRF in a public-facing app → unauthenticated IMDSv1 credential theft → lateral movement using the stolen role's permissions. This is precisely the chain IMDSv2 is designed to break.
"Our public-facing application has a known SSRF vulnerability we haven't patched yet, but we want to prevent an attacker from using it to steal our EC2 instance's IAM credentials" → enforce IMDSv2 (defense-in-depth; doesn't fix the SSRF bug itself, but neutralizes its most severe consequence).

AWS Systems Manager Session Manager SSH/bastion replacement

What it doesProvides interactive shell access (browser-based or AWS CLI) to managed nodes — EC2, on-premises servers, edge devices, VMs — without opening inbound ports, maintaining bastion hosts, or managing SSH keys

Access modelControlled entirely via IAM permissions on the Systems Manager API — access can be granted/revoked from a single, central location rather than per-instance key/credential management

PrerequisiteSSM Agent installed on the managed node (pre-installed on many current AMIs); the node needs network access to SSM endpoints (directly, or via VPC endpoint for private subnets with no internet access)

Port forwardingLets a local client forward traffic to a port on the managed node (or, with remote host port forwarding, to a port on a DIFFERENT remote host reachable from the managed node, using it as a "jump host" without exposing that remote host directly)

Logging — the critical nuanceStandard interactive sessions CAN be logged (content) to CloudWatch Logs and/or S3. BUT sessions that connect via PORT FORWARDING or SSH-over-Session-Manager are NOT content-logged — because that traffic is encrypted end-to-end within the tunnel and Session Manager only serves as a transport tunnel for it

What IS still recorded for port-forwarding/SSH sessions: the fact that a session was INITIATED (who, when, against which node) is captured in CloudTrail, even though the actual data exchanged within the tunnel is not logged by Session Manager.
"We need full content logging of every command an operator runs during a remote access session, for compliance" → standard interactive Session Manager sessions WITH logging enabled satisfy this; port-forwarding or SSH-tunneled sessions through Session Manager do NOT provide content-level audit logs, only session-initiation metadata via CloudTrail.

AWS STS Mechanics High — underlies nearly every federation/cross-account scenario already covered

Default session duration3,600 seconds (1 hour) by default for AssumeRole, configurable up to the role's own maximum session duration setting

Role chaining capIf you assume a role using credentials that were THEMSELVES obtained by assuming another role (role chaining), and you request a DurationSeconds greater than 1 hour, the operation FAILS — chained sessions are hard-capped at 1 hour regardless of any role's configured maximum

sts:SourceIdentityAn optional, settable value at the FIRST AssumeRole call that PERSISTS across the entire subsequent role chain — lets CloudTrail logs attribute actions taken deep into a chain back to the originally authenticated identity, even after several hops. Can be required via a role trust policy condition

Session tags & transitive tagsKey-value pairs attached to a session (used for ABAC); a tag marked TRANSITIVE persists into subsequent sessions during role chaining, while a non-transitive tag does not carry forward

GetSessionToken vs AssumeRole vs GetFederationTokenGetSessionToken — temporary creds for the SAME IAM user/root, mainly to enable MFA-protected API calls. AssumeRole — temporary creds for a DIFFERENT role, the standard cross-account/federation mechanism. GetFederationToken — temporary creds for a federated user identity without an existing IAM identity, scoped by a session policy

Token revocationSTS tokens CANNOT be individually revoked once issued — they remain valid until natural expiration. To forcibly invalidate already-issued sessions, attach/update an IAM policy denying access based on the aws:TokenIssueTime condition key (effectively revoking everything issued before a given point)

This last point is the EXACT mechanism behind the "STS session credential revocation" reasoning already covered in the GuardDuty module's specialty-level scenario — deleting IAM access keys does nothing to an already-issued STS session; only a TokenIssueTime-based deny policy (or waiting for natural expiration) actually revokes it.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails.

A third-party SaaS vendor needs to assume a role into our account, and they have many other customers using the same mechanism

third-party vendormany customersconfused deputy

Expected Answer

Require ExternalId on the role's trust policy

Distractor	Why it's wrong
Restricting the trust policy's Principal to the vendor's account ID alone	Necessary but NOT sufficient — it doesn't prevent the vendor's own system from confusing which of ITS customers' sessions should map to your role, which is the actual confused-deputy risk ExternalId addresses

Prevent an attacker exploiting an SSRF vulnerability in a web app from stealing the EC2 instance's IAM role credentials

SSRFsteal instance credentials169.254.169.254

Expected Answer

Enforce IMDSv2 (require session tokens)

Distractor	Why it's wrong
Removing the instance's IAM role entirely	Breaks legitimate application functionality that depends on that role — IMDSv2 solves the SPECIFIC theft vector without removing needed permissions
Patching the SSRF vulnerability only	Defense-in-depth principle — IMDSv2 is the layer that limits BLAST RADIUS even before/if the underlying app vulnerability is fixed

Provide an engineer shell access to a private-subnet EC2 instance, with zero open inbound ports and a full audit trail

zero inbound portsno bastionfull audit trail

Expected Answer

AWS Systems Manager Session Manager (standard interactive session, with logging enabled)

Distractor	Why it's wrong
A bastion host with SSH key management	Requires open inbound ports (even if just to the bastion) and ongoing SSH key lifecycle management — exactly what Session Manager is designed to eliminate
Session Manager via port forwarding	Provides the port-less access, but does NOT provide content-level audit logging — fails the "full audit trail" requirement specifically

Forcibly invalidate STS session credentials that were already issued to a compromised IAM role, before they naturally expire

revoke active sessionalready issuedbefore expiration

Expected Answer

Attach/update an IAM policy denying access based on aws:TokenIssueTime

Distractor	Why it's wrong
Deleting the IAM role's access keys	Has no effect on already-issued STS session tokens — they remain valid until natural expiration regardless of what happens to long-lived access keys

Trace, via CloudTrail, exactly which originally-authenticated human took an action four AssumeRole hops deep into a role chain

role chainattributionmultiple hops

Expected Answer

sts:SourceIdentity, set at the first AssumeRole and persisting through the chain

Distractor	Why it's wrong
The session name on the final AssumeRole call alone	Only reflects the immediate caller of the LAST hop, not the originally authenticated identity from the start of the chain — source identity is specifically designed to persist across the whole chain where session names don't

Integrations

AWS CloudTrail

WhatRecords every AssumeRole call (including ExternalId usage and source identity, when set), and every Session Manager session start event

AWS Organizations

WhatDeclarative Policies (Dec 2024+) can enforce IMDSv2 as a non-overridable, org-wide default — building on the same declarative-policy mechanism covered in the IAM & Governance bundle

AWS Config / Trusted Advisor

WhatCan audit instance metadata configuration and Auto Scaling Group launch template settings for IMDSv2 compliance and hop-limit misconfiguration

Amazon CloudWatch Logs / S3

WhatDestinations for Session Manager session content logging (for standard interactive sessions only — not port forwarding/SSH)

VPC Endpoints

WhatLet Session Manager reach SSM endpoints from fully private subnets with no internet gateway/NAT, preserving the "no open inbound ports" property end-to-end

AWS Lambda

WhatExplicitly does NOT use EC2 IMDS — receives credentials via a separate Lambda runtime mechanism, making IMDSv2 enforcement irrelevant to it

Costs, Limits & Quotas

Pricing Model

STSNo direct charge for AssumeRole/GetSessionToken/GetFederationToken calls

IMDSv2 enforcementNo direct charge — a configuration setting, not a billed feature

Session ManagerNo direct charge for the Session Manager capability itself; standard charges apply for CloudWatch Logs/S3 if session logging is enabled

Common Cost Mistakes

Enabling verbose session logging to both CloudWatch Logs AND S3 simultaneously for every session when only one destination is actually needed
Over-provisioning long session durations on roles "just in case," increasing the window of exposure if a session is compromised, with no cost benefit

Cost Optimization

These are largely zero-marginal-cost security controls — the "cost" tradeoff here is almost entirely operational/architectural, not financial
Scope session logging destinations to what's actually needed for the compliance requirement at hand

Limits & Quotas

Role chaining session durationHard-capped at 1 hour, regardless of the role's own configured maximum session duration

ExternalId length2–1,224 characters, alphanumeric plus a defined symbol set, no whitespace

Session tag value lengthPlain-text session tag values cannot exceed 256 characters

IMDSv2 default hop limit1 — must be explicitly increased (typically to 2) for container-on-EC2 scenarios where the request must traverse a bridge interface

Session Manager port forwardingRequires SSM Agent version 2.3.672.0 or later on the managed node; remote-host port forwarding requires version 3.1.1374.0 or later

⚠️ Exam trap

IMDSv2 enforcement (requiring tokens) and the hop limit are TWO SEPARATE controls — requiring tokens alone doesn't prevent a stolen token from being relayed beyond the instance if the hop limit is left at a permissive value, and a restrictive hop limit alone doesn't prevent unauthenticated GET-based theft if tokens aren't required. Both should generally be configured together.

Best Practices & Common Exam Traps

8 — Best Practices

Must Know

ExternalId solves the confused deputy problem specifically for third-party, multi-customer cross-account role assumption
IMDSv2 = token requirement (blocks unauthenticated theft) + hop limit (blocks relaying a stolen token) — two distinct controls
Session Manager port-forwarding/SSH sessions are NOT content-logged, only session-initiation metadata is captured
Role chaining caps session duration at 1 hour regardless of any role's own maximum
STS tokens cannot be individually revoked — only invalidated via a TokenIssueTime-based deny policy or natural expiration

Good Practice

Require ExternalId on every third-party cross-account trust relationship, even if not strictly required for two-party same-org trust
Enforce IMDSv2 with hop limit 1 as an account or org-wide default via Declarative Policies
Replace bastion hosts and SSH key management with Session Manager for EC2 access
Require sts:SourceIdentity on sensitive role trust policies to preserve attribution through role chains

Advanced Practice

Use SCPs to deny launching any EC2 instance without IMDSv2 required, as a hard organizational guardrail beyond the default setting
Use transitive session tags for ABAC decisions that need to persist meaningfully through a role chain
Build a TokenIssueTime-based emergency revocation runbook in advance, rather than discovering the mechanism for the first time during an actual incident
For container-on-EC2 workloads needing metadata access, deliberately tune the hop limit to exactly what's needed (e.g., 2) rather than disabling the protection broadly

9 — Common Exam Traps

Misconception	Reality
"Restricting a role's trust policy Principal to a specific account ID is sufficient cross-account protection"	Insufficient alone for third-party, multi-tenant scenarios — ExternalId is the additional control needed to prevent confused-deputy-style cross-customer confusion on the THIRD PARTY's side
"IMDSv2 enforcement protects Lambda functions from credential theft too"	False — Lambda doesn't use EC2 IMDS at all; this setting is entirely irrelevant to Lambda's credential model
"All Session Manager sessions are fully content-logged by default"	False — port forwarding and SSH-tunneled sessions are explicitly NOT content-logged, due to end-to-end encryption within the tunnel; only session-initiation metadata is captured via CloudTrail
"Deleting an IAM role's access keys revokes any active STS sessions using that role"	False — STS session tokens remain valid until natural expiration; only a TokenIssueTime-based deny policy can forcibly invalidate already-issued sessions
"You can chain roles indefinitely with each chain hop using its own full configured session duration"	False — role chaining caps the session duration at 1 hour maximum, regardless of any individual role's own configured maximum

Lookalike Comparisons

Comparison	What actually differs
ExternalId vs restricting trust policy Principal	Solves confused deputy across MULTIPLE customers of the same third party vs only verifies the calling ACCOUNT is correct — necessary but not sufficient alone in multi-tenant scenarios
IMDSv1 vs IMDSv2	Unauthenticated GET request, trivially SSRF-exploitable vs token-based PUT-then-GET flow, resistant to most SSRF payload patterns
IMDSv2 token requirement vs hop limit	Blocks unauthenticated credential RETRIEVAL vs blocks a retrieved token from being RELAYED beyond the first network hop — complementary, not redundant
Session Manager standard session vs port forwarding/SSH session	Content fully logged (if enabled) vs content NOT logged due to end-to-end tunnel encryption, only initiation metadata captured
AssumeRole vs GetSessionToken vs GetFederationToken	Temporary creds for a DIFFERENT role (cross-account/federation) vs temporary creds for the SAME identity (mainly for MFA-gated calls) vs temporary creds for a federated user with no existing IAM identity

Identity & Access Boundary Bundle

The Core Mental Model — Four Different Boundaries, One Shared Question

Exam Domain Mapping

Decision Tree — Mental Model

Final Summary

Core Services — Deep Dive

AWS Exam Thinking

Integrations

Costs, Limits & Quotas

Pricing Model

Common Cost Mistakes

Cost Optimization

Limits & Quotas

Best Practices & Common Exam Traps

8 — Best Practices

9 — Common Exam Traps

Lookalike Comparisons

Flashcards — 18 Cards

Practice Quiz — 9 Questions