Authentication

Three identities, three front doors

A clean answer to almost any SCS-C03 authentication question starts with one question: who is signing in? AWS gives each kind of caller its own front door, and naming the caller usually names the service before you read any other detail.

The human workforce (your employees and contractors) signs in through AWS IAM Identity Center^[1], the successor to the service formerly called AWS SSO. Identity Center connects to your existing corporate identity provider over SAML 2.0 or provisions users over SCIM, then grants access through permission sets (reusable role templates) rather than a personal IAM user per employee. People get one sign-on page across every account in the organization.

Application and customer end users authenticate through Amazon Cognito^[2]. A Cognito user pool is a managed user directory and OIDC identity provider: it registers users, runs the sign-in (including social and enterprise federation), and issues JSON Web Tokens (JWTs) your app trusts. This is customer identity and access management (CIAM), the people who use your product, not the people who build it.

Machines, code, and AWS services authenticate by assuming an IAM role^[3] and receiving temporary credentials from AWS Security Token Service (STS). An EC2 instance profile, a Lambda execution role, or an ECS task role all resolve to "assume this role, get a short-lived session, never store a key."

These doors can chain. A mobile app can sign a user in at a Cognito user pool, then hand that token to a Cognito identity pool to receive temporary AWS credentials so the app calls S3 directly. But on the exam the actor in the stem is your first and strongest signal: workforce points at Identity Center, customers point at Cognito, workloads point at roles and STS.

Identity type chooses the front door: workforce, customer, or workload.

Workforce sign-in: IAM Identity Center and federation

Treat per-employee IAM users as the legacy pattern. The modern workforce design federates an external identity provider (IdP) into AWS so people authenticate against the directory you already run and receive a short-lived AWS session, never a standing access key.

IAM Identity Center

IAM Identity Center^[4] is the front door for the whole organization. You connect an external IdP (Okta, Microsoft Entra ID, Active Directory Federation Services, or any SAML 2.0 provider) as the identity source, and Identity Center provisions users either by SCIM (the IdP pushes user and group changes automatically) or by manual sync. You then build permission sets, which are templates that Identity Center materializes as IAM roles in each target account. Assigning a group to a permission set in an account lets every member sign in there and assume that role for the session. Two facts the exam leans on: the Identity Center instance must always live in the organization management account, even though you can delegate day-to-day administration to a member account, and a delegated administrator cannot modify permission sets that are provisioned into the management account — only an Identity Center administrator working from the management account can.

SAML 2.0 vs OIDC federation to IAM

When you federate directly to IAM instead of through Identity Center, AWS verifies the assertion from your IdP and STS hands back a role session. SAML 2.0 federation uses sts:AssumeRoleWithSAML^[5]: the browser posts a signed SAML assertion, AWS validates it against a SAML identity provider object you registered in IAM, and returns credentials. Web/OIDC federation uses sts:AssumeRoleWithWebIdentity^[6]: the caller presents a JWT from an OIDC provider (Login with Amazon, Google, GitHub Actions, or any OIDC-compliant IdP). Both calls are unsigned — they need no pre-existing AWS credentials, because the assertion or token is itself the proof of identity.

AWS Directory Service

When workloads need real Active Directory (domain join, Kerberos, LDAP, group policy), AWS Directory Service^[7] provides AWS Managed Microsoft AD. You can establish a forest trust between AWS Managed Microsoft AD and an on-premises AD so users authenticate with their existing domain credentials, and Identity Center can use AWS Managed Microsoft AD as its identity source. The AD Connector variant proxies authentication to on-premises AD without storing directory data in AWS.

Identity Center federates the corporate IdP and provisions permission sets as roles across accounts.

Customer sign-in: Cognito user pools and identity pools

Amazon Cognito splits a confusingly similar pair of components, and the exam tests whether you can keep them apart. The rule: a user pool authenticates and issues tokens; an identity pool exchanges a token for temporary AWS credentials. They work alone or together.

User pool: the directory and token issuer

A Cognito user pool^[8] is a managed user directory and OIDC identity provider. It signs users in (local sign-up, social providers like Google and Apple, or enterprise SAML/OIDC IdPs) and returns three tokens: an ID token and an access token, both JWTs your app verifies against the pool's public JWKS endpoint, and a refresh token. The refresh token is the trap: it is encrypted and opaque, readable only by the user pool and used solely to mint new ID and access tokens, so it is not a JWKS-verifiable JWT. The ID token authenticates the user and carries profile claims; the access token authorizes API calls by OAuth scope. User pools support MFA with TOTP authenticator apps and SMS messages, and adaptive risk-based protections against credential stuffing.

Identity pool: the AWS credentials broker

A Cognito identity pool^[9] (federated identities) does one job: take a trusted token (from a user pool, a SAML/OIDC provider, or a social IdP) and call STS to return temporary AWS credentials so the client can reach AWS services such as S3 or DynamoDB directly. It picks the IAM role two ways: role-based access control (a default authenticated role, a rules-based choice from claims, or a role from user-pool group membership) and attribute-based access control (it maps claims to STS principal tags so IAM policies filter on aws:PrincipalTag). Identity pools can also issue limited credentials to unauthenticated guest identities when you enable that.

The combined flow

The canonical pattern chains them: the app signs a user in at the user pool and receives JWTs, then exchanges the user pool ID token at the identity pool for STS credentials, then uses those credentials to call AWS. If a stem says "web or mobile app users sign in and need to call AWS APIs directly," that's user pool plus identity pool. If it says only "authenticate users and issue tokens to my API," that's a user pool alone. If it says "my users already authenticate somewhere and just need temporary AWS credentials," that's an identity pool alone.

User pool authenticates and issues JWTs; the identity pool brokers them into STS credentials.

Machine credentials: roles, STS, and presigned URLs

Workloads never need a stored access key. They assume an IAM role and let STS hand back a session that expires on its own. This section is the credential-lifetime reference the exam quizzes hardest.

STS operations and their lifetimes

Every STS call returns the same shape: an access key ID, a secret access key, and a session token that must accompany each request. The operations differ by who calls them and how long the session lasts:

Operation	Caller / proof	Default	Max
`AssumeRole`^[10]	An existing principal with credentials	1 hour	Role's `MaxSessionDuration`, up to 12 hours
`AssumeRoleWithSAML`^[5]	A SAML assertion (unsigned call)	1 hour	Up to 12 hours
`AssumeRoleWithWebIdentity`^[6]	An OIDC JWT (unsigned call)	1 hour	Up to 12 hours
`GetSessionToken`^[11]	An IAM user, often to satisfy MFA	12 hours	36 hours (root: 1 hour)
`GetFederationToken`^[12]	An IAM user acting as a broker	12 hours	36 hours (root: 1 hour)

Two numbers are commonly traded as distractors. First, role chaining (using one role's credentials to assume a second role) caps the second session at 1 hour, regardless of the role's MaxSessionDuration. Second, the root user can only ever get a 1-hour GetSessionToken/GetFederationToken credential. STS is also a global service: it is exempt from Region-restriction SCPs that deny by aws:RequestedRegion, though you should still enable Regional STS endpoints for resilience.

IAM Roles Anywhere

IAM Roles Anywhere^[13] extends the role model to servers and containers running outside AWS. You register a certificate authority as a trust anchor, the workload presents an X.509 client certificate, and Roles Anywhere returns temporary STS credentials for a role you map to it. That removes the last common reason to mint a long-lived IAM user for an on-premises host.

S3 presigned URLs

An S3 presigned URL^[14] lets you delegate one specific S3 operation (typically GetObject or PutObject) to someone with no AWS account. The critical property: the URL carries the permissions of the IAM principal who signed it, not the recipient's, so a presigned URL can never grant more than the signer already has. Expiration depends on the signing credential, and the shorter clock always wins. Signed with an IAM user's long-term key (SigV4) via the CLI or SDK, a URL can last up to 7 days; signed in the S3 console, between 1 minute and 12 hours. Signed with temporary credentials (an assumed role or STS session), the URL dies when those credentials expire even if you asked for longer, so a URL signed by a default 1-hour role session is valid for at most that hour, and one signed from an EC2 instance profile (credentials rotate at roughly 6 hours) for at most that window.

Exam-pattern recognition

Stems that say "give a partner temporary download access to one file without an account" point at a presigned URL. "On-premises servers need AWS credentials without long-lived keys" points at IAM Roles Anywhere. "The credential must expire in an hour but the role allows twelve" is usually role chaining or a default AssumeRole session. "Require MFA before issuing CLI credentials to an IAM user" is GetSessionToken with SerialNumber and TokenCode. Watch the distractor that proposes embedding an IAM access key on an instance — almost always wrong against the option that attaches a role.

Pick presigned URL, Roles Anywhere, or AssumeRole+STS by what needs the credential.

Troubleshooting authentication failures

When sign-in breaks, the exam wants you to reach for the right log and the right knob, not guess. The discipline: every authentication event is recorded somewhere, so name the source before proposing a fix.

CloudTrail is the first stop

AWS CloudTrail^[15] records both management-console sign-ins and STS API calls, and the userIdentity element plus the error fields tell you why a credential was rejected. A failed console login appears as a ConsoleLogin event with errorMessage "Failed authentication"; a denied role assumption appears as AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity with an AccessDenied or errorCode. Root-user sign-ins, MFA usage, and the source IP are all in the record. If a stem asks "how do you find who failed to assume a role" or "detect root-user console logins," CloudTrail is the answer, and for organization-wide visibility an organization trail or CloudTrail Lake lets you query across every account.

Service-specific failure points

Each service has its own common break:

IAM Identity Center failures usually trace to permission-set provisioning. After you change a permission set you must re-provision it to the accounts that use it, or members keep getting the stale role. A delegated administrator hitting an error on a management-account permission set is expected: only an Identity Center administrator in the management account can change those. SCIM sync errors from the IdP show up as users or groups that never appear.
Amazon Cognito sign-in failures often come from token handling: an expired access/ID token (default 1 hour), a clock skew that fails JWT validation, or an attempt to verify the refresh token as a JWT (it is opaque and cannot be). App-client misconfiguration (wrong allowed OAuth flows or callback URL) blocks the hosted-UI flow. Federation failures point at the IdP attribute mapping.
AWS Directory Service authentication failures point at the trust relationship: a broken or misconfigured forest trust to on-premises AD, DNS resolution between the directories, or security-group rules blocking the AD ports. AD Connector issues usually mean it cannot reach the on-premises domain controllers.

Reading the evidence

The method that scores: identify the actor and service from the stem, pull the matching CloudTrail event (or Cognito/Directory Service logs), read the error code, and apply the fix that addresses that exact failure. A timeline of AssumeRole denials right after a permission-set edit is a provisioning problem, not a policy problem; repeated ConsoleLogin failures from one IP is a credential-stuffing signal that belongs in detection. Match the symptom to the source, then to the knob.

Triage a sign-in failure by service; CloudTrail is always the starting evidence.

Which authentication service for which identity

Identity type	IAM Identity Center	Amazon Cognito	IAM role + STS
Who it authenticates	Human workforce / employees	App and customer end users	Machines, workloads, AWS services
Backing identity source	Federated corporate IdP (SAML / OIDC) or built-in directory	Built-in user pool, social, or enterprise IdP	IAM trust policy on the role
Credential it hands back	Short-lived role session via permission set	JWT tokens (pool); AWS creds via identity pool	STS session token (access key + secret + token)
Typical default lifetime	Permission-set session (1h, up to 12h)	Access/ID token 1h; refresh up to 10y	AssumeRole session 1h, max 12h
Replaces	Per-employee IAM users	Rolling your own user database	Long-lived access keys on instances

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Authentication proves identity; authorization decides what it can do

Authentication establishes who a caller is and hands back a credential; authorization is the separate step that evaluates policies against that identity. Keep them apart when reading a stem: a failed sign-in, a federation trust, an MFA prompt, or a credential lifetime is an authentication problem, even if the wrong answers talk about permissions. The fix that issues or validates a credential is the authentication answer.

The identity type usually picks the AWS authentication service

AWS gives each caller a canonical front door: human workforce uses IAM Identity Center, application and customer end users use Amazon Cognito, and machines or AWS services assume an IAM role and get credentials from STS. Naming the actor in the question normally names the service before any other detail matters, so read for who is signing in first.

Use IAM Identity Center for workforce, not per-employee IAM users

IAM Identity Center (the service formerly named AWS SSO) federates your corporate IdP over SAML 2.0 or SCIM and grants access through permission sets, which it materializes as short-lived IAM roles in each account. That replaces creating a long-lived IAM user per employee, the legacy anti-pattern, and gives one sign-on across the whole organization.

Trap Provisioning an IAM user for each employee when the requirement is workforce SSO across many accounts; that is exactly what Identity Center and permission sets exist to avoid.

The Identity Center instance must live in the management account

An organization-wide IAM Identity Center instance always resides in the AWS Organizations management account. You can assign a delegated administrator in a member account for day-to-day work, but that delegated admin cannot modify permission sets provisioned into the management account; only an Identity Center administrator working from the management account can change those.

Trap Assuming a delegated administrator can edit a permission set used for access to the management account; that change is reserved to an Identity Center admin in the management account.

Re-provision a permission set after you edit it

A permission set is a template Identity Center deploys as an IAM role into each assigned account. After you change the permission set, you must re-provision it to those accounts or members keep assuming the stale role. A wave of access errors right after a permission-set edit is a provisioning gap, not a policy bug.

Trap Rewriting the underlying IAM policy to chase access errors that actually came from a permission set that was edited but never re-provisioned.

SAML federation uses AssumeRoleWithSAML; OIDC uses AssumeRoleWithWebIdentity

When you federate straight to IAM, a SAML 2.0 IdP drives sts:AssumeRoleWithSAML with a signed SAML assertion, while an OIDC provider (Google, GitHub Actions, any OIDC-compliant IdP) drives sts:AssumeRoleWithWebIdentity with a JWT. Match the protocol in the stem to the call: assertion means SAML, token means web identity.

AssumeRoleWithSAML and AssumeRoleWithWebIdentity need no AWS credentials

Both federation calls are unsigned: the caller presents the SAML assertion or OIDC JWT as the proof of identity, so no pre-existing AWS access key is required to make the request. Plain sts:AssumeRole, by contrast, must be called with active AWS credentials.

Trap Requiring an IAM access key before a web-identity or SAML federation call; the assertion or token itself is the credential, so those calls are unsigned.

Cognito user pool authenticates; identity pool brokers AWS credentials

A Cognito user pool is a directory and OIDC provider that signs users in and issues JWT tokens. A Cognito identity pool takes a trusted token and exchanges it through STS for temporary AWS credentials so the client calls AWS services directly. Tokens-only is a user pool; needs-AWS-credentials adds an identity pool.

Trap Reaching for an identity pool just to authenticate app users and issue tokens; that is the user pool's job, and the identity pool only enters when the client must call AWS APIs itself.

1 question tests this

A company is building a web application that allows unauthenticated users to browse public content and authenticated users to access…

A user pool issues two verifiable JWTs plus an opaque refresh token

On sign-in a Cognito user pool returns an ID token and an access token, both JWTs you verify against the pool's public JWKS, plus a refresh token. The refresh token is encrypted and opaque, readable only by the user pool and used only to mint new ID and access tokens, so it is not a JWKS-verifiable JWT.

Trap Treating all three Cognito tokens as JWTs you can verify against the JWKS; the refresh token is opaque and cannot be validated that way.

Cognito ID token authenticates the user; the access token authorizes API calls

The ID token carries identity and profile claims and proves who the user is, while the access token carries OAuth scopes and authorizes calls to your API. Send the access token to authorize an API request; use the ID token when you need the user's attributes.

Identity pools pick the IAM role by RBAC or ABAC

A Cognito identity pool chooses the IAM role two ways: role-based access control (a default authenticated role, a rules-based choice from claims, or a role from user-pool group membership) and attribute-based access control, where it maps claims to STS principal tags so IAM policies filter on aws:PrincipalTag. It can also issue limited credentials to unauthenticated guest identities when enabled.

8 questions test this

Prefer temporary, auto-expiring credentials over long-lived access keys

Long-lived IAM user access keys leak easily and are hard to rotate, so the modern pattern replaces them with credentials that expire on their own: IAM roles plus STS for workloads, federation for workforce, and IAM Roles Anywhere for on-premises servers. The exam consistently rewards the option that removes a static key in favor of an STS-issued session.

Trap Embedding an IAM user access key on an EC2 instance or app server when an attached IAM role would supply auto-rotating temporary credentials with no stored secret.

AssumeRole sessions default to 1 hour, max 12 by MaxSessionDuration

An sts:AssumeRole session lasts one hour by default; the maximum is set by the role's MaxSessionDuration, which can be raised up to 12 hours. STS always returns an access key, a secret key, and a session token that must accompany every request made with the credentials.

Role chaining caps the second session at 1 hour

When you use one role's temporary credentials to assume a second role (role chaining), the second session is limited to a maximum of 1 hour, regardless of that role's MaxSessionDuration. If a question needs a longer session, it cannot come from a chained assume-role.

Trap Expecting a chained AssumeRole session to honor a 12-hour MaxSessionDuration; chaining hard-caps the result at 1 hour.

3 questions test this

GetSessionToken issues MFA-backed credentials to an IAM user

sts:GetSessionToken lets an IAM user trade long-term keys for temporary credentials, optionally carrying MFA state when you pass SerialNumber and TokenCode, which is the standard way to require MFA before MFA-protected CLI or API calls. It defaults to 12 hours and ranges from 15 minutes to 36 hours for an IAM user.

Trap Using AssumeRole to satisfy an MFA-before-CLI requirement for an IAM user; GetSessionToken with SerialNumber and TokenCode is the operation that returns MFA-stamped credentials.

Root-user temporary credentials are capped at 1 hour

A token issued to the AWS account root user through GetSessionToken or GetFederationToken is restricted to a one-hour duration, even though an IAM user can request up to 36 hours. This is one more reason to avoid using the root user for routine work.

STS is a global service exempt from Region-deny SCPs

AWS STS is global, like IAM and CloudFront, so a Region-restriction SCP that denies on aws:RequestedRegion must exempt it or it would break authentication everywhere. You should still activate Regional STS endpoints for latency and resilience, but STS calls are not blocked by a data-residency Region deny.

1 question tests this

A company implements a data sovereignty policy requiring all AWS resources to be created only in eu-central-1 and eu-west-1 regions. The…

IAM Roles Anywhere gives on-premises servers temporary role credentials

IAM Roles Anywhere lets servers and containers outside AWS obtain temporary STS credentials by presenting an X.509 client certificate issued by a certificate authority you register as a trust anchor. It removes the last common reason to create a long-lived IAM user for an on-premises host.

Trap Creating a long-lived IAM user with static keys for each on-premises server when IAM Roles Anywhere can hand those hosts temporary role credentials from an X.509 trust anchor.

An S3 presigned URL carries the signer's permissions, not the user's

A presigned URL delegates one S3 operation to someone with no AWS account, and it acts with the permissions of the IAM principal who signed it, so it can never grant more access than the signer already has. Anyone holding the URL can use it until it expires, which is why it is treated as a bearer token.

Trap Assuming a presigned URL grants the recipient's own permissions or can exceed the signer's; it inherits exactly the signer's access and nothing more.

A presigned URL dies with its signing credential, shortest clock wins

Signed with an IAM user's long-term key via the CLI or SDK, a presigned URL can last up to 7 days (the console allows 1 minute to 12 hours). Signed with temporary credentials, it expires when those credentials do, even if you asked for longer, so a URL signed by a default 1-hour role session lasts at most that hour and one from an EC2 instance profile at most its roughly 6-hour rotation.

Trap Setting a 7-day expiry on a presigned URL signed from an assumed role or instance profile and expecting it to last; the temporary credential expires first and the URL dies with it.

CloudTrail is the first stop for failed sign-ins and assume-role denials

CloudTrail records console ConsoleLogin events and STS API calls with the userIdentity element and error fields, so it tells you who failed to authenticate and why, including root-user logins, MFA usage, and source IP. For organization-wide visibility, query an organization trail or CloudTrail Lake across every account.

Trap Reaching for VPC Flow Logs or GuardDuty to find who failed a console login or AssumeRole; the authoritative record of the sign-in event and its error is in CloudTrail.

AWS MFA spans virtual TOTP, FIDO2 passkeys, and hardware tokens

AWS supports virtual TOTP authenticator apps, FIDO2 security keys and passkeys, and hardware TOTP tokens as MFA factors, and IAM Identity Center and Cognito user pools can require MFA at sign-in. FIDO2 keys and passkeys are the phishing-resistant choice because the credential is bound to the origin and cannot be replayed.

Protect the root user with strong MFA and then lock it away

The root user cannot be deleted or scoped down by IAM policy, so the baseline control is to enable a strong MFA device on it, remove any root access keys, and reserve it for the few tasks that require it. Centralized root access for member accounts lets an organization manage member root credentials without each account holding its own.

Trap Trying to restrict the root user with an IAM policy or permission boundary; root is not constrained that way, so MFA plus locking the credentials away is the actual control.

Use AWS Directory Service when workloads need real Active Directory

AWS Managed Microsoft AD provides domain join, Kerberos, LDAP, and group policy, and you can establish a forest trust to on-premises AD so users sign in with existing domain credentials; Identity Center can use it as an identity source. Directory authentication failures usually trace to the trust relationship, DNS resolution between directories, or blocked AD ports.

Trap Blaming an IAM policy when domain users cannot authenticate through AWS Managed Microsoft AD; the cause is normally a broken forest trust, DNS, or a security-group rule blocking AD ports.

4 questions test this

Single-user rotation has a brief outage; alternating-users keeps one credential always valid

Secrets Manager single-user rotation changes one database user's password, so there is a short window where the old password is dead before the secret updates — the app must retry (exponential backoff) or stay stale. The alternating-users strategy keeps two users and rotates whichever is idle, so a valid credential is always available for high availability, but it clones a second user and needs a separate superuser secret with privileges to create/clone users.

Trap Reaching for alternating-users behind RDS Proxy, which only supports single-user rotation because the proxy never learns about the cloned user.

7 questions test this

Rotation runs createSecret/setSecret/testSecret/finishSecret and swaps the AWSCURRENT label onto AWSPENDING

The rotation Lambda runs four steps — createSecret, setSecret, testSecret, finishSecret — staging the new value under the AWSPENDING label and moving AWSCURRENT to it only after a successful test. A successful rotation but a still-broken app usually means the app cached the old credentials; an orphaned AWSPENDING label left on a version other than AWSCURRENT makes Secrets Manager think a rotation is still running. For alternating-users, the superuser secret's ARN must be stored inside the rotating secret's JSON so the function can find it.

Trap Assuming a successful rotation with the new password under AWSCURRENT proves the app will reconnect, when the app is caching the old credentials and never refreshed.

3 questions test this

A VPC-bound rotation Lambda needs a Secrets Manager VPC endpoint (and an RDS API endpoint for alternating-users)

When the rotation Lambda runs inside a private VPC with no internet path, it cannot reach the public Secrets Manager endpoint and times out (often at createSecret). Create an interface VPC endpoint for Secrets Manager so it can call the service privately. Alternating-users rotation against an RDS-managed superuser secret also needs an RDS API VPC endpoint, because the function calls the RDS API to fetch connection details.

Trap Blaming security groups or database connectivity for the timeout when the function actually cannot reach the Secrets Manager service endpoint at all.

7 questions test this

aws:MultiFactorAuthPresent requires MFA at the AssumeRole call, not just MFA enabled on the account

A trust policy condition on aws:MultiFactorAuthPresent is satisfied only when the caller supplies a fresh MFA serial number and token code in the AssumeRole call; merely having MFA registered on the IAM user is not enough. Temporary credentials minted by a service such as Lambda can never carry an MFA context, so a Lambda execution role can never assume a role whose trust policy requires MFA to be present.

Trap Assuming MFA registered on the IAM user satisfies the condition, when the --serial-number and --token-code must be passed on the AssumeRole request itself.

3 questions test this

Most Cognito SAML sign-in failures come from a stale metadata import or a mismatched ACS URL

An 'Invalid SAML response' or 'Invalid Destination' error usually means the IdP's updated metadata was never re-imported into the Cognito user pool, or the Assertion Consumer Service (ACS) URL on the IdP no longer matches the pool's https://.auth..amazoncognito.com/saml2/idpresponse endpoint. The first diagnostic step is to capture the SAML response in the browser, URL- and base64-decode it, and confirm the destination and mapped attributes.

Trap Mapping the SAML NameID to a mutable attribute like email, which spawns a brand-new profile whenever the user's email changes instead of recognizing the returning user.

3 questions test this

Session Manager S3 logging needs s3:GetEncryptionConfiguration (and PutObjectAcl for cross-account)

For Session Manager to write logs to S3 the instance profile needs s3:PutObject, plus s3:GetEncryptionConfiguration whenever 'Enforce S3 log encryption' is on, and s3:PutObjectAcl when the bucket lives in a different account; private-subnet instances also need a network path to S3. Logs never appear for port-forwarding or SSH sessions because that traffic is tunneled and Session Manager cannot capture it.

Trap Expecting logs from an SSH-over-Session-Manager or port-forwarding session, which are tunneled and intentionally not logged.

4 questions test this

Session Manager KMS encryption splits permissions: the user needs kms:GenerateDataKey, the instance needs kms:Decrypt

When Session Manager is set to encrypt session data with a customer managed key, the IAM principal starting the session must hold kms:GenerateDataKey on that key to create the data key, and the instance profile must hold kms:Decrypt to read the stream. AmazonSSMManagedInstanceCore grants neither KMS permission, so both must be added explicitly.

Trap Granting kms:Decrypt to the user instead of kms:GenerateDataKey, leaving the session unable to encrypt even though the instance can decrypt.

4 questions test this

Session Manager needs an SSM instance profile plus ssm, ssmmessages, and ec2messages reachability

A managed node needs an instance profile carrying AmazonSSMManagedInstanceCore for the SSM Agent to register; without it the instance is unmanaged. In a private subnet with no internet, sessions fail with TargetNotConnected unless interface VPC endpoints for ssm, ssmmessages, and ec2messages exist, because ssmmessages carries the Session Manager data channel.

Trap Adding only the ssm endpoint and omitting ssmmessages, which carries the actual session channel that Session Manager opens to the node.

3 questions test this

Pick the AD trust by use case: forest for transitive forest-wide auth, external for Linux WorkSpaces

A two-way trust is required for AWS Enterprise Apps (WorkSpaces, IAM Identity Center, FSx) because AWS Managed Microsoft AD must query users and groups in the other directory. A forest trust is transitive, so a single trust to the on-premises forest root authenticates users in every child domain with the least effort. Linux WorkSpaces (Amazon Linux, RHEL, Rocky, Ubuntu) use SSSD, which does not support forest trusts, so they require an external trust instead.

Trap Configuring a forest trust for Linux WorkSpaces, whose SSSD integration only works over an external trust.

8 questions test this

Client-side LDAPS encrypts AWS-to-on-prem LDAP; server-side LDAPS needs an enterprise CA on the AWS domain controllers

Client-side LDAPS encrypts traffic from AWS Managed Microsoft AD acting as an LDAP client to self-managed on-premises domain controllers; you register the CA certificate that chains to the on-prem server certificates, and a chain mismatch is the usual cause of failures. Server-side LDAPS (for apps querying the AWS directory) requires certificates issued by a Microsoft Enterprise CA joined to the AWS Managed Microsoft AD domain — third-party CA certificates installed directly on the controllers are rejected.

Trap Trying to install a third-party CA's certificate straight onto the AWS Managed Microsoft AD domain controllers for server-side LDAPS, which only accepts a joined enterprise CA.

3 questions test this

Selective authentication on a trust limits which users can authenticate via 'Allowed to Authenticate'

Enabling selective authentication on a two-way trust restricts cross-trust access to only the principals explicitly granted the 'Allowed to Authenticate' permission on the relevant computer objects in the trusting directory. If selective authentication is enabled on the on-premises side, AWS application service accounts (for WorkSpaces, FSx, and similar) must be granted that permission or provisioning fails.

Trap Leaving the AWS application service account without 'Allowed to Authenticate' after selective authentication is enabled, which silently blocks WorkSpaces provisioning.

4 questions test this

Three identities, three front doors

Workforce sign-in: IAM Identity Center and federation

IAM Identity Center

SAML 2.0 vs OIDC federation to IAM

AWS Directory Service

Customer sign-in: Cognito user pools and identity pools

User pool: the directory and token issuer

Identity pool: the AWS credentials broker

The combined flow

Machine credentials: roles, STS, and presigned URLs

STS operations and their lifetimes

IAM Roles Anywhere

S3 presigned URLs

Exam-pattern recognition

Troubleshooting authentication failures

CloudTrail is the first stop

Service-specific failure points

Reading the evidence

Which authentication service for which identity

Decision tree

Cheat sheet

Also tested in

References