AWS IAM Permission Guardrails

Introduction

30 Second Summary

Different people need different levels of access to the same account. One overly powerful login can turn a small mistake into an account-wide security problem.

In this project, you will build a three-persona lab with AWS Identity and Access Management (IAM). You will use separate console sessions to prove which identity actions succeed or receive access denied.

What You'll Build

Picture three employee sign-ins where each console allows only the identity tasks assigned to that role.

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

• An identity administrator that can manage IAM users. Amazon S3 stays out of reach.
• A read-only auditor that can inspect the IAM inventory. Attempts to create another user receive access denied.
• A self-service developer that can update its own console password. Other IAM users stay hidden.
• Secret Mission: Apply a permissions boundary to auditor-demo so membership in NWIdentityAdmins can no longer unlock IAM write actions.

Are there any prerequisites?

You need Google Chrome on Windows plus access to the AWS account root user. IAM is offered at no additional charge. This is a controlled foundations lab because AWS recommends centralized workforce access through AWS IAM Identity Center.

Before We Start

This step locks in the three temporary AWS Identity and Access Management (IAM) personas you are about to build before any resources or credentials are created. You will give the administrator, auditor, and developer distinct permissions to make least privilege visible throughout the lab.

Bootstrap a Temporary IAM Administrator

The AWS account root user should stay out of everyday administration. You will use it only to bootstrap a temporary administrator in AWS Identity and Access Management (IAM).

This step creates a temporary administrator through an IAM user group. You will end the root session as soon as that administrator can access IAM.

In this step, get ready to:

• Use the root user to open IAM without creating root access keys.
• Create NWIdentityAdmins with IAMFullAccess.
• Sign in as nw-lab-admin through the IAM user sign-in URL.

Why Use an IAM User Here?

For workforce access, AWS recommends temporary credentials through AWS IAM Identity Center. This controlled lab uses temporary IAM users so you can test how policies affect separate identities.

You will remove every lab identity during cleanup. The short lifetime keeps this exercise focused on permission behavior.

Use root access for the bootstrap

This session touches the account's most powerful identity. Keep the session brief so root access never becomes part of your normal workflow.

• Press the Windows key to open the search bar.
• Type Google Chrome into the search bar.
• Press Enter to open a regular Google Chrome window.

You will use this regular window for the root bootstrap. It later becomes the temporary administrator session.

• Go to the AWS sign-in page you normally use for this account.
• Choose the root-user sign-in path.
• Enter the email address associated with the AWS account.
• Complete any required MFA challenge.
• Use the console search to open AWS Identity and Access Management (IAM).
• Avoid creating root access keys anywhere in this lab.

You will see the IAM console while the root user remains signed in only for the bootstrap.

Having Trouble with Root Sign-In?

Confirm that you are using the email address for the AWS account owner. Complete the account recovery process if the password or MFA method is unavailable.

Use this for focused help: Help me troubleshoot my AWS root-user sign-in.

Create the administrator group and user

Policies attached to a group apply to every member. The NWIdentityAdmins group gives the temporary administrator one centrally managed permission set.

• Choose User groups in the IAM navigation.
• Choose Create group.
• Enter NWIdentityAdmins in the User group name field.
• Find IAMFullAccess in the policy list.
• Select the checkbox beside IAMFullAccess.
• Choose Create group.

You will see NWIdentityAdmins in the user groups list. Its attached permissions include IAMFullAccess.

What Does IAMFullAccess Allow?

The AWS managed IAMFullAccess policy provides full access to IAM through the AWS Management Console. Its scope does not provide general administrator access across unrelated AWS services.

This policy fits the temporary identity-administrator persona because the lab requires it to create IAM users. Cleanup removes the policy relationship with the group.

Protect the Temporary Credentials

The next screen creates an active console password. Store it in a password manager or another secure private location.

Keep the password out of screenshots and project notes. You only need it for this temporary lab session.

• Choose Users in the IAM navigation.
• Choose Create user.
• Enter nw-lab-admin in the User name field.
• Select Provide user access to the AWS Management Console.
• Select I want to create an IAM user.
• Choose Autogenerated password.
• Clear User must create a new password at next sign-in.

How Do These Sign-In Settings Work?

A console password lets the IAM user sign in. Policies still decide which AWS actions that user can perform.

Clearing the password-change requirement lets you use the autogenerated password for the lab. The user receives IAM permissions from its group membership.

• Select Add user to group.
• Select NWIdentityAdmins.
• Choose Next.

The review page should show nw-lab-admin as a member of NWIdentityAdmins. It should also show that no password change is required.

• Choose Create user.
• Save the displayed IAM user sign-in URL as your IAM user sign-in URL in your secure notes.
• Store the autogenerated password in your secure private location.

The nw-lab-admin user now exists with console access. Its membership in NWIdentityAdmins supplies the IAM management permissions.

Switch from root to the temporary administrator

The bootstrap identity is ready. Ending the root session now limits the time your most sensitive identity remains active.

• Open the identity menu in the upper-right corner of the regular Chrome window.
• Choose Sign out.
• Paste your IAM user sign-in URL into the regular window's address bar.
• Enter nw-lab-admin as the username.
• Enter the autogenerated password you saved.
• Complete the sign-in.

You will reach the AWS console as nw-lab-admin. The root session is now closed.

A separate Incognito session keeps later persona sign-ins isolated from the administrator session. This prevents cached sign-in cookies from mixing the identities.

• Open a separate Chrome Incognito window.
• Paste your IAM user sign-in URL into the Incognito address bar.

You will see the IAM user sign-in page in Incognito. Keep this window ready for later persona tests.

• Return to the regular Chrome window.
• Use the console search to open AWS Identity and Access Management (IAM).

Before you check, predict the identity name that should appear in the regular window.

• Choose Users in the IAM navigation.
• Open the identity menu in the upper-right corner.

You will see the IAM users list. The identity menu shows nw-lab-admin instead of the root user.

That sensitive handoff is complete. Your temporary administrator can now manage IAM without keeping the root user signed in.

Cannot Open the IAM Users List?

Confirm that the identity menu shows nw-lab-admin. Check that the user belongs to NWIdentityAdmins if IAM access is denied.

Confirm that IAMFullAccess is attached to the group. Use this for focused help: Help me troubleshoot the temporary IAM administrator.

Your temporary IAM administrator is ready. Next up, you will build the auditor's read-only guardrail.

Build the Auditor Guardrail

Your temporary administrator can now manage AWS Identity and Access Management (IAM) through the AWS Management Console in your regular Google Chrome window. The auditor needs visibility into the IAM inventory without identity-changing permissions.

A new IAM user starts with no permissions. You will grant three read actions through a tightly scoped group policy.

In this step, get ready to:

• Build the NWAuditors permission guardrail.
• Create the auditor-demo console persona.
• Prove the auditor's effective permissions.

Create the auditor group policy

An IAM user group applies the same permissions to every member. An inline policy lets this group carry the exact read actions required by the auditor.

• Select User groups in the IAM navigation.
• Choose Create group.
• Enter NWAuditors in User group name.
• Choose Create group.

You will see NWAuditors in the group list. The group has no policies yet.

• Select NWAuditors from the group list.
• Select the Permissions tab.
• Choose Add permissions.
• Choose Create inline policy.

The policy editor is now ready for the auditor's permission document.

• Choose JSON.
• Replace the existing JSON document with this policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadIdentityInventory",
      "Effect": "Allow",
      "Action": [
        "iam:ListUsers",
        "iam:ListGroups",
        "iam:ListPolicies"
      ],
      "Resource": "*"
    }
  ]
}

What does this policy do?

• The 2012-10-17 value identifies the policy language version.
• The ReadIdentityInventory statement keeps the auditor's read permissions together.
• The iam:ListUsers, iam:ListGroups, and iam:ListPolicies actions allow the three inventory views used in this lab.
• The "Resource": "*" entry lets those listing actions inspect the account-wide IAM inventory.
• Every other action remains blocked by implicit deny.

• Choose Next.
• Enter NWAuditorReadOnly in Policy Name.
• Choose Create policy.

You will see NWAuditorReadOnly under the inline policies for NWAuditors.

Policy missing from the group?

Confirm that you created the policy from the Permissions tab inside NWAuditors. Check that the policy name is NWAuditorReadOnly.

If the policy editor rejects the document, compare every bracket with the reference below.

Help me troubleshoot the NWAuditorReadOnly inline policy

✔️ Awesome, I've got everything!

Your inline policy matches the target file. The auditor group now has its read-only permission set.

ⓧ I'd like to double check the full code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadIdentityInventory",
      "Effect": "Allow",
      "Action": [
        "iam:ListUsers",
        "iam:ListGroups",
        "iam:ListPolicies"
      ],
      "Resource": "*"
    }
  ]
}

What should match?

This reference contains one allow statement with three IAM list actions. Its resource value covers the account-wide inventory required by those actions.

Create the auditor console user

Console credentials let the auditor sign in. The group policy still decides what the auditor can do after authentication.

The generated password is a live credential. This step keeps it away from screenshots.

• Return to the regular Chrome window from earlier.
• Select Users in the IAM navigation.
• Choose Create user.
• Enter auditor-demo in User name.
• Select Provide user access to the AWS Management Console.
• Select I want to create an IAM user.

The console password options are now visible for auditor-demo.

• Select Autogenerated password.
• Clear User must create a new password at next sign-in.
• Choose Next.

You will see the permission options for the new user.

• Select Add user to group.
• Select NWAuditors.
• Choose Next.

The review page will show NWAuditors as the user's group.

• Choose Create user.

You will see a success confirmation with the autogenerated password. The new auditor-demo user can now sign in.

• Save the generated password in a secure password manager.
• Store the username auditor-demo beside the IAM user sign-in URL from earlier.
• Keep the credential screen out of every screenshot.
• Return to Users.
• Select auditor-demo.
• Select the Permissions tab.

You will see NWAuditors listed as the user's permission group.

Group membership missing?

In the administrator window, return to User groups. Select NWAuditors.

Open the Users tab. Use Add users to add auditor-demo.

Help me fix the auditor's group membership

Test allowed and denied actions

A separate browser session keeps the auditor test isolated from the administrator session. The Incognito window from earlier is ready for this persona.

• Switch back to the Chrome Incognito window from earlier.
• Enter auditor-demo as the username.
• Enter the saved autogenerated password.
• Select Sign in.
• Decline any browser prompt to save the temporary password.

You will enter the AWS Management Console as auditor-demo.

• Open IAM from the AWS Management Console.
• Select Users in the IAM navigation.

You will see the IAM users list. It includes nw-lab-admin plus auditor-demo.

• Select User groups in the IAM navigation.

You will see the IAM user groups list. It includes NWIdentityAdmins plus NWAuditors.

• Select Policies in the IAM navigation.

You will see the IAM policies list. These three successful views prove that the read actions work.

Cannot open the inventory pages?

Confirm that the upper-right identity menu shows auditor-demo.

In the regular administrator window, confirm that auditor-demo belongs to NWAuditors. Confirm that NWAuditorReadOnly appears under the group's inline policies.

Help me troubleshoot the auditor's read access

• Return to Users.
• Choose Create user.
• Enter nw-auditor-denied in User name.
• Leave Provide user access to the AWS Management Console unselected.
• Choose Next.

The permissions page opens without any permissions selected for the proposed user.

• Choose Next.

The review page is ready to submit the creation request.

Before you submit the request, predict whether the read-only statement can authorize user creation.

• Choose Create user.

AWS returns an access-denied result. This is the intended outcome because the auditor has no permission to create users.

• Return to Users.
• Enter nw-auditor-denied in the users list search field.

You will see no matching user. The denied operation created no identity.

You have made least privilege visible. The auditor can inspect IAM without creating identities.

Your auditor guardrail is working. Next, you will give a developer one safe self-service permission.

Add Developer Self-Service

Your auditor now has read-only visibility into AWS Identity and Access Management (IAM) inventory. The next persona needs a smaller kind of control.

A developer should be able to maintain their own console password without seeing other identities. This step uses an inline group policy to keep that self-service permission tied to the signed-in username.

In this step, get ready to:

• Create the NWDevelopers group with a self-service password policy.
• Create developer-demo with console access through the developer group.
• Prove that the developer can update its own password while remaining blocked from the IAM users list.

Create the developer group and policy

An IAM user group applies the same permissions to every member. The developer policy grants only the account details needed for password rules plus actions scoped to the current username.

• Return to the regular Chrome window from earlier.
• Select User groups in the IAM navigation.
• Select Create group.
• Enter NWDevelopers under User group name.
• Select Create group.
• Confirm that NWDevelopers appears in the user groups list.

The new group now has a place in IAM. Its members still receive no permissions until you add a policy.

• Select NWDevelopers from the user groups list.
• Select the Permissions tab.
• Select Add permissions.
• Select Create inline policy.
• Select the JSON editor.
• Replace the editor contents with the developer policy below:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ViewAccountPasswordRequirements",
      "Effect": "Allow",
      "Action": "iam:GetAccountPasswordPolicy",
      "Resource": "*"
    },
    {
      "Sid": "ChangeOwnPassword",
      "Effect": "Allow",
      "Action": [
        "iam:GetUser",
        "iam:ChangePassword"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    }
  ]
}

What does this policy do?

• The ViewAccountPasswordRequirements statement lets the console read the account password requirements.
• The iam:GetUser action lets the signed-in developer retrieve details about their own IAM user.
• The iam:ChangePassword action lets the signed-in developer update their own console password.
• The ${aws:username} policy variable resolves to the current username inside the user ARN.
• Every action outside these statements remains implicitly denied.

• Select Next.
• Enter NWDeveloperSelfService as the policy name.
• Select Create policy.
• Return to the Permissions tab for NWDevelopers.
• Confirm that NWDeveloperSelfService appears under the inline policies.

The group now grants password self-service within one user's identity. It does not grant permission to browse the account's other users.

Policy Not Appearing?

• Confirm that the JSON editor contains only the policy shown above.
• Check the commas and quotation marks against the full policy below.
• Confirm that you saved the policy inside NWDevelopers.

Help me troubleshoot the developer inline policy

✔️ Awesome, I've got everything!

Your developer-group-inline-policy.json policy document is complete. The auditor policy remains unchanged.

ⓧ I'd like to double check the full code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ViewAccountPasswordRequirements",
      "Effect": "Allow",
      "Action": "iam:GetAccountPasswordPolicy",
      "Resource": "*"
    },
    {
      "Sid": "ChangeOwnPassword",
      "Effect": "Allow",
      "Action": [
        "iam:GetUser",
        "iam:ChangePassword"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    }
  ]
}

What Should Match?

Compare every statement name and action with your inline policy. The resource for ChangeOwnPassword must end with ${aws:username}.

Create the developer console user

A console password grants sign-in to the AWS Management Console. The policies attached through group membership still decide what the signed-in user can do.

These temporary credentials become active as soon as the user exists. A password manager keeps the generated password out of notes and screenshots.

• Select Users in the IAM navigation.
• Select Create user.
• Enter developer-demo under User name.
• Select Provide user access to the AWS Management Console.
• Select I want to create an IAM user.

The developer now has a console sign-in path selected. The next settings generate its temporary credential and connect it to the correct group.

• Select Autogenerated password.
• Clear User must create a new password at next sign-in.
• Select Add user to group.
• Select NWDevelopers.
• Select Next.
• Review the user details.
• Select Create user.

That is the developer identity in place. Its console password is now an active credential.

• Record the displayed IAM user sign-in URL here: your IAM user sign-in URL.
• Store the autogenerated password in your password manager.
• Return to Users.
• Select developer-demo.
• Confirm that NWDevelopers appears in the user's group membership.

The new user now receives the self-service policy through NWDevelopers.

Cannot Create the Developer User?

• Return to the regular Chrome window.
• Confirm that its identity menu shows nw-lab-admin.
• Confirm that NWDevelopers exists before assigning group membership.

Help me troubleshoot the developer user

Test self-service and denied access

Changing the developer password proves that the policy grants a useful personal action. Testing the users list proves that the same policy does not expose other identities.

This password change affects only developer-demo. Your administrator credentials remain untouched.

• Close every Incognito window to end the auditor-demo session.
• Use the three-dot menu in regular Chrome to start a fresh Incognito window.
• Navigate to your IAM user sign-in URL.
• Sign in as developer-demo with the saved autogenerated password.

• Select the username menu.
• Select Security credentials.
• Locate AWS IAM credentials.
• Select Update password.
• Enter the current autogenerated password.
• Enter a new unique password that meets the displayed password requirements.
• Select Update password.
• Replace the stored autogenerated password with the new password in your password manager.

You'll see a confirmation that the password update succeeded. You have proved that developer-demo can maintain its own console credential.

Before you test the final guardrail, do you expect the self-service policy to reveal the account's user list?

• Navigate to IAM in the Incognito window.
• Select Users.

You'll see an access-denied result instead of the users list. This proves that password self-service does not grant identity visibility.

Can You See the Users List?

• Confirm that the Incognito identity menu shows developer-demo.
• Confirm that developer-demo belongs only to NWDevelopers.
• Confirm that the ChangeOwnPassword resource matches arn:aws:iam::*:user/${aws:username}.

Help me investigate unexpected developer access

Your developer can now maintain its own password without browsing other identities. Next, you'll test whether the identity administrator is powerful inside IAM while staying restricted elsewhere.

Test the Administrator Persona

Your developer persona can update its own password without seeing the IAM user inventory. Now you will test whether the administrator persona can manage identities.

The IAMFullAccess policy gives nw-lab-admin broad control inside AWS Identity and Access Management (IAM). The key security question is whether that access stays away from unrelated services such as Amazon S3.

In this step, get ready to:

• Create the temporary IAM user nw-admin-test-user.
• Delete nw-admin-test-user.
• Confirm that Amazon S3 bucket listing is denied.

Create a temporary IAM user

A temporary user gives you a reversible way to test the administrator's IAM write access. The user needs no sign-in method because it only exists as proof.

• Switch back to the regular Google Chrome window from earlier.
• Choose Users in the IAM navigation.
• Choose Create user.
• Enter nw-admin-test-user in the User name field.
• Leave Provide user access to the AWS Management Console cleared.

Why Leave Console Access Off?

A console password controls whether a user can sign in. Permission policies control what that user can do after signing in.

Leaving console access off keeps this test user from signing in. The user creation flow does not create access keys.

• Choose Next.
• Leave every permission assignment option unselected.
• Skip any optional tags.
• Choose Create user.

You'll return to the users list. nw-admin-test-user appears as a new identity.

That first proof is in place. nw-lab-admin can create an IAM identity without granting it a sign-in method.

Test User Missing?

• Confirm that the upper-right identity menu shows nw-lab-admin.
• Return to Users in IAM.
• Search for the exact username nw-admin-test-user.

Help me diagnose why my IAM test user does not appear.

Delete the test user

Creating the user proves that the administrator can add identities. Deleting it proves that the same persona can complete the IAM user lifecycle.

• Confirm that nw-admin-test-user appears in the Users list.
• Select the checkbox beside nw-admin-test-user.
• Choose Delete.
• Enter nw-admin-test-user when IAM requests the username.
• Choose Delete.
• Filter the users list for nw-admin-test-user.

You'll see no matching user in the filtered list. The temporary identity has been removed.

Test User Still Listed?

• Check that you selected the exact username nw-admin-test-user before choosing Delete.
• Refresh the Users list.
• Repeat the deletion while the upper-right identity menu shows nw-lab-admin.

Help me remove the IAM test user safely.

Test access beyond IAM

An AWS managed policy grants only the actions written into its policy document. This final check reveals the practical scope of IAMFullAccess.

• Predict whether IAMFullAccess can list Amazon S3 buckets.
• Use the console search bar to search for Amazon S3.
• Select Amazon S3 from the search results.

You'll see an access-denied result instead of the bucket list. That denial is the intended result.

This is the important proof. Your administrator can manage IAM without gaining access to unrelated AWS workloads.

Why IAMFullAccess Stops at IAM

The IAMFullAccess policy allows iam:* plus specific read actions for AWS Organizations. Its broad name refers to full IAM access.

Amazon S3 actions sit outside this policy. IAM's implicit deny blocks the bucket-list request because no applicable policy allows it.

Can You See the S3 Buckets?

• Check that the upper-right identity menu shows nw-lab-admin.
• Return to IAM in the regular Chrome window.
• Inspect the permissions for nw-lab-admin for any access beyond IAMFullAccess.

Help me identify why nw-lab-admin can list Amazon S3 buckets.

Your three personas now have tested permission boundaries. Next, you'll see how one mistaken group membership can change the auditor's effective access.

Trigger the Group-Stacking Failure

Your temporary administrator has proved it can manage AWS Identity and Access Management (IAM) while remaining blocked from Amazon S3. Now you will test what happens when the auditor receives a second group membership.

IAM evaluates the permissions from every group an IAM user belongs to. One mistaken group assignment can silently defeat a read-only design.

In this step, get ready to:

• Add auditor-demo to NWIdentityAdmins without removing it from NWAuditors.
• Test the auditor's effective ability to create an IAM user.
• Confirm that the two group memberships caused the expanded access.

Add the auditor to the administrator group

The original NWAuditorReadOnly policy stays unchanged during this test. The new group membership changes which additional policies IAM evaluates for auditor-demo.

• Return to the AWS Management Console in the regular Chrome window from earlier.
• Return to IAM through the console search bar.
• Select User groups from the left navigation.
• Select NWIdentityAdmins from the group list.
• Select the Users tab.
• Select Add users.
• Select the checkbox next to auditor-demo.
• Choose Add users.

You'll see auditor-demo on the group's Users tab. The auditor still retains its original membership in NWAuditors.

Can't add the auditor?

• Confirm that auditor-demo still appears under Users.
• Return to NWIdentityAdmins after confirming the user exists.

Ask for help diagnosing the missing user or group membership.

Test the auditor's effective permissions

The auditor's inline policy still grants only inventory-listing actions. Its second group now contributes another permission set to the same identity.

This test reuses the temporary credential you stored earlier. The screenshot checkpoint comes after sign-in, so the saved password never needs to appear.

• Close the Incognito window from earlier to clear the previous persona session.
• Select Chrome's three-dot menu in the regular window.
• Select New Incognito window.
• Return to the IAM user sign-in URL you saved earlier.
• Sign in as auditor-demo using its saved console password.

The identity menu in the upper-right corner should show auditor-demo. This confirms that the next request comes from the auditor persona.

• Open IAM through the AWS Management Console search bar.
• Select Users from the left navigation.
• Select Create user.
• Enter nw-stacking-proof in the User name field.
• Leave Provide user access to the AWS Management Console clear.
• Choose Next.
• Leave Add user to group unselected.
• Leave the optional tag fields empty.

Before you submit the request, do you think the read-only auditor can create this user?

• Choose Create user.

The creation succeeds. This is the intended failure in the auditor design.

• Return to the Users page.

You'll see nw-stacking-proof in the user list. You have just exposed how an accidental group membership expands effective permissions.

The new user has no console password or access keys. It also has no group memberships or tags.

Why did the auditor succeed?

The NWAuditors group contributes list permissions. The NWIdentityAdmins group contributes IAMFullAccess.

The auditor policy omits user creation. That omission creates an implicit deny while no other policy allows the action.

IAM evaluates both group policies for the same request. The applicable allow from IAMFullAccess permits the user creation.

Is user creation still denied?

• Confirm that the Incognito identity menu shows auditor-demo.
• Confirm that auditor-demo appears on the Users tab for NWIdentityAdmins.
• Start a fresh Incognito session after correcting either mismatch.

Ask for help tracing the auditor's effective group permissions.

Confirm the stacked group memberships

The successful user creation is the visible symptom. The user's two group memberships explain the expanded access.

• Return to the regular Chrome window signed in as nw-lab-admin.
• Return to IAM through the console search bar.
• Select Users from the left navigation.
• Select auditor-demo.
• Select the Groups tab.

You'll see both NWAuditors and NWIdentityAdmins. This confirms that IAM combined permissions from both groups.

• Keep both group memberships unchanged for the optional Secret Mission.
• Switch back to the Incognito window signed in as auditor-demo.

Before this final check, do you expect nw-stacking-proof to remain visible in the user list?

• Refresh the Users page.

You'll still see nw-stacking-proof in the list. The risky membership remains active, so the privilege expansion is now proven and ready for the optional challenge.

Secret mission

Cap Accidental Admin Access with a Permissions Boundary

The auditor still has accidental administrator-group membership. Create and apply NWAuditorBoundary so inventory access survives while user creation is denied.

Clean Up Your Resources

Clean Up Your Resources

Your AWS Identity and Access Management (IAM) lab has no ongoing service cost because IAM is offered at no additional charge. Choose whether to keep the lab secured for a short time, pause its console access, or delete it to remove the active credentials.

Resources you used:

• IAM users: nw-lab-admin, auditor-demo, developer-demo, and nw-stacking-proof.
• IAM user groups: NWIdentityAdmins, NWAuditors, and NWDevelopers.
• Inline policies: NWAuditorReadOnly and NWDeveloperSelfService.
• Permissions boundary: the customer managed policy NWAuditorBoundary set on auditor-demo.
• Managed policy attachment: IAMFullAccess attached to NWIdentityAdmins.

Keep everything running

No cleanup action is needed to preserve the lab. Choose this option only if you plan to revisit it soon.

The console passwords remain active credentials, so secure the identities before leaving them in the account.

• Return to the regular Google Chrome window signed in as nw-lab-admin.
• Remove auditor-demo from NWIdentityAdmins.
• Require MFA for the three console users.
• Continue storing the three console passwords securely.
• Close the Incognito window.
• Sign out nw-lab-admin from the regular window.

Pause - I'll come back to this later

Suspend sign-in access while preserving the groups and policies for later. This removes the risky membership that caused the privilege-stacking failure.

• Return to the regular Chrome window signed in as nw-lab-admin.
• Remove auditor-demo from NWIdentityAdmins.
• Delete the nw-stacking-proof user from Users.
• Disable console access for auditor-demo from its IAM user settings.
• Disable console access for developer-demo from its IAM user settings.
• Disable console access for nw-lab-admin from its IAM user settings.
• Close the Incognito window.
• Sign out nw-lab-admin from the regular window.

Delete - I don't want to use this again

Deleting the lab is the safest choice for temporary identities with active credentials. This process removes only the named IAM resources from this project.

Prepare Root Access

• Close the Incognito window used by auditor-demo.
• Return to the regular Chrome window.
• Sign out nw-lab-admin.
• Sign in to the AWS account as the root user.
• Complete the required MFA challenge.
• Open AWS Identity and Access Management (IAM) in the AWS Management Console.

Remove the Permissions Boundary

The boundary must be removed from auditor-demo before you delete its customer managed policy.

• Select Users.
• Choose auditor-demo.
• Choose Permissions.
• Open Permissions boundary.
• Choose Change boundary.
• Choose Remove boundary.

The Permissions boundary section should no longer show NWAuditorBoundary.

Delete the IAM Users

Deleting each IAM user also removes its console password and group memberships.

• Repeat the deletion flow below for nw-stacking-proof, auditor-demo, developer-demo, and nw-lab-admin, in that order:
• Select the checkbox beside the current user.
• Choose Delete.
• Enter the current username in the confirmation field.
• Choose Delete.
• Refresh Users after the final deletion.

You should no longer see any of the four usernames in Users. Their console passwords are removed with the identities.

Delete the IAM User Groups

Deleting the groups removes their inline policies and detaches the AWS managed policy from the lab.

• Select User groups.
• Repeat the deletion flow below for NWAuditors, NWDevelopers, and NWIdentityAdmins, in that order:
• Select the checkbox beside the current group.
• Choose Delete.
• Enter the required group confirmation.
• Choose Delete.
• Refresh User groups after the final deletion.

You should no longer see the three group names.

The group deletions remove NWAuditorReadOnly and NWDeveloperSelfService. They also detach IAMFullAccess from the lab.

Delete the Boundary Policy

The boundary relationship is now gone, so you can permanently delete NWAuditorBoundary.

• Select Policies.
• Select NWAuditorBoundary.
• Choose Actions.
• Choose Delete.
• Confirm the policy deletion.
• Choose Delete.
• Refresh Policies.

You should no longer see NWAuditorBoundary in the customer managed policies list.

• Sign out the root user.

That completes the security cleanup. Every temporary identity and permission resource from the lab is gone.

Nice Work!

Nice Work!

Excellent work! Your three-persona AWS Identity and Access Management (IAM) lab now shows how least privilege behaves across real console sign-ins.

You've learned how to:

• Built three IAM personas with different group-based permissions for identity administration, auditing, and developer self-service.
• Proved least-privilege access through separate AWS Management Console sessions that produced successful actions or access-denied results.
• Demonstrated accumulated group permissions by adding auditor-demo to a second group. The auditor gained IAM write access through the additional membership.
• Completed the Secret Mission by applying a permissions boundary to auditor-demo. The boundary capped the auditor's access while both group memberships remained in place.

Ready to quiz yourself?