Cloud & Operations

Objective & prerequisites

Draw the boundaries between application, state, infrastructure and operator responsibilities. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

A service is more than application code. Map the client, entry point, application process, background work, database, object storage, identity, monitoring and backup destination. Separate durable state from replaceable code. A provider may operate hardware and managed components, while the customer still configures access, data, application behavior and recovery. The exact division depends on the chosen service and contract. Define a recovery-point objective (RPO) for acceptable lost changes and a recovery-time objective (RTO) for restoration time. They are design targets, not facts established by drawing a diagram. Identify what fails when one dependency is unavailable and who owns the response.

Worked example

The fictional CedarOps tool accepts an invented source, applies a checked job and publishes a report. Its local analogue has a configuration contract, release pointer, SQLite state and log fixtures. Accounts, uploads and credentials are outside this teaching sandbox. A release rollback should not replace current learner state. A database restore needs a separately reviewed data recovery decision, not merely a reversal of code. A backup stored beside its source illustrates restoration mechanics but not protection from loss of the whole device.

from lab import load,config
c=config(load("config.json"))
assert c["environment"]=="local-lab"
assert c["payments_enabled"] is False

Try it yourself

Complete architecture-worksheet.txt with components, data classification, owner, dependency, failure effect and recovery target. Classify each as replaceable code, durable state, configuration or evidence. Name one failure the local lab cannot simulate realistically. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Worked solution

Code artifacts can be replaced from a verified version; durable records and uploads need independent preservation and recovery policy. Configuration requires environment-specific values and access control. Evidence includes logs, manifests and restore results. The local temporary folders do not model an entire cloud region, identity provider outage or offsite backup loss, so those remain design scenarios, not tested availability claims.

Knowledge check

If a managed database is available, does that prove your application has a tested recovery plan?

Check and explain

No. Application permissions, backup scope, restore correctness, dependencies and operating procedures still need explicit verification.

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/shared-responsibility-model.html — primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.

Objective & prerequisites

Validate an environment contract before a process performs work. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

Configuration should distinguish environments without embedding private credentials in source or release archives. Treat environment values as strings until deliberately parsed; the string "false" is not the boolean False. Validate required fields, supported values and resource limits before starting work. This lab accepts only a closed local-lab contract with one to four workers, one to three total attempts and a bounded timeout. It refuses unknown fields and enabled launch gates. Those are teaching constraints; this file is not the production website configuration. Real secrets belong in an appropriately restricted secret facility or private configuration, with rotation and owner-controlled access. Avoid printing full environment dumps or source records in error logs.

Worked example

The supplied JSON specifies two workers, three maximum total attempts and five-second timeout. A misspelled key, API-key field, boolean worker count or string launch flag fails. The validator returns only the known safe fields. It does not read the machine’s environment, change Aruba credentials or start actual workers. A bounds check is not proof that a real scheduler respects the same limits; connect and test that behavior separately.

from lab import config,load
value=load("config.json")
assert config(value)["max_attempts"]==3
try:
    config({**value,"workers":True})
except ValueError:
    pass
else:
    raise AssertionError("Boolean worker count must fail")

Try it yourself

In copies, set workers to 0, True and 8; replace false with the string "false"; add a secret-like field. Predict the rejection category. Draft a deployment configuration checklist separating public values, private values and operational ownership without inserting any real secret. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Worked solution

All modified inputs fail the declared contract. Exact integer checks reject True, and launch gates require actual False. Unknown fields fail instead of being silently ignored. Use fictional examples in the worksheet and reference private values by their purpose, not their contents. A real environment reader would need explicit parsing and validation before passing values to this function.

Knowledge check

Is storing a password in an environment variable by itself a complete secrets-management policy?

Check and explain

No. Access, logging, retention, rotation and process boundaries still matter; the storage mechanism alone does not establish those controls.

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html — primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.

Objective & prerequisites

Use versioned artifacts and a controlled local activation step while preserving state. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

A release should identify the exact artifact, compatible state schema, required configuration, acceptance checks and recovery action. Build once and promote the reviewed artifact rather than editing production files by hand. A checksum can identify expected bytes but is not an independent signature or security audit. This local drill validates a small release contract, checks its canonical-content hash, writes an immutable version file and atomically replaces a JSON pointer on the same filesystem. It is a filesystem demonstration, not a distributed rollout, health-probed deployment or guarantee against power-loss durability problems. Real traffic routing and schema migrations require a separate design.

Worked example

The drill activates v1, then compatible v2. A v3 artifact with an empty message fails the declared smoke check before activation, so v2 stays current. Rollback repoints to v1. A fictional learner-state file keeps the same hash throughout. The smoke check validates the contract only; it does not execute a web application or establish end-to-end production health. An incompatible schema version is refused rather than pretending old code can safely read new state.

from lab import release_drill
r=release_drill()
assert r=={"failed_release_kept_v2":True,"rolled_back_to":"v1","state_unchanged":True}

Try it yourself

Run release_drill. In a temporary practice directory, try a wrong hash, reuse a version name with changed content and propose schema_version 2. Write separate rollback steps for a code regression and a data-corruption incident. Never pass the live website folder to the teaching activation function. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Worked solution

The normal drill reports failed_release_kept_v2=true, rolled_back_to=v1 and state_unchanged=true. Wrong hashes, mutable-version conflicts and incompatible schemas fail. A code rollback changes the selected artifact while retaining state. A data restore can discard newer legitimate records and therefore needs an explicit scope/backup decision; it must not be hidden inside a routine code rollback.

Knowledge check

Does switching back to an older application version automatically make an incompatible database migration safe?

Check and explain

No. Compatibility must be established. Database recovery and code selection are separate operations with different data-loss implications.

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

https://docs.python.org/3/library/pathlib.html — primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.

Objective & prerequisites

Validate recovered content without overwriting the current source. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

A backup file existing is not proof that it can restore the required records. Define the backup boundary, capture a consistent snapshot using the database’s supported mechanism and restore into a separate controlled target first. Check structural integrity and domain controls such as row identities, count and totals. A logical row hash compares the declared content; it is different from expecting two database files to have identical binary layout. Keep RPO and RTO distinct: a fast restore may still omit important changes after the snapshot. Production backups also require protected storage, retention, access, encryption, offsite/failure-domain planning and regular drills, none of which a temporary local file establishes.

Worked example

The drill creates two fictional orders worth 30000 and 40000 cents, then uses SQLite’s backup API. It subsequently adds a third source order of 5000. Restoring the snapshot into a new database yields two rows and 70000 cents with integrity_check=ok and matching logical row hash. The source remains three rows and 75000 cents. The restored snapshot omits one post-backup record, making the recovery-point limitation visible. The drill’s measured seconds describe one tiny local execution, not a promised RTO.

from lab import restore_drill
r=restore_drill()
assert r["restored_count"]==2 and r["restored_total_cents"]==70000
assert r["live_count_still"]==3 and r["live_total_still"]==75000
assert r["snapshot_logical_hash_matches"] and r["integrity"]=="ok"

Try it yourself

Run restore_drill and reconcile both databases. Explain why promoting the restored snapshot would omit the third order, and how you would document that decision. Complete backup-restore-worksheet.txt with scope, snapshot marker, controls, separate restore target, actual timing, loss window and recovery acceptance. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Worked solution

The restored controls are count 2 and total 70000; the current source stays count 3 and total 75000. Matching the snapshot’s logical content proves the stated local snapshot was recovered, not that all current changes were preserved. A real recovery decision must consider replay/reconciliation of later legitimate changes. Never test by restoring an old full production database over current accounts and uploads.

Knowledge check

If integrity_check returns ok, does that establish that every business record expected at the recovery point is present?

Check and explain

No. Structural integrity and business completeness are separate. Compare the declared snapshot identities, totals and scope.

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

https://docs.python.org/3/library/sqlite3.html — primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.

Objective & prerequisites

Turn safe structured observations into a reproducible operational signal. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

Logs describe events, metrics summarize populations, and traces connect work across components. Choose a service-level indicator (SLI) whose unit and denominator match the user-visible task, then define a service-level objective (SLO) and evaluation window. An error budget is the amount of failure allowed by that objective, not permission to ignore individual incidents. This lab uses one final publication outcome per fictional job, not every retry attempt. Logging each retry as a separate job would change the denominator. Structured fields make aggregation inspectable, but safe logging also requires excluding credentials and private payloads. Percentiles need a declared method and sample size; a percentile of a tiny fixture is not a capacity forecast.

Worked example

Twenty fictional job outcomes include eighteen successes and two failures: 90% success. A 95% sample objective permits one failure in twenty; two observed failures leave a remaining budget of −1. The nearest-rank p95 is the 19th sorted duration, 1000 ms; the maximum is 2000 ms. A closed log schema permits only job_id, stage, status and duration_ms, refusing extra payload fields. No monitoring daemon or alert message is sent, and the fixture represents a declared example window rather than production uptime.

from lab import log_summary,load
r=log_summary(load("job-logs.json"))
assert r["success_rate"]==0.9
assert r["p95_ms_nearest_rank"]==1000
assert r["remaining_failure_budget"]==-1

Try it yourself

Calculate success rate and p95 by hand, inspect the two failures and propose an actionable alert with owner, impact, evidence and next check. In a copy, repeat a job ID and add a token field. Explain why the summarizer should reject both rather than publish a misleading rate or private log. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Worked solution

The controls are 18/20=0.90, p95=1000 ms and remaining budget −1. Duplicate job IDs violate the one-final-outcome contract; unknown fields violate the safe schema. A real alert should link to bounded diagnostic evidence and a response runbook. This arithmetic does not prove a production SLO or justify a provider availability claim.

Knowledge check

Is a 90% success rate across this fixture equivalent to measuring 90% production availability over a month?

Check and explain

No. The population, observation window, collection completeness and service definition differ. State exactly what was measured.

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

https://sre.google/sre-book/service-level-objectives/ — primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.

Objective & prerequisites

Make one local state transition repeatable without claiming global exactly-once delivery. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

Queues may redeliver work after a timeout or lost acknowledgement. Design a stable business/event identifier and an idempotent effect rather than assuming one delivery. The local ledger stores the event ID and its amount in the same SQLite transaction as updating the total. An exact repeated ID returns duplicate; a conflicting amount for that ID raises an error. A simulated pre-commit failure rolls back both marker and total, so a retry can apply the event once. A commit followed by lost acknowledgement leads to a later duplicate, which must not apply again. This transaction covers one local database only. External emails, APIs or payments cannot be made atomic merely by adding a database marker; they require their own outbox/idempotency/reconciliation design.

Worked example

A applies 30000 cents. B’s attempted 40000 update fails before commit, leaving the total at 30000. Replaying the four supplied deliveries then applies B, recognizes two A deliveries as duplicates and rejects negative C. Final state contains two unique applied IDs and 70000 cents. The replay’s counters are applied=1, duplicate=2, rejected=1 because A was already committed before replay. bounded_retry permits at most three total attempts and retries only the simulated TimeoutError; validation failures are not retried. It does not implement durable queue scheduling or backoff.

from lab import queue_drill
r=queue_drill()
assert r["after_failure_cents"]==30000
assert r["unique_applied"]==2 and r["total_cents"]==70000
assert r["rerun"]=={"applied":1,"duplicate":2,"rejected":1}

Try it yourself

Trace the failure boundary and counters before running. Write a test for A repeated with a different amount, and one for three transient timeouts. Explain the difference between before-commit failure and after-commit/before-ack redelivery. Draft a rejected-message review process without automatically deleting evidence. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Worked solution

Conflicting A raises ValueError and leaves the committed total unchanged. Three TimeoutErrors cause exactly three attempts then a terminal error. An authorization or validation error should not be treated as a transient fault. In a real broker, acknowledgement policy, visibility timeout, deduplication retention and dead-letter handling need provider-specific tests. This lab is a single-process SQLite analogue, not a tested distributed queue or exactly-once guarantee.

Knowledge check

Can a local deduplication table guarantee that an external payment or email happens exactly once?

Check and explain

No. It does not atomically control that external side effect. Define and verify the whole delivery/effect boundary.

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues-at-least-once-delivery.html — primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.

Objective & prerequisites

Create a reviewable fictional resource inventory with ownership and cost assumptions. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

A cloud sandbox needs an identified account owner, approved region, necessary data scope, least-privilege access, spending review and cleanup evidence. Authentication is not permission to every resource. Use service-specific actions/resources and temporary credentials where supported; a broad administrator policy is not a suitable default for a learning lab. Budget alerts are notifications and can lag; they are not automatically a hard spending cap. Deleting one visible compute resource may leave storage, snapshots, addresses, logs or other chargeable resources. A teardown plan must enumerate dependencies, retention exceptions and post-cleanup inventory/billing review. This lesson writes a plan only and never connects to a cloud account.

Worked example

The plan uses deliberately invented unit rates: 720 compute hours×2 cents=1440, 10 storage units×3=30, and 5 egress units×10=50, totaling 1520 cents for a hypothetical forgotten 30-day footprint. These are not AWS or Aruba prices. The fictional budget is 2000 cents with an 80% alert threshold of 1600. The two-hour expiry is an owner review/cleanup target, not an automated deletion mechanism or a two-hour billing estimate. The checker rejects public access and non-fictional data, but cannot inspect real IAM, encryption, account budgets or actual bills.

from lab import cloud_plan,load
r=cloud_plan(load("cloud-plan.json"))
assert r["estimated_cents"]==1520
assert r["alert_threshold_cents"]==1600
assert not r["alert_in_example"]

Try it yourself

Complete cloud-sandbox-plan-template.txt and iam-review-worksheet.txt without real credentials. Recalculate an egress increase, list which resources require cleanup and record evidence needed to confirm removal. Explain why passing the JSON checker is not permission to deploy or proof that all provider charges stop. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Worked solution

The baseline monthly-if-forgotten estimate is 1520 cents and does not reach the 1600 example alert. Raising egress to 50 units produces 1970 cents and triggers the illustrative threshold; 100 units produces 2470, above the example budget. The owner must separately authorize any real account, prices, spending limit and resource plan before a live lab. Inventory and billing may update at different times, so retain verified teardown evidence and investigate leftovers.

Knowledge check

Does an 80% budget notification prevent any spend beyond the budget?

Check and explain

No. Notification and enforcement are distinct, and provider reporting/actions have timing and coverage limits.

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html — primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.

Objective & prerequisites

Distinguish reproducible design artifacts from an executed runtime or deployment. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

A container image packages a filesystem and process configuration; running it depends on a compatible container runtime and operating boundaries. Keep build context small, exclude secrets, use a reviewed base and avoid root where feasible. A mutable image tag is not an immutable digest, and a pinned digest still needs maintenance review. CI runs declared checks but does not make deployment safe by itself. Infrastructure as code records intended resource configuration; a plan needs review for actual account, region, permissions, state storage, cost and destructive changes before apply. This kit includes optional container and CI examples plus a provider-neutral plan worksheet. It includes no Terraform provider configuration and no apply command. Docker and Terraform are unavailable in the current checked environment, so their runtimes are explicitly unexecuted.

Worked example

The example Dockerfile runs the same local lab/tests and exits; it is not a web service or Aruba deployment. It requires the learner to provide a reviewed official Python base image reference, preferably a verified digest. Its non-root user and restricted copies illustrate intent, but were not tested in a container here. The CI YAML runs compile and unit tests in a disposable learning repository with read-only contents permission and no deploy/key steps. The commands were run locally; a hosted GitHub run is not claimed.

python3 -m compileall -q lab.py tests
python3 -m unittest discover -s tests -v
python3 lab.py

Try it yourself

Review container-ci-review.txt, Dockerfile.example and ci-example.yml. Identify the intended runtime user, copied files, base-image decision and absent secrets. Run the equivalent local compile/tests. Explain what additional evidence is required before calling the container, hosted CI or cloud infrastructure tested. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Worked solution

Local Python checks provide source-level evidence. A real container review needs a compatible runtime, resolved base digest, successful build/run, permissions/filesystem behavior and resource controls; hosted CI needs its actual run evidence. Neither an example Dockerfile nor YAML is an executed deployment. The provider-neutral JSON checks arithmetic/declared flags only and does not substitute for a real IaC plan.

Knowledge check

If a Dockerfile looks correct and local tests pass, can you report that its Linux container ran successfully?

Check and explain

No. Design review and local source tests are different from container-runtime evidence. Mark the latter unexecuted until it actually runs.

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

https://docs.docker.com/build/building/best-practices/ — primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.

Objective & prerequisites

Produce a handover that separates containment, code rollback, data recovery and prevention. Prerequisites: Python functions, JSON, basic SQL, Git and the existing software/testing workshops. Extract the full kit and open a terminal in cloud-operations-kit. Python 3.10+ with its standard SQLite module is sufficient for the executed labs; no cloud account, credentials, package installation or network is needed. All data and prices are invented teaching fixtures. The runnable drills use new temporary folders and databases, never the website or hosting. These free companions retain existing course progress/access. Payments and public registration remain disabled.

python3 lab.py
python3 -m unittest discover -s tests -v

Understand the concept

An incident response begins with user impact, scope and evidence, not a confident root-cause guess. Record detection time, affected task/population, current version/configuration, trusted observations and unknowns. Stabilize through the least risky authorized action, preserve evidence and assign ownership. A code rollback can address a compatible regression; data restoration needs an explicit recovery point and review of lost changes. Validate recovery with business controls and user-visible acceptance, then document causes, contributing conditions and prevention work without blame. A tabletop is a scenario exercise; it does not establish a production response time or authorize live changes.

Worked example

The fictional window shows two failed publications and p95=1000 ms. The runbook asks you to inspect bounded error categories and recent release/configuration evidence before naming a cause. The local release drill proves pointer rollback preserves a fictional state file; the restore drill proves a separate snapshot restores 70000 cents while current source remains 75000. Neither proves that a rollback fixes the log failures. You must identify the missing causal/acceptance evidence rather than joining unrelated drills into a false end-to-end incident success.

from lab import report
r=report()
assert r["observability"]["meets_sample_slo"] is False
assert r["release"]["state_unchanged"]
assert r["restore"]["live_total_still"]==75000
assert "Docker/container runtime" in r["not_executed"]

Try it yourself

Complete incident-runbook-template.txt and a 250–400 word evidence memo. Use each drill’s actual results, record unexecuted cloud/container activities and specify the checks needed to close a real incident. Include a resource cleanup review and one improvement with owner and acceptance evidence. Predict the result first, keep the original fixture, and record the exact command and observed outcome from your practice copy.

Worked solution

A sound memo distinguishes sample SLO breach, local rollback mechanics and separate recovery controls. It keeps current data intact, states the snapshot’s missing post-backup record and avoids a claimed production RTO. Follow-up may include reproducible error investigation, independent source completeness checks and a reviewed deployment/recovery exercise. No live site, account, upload, payment or registration setting is changed by this mini-project.

Knowledge check

Does a successful local rollback drill prove it fixed an unrelated set of production failures?

Check and explain

No. Recovery requires incident-specific acceptance evidence and a supported causal diagnosis. Keep tabletop and production claims separate.

Evidence, mistakes & handover

State whether an activity was executed locally, reviewed as a design, or left unexecuted. A successful local drill does not verify a cloud provider, container, hosted pipeline or production recovery. Keep an owner, acceptance criteria, known failures and rollback/cleanup evidence with the work. The download includes source fixtures, runnable drills/tests, separate exercises and solutions, a runbook, a resource plan, an optional container/CI review pack and a capstone rubric. Credit the teaching baseline and your own contribution; no certification, commercial service or employment guarantee follows.

Authoritative reference

https://sre.google/sre-book/managing-incidents/ — primary/official reference for the mechanism. Lesson explanations and fictional cases are original. Provider details can differ; this lesson does not configure or provision an account. No production access, payment, public registration or live deployment is activated.