Lesson 042 · AWS Learning Path

AWS 042: Users, groups and policies

Anil Jalela · Published Aug 6, 2025 · 8 min read

A reusable policy attaches to an IAM user group and gives consistent permissions to its members

The problem

A team uses Users, groups and policies as a label or Console setting without proving the identity, scope, behavior, failure boundary, cost, or operational result. The configuration appears complete but the real requirement remains untested.

Final outcome

The learner will inspect, explain, test, and document Users, groups and policies. The submission must connect the Console and CLI view to the same AWS control, state what the evidence proves, diagnose one likely failure, and make a requirement-based architecture decision.

Learning outcomes

You will be able to:

explain iam users have long-term identity;
explain groups contain users only;
explain policies contain permissions;
explain aws managed and customer managed differ;
explain groups do not provide credentials;

distinguish successful configuration from successful workload behavior;
preserve redacted evidence and complete the stated cleanup or retention decision.

Mental model

requirement
   -> identity and permission
   -> account, Region, and resource scope
   -> configuration or request
   -> observable state
   -> workload result
   -> failure evidence
   -> cleanup or controlled retention

Never begin with a create button or a copied command. Start with the result that must be proven and the boundary that must remain protected.

Core facts

Concept	What it means in practice
IAM users have long-term identity	An IAM user can have a console password and access keys. Those credentials persist until changed or deleted, which creates more lifecycle and leakage risk than a temporary role session.
Groups contain users only	An IAM group is a permission-management collection for IAM users. A group cannot be a principal in a resource policy, cannot contain roles, and cannot be nested inside another group.
Policies contain permissions	Identity-based policies attach to users, groups, or roles. A managed policy is a separate reusable resource; an inline policy has a strict one-to-one relationship with its identity.
AWS managed and customer managed differ	AWS maintains AWS managed policies and can update them. The customer controls versions and changes for customer managed policies, making their behavior more predictable.
Groups do not provide credentials	A user inherits permissions from every group membership, but still authenticates with the user credentials. Removing a user from a group removes only that group contribution.
Prefer roles and group assignment	Attach permissions to groups for the rare IAM-user workforce case and to roles for workloads or federation. Avoid copying the same policy directly onto many users.

How to reason about it

Managed policy reuse simplifies administration, but a broad shared policy can create a large blast radius when edited. Use clear ownership, policy review, version control, and staged deployment. Inline policies are useful when the permission must be deleted with one identity, but they are harder to discover and reuse at scale.

Policy attachment is only one input to effective access. A user can inherit multiple group policies, direct policies, a permissions boundary, and organization restrictions. Inventory every applicable layer before concluding that one attached AdministratorAccess policy gives unrestricted control.

Use the following decision table as a starting point, then change the answer when the scenario changes.

Requirement	Preferred direction	Why
Several legacy IAM users need the same job access	Attach a customer managed policy to a group	One reviewed permission set is easier to change than duplicate user policies.
A policy must exist only with one role	Inline role policy	The policy lifecycle follows that identity, though reusable policies remain preferable for shared permissions.
A stable production policy must not expand unexpectedly	Customer managed policy under change control	The customer controls its versions instead of accepting future AWS managed policy updates.
New employee access is required in 30 accounts	Identity Center group assignment	Do not create and synchronize IAM users and groups separately in every account.

Prerequisites, permissions, Region, and cost

Run this lesson as the approved non-root course identity. Begin with aws sts get-caller-identity, confirm the private account record, and set the fixed project Region before any regional query. IAM resources are global within an account, while STS endpoints and the services reached by an identity can be regional.

Use only the read or change actions required for this lesson. An AccessDenied result is evidence to analyse, not permission to switch to root or attach AdministratorAccess. Record the action, resource, principal type, request context, and smallest justified correction.

The listed cost tier is T0 - no resource creation. Free Tier eligibility and credits are account-specific. Before a mutating lab, identify every resource that can charge, estimate its duration, start a timer, and write the reverse cleanup order. A budget reports cost after billing data arrives and is not a real-time stop control.

AWS Management Console method

Open IAM, then Users and User groups, and inspect how one user receives direct and group permissions.
Open Policies and compare an AWS managed policy with a customer managed policy and its versions.
Open an identity with an inline policy and note that the inline policy is owned by only that identity.

For every step record the service page, selected account and Region, exact object, visible state, and why that state matters. A Console label or green status is not enough unless it is tied to the final workload outcome.

AWS CLI or API evidence

Inspect all direct and group-derived managed policies for one IAM user.

aws iam list-attached-user-policies --user-name ExampleUser
aws iam list-groups-for-user --user-name ExampleUser

The first command shows direct managed policies only. Review inline user policies and every listed group policy as separate steps before calculating effective access.

Before running the command, replace every placeholder, explain each option, and decide whether the operation is read-only or mutating. Capture the exit code immediately. Redact account IDs, ARNs, public addresses, request identifiers, and personal data before sharing.

The CLI and Console are clients of AWS APIs. Matching state across them increases confidence, but neither substitutes for data-plane or application verification.

Practical work

Create users-groups-and-policies-evidence.md. Record the problem, account and Region preflight, observed Console state, matching CLI result, every decision in the table, one intentional misconception, one failure diagnosis, and the retained-state or cleanup result.

The evidence package must include:

non-root principal type, account verified privately, and Region;
exact intended and observed state;
one Console observation and the matching CLI or API result;
one successful result and one denied, failed, or counterexample result;
what each result does not prove;
cost state and elapsed lab time;
cleanup evidence or a named retained-state owner and next lesson.

Verification standard

Use three levels of proof:

Control plane: the object or policy exists with the intended configuration.
Data plane or behavior: the request, packet, session, storage path, or application does what the requirement states.
Operations: monitoring, failure diagnosis, cost, ownership, and cleanup are known.

A control-plane response can precede final readiness. Use waiters or state polling where supported, then test the actual behavior. If a request times out, do not assume it failed. Inspect state and use documented idempotency before retrying a mutation.

Troubleshooting method

Symptom	Evidence first	Smallest safe response
command cannot authenticate	credential source, expiry, caller preflight	restore approved temporary login
access is denied	action, resource, principal, all policy layers	correct only the missing or conflicting control
object appears missing	account, Region, filters, pagination, permission	align scope before creating anything
configured state exists but behavior fails	route, identity, dependency, logs, service state	test the next boundary in the path
cleanup is blocked	dependency inventory and owning service	remove dependants in reviewed reverse order

Keep the original symptom and timestamp. State one hypothesis, make one reversible change, repeat the original test, and record rollback. Never open a management port to the world, expose credentials, disable TLS verification, format an unknown disk, or add broad permissions as a generic fix.

Architecture and certification decisions

Professional-level questions provide competing valid features. Identify the requirement that decides between them: human or workload identity, same-account or cross-account access, regional or zonal scope, stateful or stateless filtering, durable or ephemeral data, latency, RTO/RPO, cost, or operational ownership.

Explain why the selected option fits and why each plausible alternative fails one stated requirement. Do not rely on feature memorization or reproduce protected certification questions.

Knowledge check

Can an IAM group assume a role?

Expected direction: No. Users assume roles. A group can grant its users permission to call sts:AssumeRole, but the group is not a principal.

Does deleting an inline policy from one role affect another role?

Expected direction: No. An inline policy belongs to one identity.

Why can an AWS managed policy be unsuitable for a tightly controlled role?

Expected direction: AWS can update it, and it often covers a broad reusable job function rather than the exact workload resources.

Does removing a direct policy guarantee that a user loses the action?

Expected direction: No. Another group, resource policy, or applicable policy source might still allow it.

Cost, cleanup, and retained state

No workload resource should remain unless this lesson explicitly creates and retains one for the next numbered lab.

Cleanup evidence includes the final state query, not only a successful delete response. Search related resources, other Regions used by the lab, retained storage, public IPv4 addresses, logging destinations, and service-managed dependencies. Schedule a later billing review because cost data can lag.

Completion gate

Pass when the practical artifact explains the real problem, matches Console and CLI evidence, answers every knowledge check, diagnoses one failure without broadening access, records cost, and proves cleanup or approved retention. The learner must defend one decision orally and name the requirement that would change it.

Official sources

View complete AWS learning path