DevOps Engineer Test: Example Questions & Assessment Template
Why generic infrastructure questions fail
Most DevOps assessments ask textbook questions: "What is a container?" or "Define CICD." These questions measure trivia recall, not whether someone can design a resilient system under pressure or debug a production incident at 2 AM.
A real DevOps test should measure judgment, not facts. It should test whether someone understands trade-offs between automation and operability, knows when to scale horizontally versus vertically, and can reason about failure modes.
Here's what a signal-bearing DevOps assessment looks like.
Category 1: Infrastructure design under constraints
Scenario-based question:
"You have an application running on a single EC2 instance. It handles 1000 RPS, uses 70% CPU, and has 4GB of RAM with 60% utilization. Your SLA is 99.9% uptime. The application is stateless. What changes would you make, and in what order? What trade-offs are you making?"
This tests:
- Understanding of scalability vs. redundancy (both needed for 99.9%)
- Cost awareness (whether they jump to expensive solutions)
- Sequencing knowledge (failover before optimization)
- Trade-off articulation (EBS gp3 vs. local NVMe, for instance)
A candidate who says "add a load balancer and spin up two more instances in another AZ" is thinking clearly. A candidate who says "switch to Kubernetes" might be pattern-matching without understanding the constraint (high availability, not multi-tenancy).
Category 2: Incident response and troubleshooting
Scenario-based question:
"Your CI/CD pipeline is failing on random builds. The error is 'connection timeout to Docker registry.' The issue happens roughly once per 20 builds. What do you check first, and what instrumentation would you add?"
This tests:
- Systematic debugging methodology
- Understanding of network isolation and authentication
- Observability thinking (what would they instrument if they had to prevent this next time?)
- Prioritization (they don't need perfect root-cause analysis, they need the build system stable now)
A candidate who starts with "check the Docker registry status page" is less thoughtful than one who says "first: is it retry-able and did we add rate limiting? second: check if the registry token is expiring mid-build or if our network config changed."
Category 3: Code and configuration review
Live exercise:
Provide a 30-line Terraform snippet or a Docker Compose config with intentional issues. Ask the candidate to identify problems and explain the fix.
Example Terraform issues:
- Security group allowing 0.0.0.0/0 to a database port
- Missing backup retention policy on RDS
- Hard-coded database password in variables
- No tags for cost allocation
Example Compose issues:
- Privileged containers without justification
- Missing health checks
- Logging to stdout without limits (disk fill risk)
- No resource constraints (CPU/memory)
This tests whether they've shipped production systems and learned what breaks. Textbook engineers don't catch these; experienced operators do.
Category 4: Architecture and tool selection
Conversation:
"We need to coordinate jobs across 50 microservices. Each job takes 2–30 minutes. We want strong ordering guarantees. What would you use? Walk me through the trade-offs."
Valid answers:
- Temporal (workflow orchestration, strong ordering, complex to operate)
- Step Functions (managed, limited to AWS, less flexible)
- Pub/Sub + consumer app (low coupling, weak ordering, operationally simpler)
- Kubernetes Jobs + custom controller (flexible, more operational overhead)
The interviewer should push back: "Step Functions sounds simpler." The candidate should defend: "Until you need to retry a job that already partially succeeded, or until you have a 2-minute job running on a 10-minute SLA, then you need the workflow state machine. But that's true cost — the complexity tradeoff."
This tests judgment and experience, not knowledge.
Category 5: Observability and monitoring
Short scenario:
"You've deployed a change and your error rate went from 0.1% to 0.5%. Latency p99 is the same. The change touched logging and tracing, not request handling. Where do you look?"
A weak answer: "Check the logs." A strong answer: "First, I'd check if the tracing instrumentation or logging level changed — that could increase error visibility without increasing actual errors. Then I'd look at log cardinality. Then I'd check if we're logging new error cases that weren't being caught before."
This separates operators from engineers who've only read the Kubernetes docs.
How to structure the assessment
- 30-minute take-home: Infrastructure design scenario + configuration review. Ask them to explain their decisions.
- 30-minute synchronous interview: Live troubleshooting conversation + architecture discussion. Record their reasoning.
- Pair the assessment with keystroke integrity signals. DevOps candidates copying entire solutions from ChatGPT or StackOverflow will show unusual edit patterns. ClarityHire captures this by default.
The honest counter-point
Not every role needs this depth. Junior DevOps or SRE roles benefit from simpler filtering: can they read Terraform, can they deploy an app, can they understand a network diagram? For senior+ hiring, this rubric applies. For mid-level, dial down the complexity but keep the scenario-based structure.
Next steps
Ready to assess your DevOps candidates with real tests? Check out our DevOps and Cloud Engineering assessment hub for templates and guidance on how to assess DevOps engineers' skills.