DevOps engineer screening questions: cloud, infrastructure as code, CI/CD and on-call

DevOps engineer screening questions should find out what the candidate built and ran in production, not which tools their company had. Ask which cloud accounts and services they provisioned themselves, whether they wrote the infrastructure code or edited it, whether they built the CI/CD pipeline or only used it, how often they were paged, and what they did about cost. Engineers with real ownership answer with specifics about state files, broken deploys and incidents at 3 a.m. Inflated resumes list Kubernetes, Terraform and three clouds without a single failure story.

This bank goes deeper on infrastructure and operations than software engineer phone screen questions, which covers application developers. Each group below has strong answers and red flags, followed by certification notes, a cost worked example and a knockout checklist.

DevOps, SRE, platform or cloud engineer: what the title hides

Cloud platforms and certifications

Certifications are rarely required for DevOps roles, but clients sometimes ask for them. Know what the common ones are:

Ask for the issuer's verification link or digital badge if the client requires a certification, and check the expiry date. A current certification plus production stories is the strongest combination; a stack of certifications with no production ownership is common among career changers and is a reason to ask more questions, not to reject.

Infrastructure as code: wrote it, edited it or ran it

Terraform, OpenTofu, CloudFormation, Bicep, Pulumi and Ansible appear on nearly every DevOps resume. The difference between writing infrastructure code and running someone else's shows up quickly in the questions below.

• "Did you write the modules, or change variables in modules someone else wrote?" Strong: describes a module they built, what it created, and who reused it. Red flag: only ever changed a value and ran apply.
• "Where was state stored, and did you ever have a state problem?" Strong: remote state with locking, and a story about a lock, a drifted resource or an import. Red flag: does not know what state is, for a Terraform-heavy role.
• "Tell me about a plan that showed a change you did not expect." Strong: "The plan wanted to replace the database because someone renamed a resource. I used a moved block instead." Red flag: has never read a plan closely.
• "How were infrastructure changes reviewed and applied?" Strong: pull requests, plan output in the review, applies from a pipeline, not laptops. Red flag: applied from their own machine to production with no review.
• "What is still created by hand in that environment, and why?" Strong: an honest list and a reason. Red flag: "Everything is in code," from a company of any age.
• "Ansible or configuration management: what did your playbooks do?" Strong: specific tasks such as patching, hardening or app configuration across a known number of servers. Red flag: ran playbooks written by others, described as authoring.

CI/CD ownership: built the pipeline or pushed through it

Containers and Kubernetes: operated clusters or deployed onto them

"Kubernetes" on a resume can mean running the clusters or writing a deployment file for a cluster another team ran. Both are useful; clients hiring someone to run clusters need the first.

• "Who created and upgraded the clusters: you, another team, or a managed service like EKS, AKS or GKE?" Strong: honest ownership and one upgrade they did. Red flag: claims cluster operations but has never upgraded one.
• "How many clusters and roughly how many services ran on them?" Strong: numbers stated easily. Red flag: "a lot."
• "How were applications packaged and deployed: Helm, Kustomize, GitOps?" Strong: names the approach and a problem with it. Red flag: a list of all three with no preference or experience.
• "Tell me about a pod or node problem you debugged." Strong: a specific failure (out-of-memory kills, a crash loop, a node running out of disk) and how they found the cause. Red flag: restarted things until it worked.

On-call, incidents and reliability

Cost optimization: checking savings claims

"Reduced cloud costs 40 percent" is one of the most common DevOps resume lines. You can check it without knowing cloud pricing by asking for the baseline, the change and how it was measured.

• "What was the monthly cloud spend you were responsible for?" Strong: an approximate figure. Red flag: never saw the bill.
• "How did you find out what was expensive?" Strong: cost explorer or billing reports, tagging by team or service. Red flag: guessed.
• "Tell me about a saving you made that later caused a problem." Strong: an honest trade-off, such as instances too small for peak traffic. Red flag: no trade-offs ever.

How DevOps resumes overstate the work

Logistics, knockout checklist and scorecard

Knock out, or flag to the client before submitting, if:

• The role owns production and the candidate has never been on call or worked an incident.
• Infrastructure as code is a must-have and they have only changed variables in others' modules.
• The client's primary cloud is one the candidate has never used in production, and the client said that matters.
• The candidate cannot commit to the on-call rotation.

Record the incident and the savings claim with their real numbers and the candidate's words. An engineering manager trusts "cut 22K a month by rightsizing; 'finance bought the savings plan'" more than "cost optimization expert." Interview Signal attaches quotes like that to each score from the call. Keep questions about shifts and on-call about the schedule; the EEOC notes that pre-employment inquiries pointing at protected characteristics can be used as evidence of discrimination.