Multi-factor authentication (MFA) adds a second factor beyond passwords. Access keys (ID + secret) authenticate CLI/SDK calls—treat secrets like passwords.
MFA types
- Virtual MFA app (Google Authenticator, Authy)
- Hardware MFA keys (FIDO, U2F) for high-privilege users
- Require MFA for sensitive operations via IAM condition keys
Access key hygiene
- Create keys only when CLI/SDK needs them
- Store in password manager or secrets manager—never in Git
- Rotate periodically; delete unused keys
- Prefer temporary credentials from
aws sts assume-role
Example placeholders only: AKIAIOSFODNN7EXAMPLE / wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY appear in AWS docs—do not use these as real credentials.
Configure CLI safely
aws configure --profile sandbox
# Enter access key ID and secret when prompted
# Default region: us-east-1 (or your chosen sandbox region)
chmod 600 ~/.aws/credentialsPractice: Perform IAM steps in the IAM Console or with the AWS CLI in a sandbox account only.
Important interview questions and answers
- Q: Why MFA on root?
A: Password leaks are common; MFA blocks most unauthorized Console logins. - Q: Where not to store secrets?
A: Source code, public repos, Slack messages, or lesson copy-paste into tickets.
Self-check
- Name two MFA options for IAM users.
- What should you do with unused access keys?
Tip: chmod 600 on ~/.aws/credentials; rotate keys you suspect leaked.
Interview prep
- Why MFA?
Second factor blocks most password-only account takeovers.
- Key storage?
Never in Git or chat—use secrets manager or role-based temporary credentials.