AWS 050: Create a least-privilege role and test allowed and denied actions
The problem
A team uses Create a least-privilege role and test allowed and denied actions 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 Create a least-privilege role and test allowed and denied actions. 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 lab boundary;
- explain trust first;
- explain narrow permission;
- explain session evidence;
- explain denied proof;
- 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 retentionNever 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 |
|---|---|
| Lab boundary | Create one role named nw-p03-readonly-role, allow only selected read operations, prove one allowed and one denied action, then remove the role. |
| Trust first | The bootstrap administrator assumes the role for testing. The trust policy names only the current account principal path used for the lab. |
| Narrow permission | The lab policy allows sts:GetCallerIdentity and ec2:DescribeAvailabilityZones. It does not grant resource creation or mutation. |
| Session evidence | After assumption, GetCallerIdentity must show an assumed-role session. The temporary access key, secret, and token are never copied into submitted evidence. |
| Denied proof | A harmless list or create action absent from the role policy must return AccessDenied. Denial is part of the intended result. |
| Cleanup | Delete inline policies, remove the role, and verify get-role returns NoSuchEntity. IAM objects have no hourly charge, but cleanup prevents later confusion. |
How to reason about it
Create the trust and permission documents as separate JSON files. Validate them before creation. Record the exact principal and actions, and refuse any suggestion to attach AdministratorAccess just to make the test easier.
Use a named temporary profile or a subshell for the assumed credentials. Restoring the original identity is a required lab step. Never paste temporary credentials into the lesson submission.
Use the following decision table as a starting point, then change the answer when the scenario changes.
| Requirement | Preferred direction | Why |
|---|---|---|
| Read zone inventory | Allow ec2:DescribeAvailabilityZones | The action is read-only and does not support a narrower resource ARN. |
| Create an instance | Intentionally denied | The role is an evidence reader, not a builder. |
| Need broader read later | Add only observed required actions | Do not replace the policy with a broad job-function policy. |
| Lab finished | Delete role and local session state | The evidence remains while access is removed. |
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 T1 - free or near-free with immediate cleanup. 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, Roles, Create role, choose Custom trust policy, and name the role nw-p03-readonly-role.
- Add one customer inline policy named nw-p03-readonly with only the approved read actions, then inspect Access Advisor and policy validation.
- Use the role switch or CloudShell assume-role path, prove allowed and denied actions, then remove the policy and role.
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
Assume the role and test its effective identity before any action.
aws sts assume-role --role-arn arn:aws:iam::<account-id>:role/nw-p03-readonly-role --role-session-name p03-test
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::<account-id>:role/nw-p03-readonly-role --action-names ec2:DescribeAvailabilityZones ec2:RunInstancesThe simulator should evaluate the describe action as allowed and the launch action as implicitly denied. A live assumed-role test still supplies the final evidence.
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
Use exact names nw-p03-readonly-role and nw-p03-readonly. Save the trust and permission JSON, run Access Analyzer validation, create the role, assume it for a 15-minute test session, run describe-availability-zones, attempt one harmless unauthorized operation selected by the instructor, and save redacted allowed/denied evidence. Return to the bootstrap identity, delete the inline policy and role, and verify absence.
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
- Why is an AccessDenied result required?
Expected direction: It proves the permission boundary, not a broken lab.
- May temporary credentials enter evidence?
Expected direction: No. Record only the session type and redacted result.
- Does the trust policy grant EC2 describe permission?
Expected direction: No. The permission policy does.
- What proves cleanup?
Expected direction: The role is absent and the original identity is restored.
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.