AWS 040: AWS account, cost, and tooling foundation
Purpose
This checkpoint verifies that the personal AWS account is safe enough for later practical work and that the learner can use Console, CloudShell, local CLI, and SDK context without confusing identity, Region, permission, output, or pagination.
Passing requires evidence. A list of definitions is insufficient.
Required submission
Submit tooling-checkpoint.md plus redacted artifacts from AWS 024 through AWS 039. Do not include account IDs, principal ARNs, email addresses, telephone numbers, payment data, credentials, MFA material, or raw debug logs.
Critical safety gates
Every item must pass:
- root MFA enabled;
- no root access keys;
- separate daily non-root identity;
- daily identity uses MFA or approved federation;
- billing budget and notification path active;
- security, operations, and billing contacts current;
- fixed course Region documented;
- temporary local CLI authentication used;
- no secret in evidence or shell history;
- no unnecessary resource or quota changes.
A failed safety gate blocks progression regardless of score.
Task 1: account ownership and recovery
Explain and provide redacted evidence for:
- root use cases;
- root MFA and recovery resilience;
- absence of root access keys;
- protected root mailbox and phone recovery path;
- daily identity separation;
- what happens if the primary MFA device is lost.
Do not perform a destructive recovery test.
Task 2: cost protection
Open Billing and Cost Management and record:
- current account plan;
- Free Tier or credit state;
- relevant expiry;
course-monthly-costbudget status;- actual and forecast thresholds;
- verified notification;
- last review time.
Then answer:
- Why can a Paid plan receive charges even with credits?
- Why is a budget not a circuit breaker?
- Why can billing data and alerts be delayed?
- What retained resources can continue charging after compute deletion?
- Which page begins a charge investigation?
Use current account values, not values copied from course text.
Task 3: contact readiness
Use the contact matrix from AWS 026. For each contact type, give one sample notice, first response, escalation owner, and quarterly review date.
Scenario: an email claims an access key was exposed and asks the learner to sign in through a shortened link. Describe the safe verification and containment sequence without clicking the link or sending credentials.
Task 4: Console and Region
In the Console:
- prove non-root identity type;
- select the fixed course Region;
- open EC2 instance inventory;
- open VPC inventory;
- open IAM;
- explain which views are regional and which are account/global;
- compare one read-only page in a second Region;
- return to the course Region.
Explain why an empty EC2 page does not prove the account has no instances anywhere.
Task 5: CloudShell
Open standard CloudShell and run:
pwd
whoami
aws --version
aws configure list
aws sts get-caller-identity --output json --no-cli-pager
Explain what each command proves and what it does not prove. Confirm that whoami is a Linux user, while get-caller-identity returns AWS identity context.
Record CloudShell Region and intended workload Region. If they differ, explain why and how --region scopes a command.
Task 6: local CLI
On Linux prove:
- CPU architecture;
- AWS CLI v2 version;
- executable path;
- all discovered AWS CLI paths;
courseprofile;- temporary authentication method;
- resolved credential source;
- fixed Region;
- logout behavior.
The learner must explain installer provenance, why the archive was validated, what sudo did, and why installation did not prove AWS access.
Task 7: three-interface comparison
Use Console, CLI, and the Python SDK to report:
- principal type;
- Region;
- Availability Zone names;
- Availability Zone IDs.
All interfaces must match. If one differs, diagnose account, principal, Region, provider, filter, and pagination before correcting it.
Explain why application code should use an SDK rather than parse human-formatted CLI table output.
Task 8: API safety
For a mutating request that times out after reaching AWS:
- explain why success or failure may be ambiguous;
- classify the error before retry;
- show how a supported client token or business idempotency key prevents duplicate effect;
- define maximum attempts and elapsed time;
- specify verification and audit evidence;
- explain why a new random token on every retry is wrong.
No mutating request is executed.
Task 9: infrastructure placement
Draw:
partition -> Region -> Availability Zones
-> Local Zone where applicable
edge service -> points of presence -> regional origin
For the training portal:
- choose a primary Region;
- place application capacity across at least two AZs;
- identify cacheable edge content;
- keep assessment writes on the controlled transactional path;
- state a recovery Region requirement;
- explain zone IDs across accounts;
- identify data transfer and replication consequences.
Task 10: responsibility and governance
Compare customer and AWS responsibility for EC2, RDS, and S3 across:
- physical infrastructure;
- operating system;
- engine/platform;
- identity;
- network exposure;
- encryption;
- data;
- backup and restore;
- availability design;
- monitoring;
- cost.
Then provide the approved course tagging keys, prohibited tag data, naming format, and read-only tag compliance method.
Task 11: quota and support
Record:
- one regional quota;
- one global quota;
- applied value and usage if visible;
- headroom calculation;
- adjustability;
- expected lead time and owner.
Select Basic, Business Support+, Enterprise Support, or Unified Operations for:
- this personal learning account;
- a 24/7 revenue application needing business-critical technical response;
- a large critical portfolio needing named strategic guidance.
Use current AWS plan documentation, not historical names.
Task 12: controlled troubleshooting
Reproduce or review the AWS 039 failures:
- missing profile;
- environment profile precedence;
- invalid Region;
- denied or inapplicable read operation;
- artificially limited pagination.
For each give symptom, exit code, error stage, cause, smallest correction, and retest. The final known-good preflight must succeed.
Scoring
| Area | Points |
|---|---|
| root, identity, and contacts | 15 |
| billing and budget | 10 |
| Console, CloudShell, and local CLI | 20 |
| API, SDK, retry, and idempotency | 15 |
| global infrastructure | 10 |
| shared responsibility and tags | 10 |
| quotas and support | 10 |
| troubleshooting | 10 |
| Total | 100 |
Pass requires 85 overall, at least 70 percent in each area, and every critical safety gate.
Oral defense
The reviewer selects four actions from the evidence:
- one root-security decision;
- one CLI command;
- one architecture decision;
- one troubleshooting correction.
For each, the learner explains purpose, parameters, success evidence, failure evidence, scope, cost, and cleanup or retained state.
Remediation
Failed work is corrected with a new scenario:
- identify the failed competency;
- remove unsafe evidence immediately;
- revisit the source lesson and official documentation;
- produce corrected evidence;
- explain the original error;
- repeat the oral defense;
- record retest outcome.
Do not solve a permission failure by using root or attaching broad administrator access.
Completion gate
Pass when the score reaches 85, every safety gate passes, the final non-root account/Region preflight is correct, cost and contact controls remain active, and the learner independently defends all four selected actions.
Retain the secure account baseline, contacts, budget, fixed Region record, approved CLI profile, and private evidence. Remove obsolete tokens, temporary installers, and unsafe transcripts.