Practice for real, with AI

Model answer

A Pod is the smallest deployable unit and represents one or more containers that share the same network namespace and storage. Containers in a Pod can reach each other on localhost and share mounted volumes. You rarely create Pods directly; controllers like Deployments manage them so they are recreated and scaled automatically.

Model answer

A Deployment manages stateless, interchangeable pods with random names and is ideal for web servers and APIs. A StatefulSet gives pods stable, ordered identities and stable per-pod storage, which is required for stateful systems like databases and clustered queues that need predictable names and persistent disks.

Model answer

A Service selects pods using label selectors and tracks their IPs in an Endpoints object that updates as pods come and go. The Service gets a stable virtual IP and DNS name, so clients connect to the Service and kube-proxy load-balances to the current healthy pods, insulating callers from pod churn.

Model answer

The API server is the front door that validates and persists all state to etcd, the cluster key-value store. The scheduler assigns pending pods to nodes based on resources and constraints. The controller-manager runs reconciliation loops that drive actual state toward desired state. On each node, the kubelet runs pods and kube-proxy programs service networking.

Model answer

Both inject configuration into pods as env vars or mounted files, but ConfigMaps hold non-sensitive data while Secrets hold sensitive data. Secrets are base64-encoded, not encrypted, by default, so enable encryption at rest and restrict access with RBAC. Treat Secrets as sensitive even though the encoding is not real protection.

Model answer

Start with kubectl describe pod to read events, then kubectl logs with the previous flag to see output from the crashed container. Common causes are a failing command or bad config, a missing dependency or secret, a failing liveness probe, or an out-of-memory kill. Fix the root cause, then watch the restart succeed.

Model answer

Requests are the resources guaranteed to a container and used by the scheduler to place it; limits are the hard ceiling. If a container exceeds its memory limit it is OOM-killed, and exceeding CPU limit throttles it. Setting them well prevents noisy-neighbor problems and enables reliable autoscaling.

Model answer

RBAC grants permissions through Roles or ClusterRoles that list allowed verbs on resources, bound to subjects via RoleBindings or ClusterRoleBindings. Subjects are users, groups, or service accounts. Pods authenticate with service accounts. The guiding rule is least privilege: grant only the specific verbs and resources each workload needs.

Model answer

The manifest is sent to the API server, authenticated, authorized via RBAC, and validated by admission controllers. The desired state is written to etcd. Controllers notice the change and reconcile: the Deployment controller creates a ReplicaSet, which creates pods, the scheduler binds them to nodes, and kubelets start the containers.

Model answer

A liveness probe tells the kubelet whether a container is still healthy, and a failing one triggers a restart of that container. A readiness probe tells the service whether the pod is ready to receive traffic, and a failing one removes the pod from the endpoints list without restarting it. Use readiness for slow startup or temporary overload, and liveness only for unrecoverable hangs, otherwise you risk restart loops.

Model answer

A Deployment creates a new ReplicaSet and shifts pods over gradually, governed by maxSurge and maxUnavailable so capacity stays steady. Each revision is recorded, so you can inspect history and revert with a single rollback to the previous ReplicaSet. Pair it with readiness probes so traffic only flows to pods that are actually ready, which keeps the update safe.

Model answer

The browser resolves the domain to an IP via DNS, opens a TCP connection to that IP on port 443, performs a TLS handshake to establish encryption and verify the certificate, then sends an HTTP request. The server responds, possibly through a load balancer and CDN, and the browser renders the result. Each step is a place things can break.

Model answer

TCP is connection-oriented and reliable: it establishes a connection, guarantees ordered delivery, and retransmits lost packets, which suits web traffic and databases. UDP is connectionless and best-effort with no ordering or retransmission, which suits low-latency, loss-tolerant traffic like DNS, video, and gaming.

Model answer

CIDR notation like 10.0.0.0/16 marks how many leading bits are the network portion; the rest address hosts. A /16 has 65,536 addresses, a /24 has 256. Subnetting splits a block into smaller networks for isolation and routing, for example public and private subnets within a VPC.

Model answer

A forward proxy sits in front of clients and forwards their requests outward, often for filtering or caching on the client side. A reverse proxy sits in front of servers and accepts requests on their behalf, providing load balancing, TLS termination, and caching. NGINX as a reverse proxy is the classic example.

Model answer

A maps a name to an IPv4 address and AAAA to IPv6. CNAME aliases one name to another. MX directs mail. TXT holds arbitrary text, used for SPF, DKIM, and domain verification. NS delegates a zone. TTL controls caching, which is why DNS changes can take time to propagate.

Model answer

Walk the stack methodically: confirm the target resolves with DNS, check the route exists, verify the port is listening with ss, check firewall or security group rules, and test connectivity with curl or telnet. Tools like tcpdump and mtr show exactly where packets stop. Isolate the layer before guessing.

Model answer

Layer 4 load balancing operates on TCP/UDP and routes by IP and port without inspecting content, so it is fast and protocol-agnostic. Layer 7 understands HTTP and can route by host, path, header, or cookie, enabling features like path-based routing and TLS termination at the cost of more processing.

Model answer

The browser resolves the hostname through DNS, opens a TCP connection and a TLS handshake for HTTPS, then sends an HTTP request. The server, often behind a load balancer and reverse proxy, routes the request to an app instance, which responds with HTML. The browser then fetches linked assets and renders the page. Knowing each hop helps you reason about where latency or failures come from.

Model answer

State is the file that maps your configuration to real-world resources and stores metadata Terraform needs to plan changes. It is the source of truth, so it must be stored remotely with locking, for example S3 with a DynamoDB lock, to prevent corruption when teams run apply concurrently. Losing or corrupting state is one of the worst things that can happen.

Model answer

Plan computes the difference between desired configuration and current state and shows exactly what will be created, changed, or destroyed without making any changes. Apply executes that plan against the real infrastructure. You should always read the plan, ideally a saved plan file, before applying in production.

Model answer

Keep each environment state isolated. Options are separate directories per environment, separate backends, or workspaces. Many teams prefer separate directories or backends because it makes the separation explicit and reduces the risk of applying a change to the wrong environment. Share logic through versioned modules.

Model answer

A module is a reusable, encapsulated set of resources defined behind input variables and output values. It lets you package a pattern, like a VPC or an app stack, once and reuse it across teams and environments, pinned to a version. Modules are how you keep infrastructure code DRY and consistent.

Model answer

Drift is when the real infrastructure differs from what state and config describe, usually because someone changed it manually. Run terraform plan to detect it, since the plan will show changes needed to reconcile reality with config. Prevent drift by restricting manual changes and routing all changes through code.

Model answer

Use a lifecycle block with prevent_destroy on the resource, always review the plan before apply, restrict who can run apply in production, and use policy as code to block dangerous changes. For shared state, locking prevents concurrent applies that could cause surprises.

Model answer

Static keys are long-lived and leak easily, and rotating them is painful. Assuming a role or using OIDC federation in CI gives short-lived, automatically-rotated credentials scoped to exactly what the run needs. This shrinks the blast radius if anything is exposed and is the modern best practice.

Model answer

A VM virtualizes hardware and runs a full guest operating system on a hypervisor, so it is heavy and slow to start. A container is an isolated process that shares the host kernel using namespaces and cgroups, so it starts in milliseconds and uses far fewer resources. Containers package the app and its dependencies but not a full OS, which is why they are smaller and more portable.

Model answer

Each instruction in a Dockerfile creates a read-only layer, and layers stack into the final image. Docker caches each layer and reuses it on the next build if the instruction and its inputs are unchanged. To maximize cache hits, order instructions from least to most frequently changing, for example copy the dependency manifest and install before copying source code.

Model answer

Use a small base image such as Alpine or distroless, use multi-stage builds so only the final artifact ships, combine and clean up package installs in a single RUN, copy only what you need, and use a dotignore file to keep build context lean. A multi-stage build that compiles in a fat builder and copies the binary into a minimal runtime is usually the biggest win.

Model answer

ENTRYPOINT defines the executable that always runs, while CMD provides default arguments that are easy to override at runtime. A common pattern is ENTRYPOINT for the binary and CMD for default flags, so users can pass their own arguments without retyping the command. Both should use the exec form, a JSON array, to avoid an extra shell process.

Model answer

Containers are ephemeral, so anything written to the container layer is lost when the container is removed. Use volumes for data that must persist, which Docker manages outside the container lifecycle, or bind mounts to map a host directory in, which is handy in development. For databases, always use a named volume.

Model answer

Place them on the same user-defined bridge network and they can reach each other by container name, since Docker provides built-in DNS resolution. The default bridge network does not give name resolution, so always create a user-defined network for multi-container apps, which is exactly what Compose does for you.

Model answer

Continuous delivery means every change that passes the pipeline is ready to release, but a human approves the final push to production. Continuous deployment removes that gate, so every green build deploys to production automatically. Both rely on strong automated testing; deployment just trusts the pipeline enough to skip manual approval.

Model answer

Cache dependencies between runs, parallelize independent jobs, run the cheapest and most likely to fail checks first to fail fast, and only run heavy end-to-end tests on the right triggers. Building an artifact once and promoting it through stages, rather than rebuilding per stage, also saves significant time.

Model answer

Store secrets in the CI provider encrypted store or an external secrets manager, inject them as masked environment variables at runtime, and scope each secret to the minimum jobs or environments. Never commit secrets to the repo or echo them in logs, and rotate them regularly. Prefer short-lived, OIDC-based credentials over long-lived keys.

Model answer

Blue-green keeps two identical environments and switches all traffic from the old to the new at once, giving instant rollback by switching back. Canary releases the new version to a small slice of traffic, watches metrics, and gradually ramps up, limiting blast radius. Canary catches problems with real traffic; blue-green is simpler but flips everyone at once.

Model answer

A quality gate is an automated checkpoint that must pass before the pipeline continues, such as passing tests, meeting a coverage threshold, no critical vulnerabilities, or successful linting. Gates encode the team standard so bad changes stop automatically instead of relying on people to remember to check.

Model answer

Deploy immutable, versioned artifacts so the previous version is always available, keep database migrations backward-compatible, and decouple deploy from release using feature flags. Automate health checks after deploy and wire automatic rollback on failure. The goal is that reverting is a fast, boring, well-rehearsed operation.

Model answer

Toil is manual, repetitive, automatable work that scales with service size and produces no lasting value, like restarting a service by hand. SRE caps toil so engineers spend time on engineering that reduces future toil. Automating toil away is both a productivity and a reliability win.

Model answer

A blameless postmortem analyzes an incident assuming everyone acted reasonably given what they knew, focusing on systemic causes and concrete fixes rather than punishing individuals. Removing blame encourages honest disclosure, which surfaces the real contributing factors and prevents recurrence far better than finger-pointing.

Model answer

Each extra nine of reliability costs exponentially more, and users rarely perceive the difference past a point because their own networks and devices fail. Targeting 100% also leaves no error budget, which means no room to ship changes. The right target is the lowest reliability users are happy with, freeing budget for velocity.

Model answer

Set aggressive timeouts so you do not hang, retry with exponential backoff and jitter but bound the retries, use a circuit breaker to stop hammering a failing dependency, and apply load shedding or fallbacks to degrade gracefully. Assume every dependency will fail and design so one failure does not cascade.

Model answer

Declare the incident early, appoint an incident commander to coordinate, and assign clear roles for operations and communications. Keep a running timeline, communicate status to stakeholders on a cadence, and focus on mitigation first and root cause later. After resolution, run a blameless postmortem with tracked action items.

Model answer

An error budget is the allowed amount of unreliability, the gap between your SLO and one hundred percent. While budget remains, teams ship features freely; once it is exhausted, the focus shifts to reliability work until the service recovers. It turns the reliability debate into a shared, data-driven decision instead of a tug of war between product and operations.

Model answer

Metrics are numeric time-series that are cheap to store and great for dashboards and alerting. Logs are detailed, timestamped events useful for understanding what happened. Traces follow a single request across services to find where latency or errors occur. Used together they let you ask and answer arbitrary questions about a system.

Model answer

Monitoring watches known signals and alerts on predefined conditions, answering questions you anticipated. Observability is the property of being able to understand a system's internal state from its outputs, including questions you did not anticipate. Rich, high-cardinality telemetry is what makes a system observable rather than just monitored.

Model answer

A good alert is actionable, urgent, and tied to user-facing symptoms rather than internal causes. It should fire when a human needs to do something now, link to a runbook, and rarely be a false positive. Alerting on symptoms like elevated error rate or latency, not every resource metric, prevents fatigue.

Model answer

An SLI is a measured indicator of service health, such as the fraction of successful requests. An SLO is the target for that SLI, for example 99.9% over 30 days. The error budget is the allowed shortfall, here 0.1%, which the team can spend on releases and risk. When the budget is exhausted, slow down and focus on reliability.

Model answer

Expose a metrics endpoint using a client library, emitting counters for events, gauges for current values, and histograms for distributions like latency. Use consistent labels but keep cardinality under control. A scraper like Prometheus pulls the endpoint, and you query with PromQL for dashboards and alerts.

Model answer

Use df -h to see which filesystem is full, then du -sh on directories, often du -sh /var/* sorted by size, to drill into the offender. Common culprits are logs and old artifacts. Watch for deleted-but-open files, which lsof can reveal, since the space is not freed until the holding process closes them.

Model answer

SIGTERM (15) asks a process to shut down gracefully, letting it clean up, and can be caught or ignored. SIGKILL (9) forcibly terminates immediately and cannot be caught or ignored. Always try SIGTERM first so the process can flush state, and reserve SIGKILL for processes that refuse to exit.

Model answer

The three digits are owner, group, and other, each summing read 4, write 2, and execute 1. So 755 means the owner has read, write, execute, and group and other have read and execute. 644 is read-write for owner and read for everyone else, the common mode for regular files.

Model answer

Start with uptime and top or htop to see load average and what is consuming CPU and memory. Use vmstat and iostat to separate CPU, memory, and disk pressure, and check for I/O wait. Inspect the heaviest processes, look at recent changes and logs in journalctl, and correlate with any deploy or traffic spike.

Model answer

The desired state is declarative, versioned and immutable in git, pulled automatically by agents, and continuously reconciled so the running system matches git. Git becomes the single source of truth and a full audit log, and changes happen through pull requests rather than manual cluster edits.

Model answer

It removes manual, drift-prone cluster changes by making git the source of truth, so deployments are reviewable, auditable, and easy to roll back by reverting a commit. Reconciliation also auto-heals drift, and recovery becomes pointing a fresh cluster at the repo. It brings software engineering discipline to operations.

Model answer

Argo CD runs in the cluster and watches a git repo of manifests. It continuously compares the desired state in git with the live cluster state, reports sync and health status, and can automatically apply changes and self-heal drift. Operators push changes to git via pull request and Argo reconciles the cluster.

Model answer

Never store plaintext secrets in git. Encrypt them so only the cluster can decrypt, using tools like Sealed Secrets, or keep secret material in an external store and reference it with the External Secrets Operator, which injects real values at runtime. The encrypted reference lives in git; the secret never does.

Model answer

Grant each identity only the specific permissions it needs to do its job, and nothing more. Prefer roles with short-lived credentials over long-lived access keys, scope policies tightly to specific resources and actions, and review them regularly. This limits the damage if a credential is compromised.

Model answer

Create a VPC with public and private subnets across multiple availability zones. Put load balancers in public subnets with an internet gateway, and application and database tiers in private subnets that egress through a NAT gateway. Use security groups for tier-to-tier rules and keep the database reachable only from the app tier.

Model answer

set -e exits on any command failure, set -u errors on use of an unset variable, and set -o pipefail makes a pipeline fail if any stage fails, not just the last. Together they make scripts fail loudly and early instead of silently continuing in a broken state, which is essential for reliable automation.

Model answer

An idempotent operation produces the same result whether run once or many times, for example ensuring a user exists rather than blindly creating it. It matters because automation and configuration management re-run frequently, and idempotency makes re-runs safe, which is the foundation of declarative tooling.

Model answer

Platform engineering builds and runs an internal developer platform that abstracts infrastructure complexity behind self-service golden paths, treating the platform as a product with developers as customers. The goal is to reduce cognitive load and let product teams ship safely without becoming infrastructure experts.