Locate compute isolation boundaries and preserve deployment evidence after workloads disappear.
50 min 135 XPSkills: Compute isolation, Image provenance, Ephemeral evidence
Brief
At Halcyon Clinics, an overnight intake surge creates twelve temporary workers. By morning, ten have disappeared. The operations lead presents a screenshot of the two survivors as proof that every worker used the approved image. Meanwhile, a developer calls each container a tiny virtual machine and assumes each has its own kernel.
Your assignment is to reconstruct what ran, where the isolation boundary sat, and which controls remained the clinic's responsibility. You will distinguish machine images from container images, identify who schedules replicas, and preserve identity-linked launch and termination evidence rather than relying on a list of currently running machines.
A workload can disappear before the audit begins. Design evidence collection around its lifecycle, not its survival.
Virtual machines and the hypervisor boundary
A virtual machine receives virtual CPUs, memory and devices from a hypervisor and boots a guest operating system with its own kernel. A type 1 hypervisor runs directly on host hardware; a type 2 hypervisor runs on a host operating system. The distinction is placement, not whether the guest has a desktop interface. Giving four VMs two virtual CPUs each on a four-core host does not create eight physical cores: scheduling and contention still determine delivered capacity.
A machine image is a reusable boot template containing an operating system and, often, installed applications and configuration. Launching twenty VMs from an approved template does not prove they stayed patched: running guests can drift, and old image versions can keep launching. Rebuild the template, validate it, and replace instances deliberately; persistent data needs a separate migration or storage plan. A snapshot may contain sensitive data and is not automatically a sanitized deployment template.
Isolation and configuration controls need evidence at different layers: hypervisor patch records, guest vulnerability results, image approval records, and instance-to-image launch mappings. An auditor asking whether all ninety launches used the approved version needs the launch population and immutable image identifiers, not merely the five VMs still running today. Separate guest kernels improve isolation but do not make hypervisor compromise impossible.
VMs boot guest kernels, while ordinary containers share a host kernel regardless of their separate user-space files.
Container images, registries and scheduling
A container packages an application and its user-space dependencies, normally running as isolated processes that share the host kernel. Namespaces restrict views of processes and networks; resource controls limit CPU and memory. Neither mechanism gives each container a separate kernel. A privileged container or broad host filesystem mount can undermine isolation. If a host kernel flaw affects thirty containers, rebuilding application dependencies alone does not repair that kernel.
A container image consists of filesystem layers plus runtime metadata; a running container adds writable state that is commonly discarded on replacement. A registry stores and distributes images. A tag such as release can be reassigned, while a content digest identifies particular image content. Pin deployments to an approved digest and retain its scan result, provenance and approval. Scanning a tag yesterday does not establish what bytes a reassigned tag delivers today, and a digest identifies content without proving it is safe.
An orchestrator compares desired state with actual state, schedules replicas onto eligible nodes, restarts failed workloads and rolls out replacements. Desired replicas of four with only three running should trigger reconciliation, but insufficient node capacity can prevent convergence. The orchestrator is not the image registry and does not automatically make code trustworthy. Audit deployment authorization, admission decisions, runtime privilege settings, and the link from workload identity to digest; those records support change control and least privilege.
Functions and autoscaling are bounded services
A serverless function executes code in response to an event without the team provisioning individual servers for each invocation. Infrastructure still exists; responsibility shifts rather than vanishes. The service operates the underlying execution platform, while the customer still governs code, dependencies, permissions, triggers and data handling. A cold start initializes a new execution environment. Warm reuse is possible, so temporary files and process memory must not be treated as a durable or clean per-request database.
Autoscaling adjusts capacity from signals and policy. Suppose two replicas each process fifty requests per second and traffic rises to three hundred. At that measured throughput, six ready replicas are needed before headroom; a maximum of four caps capacity at two hundred. Threshold periods, startup delay, cooldown and quotas all affect response. Scaling replicas is different from adding nodes, and a bounded function concurrency setting can throttle invocations even when the service manages infrastructure.
For availability controls, retain scaling policy versions, metric timestamps, scaling decisions, readiness events and load-test results. A configured maximum is a safety or cost bound, not proof that the application meets its service objective. Function triggers can deliver an event more than once; use idempotent processing so retries do not create duplicate clinical records. Audit runtime identity permissions and invocation failures as well as execution counts.
Ephemeral compute needs durable evidence
Ephemeral means replaceable and short-lived, not exempt from patching or investigation. Local disks and container writable layers may disappear at termination. At 02:00 a worker launches from digest D7, at 02:06 it handles a record, and at 02:08 it terminates. A 09:00 inventory cannot establish its existence or its image. Export lifecycle events and runtime logs continuously to storage outside the worker's lifecycle; verify delivery before a scale-in operation where practical.
Record a unique instance or workload ID, image digest or machine-image ID, deployment revision, actor or runtime identity, launch time and termination time in UTC. Correlate application logs using that same workload ID; names and network addresses can be reused. Preserve image approvals and scan results separately, linked by immutable image identity. For example, a launch event for worker-17 joins its D7 approval to an application event at 02:06, even after worker-17 no longer exists.
Define retention against policy and investigation needs: this clinic requires at least ninety days for lifecycle records. Restrict deletion and write access, monitor export failures, and test retrieval for a terminated instance. A complete control needs a reconciliation between launch records and exported evidence, plus documented handling of gaps. The auditor's question is not simply whether logs exist, but whether every in-scope launch can be traced to an approved image throughout the review period.
External lifecycle evidence reconstructs a worker that a later inventory cannot see.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: Count the kernels, not the labels
Scenario sim+45 XP
Read the brief and answer both questions.
Incident brief
A lab host boots directly into a hypervisor and runs two guests, each with its own operating-system kernel. The trainer calls this type 2 because there are two guests. In another environment, six application containers run as isolated processes on one host kernel; a developer claims their six images imply six kernels.
Term bank, not all of these are right
type 1type 216
1.1Which hypervisor type matches the lab host? (type and a number)
1.2How many host kernels do the six described containers share? (a number)
Task 2: The tag that moved
Scenario sim+45 XP
Read the brief and answer both questions.
Incident brief
A deployment approved yesterday refers to a mutable image tag. Today that tag points to different content. The engineer says the registry will restore four replicas because it stores their images. The actual scheduler observes only three running replicas against a desired count of four.
Term bank, not all of these are right
digestorchestratortagregistry
2.1Which immutable image identifier should approval and deployment share? (one word)
2.2Which component reconciles the replica count? (one word)
Task 3: The missing morning fleet
Scenario sim+45 XP
Read the brief and answer both questions.
Incident brief
After demand falls, a compute policy automatically reduces twelve instances to two. The service owner labels this backup rotation and offers the morning inventory as evidence for all twelve launches. The ten terminated workers kept logs only on their disposable local disks.
Halcyon Clinics is replacing intake workers with ordinary containers on shared hosts. The migration memo incorrectly calls them separate-kernel VMs. Author the runtime and evidence plan using the supplied fields; this is a configuration exercise, not a request to implement the application.
Use the approved immutable reference exactly, disable privileged execution, and apply the stated replica bounds. The owner proposes local-only evidence because workers live less than ten minutes. Reject that shortcut: lifecycle export must survive termination and meet the clinic's retention floor.
Approved rollout requirements
Runtime: ordinary containers, no separate guest kernel.
Approved image reference: intake@sha256:7777777777777777777777777777777777777777777777777777777777777777
Privilege policy: privileged execution forbidden.
Autoscaling bounds: minimum 2 replicas, maximum 8 replicas.
Evidence: export lifecycle records outside the worker lifecycle.
Retention: at least 90 days.
Correlation: use workload_id, not a reusable display name.
Review six independent statements in the clinic's compute assurance packet. Accept only statements that are technically sound and provide the claimed evidence. The packet owner insists that managed execution removes all customer controls and that containers are miniature VMs.
For rejections, choose the single root defect: kernel-boundary means a false isolation claim; mutable-reference means approval is tied only to a movable tag; responsibility-gap means customer duties are incorrectly discarded; evidence-loss means records cannot outlive the workload. Accepted statements need no reason code.
Verdicts are accept or reject. Every rejection needs one reason code from: kernel-boundary | mutable-reference | responsibility-gap | evidence-loss.
Assurance packet statements
CC-1 | Each ordinary container has a separate guest kernel, so the shared host kernel needs no assessment.
CC-2 | An approval records only tag release; the tag was reassigned after scanning, but the packet claims the original scan proves the deployed bytes were scanned.
CC-3 | A serverless function means the customer no longer needs to review its code dependencies or runtime identity permissions.
CC-4 | Workers keep their only lifecycle logs on disposable local disk; tomorrow's inventory will prove all terminated launches.
CC-5 | Launch records link unique instance IDs to approved machine-image IDs; guest scan results are retained separately to detect drift.
CC-6 | A deployment pins an approved image digest, and orchestrator events record replacement replicas and their workload IDs.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Cloud Fundamentals
Storage Building Blocks
Choose storage interfaces and distinguish surviving data, reachable data, and recoverable data.
