Identity and Access Management practice questions

An MFA-enforcement deny must exempt the self-service actions a user needs to enroll a device; this is done inside the deny statement with NotAction, because an explicit deny cannot be overridden by an allow.

The enrollment calls fail because the deny matches them. The fix is to stop the deny from covering them: NotAction lists the MFA self-service actions (such as iam:CreateVirtualMFADevice, iam:EnableMFADevice, iam:ResyncMFADevice, iam:ListMFADevices) and iam:GetUser, and the deny applies to everything else. A separate Allow loses to the explicit deny. Switching to Bool does not help console users, whose sessions carry the key with the value false. Moving the deny into a permissions boundary keeps it a deny.

1. Recognize that the enrollment calls are blocked by an explicit deny.
2. Recall that an explicit deny beats every allow, so adding an Allow cannot help.
3. Exclude the enrollment actions from the deny itself with NotAction.
4. Keep BoolIfExists so long-term access-key requests stay denied.

Exam tip: To let users bootstrap MFA, carve the enrollment actions out of the deny with NotAction; never try to override a deny with an allow.

MFA factors differ in phishing resistance. FIDO2 security keys and passkeys are origin-bound; TOTP codes, whether from an app or a hardware token, can be relayed by a real-time phishing proxy.

The exercise shows that a typed one-time code can be captured and replayed within seconds. Only an origin-bound factor stops this, because the authenticator refuses to produce a valid response for the lookalike origin. A hardware TOTP token is the tempting choice ("hardware" sounds stronger), but it still yields a relayable code, and tightening aws:MultiFactorAuthAge does not help when the relay happens within seconds.

1. Identify the threat: real-time relay of a password plus a one-time code.
2. Separate code-based factors (virtual or hardware TOTP) from origin-bound factors (FIDO2).
3. Choose the factor whose response cannot be used on a different site.

Exam tip: For phishing resistance choose FIDO2 security keys or passkeys; any TOTP code, hardware or virtual, can be relayed.

For OIDC workload federation the role trusts the IAM OIDC provider for token.actions.githubusercontent.com and checks two token claims: aud (sts.amazonaws.com for the AWS action's default) and sub (repo:<org>/<repo>:ref:refs/heads/<branch> for a branch run). In the options, "…" stands for token.actions.githubusercontent.com.

Both claims must match what the token actually carries and be no broader than the requirement. An organization-wide or repository-wide wildcard on sub lets other repositories or branches assume the role. A correct sub with the wrong audience fails closed, because the token's aud is sts.amazonaws.com. IAM also refuses to save a GitHub trust policy whose sub condition is missing or is only a wildcard, but it accepts the broader patterns shown, so the scope is still the author's job.

1. Recall the default aud claim for the AWS credentials action: sts.amazonaws.com.
2. Recall the sub format for a branch run: repo:<org>/<repo>:ref:refs/heads/<branch>.
3. Reject patterns that admit other repositories, branches or pull requests.
4. Reject an aud value the token does not carry.

Exam tip: Scope GitHub OIDC roles with aud = sts.amazonaws.com and an exact sub for the repository and branch; wildcards widen who can deploy.

Long-term access keys never carry MFA context. An IAM user gets MFA-bearing credentials by calling GetSessionToken (or AssumeRole) with SerialNumber and TokenCode.

With roles ruled out, GetSessionToken is the STS call that turns long-term keys plus a current MFA code into temporary credentials with aws:MultiFactorAuthPresent = true. Calling it without the MFA parameters gives a session without MFA. GetFederationToken cannot carry MFA at all. The CLI mfa_serial setting is tempting, but it only drives an MFA prompt when the profile assumes a role.

1. Note the constraint: long-term keys, no role.
2. Recall which STS calls accept SerialNumber and TokenCode: GetSessionToken and AssumeRole.
3. Rule out GetFederationToken, which carries no MFA context.
4. Use the returned temporary credentials for the protected call.

Exam tip: From long-term keys without a role, GetSessionToken with the MFA serial and code is how an IAM user gets an MFA-present session.

Direct SAML 2.0 federation to IAM: create an IAM SAML identity provider from the IdP metadata, create roles that trust it (sts:AssumeRoleWithSAML), and have the IdP send a Role attribute with role/provider ARN pairs chosen from the user's groups.

The deciding constraint is "no AWS directory service": IAM Identity Center with AD Connector would otherwise be a good answer. With AD FS already speaking SAML, the direct path is an IAM SAML provider and roles; group-to-role mapping happens in the IdP's Role attribute. IAM groups cannot be assumed by federated users, and an OIDC web-identity flow does not give AD-group-driven console sign-in.

1. Spot the constraints: one account, existing SAML IdP, no AWS directory service.
2. Choose direct SAML federation to IAM over Identity Center with AD Connector.
3. Map groups to roles through the assertion's Role attribute (role ARN, provider ARN).
4. Remember federated users get role sessions, never IAM users or groups.

Exam tip: For console access from an existing SAML IdP into one account, use an IAM SAML provider and roles; groups map to roles in the Role attribute.

The external ID defends against the confused deputy when a third party assumes roles in many customers' accounts: the vendor generates a unique value per customer, the customer's trust policy requires it, and customers cannot set or change it.

Every request in this scenario, legitimate or not, comes from the vendor's account and IP ranges, so account and IP conditions cannot tell your request from another customer's. Only a value tied to your customer record on the vendor side can. A customer-generated value is the subtle trap: if customers can type the value, a malicious customer can type yours.

1. Recognize the confused deputy: the vendor is trusted, and the attacker is another customer of the vendor.
2. Rule out checks that the vendor's own requests always pass (account, IP).
3. Require sts:ExternalId in the trust policy.
4. Make sure the vendor, not the customer, generates the unique value.

Exam tip: Third-party roles need sts:ExternalId, generated by the vendor per customer and not editable by customers.