Virtual Machines Containers and Serverless

What you will be able to do

• Explain the five core cloud decisions involved in virtual machines containers and serverless.
• Choose a cloud resource or configuration that matches a stated workload requirement.
• Interpret provider state, workload behavior, and operational evidence before changing broader cloud state.
• Apply an inventory, select, configure, verify, recover, and document workflow to a realistic cloud decision.

01

Build the Cloud Decision Map

Select virtual machines, containers, or serverless execution by comparing isolation, packaging, lifecycle, control, and scaling behavior.

Cloud services combine provider-managed layers with customer-controlled configuration. A useful design keeps workload need, resource scope, identity, network path, data, health, cost, and recovery visible instead of relying on a product name.

Start with an inventory and read-only evidence. Record the account or project, location, resource identifier, owner, configuration source, dependencies, expected behavior, and current observation before changing state.

02

Virtual machine

A virtual machine provides a guest operating system with allocated compute, memory, storage, and network interfaces. It answers one distinct architecture or operating question within virtual machines containers and serverless.

Choose a VM when operating-system control or legacy software compatibility is required. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not ignore guest patching, hardening, image, and recovery responsibilities. The expected evidence is the instance boots the approved image and exposes health evidence.

03

Container image

A container image packages an application and its user-space dependencies for a compatible container runtime. It answers one distinct architecture or operating question within virtual machines containers and serverless.

Use a versioned image and keep runtime configuration outside the immutable package. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not treat a container boundary as a complete security design. The expected evidence is the same image produces the expected application behavior.

04

Serverless function

A serverless function runs code in response to an invocation or event while the provider manages the execution platform. It answers one distinct architecture or operating question within virtual machines containers and serverless.

Choose a function for bounded event-driven work with explicit inputs and outputs. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not assume execution is continuous or local state persists between invocations. The expected evidence is a test event produces one traceable result without hidden state.

05

Runtime artifact

Images, container packages, and function bundles are versioned artifacts used to create repeatable execution environments. It answers one distinct architecture or operating question within virtual machines containers and serverless.

Record the artifact version, configuration source, identity, and deployment target together. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Do not deploy an untraceable latest build into a controlled environment. The expected evidence is the running workload maps to one immutable artifact version.

06

Compute selection

The right compute model follows control, portability, startup, scaling, state, security, and operating-effort requirements. It answers one distinct architecture or operating question within virtual machines containers and serverless.

Score the workload against those requirements before selecting the execution model. Keep the target, location, identity, configuration, and observed outcome together so another person can reproduce the reasoning.

Respect this boundary: Stop when a required runtime or responsibility boundary has not been verified. The expected evidence is the selection explains both the fit and the rejected alternatives.

07

Verify One Cloud Change

Before changing cloud state, name the exact resource, required authorization, user impact, expected signal, cost effect, and recovery path. Preview the scope with an inventory or policy view and protect data or configuration that cannot be recreated safely.

Make one narrow change and stop. If the provider response, location, identity, dependency, or effective configuration differs from the plan, preserve that evidence and reassess instead of adding unrelated changes.

A successful API response or portal notification proves only that an operation was accepted. Repeat the original workload path, inspect health and security signals, verify the resulting resource state independently, and remove temporary access or test resources.

08

Recap Before Practice and Prove

Start with virtual machine. Choose a VM when operating-system control or legacy software compatibility is required. Confirm that the instance boots the approved image and exposes health evidence.

Keep container image separate. Use a versioned image and keep runtime configuration outside the immutable package. Respect this boundary: do not treat a container boundary as a complete security design.

Use serverless function as its own decision. Choose a function for bounded event-driven work with explicit inputs and outputs. Preserve the resulting evidence.

Before a broader change, review runtime artifact. Record the artifact version, configuration source, identity, and deployment target together. Stop when do not deploy an untraceable latest build into a controlled environment.

Finish with compute selection. Score the workload against those requirements before selecting the execution model. Record the final state, health signal, recovery boundary, owner, and next decision.