# AWS CLI

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/aws-cli

## Quick definition

The AWS CLI is a program you run on your computer that lets you talk to Amazon Web Services by typing commands. Instead of clicking buttons in a web page, you type instructions and get text responses. It is useful for automating tasks and managing cloud resources without a graphical interface.

## Simple meaning

Imagine you are a chef in a busy kitchen. Your kitchen has many appliances: an oven, a blender, a refrigerator, and a stove. Each appliance has its own set of knobs, buttons, and displays. To cook a meal, you walk around the kitchen and press buttons on each machine. That works fine when you are cooking for one or two people, but if you need to prepare a hundred meals, walking to each appliance and pressing buttons one by one would take forever and you would likely make mistakes. Now imagine that instead of using the physical knobs, you have a single remote control that can talk to every appliance. You press a button on the remote that says "set oven to 350 degrees" and the oven immediately responds. You press another button that says "blend for 30 seconds" and the blender starts. That remote control is like the AWS CLI. It gives you one way to send instructions to all the different Amazon Web Services, like servers, databases, and storage, without having to log into a website and click through menus. The AWS CLI works by letting you type commands into a terminal window, which is a text-based interface on your computer. For example, you can type a command to list all the virtual servers you have running, and the CLI shows you a list of them as text. You can type another command to create a new server, and the CLI makes it happen. The CLI uses something called an API, which is like a set of rules for how software talks to software. When you type a command, the CLI sends a request to Amazon's servers using this API, and Amazon's servers carry out the action. The response comes back as text that you can read on your screen. This is much faster than using a web browser, especially when you need to do many tasks quickly or repeatedly. People who manage cloud systems often write scripts that contain many CLI commands, so they can run dozens or hundreds of actions with one command. The AWS CLI is free to download, but you do need an AWS account and you must set up security credentials so Amazon knows you are allowed to make changes. Once set up, you can use it on Windows, Mac, or Linux computers. It is a powerful tool that gives you fine control over your cloud resources, and it is used by system administrators, developers, and IT professionals every day.

To make it even easier to understand, think of the AWS CLI as a universal translator. You speak English, but each cloud service speaks its own special language. The CLI translates your English-like commands into the exact language each service understands. You do not have to learn the details of each service's own API; the CLI handles that for you. This is why the CLI is so popular: it saves time, reduces errors, and makes it possible to automate repetitive tasks. Without the CLI, you would have to log into the AWS Management Console, click through many pages, and fill out forms every time you wanted to create a resource. With the CLI, you can create a hundred identical servers with a single loop in a script. That efficiency is why the CLI is considered an essential tool for anyone working with AWS.

## Technical definition

The AWS Command Line Interface (AWS CLI) is an open-source tool that enables users to interact with Amazon Web Services from a terminal session. It is built on top of the AWS SDK for Python (boto3) and relies on the AWS API, which uses HTTPS as the underlying protocol. All communication between the CLI and AWS services is encrypted using TLS 1.2 or later, ensuring that credentials and data are secure during transit.

When a user executes a command, the AWS CLI performs several steps. First, it parses the command line arguments to determine the target service, the action, and any parameters. It then loads the user's AWS credentials, which are typically stored in a configuration file at ~/.aws/credentials on Linux or macOS, or in C:\Users\username\.aws\credentials on Windows. These credentials consist of an access key ID and a secret access key, which are generated from the AWS Management Console (or through the CLI itself). Optionally, users can also configure a default region and output format in the ~/.aws/config file.

Once credentials are loaded, the CLI constructs an HTTP request. This request includes the action to be performed, any input parameters (such as instance type or bucket name), and a signature. The signature is created using the AWS Signature Version 4 signing process. This cryptographic process ensures that the request has not been tampered with and that the sender is authenticated. The request is sent over HTTPS to the appropriate AWS service endpoint, for example ec2.us-east-1.amazonaws.com for EC2 operations in the US East region.

The AWS service receives the request, validates the signature, checks permissions using AWS Identity and Access Management (IAM), and then executes the requested action. The response is returned in a structured format, typically JSON or text, which the CLI then formats and displays to the user. By default, the AWS CLI outputs to standard out in JSON format, but users can specify other output formats such as table (human-readable columns) or text (each value on a separate line). For scripting and automation, the JSON output is most useful because it can be piped into other command-line tools like jq for further processing.

The AWS CLI supports over 200 AWS services, including EC2 (compute), S3 (storage), IAM (identity), Lambda (serverless), DynamoDB (database), and many more. Each service has its own set of subcommands, arguments, and options. For example, the command "aws ec2 describe-instances" calls the EC2 service to list all running instances. The command "aws s3 cp myfile.txt s3://my-bucket/" copies a local file to an S3 bucket. These commands can be combined in shell scripts, making it possible to orchestrate complex workflows like deploying an entire application stack with a single script.

One of the key technical features of the AWS CLI is its support for pagination. When a command returns many results (like thousands of S3 objects or EC2 instances), the API splits the results into pages. The CLI automatically handles pagination by making multiple requests in the background and combining the results into a single output, unless the user specifies the --no-paginate option. This is transparent to the user, who sees all results as if they came in one response.

Another important aspect is the use of profiles. Users can create multiple named profiles in the credentials file to manage different AWS accounts or different IAM roles. For example, a developer might have a profile for a development account and another for a production account. The command "aws ec2 describe-instances --profile production" would use the credentials associated with the production profile. This allows a single installation of the AWS CLI to manage multiple environments securely.

The AWS CLI also supports environment variables. If environment variables like AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_DEFAULT_REGION are set, the CLI uses them instead of the configuration files. This is particularly useful in continuous integration/continuous deployment (CI/CD) pipelines or Docker containers, where static configuration files may not be available.

For advanced users, the AWS CLI provides the ability to use command completion, which suggests options and subcommands when you press the Tab key. It also supports dry-run mode (using the --dry-run flag), which validates that you have permission to perform an action without actually executing it. This is incredibly useful for testing and avoiding accidental changes.

On the network side, the AWS CLI can be configured to use a proxy server, and it supports retry logic for transient failures. By default, it retries up to a certain number of times with exponential backoff, which is essential when working in error-prone network environments.

In terms of installation, the AWS CLI can be installed via pip (Python Package Index), via MSI installer on Windows, via brew on macOS, or via the bundled installer for Linux. The current major version is AWS CLI v2, which introduced many new features including the ability to use SSO (single sign-on) and improved credential management.

Finally, the AWS CLI is not just for humans typing commands. It is designed to be used by scripts and automation tools. Tools like Terraform, Ansible, and CloudFormation often use the AWS CLI behind the scenes to make API calls. Understanding how the AWS CLI works is fundamental to understanding how many cloud automation tools operate, making it a cornerstone skill for cloud professionals.

## Real-life example

Let me tell you a story about Maria, who owns a small bakery called Sweet Bytes. Maria makes custom cakes for birthdays, weddings, and corporate events. She has a team of three bakers, each with their own workstation. Every morning, Maria walks around the bakery and checks each baker's station: is the oven on, does the mixer have attachments, is the refrigerator stocked with cream, and are the cake pans clean? That is fine when she has only three bakers, but her business is growing, and soon she will have twenty bakers. Walking around to check each station will take an hour each morning. So Maria decides to install a central control system. She puts a small tablet on her desk that is connected to every oven, mixer, refrigerator, and pan rack in the bakery. Now she can sit at her desk, type a command on the tablet, and see the status of every oven. She can type another command and set all ovens to preheat to 350 degrees. She can type another command and lock all refrigerators so no one opens them during the afternoon rush. This central tablet is like the AWS CLI. Instead of physically walking to each machine, Maria sends text commands from one place. The tablet sends signals to the machines, and they respond. In the cloud world, instead of logging into a web page to check each server, you open your terminal and type "aws ec2 describe-instances" to see all your servers. Instead of clicking through menus to create a new database, you type "aws rds create-db-instance" and it happens in seconds. Maria loves her tablet because it saves time and reduces mistakes. She can even write a script that runs every morning automatically: preheat ovens, check ingredient levels, and assign tasks to bakers. That script is like a shell script using AWS CLI commands. She can run the same script for a week, a month, or a year, and it always does the same thing. This is the real power of the CLI: repeatability and automation. Without the CLI, you are like Maria walking around the bakery every day, doing the same checks manually. With the CLI, you sit back and let the tool do the work.

Now imagine that Maria's bakery has branches in three different cities. Each branch has its own ovens and refrigerators. With her central tablet, she can send commands to any branch. In AWS, you can manage resources in different regions using the --region flag. For example, "aws ec2 describe-instances --region us-west-2" lists servers in Oregon, while "aws ec2 describe-instances --region eu-central-1" lists servers in Frankfurt. Maria can control all her branches from one tablet, just as a cloud administrator can control resources across the globe from one terminal. This is why the CLI is so powerful for companies that operate globally: it gives you a single pane of glass for all your cloud resources, regardless of where they are located physically.

Maria also discovers that her tablet can be set up to require a password to prevent unauthorized access. In AWS, the CLI uses access keys and secret keys to authenticate you. If someone steals your laptop, they cannot use the CLI without the keys. Maria sets up her tablet with a fingerprint scanner; in AWS, you can enable multi-factor authentication (MFA) for CLI access. The parallels are strong because the underlying concept is the same: secure, centralized control of distributed assets.

Finally, Maria realizes that she can give limited access to her head baker. The head baker can send commands to the ovens but not to the refrigerators. In AWS, you use IAM policies to grant granular permissions. You can create a user who can only list S3 buckets but not delete them, or a user who can start EC2 instances but not terminate them. The CLI respects these permissions, so users cannot exceed their authority. This makes the CLI both powerful and safe.

## Why it matters

In the real world of IT, speed and consistency are critical. When you manage cloud infrastructure, you often need to perform the same actions repeatedly: launching servers, creating storage buckets, updating firewall rules, or deploying code. Doing these tasks through the AWS Management Console is slow and prone to human error. The AWS CLI matters because it allows you to automate these tasks. You can write scripts that run thousands of commands in minutes, and those scripts will execute the same way every time. This is essential for operations like scaling up during a traffic spike or rolling back a failed deployment.

The CLI also matters for version control and auditability. When you use the console, there is no record of what you clicked. When you use the CLI, every command can be logged, recorded, and replayed. This is important for compliance and security. If a server is accidentally deleted, you can look at the logs to see who ran the termination command and when. In many regulated industries, this kind of audit trail is mandatory.

the AWS CLI enables infrastructure as code (IaC). Tools like AWS CloudFormation and Terraform rely on the CLI or equivalent APIs to create and manage resources. Understanding the CLI helps you understand how these higher-level tools work. If you know the CLI commands, you can debug a CloudFormation stack by running the equivalent CLI commands manually.

Another reason the CLI matters is that it works in environments where a browser is not available. For example, in a continuous integration pipeline, your code is built and tested on a server that has no display. The only way to interact with AWS from that server is through the CLI or SDK. If you cannot use the CLI, you cannot fully automate your deployment pipeline.

Finally, the CLI is free and runs on any operating system. This means that whether you are a lone developer on a Mac, a team using Linux servers, or an enterprise locked into Windows, you can use the same tool. The AWS CLI bridges the gap between different platforms and provides a consistent interface to the cloud.

## Why it matters in exams

The AWS CLI is a frequent topic in multiple AWS certification exams. For the AWS Cloud Practitioner exam, you are expected to know what the CLI is and when you would use it instead of the console. You might see questions that present a scenario where an administrator needs to perform a repetitive task on many resources, and the correct answer is to use the CLI or write a script. You also need to understand that the CLI requires access keys for authentication and that MFA can be used for increased security.

For the AWS Developer Associate exam, the CLI is more deeply embedded. You must know how to install, configure, and use the CLI for common tasks like managing S3 buckets, Lambda functions, and DynamoDB tables. Questions may ask about output formats (JSON, text, table) or how to use the --query parameter with JMESPath expressions to filter output. You should understand how to use the CLI with IAM roles and the difference between using access keys and using an IAM role with the CLI. There may be scenario-based questions where you need to choose the correct CLI command to, for example, upload a file to S3 or invoke a Lambda function.

For the AWS Solutions Architect Associate exam, the CLI appears in the context of automating infrastructure tasks. You might see questions about using the CLI to create automated backups, schedule snapshots, or manage lifecycle policies. Understanding how to use the CLI with CloudTrail logging is also relevant. You may need to know that the CLI can be used with the --dry-run flag to validate permissions without making changes, or that pagination is automatically handled.

Beyond AWS exams, the AZ-104 (Azure Administrator) and Azure Fundamentals exams may also reference the concept of CLI tools, though they focus on Azure CLI. Similarly, the Google Associate Cloud Engineer and Digital Leader exams cover the gcloud CLI. While the specific commands differ, the underlying concepts of using a command-line tool to manage cloud resources are universal. In these exams, you might be asked to contrast using the CLI versus the portal, or to identify the correct command for a given task.

In all these exams, the common thread is that you need to know when to use the CLI, the basic syntax, and how to secure it. Questions often test your ability to choose between the CLI, SDK, and console for a specific use case. You might also see questions about configuration: where are credentials stored, what is the purpose of the config file, how to use profiles, and how to set environment variables. Knowing these details can earn you easy points.

Finally, exam questions may present an error scenario, such as "the CLI returns an access denied error" and ask you to troubleshoot. The answer could be that the IAM policy does not allow the action, or that the access keys are expired, or that the profile is incorrectly configured. Being comfortable with the CLI's error messages is important.

## How it appears in exam questions

In certification exams, questions about the AWS CLI appear in several distinct patterns. The first pattern is the "best tool" question. For example, a question describes a developer who needs to perform the same operation on 50 EC2 instances, like adding a tag. The developer needs the fastest and most repeatable method. The answer choices include the AWS Management Console, the AWS CLI, the SDK, and CloudFormation. The correct answer is usually the AWS CLI, because it can be scripted and run from a terminal quickly.

The second pattern is the "command syntax" question. You might be given a scenario and asked which command will accomplish a specific task. For example, "Which AWS CLI command will list all S3 buckets?" with options like "aws s3 list-buckets", "aws s3api list-buckets", "aws s3 ls", etc. The correct answer is "aws s3 ls" (for the simpler s3 command set) or "aws s3api list-buckets" (for the API-level command). Knowing the difference between the high-level s3 commands and the s3api commands is a common point of confusion.

The third pattern is the "configuration and security" question. You might be asked where AWS CLI credentials are stored, or how to use MFA with the CLI. For example, "An administrator needs to use the CLI from a shared workstation. What is the best way to ensure credentials are not stored on the machine?" Answer: Use environment variables or AWS IAM roles with temporary credentials (STS).

The fourth pattern is the "troubleshooting" question. For example, "A user runs a CLI command and gets an 'AccessDenied' error. What is the most likely cause?" The answer could be that the IAM policy does not allow the action, or that the credentials are incorrect, or that the user is not in the correct profile.

The fifth pattern is the "output and filtering" question. You might be asked how to get only specific fields from the output. For example, "Which option will return only the instance IDs of all running EC2 instances?" The answer involves the --query parameter with JMESPath, like "aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId'".

The sixth pattern is the "automation" question. A scenario might describe a cron job or CI/CD pipeline that needs to interact with AWS. The question tests whether you know that the CLI is the appropriate tool for automated scripts.

Finally, the cloud practitioner exam may ask a simpler version: "What is the AWS CLI used for?" with answer choices like "to manage AWS services from a command line" or "to visualize usage patterns". The correct answer is to manage services from a command line.

To prepare, practice writing commands and interpreting output. Many exam simulators include CLI-based questions, and AWS provides free labs through the AWS Skill Builder.

## Example scenario

Scenario: You work for a media company that uploads daily video files to an S3 bucket for processing. Each day, you must upload 20 files from your local computer to a specific S3 bucket named "daily-videos". The files are named with the date and a sequence number, like "2025-03-15-001.mp4". You are tired of logging into the AWS Console, clicking "Upload", selecting each file manually, and waiting for the browser-based upload to finish. You want a faster, repeatable way.

Solution using AWS CLI: You open a terminal window on your computer. First, you configure the CLI with your access key and secret key if you haven't already. Then you navigate to the folder containing the 20 files. You type the command:

aws s3 cp 2025-03-15-001.mp4 s3://daily-videos/

This copies the first file. But you do not want to type that 20 times. So you write a simple loop in your shell (bash on Linux/Mac or PowerShell on Windows). For example, in bash:

for i in {001..020}; do
 aws s3 cp 2025-03-15-$i.mp4 s3://daily-videos/
done

That loop runs the CLI command 20 times, once for each file. The CLI uploads each file, shows progress, and reports success or failure. The whole process takes seconds instead of minutes. You can save this script and run it every day, simply changing the date. You can even schedule it using cron or Task Scheduler to run automatically every morning.

If you need to verify that all files uploaded correctly, you can run:

aws s3 ls s3://daily-videos/

This lists all objects in the bucket. You can see the names and sizes, confirming the upload. If a file failed to upload, you would see an error message like "upload failed: 2025-03-15-005.mp4 to s3://daily-videos/...". You could then manually retry that one file.

This scenario illustrates how the CLI saves time, reduces manual effort, and enables automation. It also shows how the CLI integrates with standard shell scripting tools to handle bulk operations. In the exam, you might see a similar scenario where the task is to upload multiple files, and you need to choose the AWS CLI with a loop as the correct solution.

## Common mistakes

- **Mistake:** Using the wrong command set (e.g., using s3api when s3 would be simpler).
  - Why it is wrong: The s3 commands (aws s3 cp, aws s3 sync, etc.) are higher-level and include features like automatic retries, progress bars, and recursive operations. The s3api commands are low-level and require manual handling of pagination and error retries. Using s3api for a simple upload makes the command longer and more error-prone.
  - Fix: For common operations like uploading, downloading, syncing, and listing files in S3, use the s3 commands. Use s3api only when you need fine-grained control, such as setting specific ACLs or bucket policies.
- **Mistake:** Forgetting to configure the default region, leading to errors like 'You must specify a region'.
  - Why it is wrong: Many CLI commands require a region to know which AWS endpoint to contact. If you do not set a default region via 'aws configure' or the --region flag, the CLI does not know where to send the request, and it returns an error.
  - Fix: Run 'aws configure' and enter a default region (e.g., us-east-1). Alternatively, always include the --region flag in your commands, like 'aws ec2 describe-instances --region us-west-2'.
- **Mistake:** Storing long-term access keys on shared or unsecured machines.
  - Why it is wrong: If someone gains access to your credentials file, they can impersonate you and perform any action your IAM user is allowed to do. This is a serious security risk.
  - Fix: Use temporary credentials from AWS STS (Security Token Service) or use IAM roles for EC2 instances. On shared machines, use environment variables and never save the credentials file.
- **Mistake:** Assuming the CLI output format is always JSON and not using --query for filtering.
  - Why it is wrong: The default output is JSON, which is hard to read for humans. Many users pipe the output to grep or parse it manually, which is inefficient. The CLI has built-in filtering and formatting features.
  - Fix: Use the --query parameter with JMESPath expressions to extract exactly the data you need. For example, 'aws ec2 describe-instances --query "Reservations[*].Instances[*].InstanceId"' returns only instance IDs.
- **Mistake:** Mixing up the order of arguments, especially for commands that require source before destination.
  - Why it is wrong: For commands like 'aws s3 cp' and 'aws s3 mv', the first positional argument is the source and the second is the destination. Reversing them will cause the CLI to try to copy from a bucket to a local path, which might not exist, or worse, overwrite files.
  - Fix: Always remember the pattern: source first, destination second. For example, 'aws s3 cp myfile.txt s3://my-bucket/' (local to bucket) and 'aws s3 cp s3://my-bucket/myfile.txt .' (bucket to local).
- **Mistake:** Not using the --dry-run flag before making destructive changes.
  - Why it is wrong: Without a dry run, you might accidentally terminate instances, delete buckets, or modify permissions. The CLI will execute the command immediately without asking for confirmation.
  - Fix: Add --dry-run to commands that support it (like EC2 start/stop/terminate). The CLI will tell you if your command is valid and if you have permission, without actually performing the action.
- **Mistake:** Believing that CLI commands are case-sensitive when they are not.
  - Why it is wrong: While the CLI itself is case-sensitive for option names (e.g., --query must be lowercase), many users assume they can write 'AWS s3 cp' instead of 'aws s3 cp'. The command 'aws' must be lowercase. Also, parameter values are often case-sensitive, but the command syntax is not flexible.
  - Fix: Always write the base command 'aws' in lowercase. Use the exact casing for subcommands and options as shown in the documentation.

## Exam trap

{"trap":"A question shows a CLI command that uses the --query parameter with a JMESPath expression, but the expression is incorrectly written (e.g., missing brackets or quotes). The trap is to make you think the command is valid when it is not.","why_learners_choose_it":"Learners who have only practiced simple commands may not be comfortable with the exact syntax of --query. They might see a JMESPath expression that looks close to correct and assume it works. Or they may not be aware that --query requires single quotes on Linux/Mac and double quotes on Windows in some cases.","how_to_avoid_it":"Practice using the --query parameter with different commands. Remember that the expression must be a valid JMESPath string. For example, to get instance IDs, the correct expression is: 'Reservations[*].Instances[*].InstanceId'. Note the brackets and dot notation. Test your commands in a sandbox environment before the exam so you become familiar with common patterns."}

## Commonly confused with

- **AWS CLI vs AWS SDK (Software Development Kit):** The AWS CLI is a command-line tool for interacting with AWS services through typed commands. The AWS SDK is a set of libraries in programming languages like Python (boto3), Java, or JavaScript that allow you to write code that calls AWS APIs. The CLI is ideal for manual operations and scripting, while the SDK is used when you need to integrate AWS functionality into a custom application. (Example: If you want to upload a file from your terminal, use the CLI: 'aws s3 cp file.txt s3://bucket'. If you are writing a Python app that uploads a file, use the SDK: 'import boto3; s3.upload_file('file.txt', 'bucket', 'file.txt')'.)
- **AWS CLI vs AWS Management Console:** The AWS Management Console is a graphical web interface where you click buttons, view dashboards, and fill out forms to manage AWS resources. The AWS CLI is a text-based interface where you type commands. The console is easier for beginners and for visualizing resources, but the CLI is faster and more suitable for automation and repetitive tasks. (Example: To create an EC2 instance via the console, you log in, navigate to EC2, click 'Launch Instance', and select options. Via the CLI, you type a single command: 'aws ec2 run-instances --image-id ami-xxx --instance-type t2.micro'.)
- **AWS CLI vs Azure CLI:** Azure CLI is the equivalent command-line tool for Microsoft Azure. It has similar goals but different commands, syntax, and underlying APIs. For example, to list virtual machines in Azure, you use 'az vm list', while in AWS you use 'aws ec2 describe-instances'. The concepts are the same, but the specific commands are different. (Example: If you are managing Azure resources, you use 'az' commands. If you are managing AWS resources, you use 'aws' commands. They are not interchangeable.)
- **AWS CLI vs gcloud CLI:** gcloud CLI is the command-line tool for Google Cloud Platform. Like Azure CLI, it serves the same purpose but has its own command set. For example, to list Compute Engine instances, you use 'gcloud compute instances list'. The underlying principles of using a terminal to manage cloud resources are identical, but the commands and APIs are different. (Example: To create a VM in Google Cloud: 'gcloud compute instances create my-vm'. To create a VM in AWS: 'aws ec2 run-instances ...'.)
- **AWS CLI vs Terraform:** Terraform is an Infrastructure as Code (IaC) tool that uses its own declarative language (HCL) to define cloud resources. You write a configuration file describing what you want, and Terraform uses APIs (including AWS APIs) to make it happen. The AWS CLI is imperative: you tell it to do a specific action immediately. Terraform is declarative: you describe the end state, and Terraform figures out the actions. (Example: With the CLI, you say: 'Create this bucket now.' With Terraform, you write: 'I want a bucket with these properties.' Terraform then creates it (if it doesn't exist) or updates it (if it already exists but is different).)

## Step-by-step breakdown

1. **Install the AWS CLI** — You first need to download and install the AWS CLI on your computer. For Linux, you can use the bundled installer or pip. For macOS, you can use brew or the bundled installer. For Windows, you can use the MSI installer. After installation, verify it by typing 'aws --version' in your terminal. If it prints a version number, installation is successful.
2. **Create IAM credentials in AWS** — Before using the CLI, you need an AWS account and a set of access keys. Log into the AWS Management Console, go to IAM, create a user (or use an existing one), and generate an access key ID and secret access key. These keys act as your username and password for the CLI. Never share them or commit them to code.
3. **Configure the AWS CLI with your credentials** — In your terminal, type 'aws configure'. The CLI will prompt you for your access key ID, secret access key, default region (e.g., us-east-1), and default output format (json, table, or text). This stores the information in two files: ~/.aws/credentials and ~/.aws/config. You can also configure multiple profiles using 'aws configure --profile name'.
4. **Test your configuration with a simple command** — Run a harmless command like 'aws s3 ls' to list all S3 buckets in your account. If it returns a list of buckets (or nothing if you have none), your credentials are correct. If you get an error like 'Unable to locate credentials', you need to reconfigure.
5. **Understand command structure** — The general structure is: aws [service] [operation] [parameters]. For example, 'aws ec2 describe-instances' calls the EC2 service and the 'describe-instances' operation. Parameters are specified with double dashes (e.g., --instance-ids i-1234567890abcdef0). Some services have subcommands, like 'aws s3 cp' (copy) and 'aws s3 ls' (list).
6. **Use the --help flag to explore commands** — If you are unsure of the options for a command, type 'aws ec2 describe-instances help' or 'aws ec2 help'. The CLI will display documentation including required and optional parameters, examples, and output structure. This is a valuable tool during both learning and real work.
7. **Perform an action, such as creating an S3 bucket** — Try creating an S3 bucket with a unique name (bucket names are globally unique). Command: 'aws s3 mb s3://my-unique-bucket-name-123'. The CLI will create the bucket and report success. Verify by listing buckets again with 'aws s3 ls'. This step confirms that you can not only read but also create resources.
8. **Use --query to filter output** — Instead of printing all JSON output, you can extract specific fields. For example, 'aws ec2 describe-instances --query "Reservations[*].Instances[*].[InstanceId,State.Name]"' prints only instance IDs and their state. This makes the output readable and easier to use in scripts.
9. **Combine commands in a script** — Write a simple shell script that, for example, stops all running EC2 instances in a specific region. Use a loop with 'aws ec2 stop-instances --instance-ids' and feed the instance IDs from a previous describe command. This demonstrates the power of automation.
10. **Clean up to avoid charges** — If you created resources during testing, delete them to avoid ongoing costs. Use 'aws s3 rb s3://my-bucket --force' to delete a bucket and its contents. Use 'aws ec2 terminate-instances --instance-ids' to terminate instances. Always confirm with the --dry-run flag first if available.

## Commands

```
aws s3 ls
```
Lists all S3 buckets in the configured AWS account. Commonly used to verify connectivity and permissions.

*Exam note: Exams test understanding that this command requires s3:ListAllMyBuckets permission and returns bucket names and creation dates.*

```
aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" --query "Reservations[].Instances[].InstanceId"
```
Filters for running EC2 instances and returns only their Instance IDs using JMESPath query.

*Exam note: Appears in exam questions about filtering output with --filters and --query to extract specific fields.*

```
aws iam create-user --user-name devops-bot
```
Creates a new IAM user with the specified username. Used for provisioning access.

*Exam note: Tests knowledge that IAM users are global and that this command alone does not grant permissions.*

```
aws lambda invoke --function-name my-function --payload '{"key":"value"}' output.txt
```
Invokes a Lambda function synchronously with a JSON payload, returns the result to output.txt.

*Exam note: Exams check understanding of synchronous vs asynchronous invocation and payload formatting.*

```
aws s3 cp /local/path s3://my-bucket/remote/path --recursive
```
Recursively copies all files from a local directory to an S3 bucket. Useful for bulk uploads.

*Exam note: Appears in questions about S3 operations with --recursive flag and appropriate IAM permissions (s3:PutObject).*

```
aws configure
```
Interactive command to set or update AWS CLI credentials and default region. Stores in ~/.aws/credentials and ~/.aws/config.

*Exam note: Tests knowledge that this sets environment for all subsequent commands and that credentials are stored in plaintext.*

## Troubleshooting clues

- **Access Denied when listing S3 buckets** — symptom: Running 'aws s3 ls' returns 'An error occurred (AccessDenied) when calling the ListBuckets operation'. The IAM user or role lacks s3:ListAllMyBuckets permission. This is an IAM policy issue. (Exam clue: Exam questions present this error to test if the student identifies missing IAM permissions.)
- **Credentials not found error** — symptom: Running any command returns 'Unable to locate credentials. You can configure credentials by running "aws configure".'. No AWS access key and secret key are configured. The CLI looks in environment variables or credential files. (Exam clue: Tests understanding of credential provider chain and that aws configure solves this.)
- **Invalid JSON in parameter** — symptom: Using --cli-input-json returns 'Parameter validation failed: Invalid JSON'. The JSON file has syntax errors (e.g., missing commas, unclosed braces). (Exam clue: Exams test ability to correctly format JSON for AWS CLI commands like --payload or --cli-input-json.)
- **Region not specified error** — symptom: Running a command returns 'You must specify a region. Specify using --region or configure default region.'. No region is set in config file or environment variable, and --region flag was omitted. (Exam clue: Tests that region is required for most services except IAM and some global services.)
- **Subscription required for ec2 operations** — symptom: Running 'aws ec2 describe-instances' returns 'You have requested more than the maximum number of items allowed'. No error; this occurs when pagination is needed. Use --max-items and --next-token pagination. (Exam clue: Tests knowledge of pagination with --max-items and --next-token for large result sets.)
- **InvalidClientTokenId error** — symptom: Running commands returns 'The security token included in the request is invalid'. The access key ID is expired or invalid. Usually from an incorrect or rotated key. (Exam clue: Exams test that this error indicates a credential issue, not a permission problem.)
- **SignatureDoesNotMatch error** — symptom: Running AWS CLI command returns 'The request signature we calculated does not match the signature you provided'. The secret access key is incorrect or the system time is off. AWS uses HMAC-SHA256 based on time. (Exam clue: Tests understanding that clock skew or wrong secret key causes this error.)

---

Practice questions and the full interactive page: https://courseiva.com/glossary/aws-cli