Hey there! I totally get the frustration of dealing with wrong AWS credentials or permission errors when switching between accounts—been there, done that. Luckily, there are straightforward CLI commands to cover all your needs, let's break them down:

1. Verify AWS Credential Validity & Check Current IAM Identity #

The most lightweight and reliable command for this is:

aws sts get-caller-identity

Here's why it’s perfect for your needs:

• It doesn’t require any service-specific permissions (like EC2 access) — it only checks if your credentials are valid and returns your identity details.
• The output will clearly show:
  • Account: Your AWS account ID
  • UserId: Unique ID for your IAM user/role
  • Arn: The full Amazon Resource Name of your identity (you’ll instantly see if you’re logged in as an IAM user or a role)
• If your credentials are invalid (wrong access key, expired token, etc.), it’ll immediately throw an error like InvalidClientTokenId so you know to fix your config.
• For named profiles, just add the --profile flag:

  aws sts get-caller-identity --profile marketing-team
  

Compared to the aws ec2 describe-instances command you tried, this is far better for quick validation because it doesn’t depend on having EC2 permissions enabled.

2. Query IAM User's Permissions & Attached Roles #

Once you’ve confirmed your identity, use these commands to dig into your permissions and roles:

a. List Attached Policies (Managed & Inline) #

• View managed policies attached to your user:

  aws iam list-attached-user-policies --user-name <your-iam-username>
  

• View names of inline policies tied to your user:

  aws iam list-user-policies --user-name <your-iam-username>
  

• Get the full content of an inline policy:

  aws iam get-user-policy --user-name <your-iam-username> --policy-name <policy-name>
  

b. Check Roles You Can Assume #

If your user is allowed to switch to other IAM roles:

• First, check your user’s policies for the sts:AssumeRole permission (use the policy commands above to scan for this action).
• To test assuming a role, run:

  aws sts assume-role --role-arn <arn-of-the-role> --role-session-name temp-session
  

  The output will include temporary credentials — you can use these to set environment variables or update your profile, then run aws sts get-caller-identity again to confirm you’re acting as the role.

c. Simulate Permissions (Test Action Access) #

If you want to quickly verify if you can perform a specific action (like launching an EC2 instance or writing to S3), use:

aws iam simulate-principal-policy --policy-source-arn <your-user-arn> --action-names "ec2:RunInstances"

This will return a clear Allowed or Denied result, along with details about which policy is governing the permission.

3. Fixing the decode-authorization-message Error #

The InvalidAuthorizationMessageException you hit usually happens for one of these reasons:

• You copied the encoded-message incorrectly (double-check for missing characters, extra spaces, or typos — the string is base64-encoded and needs to be exact).
• Your IAM user doesn’t have the sts:DecodeAuthorizationMessage permission, so even a valid message will fail.
• This command only works with the EncodedMessage field from an actual AccessDenied error response. Make sure you’re using the exact string from the error you received when running another CLI command.

内容的提问来源于stack exchange，提问作者PatS