Lesson 023 · AWS Learning Path

AWS 023: Cloud and IT foundation

Anil Jalela · Published Jul 18, 2025 · 5 min read

Purpose

This checkpoint tests whether you can reason about cloud systems before working inside an AWS account. It is not a vocabulary quiz. You must explain decisions, calculate boundaries, trace paths, diagnose evidence, and model an application independently.

Required submission

Submit one foundation-checkpoint.md and the evidence files from AWS 001 through AWS 022. Remove secrets, personal identifiers, public IP addresses tied to you, and any account information before sharing.

Assessment rules

• Closed notes for the first 45 minutes.
• Notes and official documentation allowed during remediation.
• No protected certification questions.
• No AWS resources or paid tools.
• State assumptions when information is missing.
• Show calculations and reasoning, not only final answers.

Domain 1: cloud and responsibility

Explain:

1. elasticity compared with scalability;
2. high availability compared with disaster recovery;
3. fault tolerance compared with backup;
4. CapEx compared with OpEx;
5. shared responsibility for infrastructure, configuration, identity, data, and application security;
6. why a managed service changes but does not remove customer responsibility.

Scenario: A team migrates a vulnerable web application to a managed cloud database but leaves the application secret in a public repository. Identify the provider and customer responsibilities and the first containment actions.

Pass evidence must distinguish security of the cloud from security in the cloud without using the model as an excuse to ignore service-specific responsibility.

Domain 2: architecture requirements

Use the training-portal scenario from AWS 022. Without naming AWS services:

• draw presentation, application, and data responsibilities;
• trace catalog browse, sign-in, assessment submission, and admin publish;
• mark internet, identity, application, data, and control-plane boundaries;
• define one availability target, RTO, and RPO;
• explain how a timed-out committed write is retried safely;
• identify at least three unknown requirements.

Pass evidence must make logical tiers independent of server count.

Domain 3: networking

Starting with private planning pool 10.0.0.0/8, select 10.20.0.0/16 for the proposed VPC and use these /20 subnets:

10.20.0.0/20
10.20.16.0/20
10.20.32.0/20
10.20.48.0/20
10.20.64.0/20
10.20.80.0/20

For each subnet provide first address, last address, total address count, ordinary AWS-assignable count, tier, and failure-domain intent.

Then explain:

• why 10.0.0.0/8 is not entered as the course VPC CIDR;
• why private addressing is not a firewall;
• route selection using longest-prefix match;
• DNS resolution compared with packet routing;
• the stateful return behavior of a firewall;
• one likely hybrid-network overlap failure.

Domain 4: Linux and data formats

Provide commands and explanations that:

• identify the current directory;
• create a nested evidence directory safely;
• list files including hidden entries;
• show file permissions;
• inspect a service and recent logs without changing it;
• prove one successful and one failed command using exit codes;
• set, print, export, and remove a nonsecret environment variable;
• validate JSON;
• explain why a downloaded script should be inspected before execution.

Do not include commands you cannot explain. A correct command with an unsafe or incorrect explanation does not pass.

Domain 5: compute, storage, and data

Choose and justify:

1. a virtual machine for a legacy daemon needing operating-system control;
2. a container for a portable stateless worker;
3. a function for short event-driven processing;
4. object storage for durable course media;
5. block storage for a filesystem attached to one compute host;
6. file storage for shared filesystem semantics;
7. relational data for transactionally related assessment records;
8. key-value data for direct session lookup;
9. graph data for relationship traversal;
10. an analytics path for historical completion reporting.

Include one rejected alternative for every choice.

Domain 6: reliability and troubleshooting

For each symptom, give evidence, likely cause, smallest safe correction, and retest:

Practical challenge

Create:

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

Build foundation-checkpoint.md with these sections:

Assumptions
Cloud responsibility
Three-tier model
Networking calculations
Linux evidence
Compute and storage decisions
Data decisions
Reliability plan
Troubleshooting
Self-assessment

The document should stand alone. A reviewer must be able to follow the reasoning without reading earlier notes.

Scoring

Pass requires:

• at least 80 overall;
• at least 60 percent in every domain;
• correct CIDR boundaries;
• no unsafe secret handling;
• no missing architecture flow;
• no claim that backup alone proves recovery.

A critical safety failure produces remediation even when the numeric score is high.

Oral review

The reviewer selects three claims from the submission and asks:

1. What evidence supports this?
2. Which assumption would change the decision?
3. What would fail first?
4. How would you detect it?
5. What is the lowest-risk correction?

The learner should answer in plain language rather than reciting product slogans.

Remediation and retest

For a failed domain:

1. name the exact failed competency;
2. return to the relevant lesson;
3. correct the artifact;
4. add an explanation of the original error;
5. complete a different scenario supplied by the reviewer;
6. retest only after the evidence is complete.

Do not average a critical gap away. For example, strong database knowledge does not compensate for unsafe credential handling.

Common checkpoint failures

• service names replace requirements;
• diagrams omit identity or return traffic;
• a /20 boundary is calculated like a /24;
• public, private, encrypted, and authorized are treated as synonyms;
• exit output is copied without explaining what it proves;
• a cache is treated as the only durable copy;
• Multi-AZ is claimed without dependency analysis;
• cleanup is omitted because the work was "only a lab."

Completion gate

Pass when the scored submission reaches 80, clears every critical gate, and the oral review confirms independent reasoning. Record the score, failed items, remediation, retest date, and reviewer decision in P01.

No AWS resources were created.

Official sources

• AWS Well-Architected Framework
• AWS Shared Responsibility Model
• AWS Regions and Availability Zones
• RFC 1918 private address allocation
• AWS database selection guide