Containers, Kubernetes, Terraform and AWS for Full-Stack Interviews

At 4+ years you are not expected to run a cluster alone. You are expected to read a Deployment file, explain why a pod keeps restarting, choose between Lambda and a container, write a safe IAM policy, and say what terraform plan is telling you. This lesson gives the words and the model answers.

It does not repeat the hands-on steps. For Docker, read DevOps, Lesson 9. For IAM basics, read Lesson 5. For VPC, Lesson 6. For RDS, Lesson 8. For S3 and CloudFront, Lesson 11. For load balancers and auto scaling, Lesson 12. For Terraform step by step, Lesson 15. For cost, Lesson 19. The release side (pipelines, rollbacks, Sentry, SLOs) is in Deployment, CI/CD and Monitoring. Here we look at what is asked in the interview room.

Words used in this lesson

• A container is a running process that is isolated from others (its own files, network and process list) but shares the host's operating system kernel. Think of a flat in a building: separate rooms, shared pipes.
• A virtual machine (VM) is a whole fake computer with its own operating system, running on real hardware. Think of a separate house.
• Kubernetes (K8s) is a system that runs containers across many machines and keeps them in the state you asked for. You say "I want 3 copies of this image", and it makes that true and keeps it true.
• A cluster is a set of machines (nodes) run by Kubernetes. The control plane is the part that makes decisions. Nodes run your containers.
• Declarative means you describe the result you want, not the steps. Reconciliation is the loop where Kubernetes compares "what you asked for" with "what exists" and fixes the difference.
• A manifest is a YAML file that describes one Kubernetes object.
• Infrastructure as Code (IaC) means you describe servers, databases and networks in files, store them in Git, and apply them with a tool, instead of clicking in a console.
• Serverless means you give the cloud a function or a container and it runs it on demand, scales it, and bills by use. There are still servers; you just do not manage them.
• PaaS (Platform as a Service) is a host that builds and runs your app from your code with almost no setup, such as Vercel, Render or Heroku.
• Least privilege means giving a person or program only the permissions it needs for its job, and nothing more.

1. Containers vs VMs

Containers are not "lighter VMs". They are normal processes with walls built from Linux features (namespaces limit what a process can see, cgroups limit how much CPU and memory it can use). That is why a container cannot run a different kernel, and why a kernel bug can matter to every container on the host.

Most of the cloud is both: your containers run on VMs (EC2 nodes), or on a managed layer that hides the VMs (Fargate).

2. What Kubernetes does, and the objects you must know

You do not tell Kubernetes "start container X on machine 3". You send it an object that says what you want. Controllers inside Kubernetes watch for differences and fix them. If a node dies, the Deployment controller notices that only 2 of 3 pods exist and creates another.

The objects, in order of use

• A Pod is the smallest thing Kubernetes runs: one or more containers that share a network address and storage. Usually one container per pod. Pods are disposable: they get a new IP when replaced.
• A Deployment is an object that keeps N identical pods running and handles updates. It creates a ReplicaSet (one per version) that does the counting. You almost never create bare pods.
• A Service is a stable name and IP in front of a changing set of pods. It finds pods by labels (key-value tags). Types: ClusterIP (inside the cluster, the default), NodePort, and LoadBalancer (asks the cloud for a load balancer).
• An Ingress is a set of HTTP rules (host and path to Service) that an ingress controller (a program such as NGINX or a cloud load balancer controller) turns into real routing. The Gateway API is the newer, more expressive replacement; the Kubernetes docs say the Ingress API is frozen (still supported, no new features) and recommend Gateway for new work. Also note: the Kubernetes project announced the retirement of the community ingress-nginx controller, with best-effort maintenance only until March 2026 (see its README). The nginx class in my example is only a placeholder; for new work pick a controller that is still maintained, or use a cloud load balancer controller or a Gateway API implementation.
• A ConfigMap holds non-secret settings. A Secret holds sensitive values (passwords, tokens).
• An HPA (HorizontalPodAutoscaler) changes the number of replicas of a Deployment based on a metric such as CPU.

Difference in one line: a Pod runs the app, a Deployment keeps pods alive and updates them, a Service gives them one stable address.

One complete example

This file creates all of them for a Node API. It passed kubeconform --strict against Kubernetes 1.34.

apiVersion: v1kind: ConfigMapmetadata:  name: shop-api-configdata:  LOG_LEVEL: info  FEATURE_NEW_CHECKOUT: "false"---apiVersion: v1kind: Secretmetadata:  name: shop-api-secretstype: OpaquestringData:  DATABASE_URL: postgres://shop:CHANGE_ME@db.internal:5432/shop---apiVersion: apps/v1kind: Deploymentmetadata:  name: shop-api  labels:    app: shop-apispec:  replicas: 3  revisionHistoryLimit: 5  selector:    matchLabels:      app: shop-api  strategy:    type: RollingUpdate    rollingUpdate:      maxSurge: 1      maxUnavailable: 0  template:    metadata:      labels:        app: shop-api    spec:      terminationGracePeriodSeconds: 30      containers:        - name: api          image: registry.example.com/shop-api:1.4.2          ports:            - containerPort: 3000          envFrom:            - configMapRef:                name: shop-api-config            - secretRef:                name: shop-api-secrets          resources:            requests:              cpu: 250m              memory: 256Mi            limits:              memory: 256Mi          startupProbe:            httpGet:              path: /health/live              port: 3000            periodSeconds: 5            failureThreshold: 24          livenessProbe:            httpGet:              path: /health/live              port: 3000            periodSeconds: 10            failureThreshold: 3          readinessProbe:            httpGet:              path: /health/ready              port: 3000            periodSeconds: 5            failureThreshold: 2          lifecycle:            preStop:              sleep:                seconds: 5---apiVersion: v1kind: Servicemetadata:  name: shop-apispec:  selector:    app: shop-api  ports:    - port: 80      targetPort: 3000---apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: shop-apispec:  ingressClassName: nginx  tls:    - hosts: [api.example.com]      secretName: api-example-com-tls  rules:    - host: api.example.com      http:        paths:          - path: /            pathType: Prefix            backend:              service:                name: shop-api                port:                  number: 80---apiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata:  name: shop-apispec:  scaleTargetRef:    apiVersion: apps/v1    kind: Deployment    name: shop-api  minReplicas: 3  maxReplicas: 10  metrics:    - type: Resource      resource:        name: cpu        target:          type: Utilization          averageUtilization: 70  behavior:    scaleDown:      stabilizationWindowSeconds: 300

Read it from the top. The Deployment's selector must match the pod template labels, and the Service's selector matches the same labels. That label match is how everything finds everything.

3. Probes: how Kubernetes knows your app is fine

A probe is a check that Kubernetes runs against a container on a timer. There are three kinds, and the answer to "which one" is a classic interview question.

In my example the startup probe allows 5 s x 24 = 120 s to boot. After that, liveness takes over with a tight setting.

The most common mistake: putting a database check in the liveness probe. If the database is slow, every pod fails liveness, Kubernetes restarts them all, and now the app is down and restarting, which also hits the database harder when they come back. Liveness should only say "this process is broken". A slow dependency should make the pod not ready, not dead. (Same point as in Lesson 26.)

A tiny Node server with both endpoints and a graceful shutdown. I ran it and sent SIGTERM; it exited with code 0.

import http from "node:http";let ready = false;let shuttingDown = false;const server = http.createServer((req, res) => {  if (req.url === "/health/live") {    res.writeHead(200).end("ok"); // process is alive; do NOT check the database here  } else if (req.url === "/health/ready") {    const ok = ready && !shuttingDown; // add a cheap dependency check here if needed    res.writeHead(ok ? 200 : 503).end(ok ? "ready" : "not ready");  } else {    res.writeHead(200).end("hello");  }});server.listen(3000, () => {  ready = true;});process.on("SIGTERM", () => {  shuttingDown = true; // readiness now fails, so the Service stops sending new traffic  server.close(() => process.exit(0)); // finish in-flight requests, then exit  setTimeout(() => process.exit(1), 25_000).unref(); // stay below terminationGracePeriodSeconds});

Why preStop sleep? When a pod is deleted, two things start at about the same time: Kubernetes sends SIGTERM to your container, and it begins removing the pod from the Service. The second part spreads through the cluster and takes a moment, so for a short time new requests can still arrive at a pod that is shutting down. A few seconds of preStop sleep (before SIGTERM) hides that gap. The default grace period is 30 seconds, after which the container is killed. More on graceful shutdown: Backend, Lesson 4.

4. Requests and limits

Each container can set two numbers per resource:

• A request is the amount the scheduler reserves for the container. The scheduler places the pod on a node that has this much free. It is also the base for the HPA's CPU percentage.
• A limit is the maximum the container may use.

CPU is measured in cores (250m = a quarter of a core). Memory is in bytes (256Mi).

What happens at the limit is different for each resource, and interviewers love this:

CPU can be squeezed and shared, memory cannot. QoS (quality of service) classes decide who is evicted first when a node runs short: BestEffort (no requests or limits) goes first, then Burstable, and Guaranteed (requests equal limits for every resource) last.

My common setup: memory request equals memory limit, CPU request set, no CPU limit. The reasoning is that a CPU limit can throttle a Node app even when the node has idle CPU, which shows up as odd latency spikes. This is a common practice, not a rule, and some platforms or teams require CPU limits for fairness. State your trade-off out loud.

Without any requests, the HPA cannot calculate "70% of requested CPU", and the scheduler cannot place pods well. Always set requests.

5. Rolling updates and rollbacks

A Deployment has a strategy. The default is RollingUpdate: it creates new pods and removes old ones step by step, so there is no downtime if the pods have good readiness probes.

Two numbers control the speed:

• maxSurge is how many extra pods above the desired count may exist during the update.
• maxUnavailable is how many pods may be missing during the update.

Both default to 25%. My example uses maxSurge: 1, maxUnavailable: 0: start one new pod, wait until it is ready, then remove one old pod. It is slower but never lowers capacity. Without a readiness probe, "ready" means "container started", and the rollout can send traffic to a pod that is still booting. The readiness probe is the safety belt of rolling updates.

The other strategy is Recreate (stop all old, then start new). Use it only when two versions must never run together.

kubectl set image deploy/shop-api api=registry.example.com/shop-api:1.4.3kubectl rollout status deploy/shop-api     # waits; non-zero exit if it failskubectl rollout history deploy/shop-apikubectl rollout undo deploy/shop-api       # back to the previous revisionkubectl rollout undo deploy/shop-api --to-revision=2

If new pods never become ready, the rollout stalls. Because maxUnavailable is 0 here, the old pods keep serving, so users see no outage. After progressDeadlineSeconds (default 600 s) the Deployment is marked as failed (ProgressDeadlineExceeded) and kubectl rollout status returns an error, which is how CI notices. It does not roll back by itself. revisionHistoryLimit (default 10) is how many old ReplicaSets are kept for undo.

Other rollout facts: use an exact image tag (or digest) and never :latest, otherwise two pods can run different code under the same name. Changing a ConfigMap does not restart pods that read it as environment variables; run kubectl rollout restart deploy/shop-api or change an annotation. For pods that must survive node maintenance, add a PodDisruptionBudget (a rule such as "at least 2 pods must stay up during voluntary evictions").

Debugging a pod that does not work

6. Helm basics

Helm is a package manager for Kubernetes. A chart is a folder of YAML templates plus a values.yaml file with default settings. A release is one installed copy of a chart in a cluster, with its own history. The template fills the blanks from values:

# values.yamlimage:  repository: registry.example.com/shop-api  tag: "1.4.2"replicaCount: 3

# templates/deployment.yaml (fragment)spec:  replicas: {{ .Values.replicaCount }}  template:    spec:      containers:        - name: api          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

helm template shop ./chart -f values-prod.yaml     # render only; review the YAMLhelm upgrade --install shop ./chart -f values-prod.yamlhelm history shophelm rollback shop 3                               # go back to revision 3

The values-per-environment pattern is the main reason teams use it: one chart, a values-dev.yaml and a values-prod.yaml. A related tool, Kustomize, patches plain YAML with overlays instead of templates; it is built into kubectl (kubectl apply -k). Pick Helm when you install third-party software or need a reusable, versioned package. Pick Kustomize when you own the YAML and only need small per-environment changes.

Gotchas: Helm only knows what it installed, so edits made by hand with kubectl edit get overwritten by the next upgrade. helm upgrade --atomic rolls back on failure in Helm 3; in Helm 4 the flag is named --rollback-on-failure and --atomic is marked deprecated (I checked the Helm source). Do not hide secrets in values.yaml in Git.

7. Serverless vs containers vs PaaS: how to choose

A cold start is the extra delay when the platform must start a new instance for the first request. See Lesson 26 for how to reduce it.

My rule: start with the least infrastructure that meets the need, and move down the table only when something forces you.

• A Next.js app with normal traffic and a small team: PaaS. Your time is more expensive than the bill.
• Spiky or event-driven work (process an upload, send an email, run a nightly job): Lambda, with SQS in front.
• A steady API, workers, WebSockets, long requests, or a need for a custom runtime: containers on ECS with Fargate.
• Many services, many teams, a need for one portable platform, custom controllers, or a skilled platform team: Kubernetes. Without that team, Kubernetes is mostly extra work (upgrades every few months, add-ons, networking, security).

8. Core AWS services for a full-stack developer

You do not need the whole catalogue. This is the short list and what each one is for. Hands-on steps for most are in the DevOps series.

Notes that interviewers like:

• Pre-signed URL. A pre-signed URL is a temporary link that lets someone upload to or download from one S3 object without AWS keys. The browser sends the file straight to S3, so your server does not carry the bytes.
• SQS and Lambda. An SQS queue can trigger a Lambda function with a batch of messages. A dead-letter queue (DLQ) is a second queue where messages go after too many failed tries, so one bad message does not block the rest. Return partial batch failures so only the failed messages are retried. Set the queue's visibility timeout longer than the function timeout (AWS advises a multiple of it). The queue concepts are in Queues and Webhooks, Lesson 19.
• Lambda and databases. Each Lambda instance opens its own database connection, so a traffic spike can open hundreds. Use a connection pooler (RDS Proxy or the database's own pooler) or a database that accepts many connections.
• S3 is not a file system. It stores whole objects under keys; there are no real folders and no partial edits.

A Lambda handler for SQS with partial batch failures. I compiled this with TypeScript in strict mode against @types/aws-lambda:

import { SQSEvent, SQSBatchResponse } from "aws-lambda";export const handler = async (event: SQSEvent): Promise<SQSBatchResponse> => {  const failures: { itemIdentifier: string }[] = [];  for (const record of event.Records) {    try {      await sendEmail(JSON.parse(record.body));    } catch {      failures.push({ itemIdentifier: record.messageId });    }  }  return { batchItemFailures: failures };};declare function sendEmail(job: unknown): Promise<void>;

(For the function to use this, the SQS event source mapping must have partial batch responses turned on.)

IAM least privilege

The two default rules from Lesson 5: everything is denied unless a policy allows it, and an explicit Deny always wins. Least privilege means the policy names the exact actions, the exact resources, and where possible a condition.

A policy for the API's task role. It can read and write one bucket's objects and send to one queue, nothing else (the JSON parses; the account number is made up):

{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "UploadsReadWrite",      "Effect": "Allow",      "Action": ["s3:GetObject", "s3:PutObject"],      "Resource": "arn:aws:s3:::acme-shop-prod-uploads/*"    },    {      "Sid": "SendEmailJobs",      "Effect": "Allow",      "Action": "sqs:SendMessage",      "Resource": "arn:aws:sqs:eu-west-1:123456789012:shop-prod-emails"    }  ]}

Two kinds of policy matter for every role. The trust policy says who may become the role (for example ecs-tasks.amazonaws.com). The permission policy says what the role may do. In ECS, the task execution role lets ECS itself pull the image and read secrets at start, and the task role is what your code uses at run time. Mixing them up is a common mistake.

9. Terraform basics

Terraform is a tool that reads .tf files describing infrastructure and calls cloud APIs to make the real world match. The language is HCL. OpenTofu is a community fork of Terraform with a very similar workflow; the ideas here apply to both. Step-by-step setup is in DevOps, Lesson 15.

Words:

• A provider is a plugin that talks to one platform (AWS, Cloudflare, Kubernetes).
• A resource is one thing to create, such as a bucket.
• State is a file where Terraform records what it created and the real IDs. It is how Terraform knows that aws_s3_bucket.uploads in code is bucket abc in AWS.
• A module is a folder of Terraform files you call like a function, with inputs (variables) and outputs.
• Drift is when the real infrastructure no longer matches the code or the state, usually because someone changed it by hand in the console.

The loop

terraform init      # download providers, set up the backendterraform plan      # show what WOULD change (changes nothing)terraform apply     # make the change (asks to confirm)

plan compares three things: your code, the state, and (after a refresh) the real world. Read the plan like a code review. + is create, ~ is update in place, -/+ is destroy and recreate, which on a database means data loss. Save a plan with -out and apply exactly that file in CI, so what was reviewed is what runs.

I ran a small module with a validation rule. Here is the part that proves the guard works:

variable "instance_count" {  type    = number  default = 2  validation {    condition     = var.instance_count >= 1 && var.instance_count <= 20    error_message = "instance_count must be between 1 and 20."  }}

Setting instance_count = 50 made terraform plan stop with instance_count must be between 1 and 20 before anything was created.

State: the part that bites

State can contain secrets in plain text (database passwords, for example). Treat it like a secret file. In a team:

• Keep state remote, for example in an S3 bucket with versioning and encryption, not on one laptop and not in Git.
• Use locking, so two people (or two pipelines) cannot apply at the same time. The S3 backend supports a lock file with use_lockfile = true in recent Terraform versions (my Terraform 1.16 accepted it); older setups used a DynamoDB table for the lock.
• Split state by environment and by layer (network, data, app). One giant state is slow and risky.

terraform {  backend "s3" {    bucket       = "acme-tf-state"    key          = "shop/prod/terraform.tfstate"    region       = "eu-west-1"    encrypt      = true    use_lockfile = true  }}

Drift

Drift is found by terraform plan (it refreshes first). If someone widened a security group by hand, the plan shows the change needed to put it back. terraform plan -refresh-only shows only the difference between state and the real world, so you can decide whether to accept it. You can also bring existing hand-made resources under Terraform with an import block. The fix for drift is cultural as much as technical: remove console write access for most people and let the pipeline apply.

Modules, and two gotchas I tested

A module takes inputs and returns outputs, so dev and prod call the same code with different values. Keep modules small, version them, and do not make them wrap every provider argument.

count versus for_each. With count, resources are tracked by position. I created three items web, api, worker, then removed web from the list. Plan result: with count, two items were updated in place and the last was destroyed. With for_each, tracked by key, only web was destroyed. For AWS resources, that difference can be a recreated database or load balancer. Prefer for_each with stable keys.

Renaming. If you rename a resource in code, Terraform sees "destroy the old, create the new". Add a moved block instead:

moved {  from = terraform_data.by_key  to   = terraform_data.renamed}

The plan then said each item "has moved" and ended with 0 to add, 0 to change, 0 to destroy.

Also know lifecycle { prevent_destroy = true } (refuse to destroy this, good for databases) and terraform destroy (removes everything in that state, so be careful which directory you are in).

A short AWS example

resource "aws_s3_bucket" "uploads" {  bucket = "acme-shop-${var.env}-uploads"}resource "aws_s3_bucket_public_access_block" "uploads" {  bucket                  = aws_s3_bucket.uploads.id  block_public_acls       = true  block_public_policy     = true  ignore_public_acls      = true  restrict_public_buckets = true}resource "aws_sqs_queue" "emails_dlq" {  name                      = "shop-${var.env}-emails-dlq"  message_retention_seconds = 1209600}resource "aws_sqs_queue" "emails" {  name                       = "shop-${var.env}-emails"  visibility_timeout_seconds = 60  redrive_policy = jsonencode({    deadLetterTargetArn = aws_sqs_queue.emails_dlq.arn    maxReceiveCount     = 5  })}data "aws_iam_policy_document" "api_task" {  statement {    actions   = ["s3:GetObject", "s3:PutObject"]    resources = ["${aws_s3_bucket.uploads.arn}/*"]  }  statement {    actions   = ["sqs:SendMessage"]    resources = [aws_sqs_queue.emails.arn]  }}

Notice how the IAM policy is built from the resources' own ARNs. Least privilege is easier in code: the policy cannot point at the wrong bucket by typo.

10. Secrets

A secret is any value that gives access: passwords, API keys, tokens, private keys. Rules:

1. Never in Git, never in an image, never in a NEXT_PUBLIC_* variable (see Lesson 26).
2. Prefer roles over keys: a task with an IAM role gets short-lived credentials from AWS, and nothing needs to be stored.
3. When a value must exist, keep it in a secret store and give the app read access to just that value.

Other points: secrets in environment variables can leak through crash dumps and debug endpoints, so some teams mount them as files instead. Rotation matters: if a key leaks, you must be able to change it in minutes, so test rotation before you need it. And remember that Terraform state may hold secret values, so lock it down.

11. Cost awareness

Cloud bills punish things you forget. The basics are in DevOps, Lesson 19; here is the interview version.

• Tag every resource (env, team, service) so the bill can be split. Tags in Terraform make this automatic (default_tags on the provider).
• Set a budget alarm the first day. The cheapest outage is the one a bill alert catches.
• Biggest hidden costs: NAT gateway hours and data, data transfer out to the internet, idle load balancers and databases, unattached volumes, and logs kept forever. See Lesson 6 for NAT.
• Right-size using real CPU and memory graphs, not guesses. Requests that are far above real use waste money in Kubernetes because you pay for the reserved nodes.
• Shut down what you do not use: dev and staging at night, preview environments after a pull request closes.
• Commit later, not first: Savings Plans or Reserved Instances only after usage is stable.
• Pick the model that matches the load. Lambda is cheap for rare work but can cost more than a container under constant high load. Kubernetes has a fixed cost (control plane, add-ons, the people) that only pays off at scale.

A good answer also names the human cost: an engineer's day costs more than most small savings, so do not spend a week to save twenty dollars.

12. Multi-environment strategy

Typical set: dev (fast, cheap, may break), staging (like production, for the last checks), production. Some teams add preview environments per pull request.

What I do:

• Build once, promote the same image. The image from CI moves from dev to staging to prod. Only the configuration changes. Rebuilding for each environment means you did not test what you ship.
• One codebase for infrastructure, many inputs. The same Terraform module with dev.tfvars and prod.tfvars, and a separate state per environment. Separate folders or separate pipelines are easier to review than Terraform workspaces, which hide which environment you are in.
• Separate AWS accounts for prod and non-prod (grouped under AWS Organizations). An account is the strongest wall: a mistake or a leaked key in dev cannot touch prod data. It also makes the bill and the permissions cleaner.
• Configuration through environment variables or a values file, never if (env === "prod") scattered in code.
• Keep staging close to prod in shape (same engine version, same migrations), but smaller in size. Do not copy real customer data into staging without masking it.
• Promotion with approval: automatic to dev, a check to staging, a human click (or a gate on health metrics) to prod.
• GitOps (an approach where Git is the source of truth for what runs, and a tool inside the cluster such as Argo CD or Flux applies it) gives you an audit trail and a rollback by git revert. It is optional; many teams run helm upgrade from CI and are fine.

Common mistakes

• Using :latest image tags, so nobody knows what is running.
• No readiness probe, so rolling updates send traffic to pods that are not ready.
• A database check in the liveness probe, causing restart storms.
• No resource requests, then wondering why pods go Pending or why the HPA does nothing.
• Memory limit below real use, giving OOMKilled loops.
• Treating a base64 Secret as safe.
• Action: * in IAM, and long-lived access keys in code.
• Using count for things that have an identity.
• Editing infrastructure in the console and leaving drift.
• Choosing Kubernetes for a team of three because it looks good on a CV.

Interview questions

Key takeaways

• A container is an isolated process sharing the host kernel; a VM is a whole machine. Use containers for packing and fast deploys, and know the isolation trade-off.
• Deployment keeps pods alive and updates them, Service gives a stable address by labels, Ingress (or the newer Gateway API) routes HTTP, HPA changes replica count.
• Readiness removes a pod from traffic, liveness restarts it, startup protects slow boots. Never check the database in liveness.
• Set requests always. CPU over the limit is throttled; memory over the limit is OOMKilled.
• Rolling updates depend on accurate readiness probes. maxSurge and maxUnavailable default to 25%. rollout undo restores code, not data.
• Helm templates and versions releases; Kustomize patches plain YAML.
• Choose the simplest platform first: PaaS, Lambda, ECS/Fargate, and Kubernetes last.
• Least privilege means exact actions, exact resources, roles instead of keys.
• Terraform: remote state with locking, read every plan, prefer for_each to count, use moved for renames, watch for drift.
• A Kubernetes Secret is only base64 by default. Use encryption at rest, RBAC or an external secret store.
• Tag everything, set budgets, and watch NAT, data transfer and forgotten resources.
• Environments: build once, promote the same image, separate state and separate accounts.

What's next

To build these pieces by hand, follow the DevOps series: IAM, VPC, Docker, Auto Scaling, Terraform and Cost. For the release side, return to Deployment, CI/CD and Monitoring. Then practise Q6 and Q18 out loud, using a real project you have worked on.