Beginner 25 min read

Exercise: Create a Restricted IAM User

By the end of this lesson, you'll be able to:

Apply the identity → policy → permission → resource chain to design a narrowly-scoped IAM user
Decide between a user, a group, and a role for a specific, described access need
Walk through the console steps for creating a restricted user, with or without a real AWS account

Prerequisites: "Access Keys and IAM Security Best Practices"

Before you begin: two valid paths, as before

As in Module 1, an AWS account is not required here. Follow along directly in a real account if you have one and are comfortable creating an IAM user (this walkthrough does not require access keys or any billable resource), or read through the reasoning and steps without creating anything.

The scenario

A developer needs read-only access to a specific application's log files, stored in one S3 bucket, and nothing else. They will sign in to the AWS Console personally to check logs occasionally — this is a person, not a workload, which is the first decision point: a human who needs to sign in directly is exactly the case an IAM user (not a role) fits, per Lesson 2.

Step by step: designing the restricted access

Identity: create (or picture creating) one IAM user for this developer specifically — not a shared user, not the root user.
Grouping: if other developers will eventually need this same log-reading access, put this permission on a group (LogReaders, for instance) and add the user to it, rather than attaching a one-off policy directly — Lesson 2's reasoning about five developers applies here too, even starting from one.
Policy: attach a policy granting read-only access (s3:GetObject, following Lesson 3's example) scoped to only the one bucket the logs live in — not every bucket in the account.
Credentials: since this developer only needs Console access to browse logs occasionally, there's no need to create access keys for this user at all. Skip that step entirely unless a genuine programmatic access need shows up later.
Review: check that nothing beyond read access to that one bucket was granted — no write, no delete, no unrelated services.

Exercise

Design the restricted IAM user from the scenario above: (1) would you attach the policy directly to the user or use a group, and why? (2) would you create access keys for this user? why or why not? (3) write the one permission this user's policy should grant, in plain English (not JSON).

Show hint

Revisit Lesson 2 for the group question, Lesson 6 for the access-key question, and Lesson 3's example policy for the permission itself.

Exercise: Create a Restricted IAM User Quiz

1. A developer needs to occasionally sign in to the Console to read logs from one S3 bucket — nothing programmatic, no automation. Which identity type fits this need?

An IAM user, since a specific person needs to sign in directly An IAM role, since roles are always preferred over users The root user, since it can always read every bucket No identity is needed if the bucket is fictional

2. This restricted IAM user should be granted access keys by default, in case programmatic access is needed later.

True False

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

This closing lesson applies the whole module to one concrete task: designing (and, if you have an account, actually creating) an IAM user scoped to exactly one narrow job, deliberately choosing not to grant anything beyond what that job requires.

❬ Previous Next ❭