Deployment, operations, and cost evidence

What you will be able to do

1. Package configuration separately from code.
2. Implement health, readiness, rollback, and rate controls.
3. Measure latency and resource consumption without purchasing services.

Prerequisites: dictionaries, loops, functions, exceptions and installed Python or paper tracing. Reuse earlier Builder artifacts only when the task requires them.

This curriculum runs self-study on VetsLearn. Where the text calls for an instructor, peer or formal review, use the stated acceptance criteria for self-review. Reflection questions support reflection; they do not replace independent assessment. A peer review is optional unless your actual organization requires it.

Part 1 Technical instruction

Deployment evidence connects a versioned artifact to a versioned configuration and an observed environment. A liveness check says the process is running; readiness says it can serve safely. Releases should be staged, observed against predeclared signals, and reversible. A rollback record identifies trigger, authority, artifact version, data compatibility, execution time, and verification. Resource estimates use synthetic measurements and published assumptions; the lab performs no procurement or production deployment.

Mechanism and implementation

Readiness checks dependencies, configuration, permissions and data/model compatibility. Liveness only checks the process. Stage artifact and configuration together; make rollback data-aware. Familiar API syntax does not establish schema, reasoning, state or streaming equivalence across backends.

Constructed offline example

Save as topic_example.py and run python topic_example.py with an installed Python 3.11+ interpreter. This standard-library construction uses synthetic values; its checks are not provider measurements.

versions = {"v1": {"schema": 1}, "v2": {"schema": 2}}
def ready(version, data_schema, policy_loaded):
    return versions[version]["schema"] == data_schema and policy_loaded
assert ready("v1", 1, True)
assert not ready("v2", 1, True)
active = "v1"
assert active == "v1"
print("candidate blocked; compatible artifact retained")

Engineering decisions

• Separate liveness from readiness.
• Define rollback triggers before release.
• Choose signals that expose user harm as well as system health.

Worked example

Release v2 fails its readiness check after a configuration change. The controller rejects promotion, restores v1, and records recovery time. Image/config scans verify that no sample secret is embedded.

Diagnose the failure

A live incompatible process is not ready. This simulator performs no deployment or provider billing. If rollback fails, inspect artifact/data compatibility rather than only a model name.

Part 2 Guided practice

Predict readiness for v2 against schema 1. Add a reversible configuration migration and rollback restoring compatible data. Independently calculate resource units from a declared synthetic trace.

Answer criteria and feedback: A live incompatible process is not ready. This simulator performs no deployment or provider billing. If rollback fails, inspect artifact/data compatibility rather than only a model name.

Continue with the downloadable pack below. If the pack or interpreter is unavailable, trace this self-contained example by hand in an input/expected-status/controlling-rule table and label execution unverified. Do not invent passing output. No account, credential, paid call, purchase or actual deployment is required.

Part 3 Remediation

Use the local simulator; do not connect to a cloud account. If readiness cannot be restored, reset from the provided version manifest and preserve the failed-state log. After repair, reassess with the alternate scenario in scenario_alt.json. A critical authorization, data-handling, evidence-integrity, or prohibited-action failure cannot be averaged into successful practice; it requires targeted remediation.

Part 4 Sources and currency

• https://csrc.nist.gov/pubs/sp/800/218/final
• https://docs.docker.com/build/building/best-practices/

Use the workflow decision reference for model/deployment/harness distinctions and controlled comparisons. Source currency must be checked before each cohort. Provider/product behavior is illustrative where mocked; resolve current interfaces only from official documentation in an authorized environment.