DevOps and cloud interview bank

A Dev Container combines a container image or Compose project with development metadata such as the workspace mount, remote user, editor customizations, forwarded ports, Features, and lifecycle commands. It is optimized for writing, building, and debugging code, so it may contain compilers, shells, and editor services. A production image is a release artifact with a smaller runtime surface, a production entrypoint, and separate secret and deployment controls. They can share a base stage and build commands, but publishing the development image directly usually carries unnecessary tools and privileges into production.

An image is immutable input: filesystem layers plus default runtime configuration. Creating a container combines that image with a command, environment, networks, mounts, limits, and a writable layer. Many containers can share one image, and deleting a container does not delete the image. Unmounted changes in the writable layer disappear when that container is removed. A named volume is managed separately and can be attached to replacement containers, so it is appropriate for persistent data. Persistence is not backup, however; volume deletion, corruption, and operator mistakes still require tested backup and restore procedures.

A WebAssembly container is usually a Wasm module or component distributed with OCI tooling and executed by a Wasm runtime connected to the container stack. It reuses registries, digests, Pods, and deployment controllers, but it does not imply a Linux user space or a native process. Host access arrives through explicitly supplied imports such as WASI interfaces. A Linux container instead runs native binaries against a kernel ABI and relies mainly on namespaces, cgroups, and security policy. Wasm is not a drop-in replacement when an application needs arbitrary system calls, shell tools, devices, or unported native libraries.

Use initializeCommand for repeatable preparation where the source lives on the host. During first creation, container-side stages run as onCreateCommand, updateContentCommand, and postCreateCommand. Put installation that belongs to a new container there, and choose waitFor when attachment must wait for a later stage. postStartCommand runs whenever an existing container starts, so it should stay fast and repeatable. postAttachCommand runs after each tool attachment and should avoid changing shared project state. Test first creation, restart, reattachment, and rebuild because each path executes a different subset.

The repository controls files that supporting tools may execute. initializeCommand runs on the host, while lifecycle scripts and Features execute during creation or build. Bind mounts can expose host files, forwarded agents can expose credentials, and a mounted Docker socket can give container code control over the host engine. privileged mode, devices, and extra capabilities weaken isolation further. Review the entire .devcontainer directory and Feature sources before opening an untrusted project. Start with a non-root user, narrow read-only mounts, no Docker socket, and no credentials unless the task requires them.

Start with a non-root image user, a read-only root filesystem, narrow mounts, explicit resource limits, and only the capabilities and devices the workload requires. Do not mount the Docker socket or use privileged mode as a general permission fix. Publish only required ports, preferably on an explicit host address. Use exec-form ENTRYPOINT or CMD so the application becomes the main process and receives stop signals directly. Then test the final image: inspect its effective user and mounts, send the configured stop signal, confirm it stops accepting work, finishes bounded cleanup, and exits before the engine applies a forced kill.

Start with the whole input graph, not only devcontainer.json. Pin the base image by digest when exact content matters, commit the Dev Container Feature lockfile, and use frozen language dependency lockfiles. Review downloads and operating-system repositories used by the Dockerfile. Record the CLI and container-engine versions used in CI, because implementations and host architecture can affect the result. Run a cold-cache build to catch dependencies that exist only in an old layer, then run the project tests. Update pins through reviewed automation so reproducibility does not block security fixes indefinitely.

Pinning a base image by digest fixes the referenced manifest, and lockfiles constrain language dependencies. A narrow build context, precise COPY instructions, frozen package installation, and recorded build arguments reduce other variation. That still does not freeze operating-system repositories, remote downloads, secret values, host architecture, or builder behavior unless each is controlled. Multi-platform references can also select different manifests by platform. Run periodic cold-cache builds because a warm cache can hide an undeclared dependency. Update pins through reviewed automation, rebuild, scan, and test; a reproducible old image can still contain known vulnerabilities.

Compose normally places project services on a shared network with DNS based on service names, so an application reaches its database as db:5432 rather than localhost. Ports need publishing only when the host or an external client must connect; service-to-service traffic stays on the project network. Put database state in a named volume or external store instead of the container writable layer. depends_on controls order, but readiness requires a health check and the service_healthy condition. Validate the rendered configuration first, then start the stack and test a real connection because syntactically valid YAML cannot prove runtime readiness.

Start with the component binary, not its documentation: inspect its world, imports, exports, and pinned WIT versions. For each import, trace the runtime binding to the host implementation and then to concrete resources such as preopened directories, allowed HTTP hosts, environment values, or secrets. Continue outward through Pod volumes, ServiceAccount permissions, network policy, and node configuration because the Wasm sandbox sits inside those controls. Finally run negative tests that read a forbidden path, contact a denied host, request a missing interface, and exhaust the execution budget. Keep the observed denial and audit events as deployment evidence.

Test the complete consumer path. A conventional image can place the .wasm file in a filesystem tar layer, which works with more existing registry and image tooling but leaves entry-path and command conventions to the shim. The CNCF Wasm OCI Artifact layout uses application/vnd.wasm.config.v0+json and application/wasm, which describes Wasm directly but requires those media types to survive the registry, client, scanner, containerd, and runtime. Whichever format you select, recalculate every descriptor, deploy by digest, pull it back after publication, and start it with the exact production containerd and shim combination.

Follow the names and boundaries in order. Confirm that pod.spec.runtimeClassName equals an existing RuntimeClass metadata.name, then inspect that object’s handler and scheduling constraints. On an eligible node, verify the matching CRI runtime configuration, shim binary, engine version, and service reload. Next inspect events for scheduling, authentication, media-type, pull, unpack, and shim errors. Pull the artifact by digest with production tooling and compare its manifest, config, layer sizes, and hashes. Finally run a known-good smoke artifact through the same RuntimeClass. Do not relabel the host architecture as wasm32; use a separate label for runtime availability.