Access Keys and IAM Security Best Practices

An access key is a pair of values — an access key ID and a secret access key — used for programmatic access to AWS (from a script, an application, or the AWS CLI) instead of a Console password. If you ever see a placeholder for one in documentation or a tool's setup instructions, it's typically shown as something like:

AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY=YOUR_SECRET_ACCESS_KEY

Both values together are a credential — functionally equivalent to a password for whatever permissions the identity holding them has. Treat them with exactly that level of care.

A short, concrete list, every item of which comes up in real engineering teams sooner or later:

• Never commit an access key to Git — not even to a private repository. Once committed, treat it as compromised, even if you delete it in a later commit (it's still in the repository's history).
• Never put an access key into frontend or browser-facing code — anything that reaches a browser is visible to anyone who opens their developer tools.
• Don't paste access keys into screenshots, support tickets, public forums, or (worth saying plainly) course exercise submissions of any kind.
• If a key is ever exposed, revoke it immediately and issue a new one — don't wait to confirm whether it was actually misused first.

Lesson 3 already made this point for workloads specifically: an IAM role, assumed to get short-lived, automatically-expiring credentials, avoids the long-lived-key problem entirely. Wherever a workload can use a role instead of a stored access key, that's the safer default — access keys remain necessary for some use cases (certain local tooling, some third-party integrations), but they should be the fallback, not the first choice.

Pulling every lesson in this module into one list:

• Grant only the permissions a task requires (least privilege) — remove permissions and credentials that are no longer used.
• Prefer roles and temporary credentials over long-lived access keys wherever the workload allows it.
• Protect the root user specifically: MFA enabled, no root access keys, not used for everyday work.
• Never share IAM users or access keys between people or applications — each identity should represent one clear owner.
• Never commit credentials to Git, and never expose them in browser-facing code, screenshots, or public posts.
• Rotate or revoke credentials immediately if there's any doubt about whether they were exposed.