Secure Your AWS Account with IAM

Lock down your AWS root account and build a real IAM permission system with CLI access.

Introduction

30 Second Summary

Think about how a company gives different employees different levels of building access. The CEO gets a master key, developers get access to their floor, and interns get the lobby.

In this project, you will secure your AWS account and build a permission system that controls exactly who can do what inside your cloud environment. You will create users, assign them to groups with different access levels, and prove it all works by running real commands that succeed or fail based on the policies you wrote.

What You'll Build

You will type commands into your terminal and watch some succeed while others get rejected with "Access Denied" based on the permission boundaries you designed.

By the end of this project, you'll have:

  • A root account protected with MFA so nobody can hijack your entire AWS account with just a stolen password.
  • An admin IAM user with a working AWS CLI connection, so you never touch root again for daily work and can manage AWS from your terminal.
  • A group-based permission system with custom JSON policies that grant precise access to specific services. Your developer user can read S3 buckets but gets denied on everything else.
  • Secret Mission: Write a conditional policy that restricts access based on IP address or time of day.

Are there any prerequisites?

You need an existing AWS account (Free or Paid plan) and a smartphone with an authenticator app such as Google Authenticator, Microsoft Authenticator, or Authy.

No prior AWS experience is required. This is the first project in a series targeting the AWS Solutions Architect Associate certification.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters for your Solutions Architect journey.

Secure Your Root Account and Enable MFA

Your root user has unlimited power over your entire AWS account. It can delete resources, change billing, and lock you out permanently.

Right now, it is protected by only a password. Anyone who gets that password owns everything. MFA (Multi-Factor Authentication) adds a second lock so a stolen password alone is not enough to break in.

In this step, get ready to:
  • Enable MFA on your root account using an authenticator app.
  • Confirm no access keys exist for root.
  • Sign out of root and verify MFA is working.
Enable MFA on your root account

MFA pairs your password with a time-based code from your phone. Even if someone steals your password, they still cannot get in without your phone generating a fresh 6-digit code every 30 seconds.

  • Open your web browser and go to the AWS Management Console at https://console.aws.amazon.com/.
  • Sign in using your root user credentials (the email and password you used to create your AWS account).
  • In the top-right navigation bar, click your account name.
  • Choose Security credentials from the dropdown menu.
  • Scroll down to the Multi-Factor Authentication (MFA) section.
  • Click Assign MFA device.
  • Enter a device name (something you will recognise, like my-phone).
  • Select Authenticator app and click Next.

What will I see next?

AWS displays a QR code on screen. This QR code is tied to your specific AWS account and will be used to link your authenticator app.

  • Open your authenticator app (Google Authenticator, Microsoft Authenticator, or Authy) on your phone.
  • Tap the option to add a new account (usually a + icon or Scan a QR code).
  • Point your phone camera at the QR code displayed on screen.
  • Your app starts generating 6-digit codes that refresh every 30 seconds.
  • In the AWS wizard, type the current 6-digit code from your app into the MFA code 1 box.
  • Wait for your app to generate a new code (up to 30 seconds).
  • Type the new 6-digit code into the MFA code 2 box.
  • Click Add MFA.

Submit both codes quickly

The codes expire after a short window. If you wait too long between entering MFA code 1 and MFA code 2, the device may go out of sync. Enter both codes promptly after they appear.

You should see a success message confirming that your MFA device has been assigned.

MFA setup failing?

Make sure you are entering two different codes. Wait for the code in your app to change before entering the second one.

If your codes keep getting rejected, check that your phone's clock is set to automatic. MFA codes are time-based, so an inaccurate clock will produce invalid codes.

Why are my MFA codes being rejected?

Verify no access keys exist for root

Access keys let someone control your AWS account from a terminal or script. Root should never have access keys because that would give full unrestricted access outside the console.

  • You should still be on the Security credentials page. Scroll down to the Access keys section.
  • Confirm that no access keys are listed. You should see a message indicating no access keys exist.
  • If you see any access keys listed, click Actions, choose Deactivate, then delete the key.

Why does root not need access keys?

Access keys are long-term credentials that do not expire on their own. If someone steals a root access key, they have full, unrestricted access to your entire account from anywhere in the world. You will create access keys for a dedicated admin user in the next step instead.

Sign out and verify MFA is working

You have set up MFA and confirmed no access keys exist. Now you need to prove that MFA actually protects your sign-in.

  • In the top-right corner, click your account name.
  • Click Sign out.

Before you sign back in, think about what you expect to happen differently this time compared to before you set up MFA.

  • Go back to https://console.aws.amazon.com/ and sign in as root again using your email and password.

After entering your password, AWS now prompts you for an MFA code. This is the second lock in action.

  • Open your authenticator app and enter the current 6-digit code into the MFA code box.
  • Click Submit.
  • Confirm you are successfully logged in to the AWS Management Console.
  • Sign out again immediately. You will not use root again unless absolutely necessary.

Why sign out of root right away?

Root is for emergencies only. From this point forward, you will use a dedicated admin user for all daily work. This limits the damage if your session is ever compromised.

Not seeing the MFA prompt?

Make sure you are signing in as the root user (using email), not as an IAM user. The MFA you just configured is attached to root only.

If you accidentally closed the browser during MFA setup and never saw the success message, your MFA device might not have been assigned. Sign back in with your password, go to Security credentials, and check the Multi-Factor Authentication (MFA) section. If no device is listed, repeat the setup steps above.

Help me troubleshoot my MFA sign-in issue.

Your root account is now locked down with two layers of protection. Next up, you will create a dedicated admin user and get the AWS CLI working on your machine so you never need to touch root again.

Create Your Admin IAM User and Install the CLI

Your root account is now protected with MFA. That is a huge security win.

Right now, though, your root user is still the only identity that can access your AWS account. This is dangerous because root has unlimited power. One accidental click could delete everything. You need a separate IAM user for daily work. In this step, you will create an admin user and get the AWS CLI working on your machine so you can manage AWS from the terminal.

In this step, get ready to:
  • Create an admin IAM user with full access and console sign-in.
  • Generate access keys so the CLI can authenticate as your admin user.
  • Install and configure the AWS CLI on your Windows machine.
Create your admin IAM user

You will sign in as root one final time to create the admin user. After this, root goes back in the vault.

  • Sign in to the AWS Management Console as the root user.
  • In the top-left search bar, type IAM and select IAM from the results.
  • In the left navigation pane, click Users.
  • Click Create user.
  • Enter admin as the user name.
  • Check the box for Provide user access to the AWS Management Console.
  • Select I want to create an IAM user.
  • Choose Custom password and enter a password you will remember.
  • Uncheck User must create a new password at next sign-in.
  • Click Next.

Why uncheck the password reset?

In a production environment you would force a password reset so each user sets their own. For this project, you are the only user, so skipping the reset avoids an extra login step.

  • On the permissions page, select Attach policies directly.
  • In the search box, type AdministratorAccess.
  • Check the box next to the AdministratorAccess policy.
  • Click Next, then click Create user.

What is AdministratorAccess?

This is an AWS managed policy that grants full access to every AWS service. It is the right choice for your personal admin user because you need unrestricted access to learn and build.

In a company setting, only a few trusted accounts would ever get this policy. Everyone else gets limited permissions. You will build those limited permissions in the next steps.

  • On the confirmation page, copy the Console sign-in URL and save it somewhere safe (a note, a bookmark, a text file). You will use this URL to sign in as your admin user from now on.

You should now see admin listed on the Users page in the IAM console.

Don't see the admin user?

Make sure you clicked Create user on the final review page. If you only clicked Next, the user was not created yet.

Help me find where my admin user creation went wrong.

Create an access key for your admin user

Access keys are what let the AWS CLI prove it is acting on behalf of your admin user. Think of them as a username and password specifically for programmatic access.

  • On the Users page, click on the admin username to open the user details.
  • Click the Security credentials tab.
  • Scroll down to Access keys and click Create access key.
  • Select Command Line Interface (CLI) as the use case.
  • Check the confirmation checkbox at the bottom, then click Next.
  • Click Create access key.
  • Click Download .csv file and save it somewhere secure on your computer. You will need these values in the next substep.
  • Click Done.

Keep your access keys safe

This CSV file contains your Access Key ID and Secret Access Key. Treat them like a password. Never share them, commit them to Git, or paste them into a public forum.

If you lose the secret key, you cannot retrieve it. You would need to delete the access key and create a new one.

Now sign out of the root account. You will not use root again in this project.

  • In the top-right corner, click your account name and choose Sign out.
Install and configure the AWS CLI

The AWS CLI lets you run AWS commands directly from your terminal. Instead of clicking through the console, you type a command and get results in seconds. This is how you will work with AWS in every future project.

  • Open a Command Prompt window by pressing the Windows key, typing cmd, and pressing Enter.
  • Check whether the AWS CLI is already installed by running:
aws --version

✔️ I see aws-cli/2.x.x

The AWS CLI v2 is already installed. Skip ahead to the configuration step below.

ⓧ I see aws-cli/1.x.x

You have an older version installed. AWS CLI v1 is missing features you will need in later projects. Uninstall it first, then install v2.

  • Press the Windows key and type Add or remove programs.
  • Press Enter to open it.
  • Search for AWS Command Line Interface, click it, and choose Uninstall.
  • Once the uninstall finishes, close and reopen your Command Prompt.
  • Download and run the AWS CLI v2 installer by running this command in an administrator Command Prompt:
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi
  • Follow the installer prompts and accept the defaults.
  • Close and reopen your Command Prompt after the installer finishes.
  • Confirm the installation by running:
aws --version

You should now see a version starting with aws-cli/2.

ⓧ Command not found

The AWS CLI is not installed yet. Let's install it now.

  • Download the AWS CLI v2 installer from this URL in your browser:
https://awscli.amazonaws.com/AWSCLIV2.msi
  • Double-click the downloaded AWSCLIV2.msi file to start the installer.
  • Follow the installer prompts and accept all defaults.
  • Close and reopen your Command Prompt after the installer finishes.
  • Confirm the installation by running:
aws --version

You should now see a version starting with aws-cli/2.

Still seeing 'not recognized'?

Make sure you closed and reopened your Command Prompt after installation. The new Command Prompt loads the updated system PATH that includes the AWS CLI.

Help me troubleshoot my AWS CLI installation on Windows.

Now configure the CLI with your admin user's credentials. This tells the CLI who to authenticate as when running commands.

  • Run the configure command:
aws configure

What does aws configure ask for?

This command prompts you for four values, one at a time. Open the CSV file you downloaded earlier and have it ready.

  • AWS Access Key ID: paste the Access Key ID from your CSV.
  • AWS Secret Access Key: paste the Secret Access Key from your CSV.
  • Default region name: type us-east-1.
  • Default output format: type json.
  • Enter each value as prompted, pressing Enter after each one.

Why us-east-1?

This region (US East, N. Virginia) has the most AWS services available, is typically the cheapest, and is the default in all AWS documentation. Using it keeps your experience consistent with any tutorial or reference you follow.

Time to prove it all works. Before you run the next command, think about this: what information do you expect the CLI to return about your identity?

  • Verify your CLI is authenticated by running:
aws sts get-caller-identity

You should see JSON output containing your account number, your admin user's ARN (something like arn:aws:iam::123456789012:user/admin), and a user ID. This confirms the CLI is talking to AWS as your admin user.

Seeing 'Unable to locate credentials'?

This means aws configure did not save properly. Run aws configure again and carefully paste the Access Key ID and Secret Access Key from your downloaded CSV file. Make sure there are no extra spaces.

Help me fix my AWS CLI credentials error.

Finally, sign in to the console as your new admin user to confirm console access works too.

  • Open a browser and go to the console sign-in URL you saved earlier.
  • Enter admin as the username and the password you set during user creation.
  • Click Sign in.

You are now in the AWS console as your admin user. The account dropdown in the top-right should show admin instead of the root email address.

Your admin user is live and your CLI is connected. Next up, you will create groups and attach policies to control what different users can access.

Create Groups and Attach Managed Policies

Your admin user is set up and the CLI is connected. You have full access to your AWS account, but in a real company you would never hand that same power to every person on the team.

IAM groups let you organise users by job role and attach permissions once at the group level. In this step, you will create two groups representing different access levels, then add users to each one.

In this step, get ready to:
  • Create IAM groups for admin and developer roles.
  • Attach AWS managed policies to control what each group can do.
  • Create a test user and add it to the Developers group.
Create the Developers group

A managed policy is a pre-built permission set that AWS maintains for you. Instead of writing JSON from scratch, you pick one off the shelf and attach it to a group. Every user in that group immediately inherits those permissions.

  • In the IAM console, choose User groups in the left navigation pane.
  • Click Create group.
  • In the User group name field, enter Developers.
  • Scroll down to the Attach permissions policies section.
  • In the search box, type AmazonS3ReadOnlyAccess.
  • Select the checkbox next to AmazonS3ReadOnlyAccess.
  • Click Create group.

You should see a success banner and Developers now appears in your User groups list.

What is an IAM group?

An IAM group is a collection of users that share the same permissions. Instead of attaching a policy to each user individually, you attach it once to the group.

When someone joins the team, you add them to the right group and they instantly get the correct access. When they leave, you remove them and the access disappears.

Create the Admins group and add your admin user
  • Click Create group again.
  • In the User group name field, enter Admins.
  • In the list of users, select the checkbox next to admin.
  • Scroll down to the Attach permissions policies section.
  • Search for AdministratorAccess and select the checkbox next to it.
  • Click Create group.

You should now see both Developers and Admins in the User groups list.

Why add admin to a group?

Your admin user already has AdministratorAccess attached directly. Adding it to the Admins group means future admins get the same permissions just by joining the group. It also mirrors real-world practice where access is managed at the group level, not per user.

Create a test user in the Developers group

You need a second user to prove that group permissions actually work. This user will only have the permissions the Developers group grants.

  • In the left navigation pane, choose Users.
  • Click Create user.
  • In the User name field, enter dev-test.
  • Select the checkbox next to Provide user access to the AWS Management Console.
  • Select I want to create an IAM user.
  • Choose Custom password and enter a simple password you will remember.
  • Uncheck User must create a new password at next sign-in.
  • Click Next.

You are now on the Set permissions page.

  • Select Add user to group.
  • Select the checkbox next to Developers.
  • Click Next.
  • On the Review and create page, confirm dev-test is assigned to the Developers group.
  • Click Create user.

A success notification confirms dev-test was created.

Why does dev-test get permissions without a policy attached directly?

A new IAM user has no permissions by default. But because you added dev-test to the Developers group, it inherits the AmazonS3ReadOnlyAccess policy that the group carries. This is the power of group-based access management.

Don't see the Developers group when assigning permissions?

If the group you created earlier is not visible in the list, click the Refresh button next to the User groups heading. The group should then appear.

help me find the Developers group when creating a new IAM user

Before you verify, what do you expect to see if you open the Developers group and check its members and permissions?

  • In the left navigation pane, choose User groups.
  • Click Developers.
  • Select the Users tab.
  • Confirm dev-test appears in the list.
  • Select the Permissions tab.
  • Confirm AmazonS3ReadOnlyAccess appears.

You should see dev-test under Users and AmazonS3ReadOnlyAccess under Permissions. Your group-based permission system is live.

Your permission system is in place. Two groups, two different access levels, and a test user ready to prove it works. Next up, you will write a custom JSON policy and see what happens when dev-test tries to access a service outside its permissions.

Write a Custom JSON Policy and See Permissions Fail

Your dev-test user belongs to the Developers group, which has the AmazonS3ReadOnlyAccess managed policy attached. Managed policies cover generic, pre-defined use cases. They are convenient for getting started, but too broad for production environments.

A Solutions Architect writes custom JSON policies that grant precisely the permissions a role needs. In this step, you will put your current permission setup to the test and write your first custom policy.

In this step, get ready to:
  • Test your dev-test user's permissions on the EC2 console and see them fail.
  • Write a custom IAM policy using JSON that grants EC2 read-only access.
  • Attach the custom policy to the Developers group and verify it works with precision.
Sign in as dev-test and test EC2 access

Your dev-test user only has S3 read access through its group membership. Time to see what happens when it tries to access a different service.

  • Open an incognito or private browser window (this keeps your admin session intact in the other window).
  • Navigate to the console sign-in URL you saved in Step 2.
  • Sign in as dev-test with the password you set earlier.

Before you navigate to EC2, think about this: the Developers group only has AmazonS3ReadOnlyAccess attached. Do you think dev-test will be able to view EC2 instances?

  • In the top search bar, type EC2 and select EC2 from the results.
  • Click Instances in the left navigation pane.

You see an error stating you are not authorized to perform this action. The page refuses to load.

What just happened?

This is IAM doing exactly what it should. The Developers group only has S3 read access, so every other AWS service is blocked by default.

A new IAM user has no permissions by default. The only reason dev-test can touch S3 at all is because you explicitly attached AmazonS3ReadOnlyAccess to its group. Everything else is denied until you say otherwise.

What is least privilege?

Least privilege means granting only the exact permissions a user or service needs to do its job. Nothing more. This is the foundation of secure architecture in AWS.

Create a custom JSON policy for EC2 read access

Now you will fix the gap by writing a custom policy. Instead of granting broad EC2 access, you will allow only three specific read-only actions.

  • Switch back to your admin browser window.
  • In the IAM console, click Policies in the left navigation pane.
  • Click Create policy.
  • Click the JSON tab in the policy editor.
  • Delete any existing content in the editor and paste the following policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
        "ec2:DescribeAvailabilityZones"
      ],
      "Resource": "*"
    }
  ]
}

What does this policy do?

  • "Version": "2012-10-17" is the required policy language version. Every IAM policy uses this date string.
  • "Effect": "Allow" means this statement grants permission (as opposed to Deny, which blocks it).
  • The three actions (ec2:DescribeInstances, ec2:DescribeRegions, ec2:DescribeAvailabilityZones) are all read-only. They let the user view information but not create or modify anything.
  • "Resource": "*" is required because EC2 Describe actions do not support resource-level permissions. You must use the wildcard.
  • Click Next.
  • In the Policy name field, enter DevEC2ReadOnly.
  • In the Description field, enter Allows read-only EC2 describe actions for developers.
  • Click Create policy.

You should see a success banner confirming the policy DevEC2ReadOnly has been created.

Don't see the JSON tab?

The IAM policy editor defaults to the visual editor. Look for a JSON toggle or tab at the top of the permissions editor. Click it to switch to the raw JSON view where you can paste the policy directly.

Help me find the JSON editor in the IAM policy console.

Attach the policy to the Developers group and verify
  • In the IAM console, click User groups in the left navigation pane.
  • Click Developers.
  • Click the Permissions tab.
  • Click Add permissions, then select Attach policies.
  • Search for DevEC2ReadOnly.
  • Select the checkbox next to DevEC2ReadOnly and click Attach policies.

The Developers group now has two policies: AmazonS3ReadOnlyAccess and DevEC2ReadOnly.

Now, before you switch back to the dev-test session, make a prediction: do you think the EC2 console will load this time? What about other services like VPC?

  • Switch back to the incognito window where dev-test is signed in.
  • Refresh the EC2 Instances page.

The Instances page now loads without an error. It shows 0 instances, which is correct since you have not launched any EC2 instances yet.

  • In the top search bar, type VPC and select VPC from the results.

You still get an access denied error. Your custom policy only granted three specific EC2 actions. VPC permissions were never included, so access is blocked.

Why does VPC still fail?

This proves your custom policy works with precision. You granted exactly ec2:DescribeInstances, ec2:DescribeRegions, and ec2:DescribeAvailabilityZones. Nothing else. VPC requires its own set of permissions (like ec2:DescribeVpcs), which you deliberately did not include.

This is least privilege in action. Every permission is explicit. If you did not write it in the policy, it does not exist.

EC2 page still showing an error after attaching the policy?

Make sure you attached DevEC2ReadOnly to the Developers group (not directly to the user). Also try a hard refresh in the incognito window (Ctrl+Shift+R). IAM policy changes take effect almost immediately, but the browser may cache the old page state.

Help me troubleshoot why my dev-test user still cannot access EC2 after attaching my custom policy.

You just experienced the full cycle of IAM permissions: a denial that proved your boundaries work, a custom policy that granted exactly what was needed, and a second denial that proved your policy is precise. Next up, you will test these same permissions through the CLI to see how automation and scripting obey the same rules.

Test Permissions via the CLI

In the last step, you saw permissions in action through the console. Your dev-test user was blocked from EC2 until you wrote a custom policy. Now it is time to prove that the same policies control access through the AWS CLI.

The CLI is how you automate and script AWS at scale. By running real commands as both your admin and dev-test users, you will see the exact boundary between full access and least privilege from the same terminal window.

In this step, get ready to:
  • Create an access key and CLI profile for your dev-test user.
  • Run commands as dev-test to see which succeed and which get denied.
  • Compare admin and dev-test access side by side from the same terminal.
Create an access key and CLI profile for dev-test

Before you can run CLI commands as dev-test, that user needs its own access key. You will create one in the console and then configure a named CLI profile for it.

  • In the IAM console, click Users in the navigation pane.
  • Click on dev-test.
  • Click the Security credentials tab.
  • Under Access keys, click Create access key.
  • Select Command Line Interface (CLI) as the use case.
  • Check the acknowledgment checkbox at the bottom of the page.
  • Click Next, then click Create access key.
  • Click Download .csv file and save it somewhere secure on your computer.

What did you just create?

An access key is a pair of credentials (an Access Key ID and a Secret Access Key) that lets a program or CLI authenticate as a specific IAM user. The CSV you downloaded contains both values. You will paste them into the CLI in the next step.

Now configure a named CLI profile that uses these credentials. The command below is interactive and will prompt you for four values.

  • Switch back to your Command Prompt from earlier.
  • Configure the dev-test profile by running this command:
aws configure --profile dev-test
  • When prompted, enter these values one at a time:
  • For AWS Access Key ID: paste the Access Key ID from your downloaded CSV.
  • For AWS Secret Access Key: paste the Secret Access Key from your CSV.
  • For Default region name: type us-east-1.
  • For Default output format: type json.

You now have two CLI profiles: default (your admin user) and dev-test (your restricted developer).

Getting an error when pasting keys?

Make sure you are pasting the values exactly from the CSV with no extra spaces. If you accidentally entered a wrong value, run aws configure --profile dev-test again to overwrite the previous entries.

help me fix my AWS CLI profile configuration

Run commands as dev-test to test permissions

Your dev-test user belongs to the Developers group, which has AmazonS3ReadOnlyAccess and your custom DevEC2ReadOnly policy. S3 read and EC2 describe actions should work. Anything else should be denied.

  • Test S3 access by running this command:
aws s3 ls --profile dev-test

This succeeds. You will either see a list of your S3 buckets or an empty response if you have no buckets yet.

  • Test EC2 describe access by running this command:
aws ec2 describe-instances --profile dev-test

This also succeeds. You will see a JSON response with an empty Reservations list because you have no running instances. Your custom DevEC2ReadOnly policy is working.

Now for the moment of truth. Before you run the next command, ask yourself: do you think dev-test will be able to list IAM users? Why or why not?

  • Attempt to list IAM users by running this command:
aws iam list-users --profile dev-test

You will see an access denied error. The Developers group has no IAM permissions, so the request is rejected. This is least privilege in action.

Why did this fail?

IAM evaluates every API request against the caller's attached policies. The dev-test user only has S3 read and EC2 describe permissions. Since no policy grants iam:ListUsers, AWS returns an implicit deny.

This is the same mechanism you saw in the console when dev-test was blocked from EC2 before you added your custom policy. The CLI and the console hit the same policy engine.

Compare admin and dev-test access side by side

You have seen what dev-test cannot do. Now run the same commands as your admin user to see the contrast.

  • List S3 buckets as your admin user by running this command:
aws s3 ls --profile default

This succeeds, just like it did for dev-test. Both profiles have S3 access. Admin gets it via AdministratorAccess, and dev-test gets it via AmazonS3ReadOnlyAccess.

  • List IAM users as your admin user by running this command:
aws iam list-users --profile default

This succeeds and returns a JSON list showing both your admin and dev-test users. The same command that dev-test was denied works perfectly for admin.

What does this prove?

The --profile flag switches which credentials the CLI uses. The policies attached to each identity determine what succeeds and what fails. Same CLI, same machine, different policies, different results.

Time for the final verification. Before you run the next two commands, predict: which one will succeed and which will be denied?

  • Test the ec2:DescribeRegions action from your custom policy by running:
aws ec2 describe-regions --profile dev-test

This succeeds and returns a list of AWS regions. Your custom DevEC2ReadOnly policy explicitly allows ec2:DescribeRegions, so the request is permitted.

  • Now test an action you never granted by running:
aws rds describe-db-instances --profile dev-test

Access denied. You never gave the Developers group any RDS permissions, so the request is rejected. Your permission boundary is working exactly as designed.

Same user, precise boundaries

Notice how dev-test can describe EC2 regions but cannot touch RDS. Your JSON policy grants only the actions you listed. Everything else is denied by default. This is the principle of least privilege that Solutions Architects apply to every production environment.

Getting access denied on commands that should succeed?

Double-check that you are using the correct profile flag. --profile dev-test uses dev-test credentials. --profile default uses your admin credentials. A missing or misspelled profile flag defaults to admin.

If aws ec2 describe-instances --profile dev-test fails, confirm the DevEC2ReadOnly policy is still attached to the Developers group in the IAM console.

help me troubleshoot my AWS CLI permission errors

You just proved that the same permission engine controls both the console and the CLI. Your admin can do anything, but your developer can only touch S3 and EC2 describe actions. Next up, you will take this even further in the Secret Mission by writing conditional policies that restrict access based on IP address or time of day.

Secret mission

Write a Conditional Policy

Real-world IAM policies use conditions to restrict access based on time, IP address, or MFA status. Can you write a policy that only allows S3 access from your specific IP address? This is how enterprises lock down sensitive resources and it is frequently tested on the SAA-C03 exam.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. IAM is always free with no usage limits, so none of the resources you created in this project cost money.

Resources you used:

  • IAM users: admin, dev-test, and restricted-dev (Secret Mission).
  • IAM groups: Admins, Developers, and RestrictedDevs (Secret Mission).
  • IAM custom policies: DevEC2ReadOnly and S3IPRestricted (Secret Mission).
  • Access keys for admin, dev-test, and restricted-dev users.
  • AWS CLI v2 installed on your Windows machine.
  • AWS CLI configuration files at %USERPROFILE%\.aws\ (credentials and config).

Keep everything running

No action needed. Choose this if you plan to continue with the next project in this series.

  • All IAM resources are free and have no usage limits.
  • Your admin user, CLI setup, and groups will be useful in future projects.
  • The AWS CLI stays installed on your machine for future use.

Pause - I'll come back to this later

Clean up the test users while keeping your admin user and CLI configuration intact for next time.

  • In the IAM console, go to Users, select dev-test, and click Delete. Type the username to confirm.
  • If you completed the Secret Mission, also delete the restricted-dev user the same way.
  • Keep your admin user, the Admins group, and your CLI configuration. These are ready for the next project.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order.

Delete access keys and users:

  • In the IAM console, go to Users.
  • Select dev-test, go to the Security credentials tab, and delete any access keys listed.
  • Go back to Users, select dev-test, and click Delete. Type the username to confirm.
  • If you completed the Secret Mission, repeat the above for restricted-dev.
  • Select admin, go to the Security credentials tab, and delete its access keys.
  • Delete the admin user the same way.

Delete groups:

  • In the IAM console, go to User groups.
  • Select Developers and click Delete. Type the group name to confirm.
  • Repeat for Admins.
  • If you completed the Secret Mission, also delete RestrictedDevs.

Delete custom policies:

  • In the IAM console, go to Policies.
  • Filter by Customer managed to find your custom policies.
  • Select DevEC2ReadOnly, click Actions, then Delete. Type the policy name to confirm.
  • If you completed the Secret Mission, also delete your S3IPRestricted policy.

Uninstall the AWS CLI (optional):

  • Open Control Panel, then choose Programs and Features.
  • Select AWS Command Line Interface and choose Uninstall.
  • Confirm the uninstallation when prompted.
  • Remove your CLI configuration files by opening a Command Prompt and running:
rmdir /s /q %USERPROFILE%\.aws

What does this remove?

The .aws folder contains your CLI credentials and configuration for all profiles (default, dev-test, restricted-dev). Removing it means you will need to run aws configure again if you reinstall the CLI later.

Nice Work!

Nice Work!

You just secured an AWS account and built a real permission system from scratch. Your account is now locked down the way a Solutions Architect would set it up on day one of a new job.

You've learned how to:

  • Secure your root account with MFA and eliminate access keys, then create a dedicated admin IAM user with AWS CLI access for all daily work.
  • Build a group-based permission system using both managed policies and custom JSON policies that restrict access to specific AWS services with least privilege.
  • Prove permissions work by running CLI commands that succeed and fail based on your policies, seeing the same boundary enforced in both the console and the terminal.
  • Secret Mission: Write conditional policies using IP restrictions or time-based access controls to lock down resources beyond simple allow/deny.

Ready to quiz yourself?