DevOps Interviews: How To Prepare for Troubleshooting, Scripting, and Infrastructure

DevOps interview preparation can expand into an endless list of tools. Start with the role's responsibilities, then practice the work you may need to demonstrate: trace a failed request, inspect a deployment, write a reliable script, and explain an infrastructure change.

The examples below give you a complete troubleshooting walkthrough and a runnable Python exercise, with checks you can use to assess your answers.

Start Here: Prepare for the Actual Round

1. Confirm the format: ask about live scripting, terminals, troubleshooting, design, time limits, and permitted documentation or AI tools.
2. Choose the emphasis: map the job description to delivery pipelines, cloud infrastructure, or reliability. Review the technologies you claim on your resume.
3. Rehearse evidence: prepare one incident you handled, one implementation you understand, and the two exercises below.

If the interview is tomorrow, finish these steps before adding more tools to your study list. A DevOps title does not guarantee a particular format or exclude coding questions.

Match Preparation to the Role

• Delivery pipelines: explain how a commit becomes a tested artifact, how configuration and credentials reach each environment, and how you verify or reverse a release.
• Cloud and platform work: trace a request through DNS, networking, identity, and the application. Explain how infrastructure changes are reviewed and how environments stay separate.
• Reliability work: distinguish customer impact, immediate recovery, and root-cause investigation. Use evidence to choose between competing explanations.

For Terraform, know which backend holds the state and whether it supports locking. Investigate an existing operation before considering an unlock; disabling a lock to bypass an error can create concurrent writers. See HashiCorp's state-locking documentation.

For permissions questions, name the identity, resource, and required operation. With Kubernetes Secrets, distinguish base64 encoding from encryption and verify access controls and storage protection. The official Secrets guide explains those boundaries. Keep private credentials out of shared terminals and examples.

Worked Troubleshooting Example: A Deployment Returns 503

Fictional prompt: “The new deployment is running, but users receive HTTP 503 responses. What do you check?” Start by establishing which requests fail, where the response originates, when it started, and what changed. A status code alone does not identify the cause.

For this exercise, assume the interviewer identifies the gateway's lack of available backends. The following output is illustrative, not a recording from a real cluster. Use only the provided practice environment; first confirm the selected context:

kubectl config current-context
kubectl -n interview-lab get service inventory-api -o yaml

The relevant Service fields are:

spec:
  selector:
    app: inventory-api
  ports:
    - port: 80
      targetPort: 8080

Inspect the Pods and the Service's EndpointSlices:

kubectl -n interview-lab get pods --show-labels
kubectl -n interview-lab get endpointslices -l kubernetes.io/service-name=inventory-api

Illustrative results, shown in command order:

NAME                    READY   STATUS    RESTARTS   AGE   LABELS
inventory-api-7c9f-x2m   1/1     Running   0          2m    app=inventory-api-v2

NAME                  ADDRESSTYPE   PORTS    ENDPOINTS   AGE
inventory-api-k8m4q    IPv4          <unset>  <none>      2m

The Service requests app=inventory-api; the new Pod has app=inventory-api-v2. That explains the missing selection in this example. Kubernetes' Service debugging guide documents checking selectors, EndpointSlices, and port mappings.

A strong answer: “The new label does not match the Service selector. I'll confirm this is the intended workload, inspect the configuration change, and propose restoring the intended match through the deployment process. Afterward I'll check backend selection and a representative request through the original failing path.”

Follow the evidence through this decision tree:

No selected endpoints?
  Compare Service selector with intended Pod labels.
  Mismatch found? Correct the intended configuration and recheck.
  Labels match? Check namespace, workload existence, and controller evidence.

Endpoints exist but are not ready?
  Inspect readiness failures, application startup, and dependencies.

Intended ready endpoints exist but requests still fail?
  Check targetPort, application listener, network policy, and gateway path.

Change applied?
  Verify the original request and user-facing errors before declaring recovery.

Avoid restarting everything or changing the selector to an unrelated workload. If recovery is urgent, discuss whether a known-good rollback is safe. For the broader incident conversation, use the production debugging interview guide.

Worked Scripting Exercise: Summarize Service Failures

Prompt: Read one JSON object per line from a UTF-8 file. Count records with integer status codes from 500 through 599, grouped by service, and print the service names in a deterministic order.

Agreed contract: blank lines are ignored; each other line must parse as an object with an integer status and a nonblank string service. Boolean and string statuses are invalid. Preserve service names exactly. A parse or validation failure stops the run with its line number, without printing the record or a partial summary.

Save this complete Python 3 solution as summarize_errors.py:

import argparse
import json
import sys
from collections import Counter


def summarize(lines):
    counts = Counter()
    for number, line in enumerate(lines, start=1):
        if not line.strip():
            continue
        try:
            record = json.loads(line)
        except ValueError:
            raise ValueError(f"line {number}: invalid JSON") from None
        if not isinstance(record, dict):
            raise ValueError(f"line {number}: expected an object")
        status = record.get("status")
        service = record.get("service")
        if type(status) is not int:
            raise ValueError(f"line {number}: status must be an integer")
        if not isinstance(service, str) or not service.strip():
            raise ValueError(f"line {number}: service must be nonblank text")
        if 500 <= status < 600:
            counts[service] += 1
    return dict(sorted(counts.items()))


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("path")
    args = parser.parse_args()
    try:
        with open(args.path, encoding="utf-8") as source:
            result = summarize(source)
    except (OSError, UnicodeError, ValueError) as error:
        print(f"error: {error}", file=sys.stderr)
        return 2
    print(json.dumps(result, sort_keys=True))
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

The code uses Python's standard JSON module. Validation is separate from parsing: valid JSON can still contain the wrong field types. The exact-type check rejects booleans as statuses.

Create sample.jsonl with:

{"service":"inventory","status":503}
{"service":"billing","status":500}
{"service":"inventory","status":599}
{"service":"inventory","status":200}

Run python3 summarize_errors.py sample.jsonl. Expected standard output and exit status:

{"billing": 1, "inventory": 2}

The exit status is 0. If you append {"service":"billing","status":"503"} as line 5, standard output must be empty, the exit status must be 2, and standard error must say:

error: line 5: status must be an integer

Check these cases before considering your answer finished:

• Empty or blank-only input returns {}.
• 499 and 600 are excluded; 500 and 599 are counted.
• Repeated failures accumulate; reordering input preserves the output.
• A boolean, string, null, or missing status fails validation.
• A missing, nonstring, or blank service fails validation.
• Malformed JSON or a nonobject value fails with the correct physical line number, including preceding blank lines.
• A failure after valid records emits no partial summary.

Explain the tradeoff: the script processes the file incrementally, retains counts by distinct service, and sorts those names at the end. Memory grows with the distinct service names and largest input record, rather than the whole file. If the interviewer requests partial success, change the contract explicitly and report rejected records separately.

Common mistakes: accepting true as an integer, counting 600 as a 5xx error, printing results before validation finishes, or silently skipping bad records. Correct these behaviors before optimizing the loop.

Turn Practice Into an Interview Answer

For each exercise, state your assumptions, explain the next observation you need, and finish with verification. If you forget a command flag, describe its purpose and ask whether documentation is permitted.

For a real incident story, prepare the symptom, two plausible explanations, the evidence that narrowed them, your personal action, and how recovery was checked. Separate support ownership from deployment ownership. If the platform team shipped the fix, describe the reproduction and verification you performed rather than claiming the deployment.

Use these existing collections for focused follow-ups. They cover adjacent skills, not a complete DevOps syllabus; some questions or answers require a subscription.

• For an AWS-focused role: choose one permissions question and one retry or failure-handling question from AWS Lambda. Explain the identity, allowed action, failure path, and a check that would confirm your answer.
• For pipeline responsibilities: choose a deployment or data-quality scenario from Data Engineering Basics. Name the failed stage, recovery approach, and how you prevent duplicate or incomplete output.
• For operational stories: select a failure or disagreement prompt from behavioral and leadership questions. Give a two-minute answer, then defend one decision and one lesson.

Build a Short Preparation Sequence

1. Session one: confirm the format and map job responsibilities to your evidence.
2. Session two: trace a request and work through the deployment example, including an alternative cause.
3. Session three: solve the scripting task before reading the solution; run the boundary and failure cases.
4. Session four: review a small infrastructure change: environment, state, permissions, expected effect, and recovery.
5. Session five: rehearse two work stories and a timed mock round. Repeat the weakest part.

At the interview, ask how onboarding, code review, incident response, and on-call coverage work. A recent example of a recurring problem the team permanently fixed will tell you more about its operating habits than a list of tools.

Public Discussions Behind This Guide

Recent questions include a September 4, 2026 request for practical interview guidance, a September 7 question about concepts versus troubleshooting, and a September discussion about demonstrating relevant experience when entering DevOps. These are individual accounts, not employer-wide rules or search-demand estimates. The exercises above are original; official documentation supports the tool behavior.