1. Map a service and its operating responsibilities

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.

Knowledge check

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

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

Read the official reference ↗

— 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.