Skip to content
← DevOps foundations

Practical lab guide

Lab: inspect an AWS identity and design a bounded deployment

Produce an account-aware design and cleanup ledger without provisioning resources.

Documentation reviewed2026-10-01 · 3 min read · lab time varies
On this page

Choose the exercise that matches your access

With an assigned sandbox, AWS CLI v2, and short-lived login, perform the read-only checks below. Without an account, complete the architecture and operation-card exercise and label the API steps not executed. No cloud resource creation is required for this module.

Verify identity and scope

Run the identity bite's aws sts get-caller-identity --profile learning. Compare the account/role with the assigned sandbox. Choose a real authorized region and inspect its VPC and subnet inventory using the preceding commands.

For each result, distinguish observed facts from intended design. An empty list can be legitimate; an access-denied result should be recorded as an authorization limit, not replaced with invented IDs. Run the boto3 identity example only after the CLI context is understood and compare the caller identity.

Design one MicroBank environment on paper

Draw public entry, application services, persistent data, and event delivery. For each proposed resource, record its owner, network path, identity requirements, availability assumption, cost drivers, and retirement method. Use the repository's actual services and mark missing implementation work explicitly.

Add a cost plan using current regional pricing. A budget notification is a detection measure, not a hard limit. Avoid pricing an always-on managed Kubernetes cluster merely to learn these foundations; the later orchestration track can make that decision with evidence.

Review the proposed design as a request journey

Follow a browser request to public entry, an API, its database, and a messaging dependency. For every arrow, label the caller's network location, destination port, and authorization mechanism. DNS naming, network permission, IAM, and application account ownership answer different questions. The baseline API's missing token validation must remain an explicit prerequisite for any public deployment.

Choose one proposed compute model and explain why it fits this first experiment. Identify whether a database standby is for availability or a replica is for read scaling; do not count either as a tested restore. List the resources that could remain billable after compute stops.

A useful submission can be entirely a design when no sandbox is available. Its quality comes from consistent reasoning and visible untested assumptions, not fabricated resource IDs or cost-saving figures.

Plan a reversible first cloud experiment

Choose one future API operation, document its exact scope and required role, and write a creation/verification/cleanup plan. Keep it proposed in your notes until executed in the intended sandbox. An emulator can help exercise selected API shapes locally, but it does not validate production IAM, billing, quotas, or managed-service behavior.

Checkpoint and revision

Submit a private evidence note with the observed caller, actual region, API results or denied-access explanation, proposed topology, and resource ledger. If the lab was read-only, cleanup should accurately say no infrastructure was created. Clear cached sessions only when you no longer need them.

Explain why a correct caller identity does not prove all permissions, why a subnet label does not establish privacy, and why stopped compute is not necessarily zero remaining cost.

Revision: identity first, region explicit, read before create, track ownership, verify retirement.

Answer the checkpoint

A valid caller can still lack an action's permission or encounter an explicit deny. A subnet is public because of its routing design, not its label, and a resource additionally needs appropriate addressing and controls. Stopped compute can leave storage, snapshots, addresses, and supporting services behind. Point to these distinctions in your own diagram and ledger before continuing.

Apply this to MicroBank

After the six foundations modules, implement the application’s messaging and storage resources in LocalStack. Start with the project setup and follow its ordered steps; later implementation stages depend on the earlier files.

Sources and practice status

Primary references: AWS identity command↗; VPC documentation↗; AWS Budgets↗.

Reviewed against documentation on 1 October 2026. The exercises still need to be run in your environment. Record your results and tool versions in your notes.

Your notes and evidence

Record observations, questions, or links to your work. Keep credentials out of your notes.

Loading saved progress…

Back up or restore this path

Progress and notes stay in this browser. A backup contains only this learning path.