Introduction

When people ask which profile is default in a CLI, they are usually dealing with tools that support multiple named credential sets, such as AWS CLI. The confusion comes from precedence rules, because command flags, environment variables, and config files can all override each other. The safest approach is to inspect effective runtime configuration, not only static files.

Understand What Default Means in Practice

In many CLIs, the word default does not mean one fixed value in one fixed file. It means the profile that will be selected for this specific command execution.

For AWS CLI specifically, profile selection usually follows this order:

1. Explicit command flag such as --profile dev.
2. Environment variable such as AWS_PROFILE.
3. Fallback profile name default in config and credentials files.

Because of that order, opening your config file and seeing [default] does not guarantee that your current shell session uses it.

Check Effective Profile in Your Current Shell

Start with shell-level visibility. This detects overrides before you run any command that talks to cloud services.

echo "AWS_PROFILE=${AWS_PROFILE:-unset}"
echo "AWS_DEFAULT_PROFILE=${AWS_DEFAULT_PROFILE:-unset}"

Then inspect resolved configuration from AWS CLI.

aws configure list

This output shows where each value came from, such as environment variable or shared config file. That source column is often more useful than the value itself when debugging profile behavior.

List all known profiles:

aws configure list-profiles

If you see only one profile and no environment override, your effective default is usually the default profile.

Build a Reusable Default-Profile Check Script

If your team frequently switches profiles, a small script reduces mistakes.

1#!/usr/bin/env bash
2set -euo pipefail
3
4if [[ -n "${AWS_PROFILE:-}" ]]; then
5  echo "Effective profile from AWS_PROFILE: ${AWS_PROFILE}"
6elif [[ -n "${AWS_DEFAULT_PROFILE:-}" ]]; then
7  echo "Effective profile from AWS_DEFAULT_PROFILE: ${AWS_DEFAULT_PROFILE}"
8else
9  echo "No profile env var set. CLI will use profile: default"
10fi
11
12echo "---"
13aws configure list

This script does not guess. It reports active environment overrides and then prints the resolved config source data.

Verify by Identity, Not Only by Profile Name

A profile name can point to unexpected credentials after edits, shell reloads, or role chaining changes. Always verify with an identity command when you need certainty.

aws sts get-caller-identity

For explicit comparison:

aws sts get-caller-identity --profile default
aws sts get-caller-identity --profile dev

This confirms which account and principal are actually being used.

Diagnose Surprising Results

If output is not what you expect, check these areas in order:

1. Shell environment variables.
2. CLI version and plugin behavior.
3. Shared config and credentials file paths.
4. Wrapper scripts or aliases that inject --profile.

Helpful checks:

which aws
aws --version
alias | grep aws || true

If your environment uses custom paths, inspect those too:

echo "AWS_CONFIG_FILE=${AWS_CONFIG_FILE:-~/.aws/config}"
echo "AWS_SHARED_CREDENTIALS_FILE=${AWS_SHARED_CREDENTIALS_FILE:-~/.aws/credentials}"

Custom file locations are a frequent source of confusion in CI jobs and developer containers.

CI and Automation Guidance

In automation, implicit defaults are risky. Make profile choice explicit so jobs are reproducible.

Example in shell scripts:

export AWS_PROFILE=ci-deploy
aws s3 ls

Or pass profile directly on each command:

aws s3 ls --profile ci-deploy

Also log identity at the start of a job. It is a low-cost check that prevents high-cost account mistakes.

Cross-Tool Notes

Many CLIs follow a similar model even if variable names differ:

• Env var override.
• Command flag override.
• Default named profile fallback.

The key lesson transfers across tools. Diagnose effective runtime profile first, then fix file-level configuration only if needed.

Common Pitfalls

• Assuming [default] in config is always active.
• Forgetting environment variables exported in old shell sessions.
• Using aliases or wrappers that silently add profile flags.
• Trusting profile names without verifying resolved caller identity.
• Relying on implicit defaults in CI pipelines.

Summary

• Default profile behavior is determined by runtime precedence, not one file entry.
• Check environment variables and aws configure list before debugging deeper.
• Validate with sts get-caller-identity when account correctness matters.
• Use explicit profile settings in automation for repeatable behavior.
• Treat profile diagnostics as part of operational safety, not only local convenience.