DevOps mock interview practice

Published by MockReps.

Practise explaining how you deliver changes, diagnose failures and manage operational risk. A useful DevOps answer connects a decision to evidence: what you know, what you would check next, what could go wrong and how you would confirm recovery.

This guide contains original fictional exercises, not employer questions, customer results or a production runbook. You can read and rehearse them without an account. Confirm the interview format and expected platform with your recruiter; a cloud design discussion and a hands-on troubleshooting task need different preparation.

Choose the task you need to rehearse

Start with the responsibilities in the job description. For a delivery-focused role, practise pipeline design and release decisions. For a platform role, explain Kubernetes behaviour, access boundaries and service ownership. For an operations-heavy role, prioritise incident diagnosis, communication and recovery. You do not need to mention every tool you know in one answer.

For each exercise, state the environment and your authority. Explain how you would observe the system before changing it. A technically plausible command is not a complete answer if you cannot describe its effect or how to reverse it.

Five questions with useful follow-ups

1. CI/CD: a release passes tests but fails after promotion

Question: A service works in staging, but errors rise in production after deployment. How would you investigate differences and decide whether to continue?

A strong answer separates the artefact, runtime configuration, data shape and dependency behaviour. Identify the released version, compare relevant configuration without exposing secrets and connect the error increase to affected requests. Explain a stop condition and how the pipeline prevents an unreviewed artefact from replacing the tested one.

Follow-up: What evidence would make you investigate a downstream outage rather than revert the release?

2. Kubernetes: a new Pod never becomes ready

Question: A rollout stalls while existing replicas continue serving traffic. What would you inspect first?

Distinguish scheduling, image retrieval, container startup and readiness. Use Pod state, events and the relevant container logs to narrow the problem. Explain why a running container may still be unable to serve a request. Do not treat disabling a readiness check as proof that the service is healthy.

Follow-up: How would your investigation change if the container repeatedly restarted rather than remaining running but unready?

3. AWS: a private service loses dependency access

Question: An application in a private subnet can no longer reach a required service after a configuration change. How would you isolate the cause?

State the connection path: name resolution, route, network controls, destination listener and application authentication. Distinguish a timeout, connection refusal and permission error. Check the relevant change and seek the narrowest correction. Making the workload public or granting broad permissions would change the security boundary without establishing the cause.

Follow-up: What would you record to prove the required access works while unrelated access remains restricted?

4. Incidents and observability: latency rises but errors stay flat

Question: Request latency increases while the error rate looks normal. What do you investigate, and what do you tell the incident lead?

Ask which requests and users are affected, whether traffic changed and whether resources or dependencies are saturated. Compare latency distributions and timeouts instead of relying only on an average. Communicate the observed impact, uncertainty, current action and next update. A dashboard screenshot alone is not an explanation.

Follow-up: How would you avoid declaring recovery while queued work continues to delay users?

5. Infrastructure: a routine plan includes replacement

Question: A Terraform plan proposes replacing a stateful resource during a small change. How do you review it?

Explain why the resource is being replaced before approving anything. Identify data, dependency and downtime consequences, inspect the relevant configuration and provider behaviour, then evaluate a migration or a narrower change. A successful plan is not evidence that recovery has been tested.

Follow-up: What restoration evidence and owner decision would you require before a destructive change?

Worked response: errors during a Kubernetes rollout

Scenario: A stateless HTTP API has six replicas. During a new Deployment rollout, the error rate rises. Some new Pods are ready and others are not. Assume the team can inspect deployment history and telemetry, and can stop further promotion. No database compatibility information has been supplied.

A weak opening: “I would restart the Pods, then roll back if that did not work.” This introduces more change before identifying the affected version, user impact or rollback constraints.

A more useful response: “I would establish the affected requests and when the errors began, then prevent further promotion while the team assesses impact. I would compare errors and latency by old and new version, inspect rollout status and readiness failures, and check recent configuration changes. I would keep the known-good capacity available where possible rather than restarting all replicas.”

“If evidence points to the new version, I would check that the prior version remains compatible with current data and configuration before proposing a rollback. A Deployment revision does not reverse an external database migration. If rollback is unsafe, I would discuss the smallest mitigation with the service owner, including its user impact and remaining risk.”

“After the chosen action, I would verify user-facing errors and latency, serving capacity and any accumulated backlog across a representative observation period. I would tell the incident lead what recovered and what is still uncertain. Restored traffic would be a recovery observation; I would investigate the cause separately.”

Explain the trade-off, not just the action

Stopping promotion limits further exposure but can leave a mixed-version service. Rolling back may restore a known application version but cannot guarantee compatibility with changed dependencies. Adding replicas may help a capacity problem, but it can increase pressure on an already overloaded database. Say which evidence supports your chosen action and what would make you change course.

Challenge this answer with two changes: the new version has applied a non-reversible schema change, or both old and new versions show the same errors. Neither condition justifies repeating a rehearsed rollback answer. Ask for the missing evidence and explain a different decision path.

A short rehearsal and self-review

1. Frame: Pick one scenario and spend two minutes declaring assumptions, impact and authority.
2. Explain: Give a five-minute answer linking each investigation step to the question it resolves.
3. Challenge: Change one constraint and explain how your decision changes.
4. Review: Mark evidence, risk, verification and communication as clear, partial or missing. Repeat the least clear part.

For a real incident story, use STAR to distinguish your actions and outcome. Remove confidential details and avoid invented recovery metrics. For a broader technical round, use the 35-minute engineering routine.

Use MockReps for the next attempt

Choose a DevOps role and experience level when setting up an interview. Add an optional job description to focus on the advertised responsibilities, then select text or voice and the skills you want to practise. A CV can add career context; it is not required. Use Story Bank for genuine operational examples and review feedback against the answer you actually gave.

These public exercises are free. Personalised interviews and reports use credits: a job-description analysis, session and report cost 1, 5 and 2 credits respectively. See one-off packs and current credit costs before buying. MockReps does not run a Kubernetes cluster, execute infrastructure changes or certify operational competence. AI feedback can be wrong and is not a validated hiring decision.

Technical references for checking your reasoning

Use the official Kubernetes Deployment documentation to check rollout and revision behaviour, the running-Pod debugging guide to distinguish diagnostic evidence, and Google's monitoring chapter for latency, traffic, errors and saturation. These references support the technical discussion; they do not endorse MockReps.