What are the best DevOps engineer interview questions?
The strongest DevOps interview questions test pipeline judgment, Kubernetes operational reasoning, IaC design instinct, incident response process, and how the engineer communicates under pressure. Skip trivia questions about tool flags; instead present scenario-based problems with real constraints and evaluate how the candidate structures their diagnostic approach. A 90-minute interview covering CI/CD, Kubernetes, security, and incident response reveals more production maturity than a 3-hour certification-style exam.
Scenario-based questions predict production DevOps performance better than tool knowledge quizzes
Incident response questions reveal on-call judgment that most DevOps interviews never test
Nearshore DevOps engineers from Costa Rica bring production depth at 40-60% lower cost than US hires
DevOps engineering interviews fail in two predictable ways. Either they test which flags the candidate knows for a specific CLI tool. That reveals certification breadth, not production judgment. Or they run so broad that the interviewer never gets past the surface of any single domain. This guide organizes questions into a 90-minute structure. It is designed to reveal pipeline maturity, container depth, and incident response instinct, all in the time you actually have.
All questions are designed for your current environment. Where questions reference a specific tool, adapt them to your stack. The underlying judgment patterns are tool-agnostic. As a result, a strong engineer shows the same diagnostic structure on GitHub Actions as on GitLab CI or Jenkins.
How to Structure the Interview
A 90-minute DevOps interview should cover five domains: CI/CD pipeline depth, container orchestration operations, infrastructure as code design, security and access reasoning, and incident response process. Allocate time before the session begins, not during it. Otherwise you risk spending 45 minutes on pipelines and skipping incident response entirely.
A time allocation that works well looks like this:
- 5 minutes for context and logistics
- 20 minutes for CI/CD questions
- 15 minutes for Kubernetes and containers
- 15 minutes for Terraform or Ansible depth
- 15 minutes for security and secrets
- 15 minutes for incident response scenarios
- 5 minutes for candidate questions and close
Trim CI/CD by 10 minutes if the role is primarily platform engineering. Reallocate that time to Kubernetes and incident response if the engineer will be in the primary on-call rotation.
Send the candidate a technical context document 24 to 48 hours before the interview. It should describe your CI/CD system, container platform, IaC tooling, and the current infrastructure state at a high level. This allows the interview to focus on depth and judgment rather than orientation. For instance, strong candidates will arrive having thought through your context and will ask clarifying questions during the session, while weaker candidates will not have read it.
CI/CD Pipeline Questions
Pipeline questions should test how the candidate designs for failure, not just how the pipeline works when everything succeeds. A DevOps engineer who has only run tutorials will describe a happy path. However, one who has operated pipelines under real production pressure will immediately describe retry logic, rollback triggers, and notification routing.
Question 1: Designing a High-Frequency Deployment Pipeline
CI/CD
Walk me through how you would design a deployment pipeline for a service that deploys 15 times per day to production. What are the gates you would put in place, and how would you handle a failed deployment at 4pm on a Friday?
Strong answer: A strong candidate describes automated test gates covering unit, integration, and contract tests. They also describe a staged rollout using a canary or blue-green strategy, plus automated rollback triggered by error rate or latency thresholds. On top of that, they lay out a specific policy for Friday deploys, such as a freeze after 3pm or a required on-call acknowledgment. They typically mention deployment frequency as a DORA metric and explain what it signals about team maturity. Weak answer: A weak answer describes a basic pipeline without rollback logic, or assumes all deployments succeed and does not address failure recovery.
Question 2: Diagnosing a Build Time Regression
CI/CD
Your GitHub Actions build time has gone from 8 minutes to 24 minutes over the past quarter. The engineering team is complaining. Walk me through how you would diagnose and fix it.
Strong answer: A strong candidate starts with build analytics to identify which steps grew. Common culprits include layer cache invalidation, reduced test parallelism, longer dependency installs, or a larger artifact upload size. Instead of optimizing blindly, they look for the specific change that triggered the growth. They then consider caching strategies for dependencies and Docker layers and evaluate whether restoring test parallelism can recover the lost time. Weak answer: A weak candidate immediately recommends upgrading runner hardware without diagnosing the root cause of the regression.
Question 3: Managing Secrets Across Environments
CI/CD
How do you handle secrets in a CI/CD pipeline that deploys to three environments (dev, staging, production) with different credentials for each?
Strong answer: A strong candidate describes environment-specific secret scoping in the CI/CD platform, such as GitHub Actions environment secrets or GitLab CI protected variables. In addition, they combine this with OIDC-based short-lived credential federation to cloud IAM roles rather than static access keys. They note that secrets should never appear in pipeline logs or artifacts, and that a rotation policy should be documented. Weak answer: A weak candidate stores credentials as plain CI/CD variables without addressing rotation, scope isolation, or log masking.
Kubernetes and Container Questions
Kubernetes questions should distinguish between engineers who have written Helm charts and applied them with kubectl from those who have managed cluster infrastructure under production load. The former group describes what Kubernetes does. In contrast, the latter group describes what breaks and why.
Question 4: Diagnosing a CrashLoopBackOff in Production
Kubernetes
A deployment is in a CrashLoopBackOff state in production. You have no recent deployments or configuration changes in the last 48 hours. Walk me through your next 10 minutes.
Strong answer: A strong candidate first checks pod logs for the crash exit code. Then they review events with kubectl describe to see if there is an OOM kill or liveness probe failure. They check whether the node the pod is scheduled on has resource pressure. They also look at recent node pool activity, such as scaling events or preemption if the cluster uses spot instances. They also check whether a dependent service, like a database or external API, is healthy. Importantly, they post a status update before going deep on any single path. Weak answer: A weak candidate immediately tries to delete and recreate the pod without diagnosing the root cause, or checks only application logs without looking at cluster-level events.
Question 5: Managing Resources Across Namespaces
Kubernetes
How do you manage resource requests and limits across a multi-tenant Kubernetes cluster where different application teams own their own namespaces?
Strong answer: A strong candidate describes LimitRange objects for per-pod defaults, ResourceQuota for namespace-level caps, and a governance process for teams requesting quota increases. They note that requests must be set to enable bin packing, and that limits should be set conservatively to prevent noisy-neighbor memory pressure. They also discuss how to audit namespaces for missing requests using a policy engine such as OPA or Kyverno. Weak answer: A weak candidate describes setting limits on individual pods without a namespace governance model, which does not scale across teams.
Question 6: Controlling Container Image Bloat
Containers
Your container images are growing from 200MB to 1.2GB over 18 months. What are the most likely causes, and how would you bring them back down?
Strong answer: A strong candidate describes using dive or docker history to identify which layers are growing. They name common causes, such as dev dependencies included in production builds, uncompressed ML model files, or accumulated build artifacts not cleaned in the same layer. For solutions, they propose multi-stage builds to separate build dependencies from runtime, Alpine or distroless base images, and a CI gate that fails builds exceeding a size threshold. Weak answer: A weak candidate recommends switching to a smaller base image without auditing which layers are actually contributing to the growth.
Need Pre-Vetted DevOps Engineers?
Kore BPO candidates have already passed technical screens equivalent to these questions. First profiles in 72 hours.
GET STARTED
Infrastructure as Code Questions
IaC questions should assess practical depth with the specific tools your team uses. Questions about Terraform state management and module design reveal production experience. By contrast, questions about what Terraform is and how it works only reveal tutorial experience. Ask about the hard parts, not the concepts.
Question 7: Stabilizing an Inherited Terraform Codebase
Terraform
You have inherited a Terraform codebase with no module structure, 2,000 lines in a single main.tf file, and manual state edits in the git history. What is your approach for the first 90 days?
Strong answer: A strong candidate first stabilizes the existing codebase by ensuring remote state is properly configured and locking is active before touching structure. Next, they audit for drift between state and actual cloud resources. Rather than attempting a full refactor, they introduce module boundaries incrementally, starting with the highest-change resources such as compute and security groups. They document the intended target state before moving a single resource. Weak answer: A weak candidate immediately begins refactoring into modules without stabilizing the existing state or understanding what is currently deployed.
Question 8: Handling Out-of-Band Terraform Changes
Terraform
How do you handle a situation where a colleague ran terraform apply directly from their laptop and created production resources that are not in the CI/CD pipeline?
Strong answer: A strong candidate imports the out-of-band resource into state with terraform import. They reverse-engineer the configuration to match the actual resource and add it to the codebase under version control. After that, they implement a control to prevent future out-of-band applies. For example, they might revoke direct cloud access for engineers who can use the CI/CD pipeline instead, or implement Sentinel or OPA policies that require plan approval before apply. Weak answer: A weak candidate deletes and recreates the resource through Terraform without importing it, or adds it to state without blocking future out-of-band creates.
Security and Access Questions
Security questions for DevOps engineers reveal whether their default orientation is least-privilege and defense-in-depth. Alternatively, they reveal whether the candidate treats security as a constraint imposed on them rather than a design principle they own. Engineers with production DevOps depth raise security implications without being prompted, while engineers without it need to be asked.
Question 9: Remediating an Over-Privileged Access Key
Security
A developer on your team has been using a long-lived AWS access key with AdministratorAccess to run Terraform locally. How do you remediate this and prevent it from recurring?
Strong answer: A strong candidate rotates the key immediately, then audits CloudTrail for the past 90 days to confirm no unauthorized actions were taken with it. Next, they replace long-lived keys with OIDC federation, such as GitHub Actions OIDC to an IAM role or AWS SSO for developer access. They scope the IAM role to only the permissions required for Terraform operations in that environment. Finally, they implement a scheduled credential audit to detect future long-lived key creation. Weak answer: A weak candidate rotates the key and asks the developer to use a more restricted IAM user, without addressing the structural problem of long-lived credentials.
Question 10: Securing the Container Image Supply Chain
Security
How do you approach container image security in a CI/CD pipeline that builds 30 images per day across 15 microservices?
Strong answer: A strong candidate describes integrating an image scanner, such as Trivy, Snyk, or Grype, as a required CI gate. The threshold policy fails on critical CVEs and warns on high ones. In addition, they pin base image digests rather than mutable tags to prevent supply chain substitution. They implement image signing with Cosign for production deployments, and they run a scheduled rescan of the image registry for vulnerabilities that emerge after the initial build. Weak answer: A weak candidate describes scanning images manually on an ad hoc basis, or only scanning at build time without a scheduled rescan policy for production-deployed images.
Incident Response Questions
Incident response questions reveal how a DevOps engineer thinks under pressure and how they communicate during an active outage. The structure of their diagnostic process matters more than knowing the specific answer. In short, engineers who cannot communicate their reasoning during a scenario question will not communicate well at 2 am during a production incident.
Question 11: Diagnosing a CI/CD and Registry Outage
Incident Response
At 11:30am on a Tuesday, your Datadog dashboard shows a 60% drop in successful deployments from the CI/CD pipeline, with 5xx errors from the container registry. Three teams are blocked. Walk me through your next 20 minutes.
Strong answer: A strong candidate posts an immediate status update to the incident Slack channel before diagnosing. Then they check the container registry health dashboard and recent push and pull logs. This confirms whether the issue is read failures (pulling base images), write failures (pushing built images), or authentication failures. They also check for a registry rate limit event or a recent credentials rotation that may have invalidated pipeline service accounts. Before the root cause is confirmed, they provide a workaround, such as falling back to cached images if safe, and communicate the ETA for resolution to affected teams. Weak answer: A weak candidate goes deep on diagnostic investigation for 15 minutes without communicating status to the blocked teams. Alternatively, they attempt to re-run failed pipelines without first understanding whether the problem is on the registry or the pipeline side.
Question 12: Writing the Post-Incident Review
Incident Response
How do you write a post-incident review after a Kubernetes cluster upgrade caused a 45-minute production outage that affected a major customer?
Strong answer: A strong candidate describes a blameless timeline from the upgrade start to the restoration of service, with contributing factors clearly separated from root causes. Their action items have specific owners and deadlines. For example, instead of “improve our upgrade process,” they write “implement a pre-upgrade smoke test against the staging cluster by [date], assigned to [name].” They also distinguish between immediate fixes, such as re-enabling the disrupted control plane component, and systemic improvements, such as a staged upgrade rollout strategy. They publish within 48 hours while the timeline is accurate. Weak answer: A weak candidate produces a timeline without action items. Alternatively, they assign all action items to the DevOps team without engaging the application teams on their role in the recovery.
Communication and Team Fit
For nearshore DevOps engineers specifically, communication questions assess three things. First, whether the candidate can collaborate effectively with a distributed US team in real time. Second, whether they can push back constructively on engineering decisions that create infrastructure risk. Third, whether they can translate technical trade-offs into terms that product and business stakeholders can act on during an incident.
Question 13: Handling Pressure to Skip Staging
Communication
An engineering lead wants to skip staging and deploy a Kubernetes cluster configuration change directly to production because the staging cluster is two versions behind. How do you handle the conversation?
Strong answer: A strong candidate explains the specific risk of configuration drift between staging and production. A config change on an older cluster version may not predict production behavior. They propose a concrete alternative, such as upgrading staging to match production and running the change there with a 2-hour bake time before production. Rather than simply refusing, they frame the conversation around the customer impact of an unvalidated config change rather than engineering preference. Weak answer: A weak candidate either agrees to skip staging to avoid conflict with the engineering lead, or refuses without offering an alternative that addresses the business urgency.
Question 14: Making the Case for a Phased Migration
Communication
Your VP wants to migrate your entire CI/CD stack from Jenkins to GitHub Actions in 60 days. You have 200 Jenkins pipelines across 40 repositories. How do you make your case for a phased approach?
Strong answer: A strong candidate quantifies the risk by estimating pipeline count across complexity tiers. These range from simple build-and-push jobs to multi-environment deploys with approval gates to integration tests requiring Jenkins plugins without GitHub Actions equivalents. From there, they model the migration capacity required and propose a phased plan with specific milestones and a rollback path if critical pipelines break during migration. Throughout, they tie the timeline risk to customer impact, not engineering preference. Weak answer: A weak candidate either agrees to the 60-day timeline to avoid conflict, or opposes it without data on pipeline complexity or a concrete counter-proposal.
Frequently Asked Questions
Interview Format and Logistics
How many interview rounds should a DevOps engineer go through?
For a nearshore placement, one 90-minute structured technical interview plus a 30-minute hiring manager conversation is sufficient for senior DevOps engineer roles. A third round is appropriate only if the first session revealed a specific gap, such as Kubernetes operational depth. In that case, use it to probe more deeply before making an offer. Adding rounds that repeat the same domains does not improve prediction quality. In fact, it signals poor process to strong candidates who have competing options and limited patience for redundant screening.
Should I give a DevOps take-home assignment?
A brief async screen before the live interview is effective for DevOps roles. Ask the candidate to review an anonymized Terraform module or a Kubernetes deployment manifest and submit written feedback. This takes 45 to 60 minutes and gives you a baseline on written communication and technical judgment before investing in a 90-minute live session. By contrast, full take-home projects, such as writing a complete CI/CD pipeline for a sample application, longer than 2 hours are increasingly declined by experienced candidates with competing options.
Evaluating Candidates and Avoiding Bad Questions
How do Kore BPO DevOps candidates compare to candidates from a cold applicant pipeline?
Kore BPO candidates have already passed a technical screen using questions similar to those in this guide before reaching your interview stage. As a result, you receive 2 to 3 vetted profiles rather than reviewing 40 to 60 applicants. Your interview becomes a confirmation and fit assessment rather than an initial filter. Clients consistently report that 80 to 90% of Kore BPO candidates advance past the first round, compared to typical 15 to 25% conversion rates from cold pipelines.
What should I avoid asking in a DevOps interview?
Avoid trivia questions that test CLI flag memorization rather than judgment. For example, “What is the kubectl flag to force-delete a pod?” only reveals that the candidate has read documentation. It does not reveal whether they understand why force-deleting a pod can cause data corruption in a stateful workload. Instead, replace trivia questions with scenario questions that have constraints. Real DevOps problems always involve time pressure, incomplete information, or conflicting priorities, and questions without those constraints produce academic answers that do not predict production performance.
Evaluating Cross-Platform Candidates
How should I evaluate a candidate who comes from a different cloud platform than ours?
Evaluate depth on their primary platform, not breadth across platforms. A candidate with strong EKS production experience who has not operated AKS can still translate their Kubernetes knowledge to Azure within weeks. The underlying cluster management patterns are the same. The CI/CD and IaC questions in this guide are platform-agnostic by design. Simply adapt the cloud-specific examples to the candidate’s primary environment, and evaluate the quality of their reasoning rather than whether they named the exact same services your team uses.
