Hiring managers and recruiters can use this DevOps skills test guide to check whether a candidate can keep systems running, not just list tools on a resume. It covers what to measure at each level, 10 original sample questions with model answers, how test formats compare, and a scoring rubric. The questions focus on reasoning that carries across clouds and tool choices, so they work whatever your stack is.
What a DevOps skills test should measure
Most DevOps work is diagnosis and prevention, so test both. A candidate who fixes the symptom but never asks how to stop it recurring will get paged for the same problem again.
Sample DevOps test questions
These cover Linux, CI/CD, networking, reliability, cost and access. They don't repeat the container and Kubernetes topics in our DevOps interview questions, so you can use both.
1. Junior, debugging: df says the disk is 100% full, but du on every folder adds up to far less. What's happening?
What good looks like: a file was deleted while a process still has it open, often a log file. The space isn't freed until the process closes the file. Find it with lsof +L1 or by looking for "(deleted)" in lsof output, then restart or signal the process to reopen its logs. Strong candidates add log rotation that tells the process to reopen files, so it doesn't happen again.
2. Junior, concept: a CI step runs ./test.sh | tee results.log. Tests fail, but the step passes. Why?
What good looks like: a pipeline's exit status is the status of its last command, here tee, which succeeded. Adding set -o pipefail makes the pipeline fail if any command in it fails. Good candidates also mention set -e and set -u, and checking exit codes in scripts generally.
3. Junior, reasoning: a script works when you run it by hand but fails as a scheduled cron job. What do you check?
What good looks like: cron runs with a minimal environment: a short PATH, no shell profile, a different working directory and often a different user. Use full paths to commands and files, set the variables the script needs inside it, and send output to a log so failures are visible. Checking the system mail or logs for cron output is a good sign.
4. Mid, scenario: your site went down because a TLS certificate expired. How do you make sure it never happens again?
What good looks like: automate renewal (for example with an ACME client), keep an inventory of every certificate and where it's deployed, and monitor expiry dates from outside, alerting weeks ahead so there's time to act. Strong candidates point out that renewal can succeed while the running service still serves the old certificate, so the check should hit the live endpoint, not the file on disk.
5. Mid, scenario: flaky tests fail one build in five, and engineers now rerun until green. What do you do?
What good looks like: measure which tests flake and how often, quarantine the worst ones so they don't block merges, and give each an owner and a deadline. Fix the usual causes: shared state between tests, dependence on time or ordering, and real network calls. Automatic retries alone hide the problem. A strong answer notes that a test suite people don't trust stops catching real bugs.
6. Mid, concept: two builds from the same commit produce different artifacts. Why does that matter, and how do you fix it?
What good looks like: if builds aren't repeatable, what you tested isn't exactly what you ship. Causes include floating base image tags, unpinned dependencies and build-time downloads. Pin base images by digest, install from lockfiles, and build once, then promote that same artifact through staging to production instead of rebuilding for each environment.
7. Mid, reasoning: you moved a service to a new IP and updated DNS an hour ago, but some users still reach the old server. Why?
What good looks like: resolvers and clients cache records for the record's TTL, and some hold them longer. If the TTL was a day, some users can see the old address for a day. The fix for next time is to lower the TTL well before the move, at least one old TTL ahead, and keep the old server running or forwarding until traffic drains.
8. Senior, scenario: the team says backups run every night. How do you know you can restore?
What good looks like: you don't until you've restored. Schedule regular restore tests into a separate environment, time them, and check the data. Agree on recovery point and recovery time objectives with the business, monitor backup jobs for failure and size changes, and keep copies in a separate account or with immutability so a compromised admin account can't delete them.
9. Senior, investigation: the cloud bill rose 40% this month with no new product launches. Where do you look?
What good looks like: break the bill down by service, account and tag to find what grew. Common causes are data transfer and NAT charges, autoscaling that scaled up and never came down, forgotten test environments, unattached disks and old snapshots, and a jump in log volume. Then add guardrails: budget alerts, required ownership tags and a regular cost review.
10. Senior, design: every engineer has admin rights in production. Plan a move to least privilege without slowing the team down.
What good looks like: start by logging who uses what, so roles match real work. Move access to single sign-on with role-based groups, make day-to-day roles read-only or scoped, and add time-limited admin access with approval and an audit trail. Keep a tested break-glass path for emergencies. Roll it out team by team, and fix the tasks that need admin by automating them.
Test formats compared
A common setup is an adaptive first round for everyone, then a hands-on lab or work sample for finalists. Set rules for AI assistants before you start; see how to detect AI interview cheating. A work sample test built from a real past incident usually predicts the job better than a generic lab.
Scoring rubric
Running a DevOps test with NTRVSTA
DevOps tools are part of NTRVSTA's exam library. The live AI interviewer, as a video avatar or audio only, adapts difficulty to each answer: a candidate who nails the deleted-file question gets a harder follow-up on backups, while one who stalls gets a simpler prompt or a hint. It follows up on reasoning, so "I'd just restart it" leads to "what would you check first?" For senior roles, the system-design whiteboard lets candidates draw a deployment or access design.
Your team reviews a score breakdown (technical skills, English proficiency and communication), video snippets of key moments and a shareable report before choosing who gets the hands-on round. For hands-on coding tests instead, see our guide to coding assessment tools. Related tests: Node.js, Python and problem-solving.
Questions
How long should a DevOps skills test be?
Keep a first-round screen to 30 to 45 minutes. A hands-on lab for finalists can run 60 to 90 minutes, but only if the environment is ready to go, so setup problems don't eat the candidate's time.
Should a DevOps test target one cloud provider?
Only if the job truly needs deep knowledge of that provider from day one. Most concepts, such as DNS, least privilege, backups and deploy safety, carry across clouds. Testing them in neutral terms widens your pool without lowering the bar.
Should candidates be allowed to use AI tools or documentation?
In a hands-on lab, allowing documentation is realistic, since engineers look things up all the time. In a reasoning screen, ask them to answer on their own. Either way, state the rule up front and apply it to every candidate.
Curious how an adaptive DevOps screen feels for candidates? Take a sample interview yourself, or book a 20-minute demo and we'll walk you through a report.
