AWS Hands-On First Steps: Console, CLI, CloudShell, SDKs & Access Keys

There are five ways to talk to AWS, and on your first day it pays to learn all of them properly rather than stumbling into one and treating the rest as a mystery. You can click in the Management Console, type in the AWS CLI, use the browser-based CloudShell, call AWS from code with an SDK, or describe what you want as infrastructure as code and let AWS build it. Every one of them does the same thing underneath — sends a signed HTTPS request to an AWS service API — so the skill is not memorising buttons, it is understanding the one request/response model and the handful of ways you authenticate to it. Get that right and you can move between the console and the command line without friction, automate confidently, and — most importantly — never leak a credential or run up a surprise bill.

This is an early lesson in the AWS Zero-to-Hero course and it assumes you have already created an account and secured the root user (covered in the Cloud Fundamentals lesson). We go deeper than a typical “getting started” page: by the end you will be able to install and configure the CLI with named profiles and IAM Identity Center (SSO), read a ~/.aws/config file fluently, slice JSON with --query and JMESPath, explain the credential provider chain that decides which credentials a tool actually uses, articulate exactly why long-lived access keys are discouraged, and know when to stop clicking and start writing CloudFormation. Everything here maps to the AWS Certified Cloud Practitioner (CLF-C02) and is assumed knowledge for the Solutions Architect Associate (SAA-C03).

Learning objectives

By the end of this lesson you can:

• Navigate the Management Console with intent — the Region selector, the services search, Resource Groups, and a consistent tagging scheme.
• Install the AWS CLI v2, run aws configure, and manage multiple named profiles in ~/.aws/config and ~/.aws/credentials.
• Configure and use IAM Identity Center (SSO) for short-lived credentials with aws configure sso and aws sso login.
• Control CLI output with --output formats and extract exactly the fields you want with --query (JMESPath) and handle pagination.
• Use CloudShell for a zero-install, already-authenticated shell, and understand what an SDK (e.g. boto3) gives you over the CLI.
• Explain the default credential provider chain, the difference between access keys, IAM Identity Center/SSO and IAM roles, the role of MFA, and why long-lived keys are a liability.
• Recognise when to abandon click-ops in favour of CloudFormation / IaC for anything you intend to keep.

Prerequisites & where this fits

You should have an AWS account with the root user secured by MFA and a non-root IAM (or Identity Center) user for daily work, plus a basic grasp of Regions and Availability Zones — all from the Cloud Fundamentals lesson. You do not need any programming experience; the SDK section is conceptual. This lesson sits in the Foundations module of the AWS Zero-to-Hero course, immediately after fundamentals and IAM, and it is the practical on-ramp the entire rest of the course relies on: every later lab gives you both console steps and aws CLI commands, so the fluency you build here pays off in every lesson that follows.

Core concepts

Before the tools, fix four mental models. They explain why everything else is shaped the way it is.

Everything is an API call. There is no “the console” doing something special. When you click Launch instance, the console sends ec2:RunInstances to the EC2 API in your selected Region. The CLI sends the same request when you type aws ec2 run-instances. An SDK sends it from your code. CloudFormation sends a sequence of them on your behalf. So the console, CLI, SDK and IaC are four interfaces over one API surface, and anything you can do in one you can (almost always) do in the others. This is why an architect treats the console as a place to explore and the CLI/IaC as the place to operate.

Every request is signed and authenticated. AWS does not accept anonymous calls to your resources. Each request is cryptographically signed (with Signature Version 4) using a set of credentials, and AWS checks both who you are (authentication) and whether you may do it (authorisation, via IAM). The credentials can be long-lived access keys or short-lived temporary credentials from a role or SSO — and the entire credentials section below is about getting AWS to use the right ones automatically.

Most things are Regional; a few are global. When you make a request you (implicitly or explicitly) target a Region — ap-south-1 (Mumbai), us-east-1 (N. Virginia), and so on. Create a bucket or an instance in one Region and it is not visible from another. A handful of services are global — IAM, Route 53, CloudFront, Organizations — and a handful of operations are pinned to us-east-1 even when “global” (notably some billing and ACM-for-CloudFront tasks). The console shows your current Region in the top-right; the CLI gets it from your profile or the --region flag.

Identity comes from a principal, not a person. AWS authorises a principal — an IAM user, an IAM role (assumed by a person, a service or a federated identity), or the root user. A best-practice setup has no IAM users with long-lived keys at all: humans sign in through IAM Identity Center (SSO) and receive temporary credentials, and workloads use roles. Keep this target in mind even as we cover access keys, because access keys are the thing you are trying to avoid depending on.

Key terms used throughout: principal (the identity making a request), credentials (what proves the principal), access key (a long-lived AKIA... ID + secret pair), temporary credentials (short-lived ASIA... ID + secret + session token from STS), profile (a named set of CLI settings), STS (Security Token Service, the service that mints temporary credentials), and ARN (Amazon Resource Name, the canonical ID of any resource or principal).

The AWS Management Console

The Console (console.aws.amazon.com) is the web UI: the best place to learn a service, eyeball state, and do one-off tasks. Treat it as your map, not your factory floor.

The Region selector (top-right). This is the single most consequential control in the console and the cause of more “where did my resource go?” confusion than anything else. It sets the Region for the service you are viewing. Create a resource with the selector on Ireland and you will not see it when the selector is on Mumbai. Always glance at it before you create anything. Note the exceptions: global services (IAM, Route 53, CloudFront, Organizations) ignore it, and a few consoles (billing, support) are pinned to us-east-1.

The services search and navigation. The search bar at the top jumps to any of AWS’s 200-plus services by name (type ec2, s3, iam). The star beside a service pins it to the favourites bar. The account menu (top-right, your account/alias) holds Security credentials, Account, and the Region selector. CloudShell has its own icon in the top bar (covered below). The notifications and Cost widgets surface alerts and spend.

Resource Groups. A Resource Group is a saved, dynamic collection of resources defined by a query — usually a tag query (e.g. everything tagged Project=checkout) or a CloudFormation stack. Once grouped, you can view, operate on and apply automation (via Systems Manager) to the whole set at once. Groups are how you impose order on an account that would otherwise be a flat list of hundreds of resources. The Tag Editor (part of Resource Groups) lets you find and bulk-edit tags across services and Regions in one place — invaluable for retrofitting a tag scheme.

Tags — the discipline that makes everything else work. A tag is a key/value label (e.g. Environment=prod, Owner=payments, CostCentre=1234) you attach to almost any resource. Tags are free, but they are the backbone of three things you will care about constantly: cost allocation (Cost Explorer can break the bill down by tag — but only after you activate the tag as a cost-allocation tag in the Billing console), access control (IAM policies can allow or deny based on tags — “attribute-based access control”, ABAC), and automation/grouping (Resource Groups, backup plans, and Systems Manager all target by tag). Decide a small, mandatory tag scheme on day one — Project, Environment, Owner at minimum — and apply it everywhere. Note tag limits: up to 50 tags per resource, keys up to 128 and values up to 256 characters, and keys are case-sensitive (Env and env are different tags — a classic source of broken cost reports).

The console is excellent for learning and for the genuinely one-off. But repeating a console click ten times is a smell: that is what the CLI, and ultimately IaC, are for.

The AWS CLI

The AWS CLI is the command-line interface: the workhorse for operating AWS by hand and the foundation of shell automation. Use version 2 — v1 is legacy and v2 adds SSO support, the aws configure import/sso flows, auto-prompt, and a built-in pager. The command grammar is consistent: aws <service> <operation> [parameters], e.g. aws s3 ls, aws ec2 describe-instances, aws sts get-caller-identity.

Installing

aws --version should report aws-cli/2.x. Avoid installing v1 via pip system-wide; the official bundled installers keep the CLI self-contained and easy to upgrade.

aws configure and the two files

The quickest start is aws configure, which interactively writes your settings:

aws configure
# AWS Access Key ID [None]: AKIA...                (from your IAM user — but read the credentials section first)
# AWS Secret Access Key [None]: ....
# Default region name [None]: ap-south-1
# Default output format [None]: json

This populates the default profile across two files in ~/.aws/ (on Windows, %USERPROFILE%\.aws\):

• ~/.aws/credentials — holds secrets: aws_access_key_id and aws_secret_access_key (and, for temporary creds, aws_session_token).
• ~/.aws/config — holds non-secret settings: region, output, --query defaults, retry behaviour, SSO configuration, role-assumption settings, etc.

The split exists so you can share or commit a config (settings) without ever exposing the credentials. Never commit ~/.aws/credentials to git — it is the single most common way real AWS keys leak. Validate any setup with:

aws sts get-caller-identity
# { "UserId": "...", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/you" }

That call returns who AWS thinks you are — the fastest way to confirm the right credentials and account are in play before you run anything destructive.

Named profiles

A profile is a named bundle of settings/credentials so you can switch between accounts and roles. Create one with aws configure --profile dev, then target it with --profile dev on any command or by exporting AWS_PROFILE=dev for a whole shell session. The files look like this (note the profile prefix in config but not in credentials — a notorious gotcha):

# ~/.aws/config
[default]
region = ap-south-1
output = json

[profile dev]
region = ap-south-1
output = table

[profile prod-admin]
role_arn = arn:aws:iam::222222222222:role/AdminRole
source_profile = dev          # assume the role using dev's credentials
mfa_serial = arn:aws:iam::111111111111:mfa/you   # require MFA to assume it

# ~/.aws/credentials
[default]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

[dev]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

The prod-admin profile above shows role assumption: it has no keys of its own — it uses source_profile = dev to call sts:AssumeRole for a role in another account, optionally forcing MFA. The CLI caches the resulting temporary credentials and refreshes them automatically. This is how you operate across many accounts safely from one set of base credentials (and even that base set is better replaced by SSO, next).

IAM Identity Center (SSO) — the modern way

IAM Identity Center (formerly AWS SSO) is the recommended way for humans to get CLI credentials: you authenticate once in the browser and the CLI receives short-lived credentials that auto-refresh, so there are no long-lived keys on your laptop at all. Configure it with aws configure sso:

aws configure sso
# SSO session name: my-org
# SSO start URL: https://my-org.awsapps.com/start
# SSO region: ap-south-1
# (browser opens; you pick an account and a permission set)
# CLI profile name: prod-admin-sso

This writes an sso-session block and a profile to ~/.aws/config:

[sso-session my-org]
sso_start_url = https://my-org.awsapps.com/start
sso_region = ap-south-1
sso_registration_scopes = sso:account:access

[profile prod-admin-sso]
sso_session = my-org
sso_account_id = 222222222222
sso_role_name = AdministratorAccess
region = ap-south-1

Thereafter you simply run aws sso login --sso-session my-org once per session (it opens the browser), and every command with --profile prod-admin-sso uses fresh temporary credentials. aws sso logout clears the cached token. For day-to-day work across multiple accounts, this is strictly better than access keys — nothing long-lived ever touches disk.

Output formats

The --output flag (or output in a profile) controls how results are rendered:

You can set a default per profile and override per command, e.g. aws ec2 describe-instances --output table.

--query and JMESPath

Most AWS responses are large nested JSON; you rarely want all of it. The --query flag applies a JMESPath expression server-response-side (the CLI filters after receiving the data) so you extract exactly the fields you need:

# Just the instance IDs and their state, as a table:
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{ID:InstanceId, State:State.Name, Type:InstanceType}' \
  --output table

# All bucket names, one per line:
aws s3api list-buckets --query 'Buckets[].Name' --output text

# Filter: only running instances' IDs
aws ec2 describe-instances \
  --query "Reservations[].Instances[?State.Name=='running'].InstanceId" --output text

JMESPath basics worth knowing: [] flattens a list, [?expr] filters, {Alias:field} reshapes into a new object, and | [0] pipes to pick the first element. --query is client-side and different from the server-side --filters that some services offer (e.g. aws ec2 describe-instances --filters Name=instance-state-name,Values=running) — use --filters to reduce what the API returns (faster, cheaper) and --query to shape what you display.

Pagination

Many “list/describe” APIs return results in pages. By default the CLI v2 auto-paginates — it follows NextToken for you and shows everything — and pipes long output through a pager (less). Useful controls:

• --no-cli-pager (or set cli_pager= empty, or AWS_PAGER="") stops output going through less — essential in scripts and CI.
• --max-items N caps the total items returned; --page-size N controls how many are fetched per underlying API call (tune to avoid throttling on huge accounts), and the CLI surfaces a NextToken you can pass to --starting-token to resume.

A common first surprise is a command that “hangs” — it is actually sitting in the pager; press q, then add --no-cli-pager.

Other quality-of-life features

aws help (and aws <service> help, aws <service> <op> help) opens full docs offline. Auto-prompt (aws --cli-auto-prompt, or cli_auto_prompt = on-partial in config) gives interactive parameter completion — superb while learning. Command completion can be enabled for bash/zsh. And --dry-run (supported by many EC2 mutating calls) checks permissions without making the change — a safe way to test a command.

CloudShell

AWS CloudShell is a browser-based shell, launched from the icon in the console’s top bar, that comes pre-authenticated as your current console identity and pre-installed with the AWS CLI, Python (and boto3), Node.js, git, jq and more. There is nothing to install and no credentials to configure — it inherits your console session’s permissions, so aws sts get-caller-identity just works. Each user gets 1 GiB of persistent storage in $HOME per Region (it survives between sessions; the rest of the environment is ephemeral and resets after about 20 minutes idle). CloudShell itself is free (you pay only for any AWS resources your commands create). It runs in the Region shown in the console and can reach the public service endpoints; with CloudShell VPC environments you can also launch it inside a VPC to reach private resources. Use it for quick CLI tasks, learning, and break-glass administration from any machine without setting up local credentials — it is the fastest way to run an aws command safely.

The SDKs (boto3 and friends)

When you want AWS to do something from your own program rather than a shell, you use an SDK — a language library that wraps the same APIs with native types, automatic request signing, retries with back-off, and pagination helpers. AWS publishes SDKs for Python (boto3), JavaScript/TypeScript, Java, .NET, Go, Rust, PHP, Ruby, C++ and more; the CLI itself is built on the Python SDK. Conceptually, the CLI command aws s3api list-buckets is the boto3 call:

import boto3
s3 = boto3.client("s3")
buckets = s3.list_buckets()["Buckets"]   # same API, same response shape

The crucial point for this lesson: an SDK uses the same credential provider chain as the CLI (next section), so the way you authenticate the CLI is the way you authenticate your code — and the right answer for code running on AWS is almost never an access key but an IAM role attached to the compute (an EC2 instance profile, an ECS task role, or a Lambda execution role). The SDK picks those role credentials up automatically with zero configuration. You will use SDKs in depth later in the course; for now, know that the CLI is “the SDK as a command”, and the credential rules are identical.

Credentials and authentication — the part that matters most

This is the section to understand cold, for the exam and for safety. Three things to internalise: what kinds of credentials exist, how a tool decides which to use (the provider chain), and why long-lived keys are discouraged.

The three ways to authenticate

The throughline: prefer temporary credentials (SSO for people, roles for machines) and use access keys only when nothing else is possible — and even then, scope them tightly and rotate them.

Temporary credentials come from STS (Security Token Service). They look like access keys but the ID starts with ASIA and they include a third part, a session token, plus an expiry. Roles and SSO both deliver STS credentials behind the scenes; the CLI/SDK cache and refresh them for you.

The default credential provider chain

When the CLI or an SDK needs credentials, it searches a fixed, ordered list of sources and uses the first one it finds. Knowing this order is how you debug “it’s using the wrong account!” — almost always something earlier in the chain is winning. The order (CLI v2 / SDKs, simplified) is:

1. Explicit command-line/parameters — e.g. --profile, or credentials passed directly in code.
2. Environment variables — AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, and AWS_PROFILE / AWS_REGION.
3. The shared files — ~/.aws/credentials and ~/.aws/config for the selected profile (including role_arn/source_profile assumption and sso-session blocks).
4. SSO token cache — credentials from a current aws sso login.
5. Container credentials — for ECS/EKS, fetched from the task/pod role endpoint.
6. Instance profile (IMDS) — for EC2, the role attached to the instance, retrieved from the Instance Metadata Service.

So if you export AWS_ACCESS_KEY_ID in your shell, it overrides your ~/.aws profile (step 2 beats step 3) — a frequent cause of confusion. Two debugging habits: run aws sts get-caller-identity to see who you actually are, and remember that a stale exported env var is the usual culprit when a profile “isn’t working”. On AWS compute, leave the chain to find the role at steps 5–6 — do not put keys on the box.

MFA

Multi-Factor Authentication adds a second factor (an authenticator app, passkey, or hardware key) on top of the password/keys. Enforce it on the root user (always), on console sign-in for IAM/Identity Center users, and on sensitive role assumption via the mfa_serial setting shown earlier (the CLI then prompts for a code and calls sts:AssumeRole/GetSessionToken with it). IAM policies can also require MFA for sensitive actions with an aws:MultiFactorAuthPresent condition. MFA is the cheapest, highest-leverage control you can apply — a leaked password or key is far less dangerous when a second factor is required.

Why long-lived access keys are discouraged

This is exam-favourite and real-world critical. Long-lived AKIA keys are a liability because:

• They don’t expire. A key leaked in a git commit, a log, a screenshot or a laptop backup stays valid until someone notices and rotates it — attackers scan public repos for AKIA strings within minutes.
• They’re easy to sprawl. Keys get copied into .env files, CI variables, Postman, and teammates’ machines; you lose track of where they live and what they can do.
• They resist rotation. Rotating means updating every place the key is used, so in practice they rarely get rotated.
• There is almost always a better option. Humans should use Identity Center (SSO) for temporary credentials; workloads on AWS should use roles (instance profiles, task roles, Lambda execution roles); CI/CD should use OIDC federation to assume a role with no stored secret at all. Each replaces a standing secret with short-lived, automatically-rotated credentials.

If you must use access keys (a legacy tool, an off-AWS script with no federation), then: grant least privilege, never put them in code or git, store them only in the encrypted ~/.aws/credentials or a secrets manager, enable MFA on the user, and rotate on a schedule. But treat that as the exception you are trying to design away — the whole direction of modern AWS auth is away from long-lived keys.

Infrastructure as code: stop click-ops in production

Everything above is for interacting with AWS. For anything you intend to keep — production environments, anything more than a throwaway test — do not build it by clicking. Manual console changes (“click-ops”) are unrepeatable, undocumented, untestable and impossible to review or roll back; six months later nobody knows why a setting is the way it is, and recreating the environment is archaeology.

The professional answer is infrastructure as code (IaC): you declare the resources you want in a template, and a service provisions and tracks them. On AWS the native service is CloudFormation — you describe resources in a YAML/JSON template, deploy it as a stack, and CloudFormation creates/updates/deletes the resources to match, in dependency order, with automatic rollback on failure. The benefits are exactly the things click-ops lacks: the template is version-controlled (peer-reviewed in git, with history), repeatable (spin up identical dev/stage/prod), self-documenting (the template is the spec), and safe to change (a change set previews what a deployment will alter before you apply it). The AWS CDK lets you author CloudFormation in a real programming language, and Terraform is the popular multi-cloud alternative — but the principle is the same: describe infrastructure as reviewable code, and let a tool reconcile reality to it.

The mental rule for the rest of this course: console to learn and explore, CLI/CloudShell to operate and automate by hand, IaC for anything that lives. You will see a lot of aws CLI in the labs because it makes each step explicit and reproducible — but as your estate grows, those steps graduate into CloudFormation.

The diagram above shows the four interaction surfaces — Console, CLI, CloudShell and SDK — all sending signed requests to the same AWS service APIs, with the credential provider chain feeding each one and IaC (CloudFormation) orchestrating many calls at once.

Hands-on lab

In this lab you will install and configure the AWS CLI with a named profile, prove your identity, explore output shaping with --query, and run the same idea in CloudShell — all within the Free Tier at no cost. (If your organisation uses IAM Identity Center, do the SSO variant noted at each step; otherwise use an IAM user’s access key created for this purpose.)

Step 1 — Install the CLI v2. Install via the official installer for your OS, then confirm:

aws --version
# aws-cli/2.x.x Python/3.x ...

Step 2 — Configure a named profile. Create a profile called kv-lab. If you have access keys from an IAM user:

aws configure --profile kv-lab
# paste Access Key ID / Secret, set region (e.g. ap-south-1), output json

If your org uses Identity Center, instead run aws configure sso (profile name kv-lab) and then aws sso login --profile kv-lab.

Step 3 — Prove who you are. Confirm the profile resolves to the expected identity and account:

aws sts get-caller-identity --profile kv-lab

Expected output is a small JSON object with UserId, Account and an Arn — verify the Account is the one you intend before doing anything else.

Step 4 — Shape some output with --query. List your S3 buckets (you may have none — that is fine) and your current Region’s AZs, two ways:

# Bucket names only, one per line:
aws s3api list-buckets --query 'Buckets[].Name' --output text --profile kv-lab

# Availability Zones in your region as a table:
aws ec2 describe-availability-zones \
  --query 'AvailabilityZones[].{AZ:ZoneName, State:State}' \
  --output table --profile kv-lab

Step 5 — Inspect your files. Open ~/.aws/config and ~/.aws/credentials and confirm the kv-lab profile is present, that config uses the [profile kv-lab] header while credentials (if used) uses [kv-lab], and that no secrets live in config.

Step 6 — Do it in CloudShell. In the console, click the CloudShell icon (top bar). When the prompt appears, run aws sts get-caller-identity — note you did not configure anything; CloudShell inherited your console identity. Run the same describe-availability-zones query to see identical results.

Validation. You have succeeded when: aws --version reports v2; aws sts get-caller-identity --profile kv-lab returns your expected account/ARN; the two --query commands return shaped output (text list and a table); your ~/.aws files show the profile with secrets confined to credentials; and CloudShell ran the same calls with no setup.

Cleanup. Nothing here creates billable resources, so there is nothing to delete. If you created an IAM access key solely for this lab, deactivate or delete it now (IAM → your user → Security credentials) — practising the “remove keys you no longer need” habit. The kv-lab profile entries can stay (they are harmless settings) or be removed from ~/.aws/config/credentials.

Cost note. This lab is entirely Free Tier and costs ₹0 / $0. CloudShell is free; describe/list API calls are free; sts:GetCallerIdentity is free. The valuable habit it builds — using a named profile and verifying identity before acting, and reaching for CloudShell or SSO instead of stashing keys — is exactly what keeps you safe and cheap as your usage grows.

Common mistakes & troubleshooting

Best practices

• Use Identity Center (SSO) for humans and roles for workloads; treat long-lived access keys as a last resort to be designed away.
• Always verify with aws sts get-caller-identity before any consequential command — confirm the account and identity.
• Keep secrets out of ~/.aws/config and out of git; secrets belong only in ~/.aws/credentials (or a secrets manager), never in code.
• Use named profiles per account/role and switch with --profile or AWS_PROFILE; never juggle accounts by editing the default profile.
• Set a deliberate tag scheme (Project, Environment, Owner) on day one and activate the cost-allocation tags you care about.
• Use the console to explore, the CLI/CloudShell to operate, and CloudFormation/CDK for anything you intend to keep.
• Prefer CloudShell or short-lived SSO on machines you don’t control rather than copying keys around.
• Enable MFA on root, on console sign-in, and on sensitive role assumption (mfa_serial).

Security notes

The security of your entire AWS estate begins at the credential. Three habits flow directly from this lesson. First, eliminate standing secrets: humans should authenticate through IAM Identity Center for temporary credentials, and every workload on AWS should run with an IAM role (instance profile, task role, Lambda execution role) so the SDK/CLI picks up short-lived credentials automatically — there is then simply no AKIA key to leak. Second, assume any long-lived key will eventually leak and design accordingly: scope it to least privilege, never place it in code/git/logs, store it only encrypted, pair it with MFA, and rotate it — but better, replace it with SSO or OIDC federation. Third, always know who you are: aws sts get-caller-identity and an understanding of the credential provider chain are your defence against accidentally operating in the wrong account or with over-broad permissions. Finally, remember the console’s Region selector and the global-vs-Regional distinction are security-relevant too: resources created in an unexpected Region escape the monitoring and guardrails you set up elsewhere.

Interview & exam questions

1. What is the difference between the AWS Console, CLI, an SDK and CloudFormation? They are four interfaces over the same service APIs: the Console is the web UI for exploring and one-off tasks; the CLI is the command line for operating and scripting by hand; an SDK calls the same APIs from your code; CloudFormation declares many resources as code and provisions them as a tracked stack. Anything you can do in one you can essentially do in the others, because all send signed requests to the same APIs.

2. Explain the default credential provider chain. Why does it matter? It is the fixed order in which the CLI/SDK look for credentials, using the first found: command-line/explicit params, then environment variables, then the shared ~/.aws files (profiles, role assumption, SSO), then the SSO token cache, then container credentials (ECS), then the EC2 instance profile via IMDS. It matters because “the CLI is using the wrong account” is almost always something earlier in the chain (often an exported env var) winning over your profile.

3. Why are long-lived IAM access keys discouraged, and what should you use instead? Because they don’t expire, sprawl across machines and files, resist rotation, and are scanned for by attackers — a single leak is a standing compromise. Use temporary credentials instead: IAM Identity Center (SSO) for humans, IAM roles (instance/task/execution roles) for workloads, and OIDC federation for CI/CD — all short-lived and auto-rotated.

4. What is the difference between ~/.aws/config and ~/.aws/credentials? config holds non-secret settings (region, output, query defaults, SSO config, role-assumption settings) and uses [profile name] headers; credentials holds the secret access key/secret (and session token) and uses [name] headers with no profile prefix. The split lets you share settings without exposing secrets — and you should never commit credentials.

5. How do temporary credentials differ from access keys, and where do they come from? Temporary credentials are short-lived (often one hour, auto-refreshed) and consist of an ASIA... ID, a secret, and a session token, whereas access keys are long-lived AKIA... ID/secret pairs. Temporary credentials are issued by STS when you assume a role or sign in via Identity Center.

6. What does CloudShell give you, and how is it authenticated? A browser-based shell, pre-installed with the CLI/boto3/jq/git and pre-authenticated as your current console identity, with 1 GiB of persistent home storage per Region. You configure nothing — it inherits your console session’s permissions — and it is free except for resources you create.

7. What is --query and how does it differ from --filters? --query applies a JMESPath expression on the client side to shape/extract fields from the response. --filters (on services that support it) is applied server-side to reduce what the API returns. Use --filters to fetch less (faster/cheaper) and --query to display exactly what you want.

8. How do you operate across multiple AWS accounts from the CLI safely? Use named profiles: a base profile (ideally SSO) plus profiles that assume roles in other accounts via role_arn + source_profile, optionally with mfa_serial to require MFA. The CLI mints and caches temporary credentials per role, so you never copy keys between accounts.

9. Your aws command “hangs” with no output. What is happening? It is almost certainly sitting in the less pager that CLI v2 uses for long output. Press q to exit, and add --no-cli-pager (or set AWS_PAGER="") — important in scripts and CI where there is no interactive terminal.

10. Why is click-ops discouraged for production, and what replaces it? Manual console changes are unrepeatable, undocumented, unreviewable and hard to roll back. Replace them with infrastructure as code — CloudFormation (or CDK/Terraform) — so infrastructure is version-controlled, repeatable across environments, self-documenting, and previewable via change sets with automatic rollback.

11. Where should an application running on EC2 get its AWS credentials? From an IAM role attached to the instance (an instance profile), retrieved automatically by the SDK/CLI from the Instance Metadata Service via the credential provider chain. You should never place access keys on the instance.

12. What is the role of tags, and what must you do for tag-based cost reporting to work? Tags are key/value labels used for cost allocation, attribute-based access control, and grouping/automation. For cost reporting you must activate the relevant tag as a cost-allocation tag in the Billing console, and keep key casing consistent (tags are case-sensitive, so Env ≠ env).

Quick check

1. Which file should never be committed to git, and why?
2. You exported AWS_ACCESS_KEY_ID earlier and now --profile dev “isn’t working”. What is the likely cause?
3. Name the service that issues temporary credentials when you assume a role.
4. Which CLI flag shapes/extracts fields from a response using JMESPath?
5. For a human who needs CLI access across several accounts, which auth mechanism is recommended over access keys?

Answers

1. ~/.aws/credentials — it holds the secret access key/secret; leaking it exposes live AWS credentials. (~/.aws/config is settings-only and safer to share.)
2. The environment variable wins over the profile — env vars come before the shared files in the credential provider chain. unset AWS_ACCESS_KEY_ID (and friends) or pass credentials explicitly.
3. STS (Security Token Service).
4. --query (a JMESPath expression). (--filters, where supported, reduces results server-side.)
5. IAM Identity Center (SSO) — it issues short-lived, auto-refreshing credentials so no long-lived keys live on disk.

Exercise

On a machine you control, set up a clean, professional CLI configuration and document it. Specifically: (a) install CLI v2 and create at least two named profiles — if possible one using IAM Identity Center (SSO) and one that assumes a role via role_arn/source_profile (you can target a role in the same account for practice); (b) write down, for each profile, the exact ~/.aws/config and ~/.aws/credentials entries, noting which header style each file uses and confirming no secret appears in config; © run aws sts get-caller-identity under each profile and record the differing ARNs; (d) demonstrate one --query and one --filters command and explain which runs client-side vs server-side; and (e) in two or three sentences, explain how you would re-architect a hypothetical script that currently hard-codes an access key so that it uses no long-lived secret at all. This mirrors exactly the setup an architect is expected to stand up on a new machine.

Certification mapping

This lesson maps to the AWS Certified Cloud Practitioner (CLF-C02) exam, chiefly the Cloud Technology and Services domain (the ways to access and interact with AWS — Console, CLI, SDKs, CloudShell, and infrastructure as code via CloudFormation) and the Security and Compliance domain (the difference between the root user, IAM users, IAM Identity Center and roles; access keys vs temporary credentials; MFA; and why least privilege and avoiding long-lived keys matter). The credential provider chain, named profiles, role assumption and --query/pagination fluency are then assumed knowledge for the Solutions Architect Associate (SAA-C03), SysOps Administrator Associate (SOA-C02) and Developer Associate (DVA-C02) exams, all of which expect you to operate AWS confidently from the CLI and to reason about how applications obtain credentials securely.

Glossary

• Management Console — The AWS web UI for exploring services and performing one-off tasks; its Region selector sets the Region for Regional services.
• AWS CLI — The command-line interface (use v2) for operating AWS by hand and in scripts; grammar is aws <service> <operation> [params].
• CloudShell — A browser-based, pre-authenticated shell with the CLI and tools pre-installed and 1 GiB of persistent home storage per Region.
• SDK — A language library (e.g. boto3 for Python) that calls AWS APIs from code, using the same credential provider chain as the CLI.
• Profile — A named bundle of CLI settings/credentials, stored across ~/.aws/config (settings) and ~/.aws/credentials (secrets).
• Access key — A long-lived credential pair (AKIA... ID + secret) belonging to an IAM user; discouraged in favour of temporary credentials.
• Temporary credentials — Short-lived credentials (ASIA... ID + secret + session token) issued by STS for roles and SSO; auto-refreshed.
• IAM Identity Center (SSO) — The recommended way for humans to obtain temporary credentials via browser sign-in (aws configure sso / aws sso login).
• IAM role — An assumable identity that yields temporary credentials; used by workloads (instance/task/execution roles), cross-account access and federation.
• STS — Security Token Service; the service that mints temporary credentials.
• Credential provider chain — The fixed order in which the CLI/SDK search for credentials, using the first found (params → env vars → files → SSO cache → container → instance profile).
• MFA — Multi-Factor Authentication; a second sign-in factor enforced on root, console sign-in, and sensitive role assumption (mfa_serial).
• JMESPath / --query — A query language and the CLI flag that uses it to shape/extract fields from a response (client-side).
• Pagination — How list/describe APIs return results in pages; CLI v2 auto-paginates and pipes long output through a pager (--no-cli-pager to disable).
• Tag — A key/value label on a resource, used for cost allocation, ABAC access control, and grouping/automation.
• Resource Group — A saved, dynamic collection of resources (usually by tag query) for viewing and operating on many resources at once.
• CloudFormation / IaC — Infrastructure as code; declare resources in a template and provision them as a tracked stack instead of clicking (“click-ops”).

Next steps

You can now talk to AWS the way a professional does — exploring in the Console, operating with named CLI profiles, reaching for CloudShell or SSO instead of stashing keys, and understanding exactly how a tool decides which credentials to use. The natural next move is to put that fluency to work on the most fundamental compute service. Continue with Amazon EC2, In Depth: Instance Types, AMIs, EBS, User Data, IMDS & Every Launch Option (aws-ec2-deep-dive-instances-amis-ebs-user-data-imds), where every launch decision — and the very IMDS endpoint your instance role credentials come from — is covered in full. From there the course goes deep on storage, networking, databases and observability, every lab giving you both console steps and the aws commands you have just learned to run.