Learning bite
Give each workload scoped access
Describe a cloud operation through its principal, action, and resource.
AWS
Predict before you try
Does a successful request with dummy emulator credentials prove the AWS role works?
Try it: Work through the MicroBank example →On this page
The operating question
A principal is the identity making a request. Its permissions determine which actions it can perform against which resources. For the proposed MicroBank cloud publisher, begin with publishing to the intended SNS topic rather than giving it broad administration rights. Keep provisioning identities separate from runtime identities. On AWS, use workload roles and temporary credentials where supported; do not copy the emulator’s dummy keys into a cloud deployment.
Work through the MicroBank example
Write an access contract for the publisher: intended principal, topic, permitted action, credential delivery, and an unrelated action that should be denied. This design exercise needs no credentials or running cloud resources. A real check requires the approved sandbox and its evidence.
Consider one publisher identity, not an administrator identity:
| Access-contract field | Proposed value |
|---|---|
| Principal | The workload role assigned to the publisher |
| Allowed operation | Publish to the selected requested-event SNS topic |
| Resource | The exact topic in the intended account and region |
| Credential lifetime | Temporary credentials delivered through the runtime's supported mechanism |
| Negative check | Publishing to a different topic is denied |
| Separate identity | Provisioning creates/changes resources; this runtime role does not |
A positive check and a denied check answer different questions. Local dummy credentials provide neither piece of AWS authorization evidence.
Keep the selected source revision and distinguish an illustrative design from actual environment evidence. The teaching reference is MicroBank f75da68 from the implementation guide. Inspect newer application branches before carrying version-specific findings forward.
Compare your reasoning
Does a successful request with dummy emulator credentials prove the AWS role works? No. Verify authorization in the environment that enforces that role.
Checkpoint
Save your diagram or decision record, its assumptions, and the next missing verification. No cloud account or provisioning is required for this design bite. Any later cloud run needs its own approved sandbox, scoped identity, cost boundaries, and cleanup evidence.
Read further
Prove what you learned
Inspect the result
Save the component/owner decision, a denied or failed path, and the missing verification.
Explain it in your own words
Explain why your observation supports the stated outcome, and name one thing it does not prove.
Try a small variation
Change one design requirement and revise only the affected decisions; state the trade-off.
Your evidence should show
- Record the context/revision or label the work as a paper or prepared fixture.
- Compare the prediction with the actual result from “Work through the MicroBank example”.
- Save the component/owner decision, a denied or failed path, and the missing verification.
- Explain the transfer challenge and retain the same verification question.
Hint
Separate runtime, identity, network, data, messaging and recovery ownership.
Answer guide: compare after predicting
No. Verify authorization in the environment that enforces that role.
Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.
Recall the source-derived MicroBank component map and cloud service responsibility model. Revisit the previous lesson.
Save the prediction, result and explanation ↓Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.