☁️ Reading AWS CLI Error Messages

AccessDenied is a permissions error, not a "not found" error — and AWS intentionally keeps it vague.

The operation named in the message, PutObject, tells you exactly which S3 API call was attempted (uploading an object). AccessDenied means the caller's IAM identity (user, role, or federated identity) lacks the required permission — most commonly a missing s3:PutObject action in its policy, a bucket policy that explicitly denies the action, or an SCP (Service Control Policy) restricting it at the AWS Organization level.

Why AWS doesn't say more: for security reasons, AWS deliberately returns the same AccessDenied whether the bucket exists and you lack permission, or the bucket doesn't exist at all — this prevents attackers from using error messages to enumerate which resources exist in someone else's account.

How to debug: check the caller's identity with aws sts get-caller-identity, then review the attached IAM policies and the target bucket's bucket policy for an explicit Deny or a missing Allow.

How to describe this to a colleague: "The upload's getting AccessDenied on PutObject — looks like a permissions issue on my role, not a problem with the file itself." Precisely naming the operation (PutObject) rather than just saying "it's broken" gets you a faster answer from whoever owns IAM.

This error happens entirely client-side, before any request reaches AWS.

The AWS CLI looks for credentials in a defined order: environment variables (AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), the shared credentials file (~/.aws/credentials), a configured SSO session, or an EC2/ECS instance role. "Unable to locate credentials" means none of these produced anything usable — this is different from an ExpiredToken or AccessDenied error, both of which mean the CLI did send a request and AWS responded.

The fix: run aws configure to set up a profile interactively, or check that AWS_PROFILE/AWS_ACCESS_KEY_ID environment variables are set correctly if you're using them, or verify SSO login with aws sso login.

Useful distinction for the exam and for real debugging: "no credentials found" (nothing to send) vs. "AccessDenied" (credentials sent, but insufficient permission) vs. "ExpiredToken" (credentials sent, but no longer valid) — these are three different failure stages and each needs a different fix.

How to describe this to a colleague: "The CLI can't even find any credentials locally — I probably need to run aws configure or log in via SSO again."

ExpiredToken = a time problem with the credentials; AccessDenied = a permissions problem with valid credentials.

Temporary security credentials (issued when you assume an IAM role, use AWS SSO, or use MFA-protected sessions) come with an expiration time — typically 1 to 12 hours depending on configuration. Once that time passes, every API call using those credentials fails with ExpiredToken, regardless of what permissions the underlying role actually has.

This is fundamentally different from AccessDenied, where the credentials are perfectly valid and current, but the IAM policy attached to them simply doesn't allow the specific action being attempted.

The fix for ExpiredToken: re-authenticate — re-run aws sso login, re-assume the role (aws sts assume-role), or re-enter MFA — to get a fresh temporary token. There is no policy to fix; the credentials just need refreshing.

How to describe this to a colleague: "It's not a permissions problem, my session token's just expired — let me log back in." Being precise about which of the two you're seeing saves a colleague from investigating IAM policies when the real fix is a 10-second re-login.

API throttling — a temporary rate limit, not a permanent block.

AWS enforces per-API rate limits (sometimes called "throttling") to protect its own service infrastructure from being overwhelmed. This is unrelated to IAM permissions or account quotas — it's about the frequency of calls, not whether you're allowed to make them at all. The AWS CLI (and SDKs) build in automatic retry logic with exponential backoff; "reached max retries: 4" means it already tried this internally-managed retry a few times before giving up and surfacing the error to you.

Common causes: a script making many rapid describe-instances/describe-* calls in a tight loop (often across many resources or accounts, e.g. in a CI job or inventory scanner), or many processes sharing the same IAM identity hitting the same account-wide limit simultaneously.

The fix: add your own backoff/delay between calls, batch requests where the API supports it (e.g. requesting multiple instance IDs in a single describe-instances call instead of one call per instance), or reduce concurrency.

How to describe this to a colleague: "We're getting throttled — RequestLimitExceeded, not a permissions issue. I'll add some backoff to the script so it doesn't hammer the API." This distinguishes a transient, self-inflicted rate issue from an actual outage or access problem.