Learning bite
Trace cloud network boundaries
Distinguish the route to a service from the policy that permits traffic.
AWS
Predict before you try
Can the database connection work while the browser request fails?
Try it: Work through the MicroBank example →On this page
The operating question
A request needs a route to its destination and applicable access rules. For MicroBank, draw the caller, entry point, API workload, database, and messaging endpoint. Mark address resolution and every intended connection. A security group controls allowed traffic for its associated resources; naming a subnet private is not an application authentication mechanism. Keep public ingress separate from database access.
Work through the MicroBank example
Create an account-free network diagram for one proposed AWS target. Record the source, destination, protocol, and port for each required connection. Include one denied path, such as an unrelated source connecting to the database. Do not open or provision anything for the diagram exercise.
For example, a proposed connection inventory might contain:
| Caller | Destination | Intended path | Evidence required |
|---|---|---|---|
| Browser | Public HTTPS entry | HTTPS on the configured entry port | DNS, certificate, and main-document response |
| Accounts workload | Accounts PostgreSQL | Private database connection on its configured port | Caller-specific connectivity and database authentication |
| Publisher | Intended SNS endpoint | HTTPS to the selected service endpoint | Route, workload identity, and permitted publish operation |
| Unrelated external caller | Accounts PostgreSQL | No permitted direct path | A controlled denied-path check in the selected sandbox |
“Private” describes a network boundary; it does not replace application authentication. Keep DNS resolution outside the application traffic arrows.
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
Can the database connection work while the browser request fails? Yes. They are different paths and must be investigated from their respective callers.
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
Yes. They are different paths and must be investigated from their respective callers.
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.