Lesson 005 · AWS Learning Path

AWS 005: How concept lessons, guided labs, break-fix labs, and architecture challenges work

Anil Jalela · Published Jun 30, 2025 · 7 min read

Why the program uses different lesson types

Creating a resource is not always the best way to learn. A cloud definition needs a classification exercise. A service configuration needs a guided lab. An outage needs evidence-led troubleshooting. A professional architecture needs a defended decision.

Using one lesson format for all of these would either make conceptual lessons artificial or make practical lessons incomplete.

What you will be able to do

By the end of this lesson, you can:

1. identify the purpose and expected evidence of each lesson type;
2. follow a guided lab without blindly copying actions;
3. diagnose a break-fix exercise from evidence before changing the system;
4. write a short architecture decision record;
5. distinguish completion from mastery.

Lesson type 1: concept and guided explanation

Use this type when the main result is understanding a model, boundary, lifecycle, or decision.

Typical structure:

1. real-world problem;
2. plain-language model;
3. labelled diagram;
4. examples and counterexamples;
5. local calculation, classification, or decision;
6. optional read-only AWS inspection;
7. misconception check;
8. evidence and assessment.

Practical evidence can be:

• a responsibility matrix;
• a packet-path drawing;
• a recovery calculation;
• a service classification;
• a decision with reasons;
• an explanation of observed read-only output.

No resource should be created merely to make the page appear hands-on.

Lesson type 2: guided lab

Use this type when the learner must configure and verify a real result.

A complete guided lab includes:

1. scenario and desired end state;
2. prerequisite evidence;
3. architecture and dependency order;
4. permissions and account identity;
5. Region and exact sample values;
6. cost warning and timer;
7. Console procedure;
8. equivalent command-line, API, or automation procedure when appropriate;
9. expected output and independent verification;
10. at least one realistic failure;
11. cleanup in reverse dependency order;
12. submission evidence and scoring rubric.

The learner must understand what each action changes. Copying a command successfully is not mastery.

Lesson type 3: break-fix or troubleshooting lab

Use this type when the system begins in a failed or degraded state.

The required order is:

Observe symptom
   |
   v
Define expected behavior
   |
   v
Collect evidence
   |
   v
Locate failed layer
   |
   v
Form one hypothesis
   |
   v
Apply smallest safe correction
   |
   v
Retest
   |
   v
Record cause and prevention

Random changes are not troubleshooting.

For example, if an EC2 web page is unreachable, do not immediately open every security-group port to the internet. Check DNS or IP, route, network ACL, security group, instance state, operating-system firewall, listening process, and application health in a deliberate order.

Good evidence includes:

• the original symptom;
• timestamp and scope;
• expected state;
• decisive evidence;
• rejected hypotheses;
• exact correction;
• successful retest;
• rollback or cleanup.

Lesson type 4: architecture challenge

Use this type when several technically valid options exist and the correct choice depends on requirements.

The learner receives:

• business goal;
• user and traffic profile;
• security and compliance constraints;
• availability and recovery targets;
• performance needs;
• operations capability;
• cost boundary;
• migration or delivery constraints.

The result is an architecture decision record, or ADR.

Course ADR template

# Decision: Short title

## Context
What problem and constraints exist?

## Requirements
Which requirements determine the choice?

## Options considered
What realistic options were evaluated?

## Decision
Which option was selected?

## Reasons
Why does it best satisfy the requirements?

## Rejected alternatives
Why were the other options not selected?

## Consequences
What security, reliability, performance, cost, and operational trade-offs remain?

## Validation
What evidence or experiment would prove the decision?

There may be more than one defensible answer. The score comes from matching requirements and explaining trade-offs, not guessing the instructor's favorite service.

Lesson type 5: automation lab

Automation begins after the manual control and service behavior are understood.

An automation lab requires:

• source-controlled files;
• a plan, preview, dry run, or validation step where supported;
• deterministic inputs;
• least-privilege execution identity;
• observable deployment;
• idempotency or repeat-run behavior;
• rollback;
• cleanup;
• evidence linking code to deployed state.

Automation that quickly repeats a misunderstanding is not progress.

Lesson type 6: checkpoint assessment

A checkpoint samples several kinds of competence:

A score can identify readiness, but a critical safety failure can still block progression.

Practical activity: classify the correct learning treatment

For each scenario, choose the best primary lesson type.

Scenario A

A student must distinguish IaaS, PaaS, and SaaS responsibility boundaries.

Scenario B

A student must launch one EC2 instance with an IAM role, user data, IMDSv2, and Session Manager, then remove it.

Scenario C

An application cannot reach its database after a network change.

Scenario D

A company must choose between backup-and-restore, pilot light, warm standby, and multi-site disaster recovery.

Scenario E

A team must deploy the same VPC reliably in development and test accounts from source control.

Scenario F

A student has completed a module and must prove independent readiness.

Expected classification

Write your first ADR

Scenario:

A new learner needs to understand cloud service models. Creating a paid managed database would add cost but would not, by itself, prove that the learner understands the responsibility boundary.

Create the directory:

mkdir -p "$HOME/nitwings-aws/evidence/aws-005"

Copy the ADR template into:

$HOME/nitwings-aws/evidence/aws-005/lesson-treatment-adr.md

Complete it with a decision between:

• concept lesson with a responsibility exercise;
• guided paid-resource lab.

Expected decision: use the concept lesson first. A later service lesson can include a managed-database lab after account, identity, networking, cost, and cleanup prerequisites exist.

Your reasons should mention:

• the learning objective;
• prerequisite order;
• cost;
• safety;
• evidence quality;
• the difference between using a service and understanding its responsibility boundary.

How to read participation labels

A fast track removes repetition, not the requirement to prove competence. No label bypasses AWS-specific identity, Region, security, cost, evidence, or cleanup controls.

Common learning failures

Check your understanding

1. When is a concept lesson practical?
2. What must happen before a troubleshooting change?
3. What makes an architecture answer defensible?
4. Why does automation come after service understanding?
5. Can a learner pass a checkpoint after exposing credentials?

Expected answers

1. When the learner produces meaningful evidence such as a classification, calculation, diagram, decision, or explanation.
2. Define expected behavior, collect evidence, locate the failed layer, and form a hypothesis.
3. It traces the selected option and rejected alternatives to explicit requirements and consequences.
4. Automation should encode understood behavior and controls, not repeat an error at scale.
5. No. Credential exposure is a critical safety failure.

Completion gate

You pass AWS 005 when:

• all six scenarios are classified correctly;
• lesson-treatment-adr.md contains a defended decision;
• you can explain the evidence expected from each lesson type;
• you understand that production brief, student-ready, technically validated, approved, and published are different states.

No AWS cleanup is required.

Official sources

• AWS Well-Architected Framework
• AWS Well-Architected reliability pillar
• AWS Well-Architected security pillar
• AWS Well-Architected cost optimization pillar