Add another lock to sign-in — IAM and MFA

Your goal

Plan stronger sign-in protection for people who manage cloud resources.

Why this matters

A stolen password should not be enough to enter an important account. You will choose an extra sign-in check, plan recovery, and learn what MFA does not protect by itself.

Words you will use

MFA means multi-factor authentication. It adds proof beyond a password. Phishing tries to trick someone into giving away access. A recovery method helps regain legitimate access.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Choose strong proof

An administrator needs an additional sign-in check that resists fake login pages. Choose a strong option when it is supported.

Which option helps resist phishing?

A phishing-resistant passkey or security key.

Passkeys and security keys can provide phishing-resistant authentication when supported and configured correctly. Choose suitable methods for the account’s identity system and test that people can use them.

The sign-in plan includes stronger proof of identity.

Supported MFA method → stronger sign-in verification

2. Prepare for a lost device

The only registered device is lost during a trip. The team needs a recovery plan without casually removing protection for anyone who asks. Choose a preparation.

What should be planned before loss?

Supported backup methods and a verified recovery process.

Register appropriate backup methods where supported and document how identity will be verified during recovery. Keep recovery material protected. A recovery path must not become an easier route for an attacker.

A legitimate user has a protected way to recover access.

Device loss → verified recovery → replacement method

3. Understand the boundary

A developer enabled MFA for console sign-in but left a long-lived API access key in a public repository. Choose the correct response.

Does sign-in MFA make that exposed key safe?

No; revoke the key and use appropriate credential controls.

MFA at sign-in does not automatically protect every use of a long-lived API key. Treat exposed credentials as compromised. Prefer short-lived credentials and carefully scoped permissions for the workflow.

The team separates sign-in protection from API credential safety.

Exposed key → revoke and investigate → safer credentials

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.