Grant each role only the necessary access
See this course’s project requirements
A fictional cloud-service architecture packet with workload and data flow, responsibility boundary, least-privilege role matrix, unit-based cost and egress budget, recovery table and supported service decision.
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- Create a unit-labeled workload, minimal-data flow, and explicit planning-assumption register.
- Produce a service-specific provider/customer matrix and a list of real-contract questions.
- Create task-based allowed/denied role cases and clearly mark the access matrix as design evidence.
- Deliver independently checked baseline and stress costs, reserve totals, and a budget-review condition.
- Create a recovery timeline and validation checklist with distinct RPO/RTO targets and unexecuted limits.
- Deliver a supported architecture decision with calculation evidence and unresolved real-service questions.
Review and revise
Use these criteria to check your work and choose what to improve.
- The implementation or declared simulation follows the supplied contract and retains inspectable original inputs.
- Normal, boundary and rejected cases are recorded with expected versus observed results.
- The changed case has a correct explanation and does not rely on hidden state.
- The project includes source, outputs, instructions and honest tool, privacy and verification limits.
Want more background?
The idea in everyday life
Fictional reference-card service: 1000 requests/month, 20 budgeted compute hours, 2 GB stored, 4 GB outbound. Invented rates: $0.05/hour, $0.20/GB-month storage, $0.10/GB outbound, $2/month fixed; 25% reserve and $6/month budget. These are exercise assumptions, not provider prices or measured workload forecasts.
Least privilege ties permissions to tasks. Viewing public cards, editing content, and operating backups do not require the same administrative capabilities.
Grant each role only the necessary access — original worked practice
Least privilege ties permissions to tasks. Viewing public cards, editing content, and operating backups do not require the same administrative capabilities.
Fictional reference-card service: 1000 requests/month, 20 budgeted compute hours, 2 GB stored, 4 GB outbound. Invented rates: $0.05/hour, $0.20/GB-month storage, $0.10/GB outbound, $2/month fixed; 25% reserve and $6/month budget. These are exercise assumptions, not provider prices or measured workload forecasts.
1. Step 1
Create roles Viewer, Editor, and Recovery operator. List their required tasks.
You should see: The three role purposes are distinct.
Least privilege ties permissions to tasks. Viewing public cards, editing content, and operating backups do not require the same administrative capabilities.
2. Step 2
Assign Viewer public read only; Editor content read/write; Recovery operator backup/restore and operational configuration.
You should see: Each role receives task-relevant capabilities.
Least privilege ties permissions to tasks. Viewing public cards, editing content, and operating backups do not require the same administrative capabilities.
3. Step 3
Explicitly deny Editor identity administration and Viewer write/restore. Record who would review a restore before execution.
You should see: Unnecessary privileged actions are separated.
Least privilege ties permissions to tasks. Viewing public cards, editing content, and operating backups do not require the same administrative capabilities.
4. Step 4
Write three allowed and three denied role/action cases; label this as a design matrix, not deployed IAM.
You should see: A least-privilege role and test-case matrix.
Least privilege ties permissions to tasks. Viewing public cards, editing content, and operating backups do not require the same administrative capabilities.
What to finish
Create task-based allowed/denied role cases and clearly mark the access matrix as design evidence.
Watch for this
Confusing a written role matrix with implemented IAM or granting broad administration to every staff role.
How can I tell I understand it?
Demonstrate the rule: Least privilege ties permissions to tasks. Viewing public cards, editing content, and operating backups do not require the same administrative capabilities. Use the supplied variant to distinguish a changed result from a broken implementation.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkTools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Source & access notes · checked 2026-10-01
Relevant documented module/API behavior inspected during expansion authoring; actual execution evidence is recorded separately. No grant eligibility is established.
Access: Official page retrieved with the web reader on 2026-10-01. Documentation reading does not certify execution in every native tool or browser.
Reuse: Original local practice files, fictional data, worked examples and questions. Concepts paraphrased and linked; source exercises are not copied.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.