Remote DevOps engineer interview questions and how to answer them

Technical questions

What you know and how you'd do the work, often with a live task or test.

1. What is the difference between a liveness probe and a readiness probe in Kubernetes?

   Why they ask

   Probes are one of the most common causes of mysterious restarts and dropped traffic, so it separates people who've run Kubernetes from people who've read about it.

   How to answer

   Liveness failure makes the kubelet restart the container. Readiness failure removes the pod from the Service's endpoints so it gets no traffic, without restarting it. Mention startup probes for slow-starting apps, and the danger of liveness probes that check external dependencies.

   Show a sample answerHide the sample answer

   If the liveness probe fails enough times, the kubelet kills and restarts the container. If the readiness probe fails, the pod is taken out of the Service endpoints, so it stops getting traffic but keeps running. For a Java app that takes a minute to boot, I'd add a startup probe, because liveness and readiness don't run until it passes. And I'd never point a liveness probe at the database: if the database blips, every pod restarts at once.

2. A pod is stuck in CrashLoopBackOff. How do you debug it?

   Why they ask

   It's the classic Kubernetes troubleshooting question and shows whether you work methodically.

   How to answer

   Explain that the container keeps starting and exiting, and Kubernetes waits longer between each restart. Then give your order: describe the pod, read the previous container's logs, check the exit code, then config, resources and probes.

   Show a sample answerHide the sample answer

   CrashLoopBackOff means the container keeps exiting and Kubernetes is backing off between restarts. I'd run kubectl describe pod <name> to see events, the last state and the exit code, then kubectl logs <name> --previous to see why the last run died. Exit code 137 with reason OOMKilled means it hit its memory limit. If the logs mention a missing variable or file, I'd check the ConfigMap, Secret and mounts. If the app starts fine but gets killed after a few seconds, I'd suspect an aggressive liveness probe.

3. Explain blue/green and canary deployments. When would you use each?

   Why they ask

   Release strategy is central to the job, and it shows whether you understand trade-offs in cost and risk.

   How to answer

   Blue/green: two full environments, switch all traffic at once, instant rollback by switching back, but double the resources during the switch. Canary: send a small share of traffic to the new version, watch metrics, then increase. Mention rolling updates as the Kubernetes default.

   Show a sample answerHide the sample answer

   Blue/green runs the new version alongside the old one at full size, then flips all traffic over, usually at the load balancer. Rollback is just flipping back, but you pay for two environments for a while, and database changes have to work with both versions. A canary sends maybe 5% of traffic to the new version and I'd watch error rate and latency before going to 25, 50 and 100. For a payments service I'd prefer a canary, because only a few users see a bad release. The Kubernetes default is a rolling update, which replaces pods gradually but gives you less control.

4. What is Terraform state, and how do you manage it in a team?

   Why they ask

   State mistakes cause some of the worst infrastructure accidents, so every Terraform interview asks about it.

   How to answer

   State maps your code to real resources. Explain why it must be remote, locked, access-controlled and never committed to Git, and that it can contain secrets.

   Show a sample answerHide the sample answer

   The state file is how Terraform knows which real resources belong to which blocks in the code. By default it's a local terraform.tfstate, which is fine alone but dangerous in a team. I keep it in a remote backend, for example an S3 bucket with versioning and encryption, and turn on locking so two people can't apply at the same time. On the S3 backend, newer Terraform versions lock with use_lockfile = true; the old DynamoDB table method is deprecated. I never commit state to Git, because it can contain passwords in plain text.

5. Someone changed a security group in the AWS console during an incident. What happens on the next terraform plan, and what do you do?

   Why they ask

   Drift between code and reality happens in every real company. They want to see judgement, not just commands.

   How to answer

   The plan will show Terraform wanting to change it back. Decide with the person whether the manual change should stay. If yes, put it in code; if no, let Terraform revert it. Mention refresh-only mode.

   Show a sample answerHide the sample answer

   The plan would show Terraform trying to put the security group back the way the code describes it. Before applying anything I'd ask whoever made the change why. If the change should stay, I'd add it to the Terraform code so the plan comes back clean. If it was a temporary fix, I'd let Terraform revert it once the incident is over. terraform plan -refresh-only is useful to see exactly what changed outside Terraform without proposing any changes to the infrastructure.

6. Our Docker image is 1.2GB. How would you make it smaller?

   Why they ask

   Image size affects build time, deploy time, cost and security surface. It's a quick test of Docker fluency.

   How to answer

   Multi-stage builds, a smaller base image, a .dockerignore, cleaning package caches in the same layer, and only copying what the app needs to run. Mention ordering layers for caching.

   Show a sample answerHide the sample answer

   First I'd check what's in it with docker history. Usually it's build tools that don't need to ship, so I'd use a multi-stage build: compile in a full image, then copy only the output into a slim or distroless base. I'd add a .dockerignore so node_modules, .git and test data don't get copied, and clean the apt cache in the same RUN line that installs packages. I'd also copy the dependency file and install before copying the source, so code changes don't bust the dependency cache.

7. A Linux server's disk is full. Walk me through what you'd do.

   Why they ask

   A basic ops scenario that shows Linux comfort and whether you'd delete something important in a panic.

   How to answer

   Confirm with df -h, find the culprit with du, check inodes and deleted-but-open files, then fix the cause (log rotation, retention) rather than just freeing space once.

   Show a sample answerHide the sample answer

   df -h to see which filesystem is full, then du -xh --max-depth=1 / | sort -h and drill down. Usually it's logs, old Docker images or a core dump. For Docker I'd use docker system df before pruning anything. If df says full but du doesn't add up, a process may be holding a deleted file open, and lsof +L1 shows it; restarting that process frees the space. I'd also check df -i in case it's inodes. Then I'd fix the cause: log rotation, journalctl --vacuum-size, or an alert at 80%.

8. A service in Kubernetes can't reach another service. How do you troubleshoot it?

   Why they ask

   Service-to-service networking is where Kubernetes confuses people most. It tests DNS, labels and network policy knowledge together.

   How to answer

   Work from DNS to endpoints to the pod: check the Service name and namespace, whether the Service has endpoints (selector and readiness), the port mapping, then NetworkPolicies.

   Show a sample answerHide the sample answer

   I'd exec into the calling pod and try the Service by its full DNS name, like orders.payments.svc.cluster.local, with curl, because a wrong namespace is common. Then kubectl get endpointslices -l kubernetes.io/service-name=orders in that namespace: if there are no endpoints, the Service selector doesn't match the pod labels or the pods aren't ready. Next I'd check the Service targetPort matches the port the container listens on. If all that is fine, I'd look for a NetworkPolicy blocking traffic between the namespaces.

9. How do you handle secrets in CI/CD and Kubernetes?

   Why they ask

   Leaked credentials are a top cause of breaches, and DevOps engineers are the people who usually leak or protect them.

   How to answer

   Never in Git or images. Use the CI tool's secret store, prefer short-lived credentials via OIDC, and a secrets manager for apps. Point out that Kubernetes Secrets are only base64-encoded and need encryption at rest and RBAC.

   Show a sample answerHide the sample answer

   Secrets never go in the repo or the Docker image. In GitHub Actions I use OIDC to get short-lived cloud credentials instead of storing long-lived access keys. For apps, secrets live in Vault or AWS Secrets Manager and get synced into the cluster. Kubernetes Secrets are only base64-encoded, so I make sure encryption at rest is turned on and RBAC limits who can read them. If a secret ever leaks, I rotate it first and investigate second.

10. When would you use Ansible instead of Terraform?

    Why they ask

    Checks you understand what each tool is for rather than using one hammer for everything.

    How to answer

    Terraform creates and manages infrastructure declaratively and tracks it in state. Ansible configures machines over SSH, agentless, with no state file. Many teams use both.

    Show a sample answerHide the sample answer

    I use Terraform to create infrastructure: the VPC, the VMs, the load balancer, the database. It keeps state and can plan and destroy. Ansible is better for configuring what's inside a server, like installing packages, managing config files and users, especially on VMs or on-premise machines. It connects over SSH and doesn't keep state. If everything runs in containers on Kubernetes, there's much less need for Ansible.

Behavioural questions

Past situations. Answer with a real example: what happened, what you did, what changed.

1. Tell me about a time you broke something in production.

   Why they ask

   Everyone in DevOps has broken production. They want honesty, ownership and what you changed afterwards.

   How to answer

   Pick a real incident. Say what you did, how you noticed, how you fixed it, what you told people and what guardrail you added.

   Show a sample answerHide the sample answer

   At a Lagos fintech I updated an Nginx config by hand on one server and missed a semicolon, so reloads failed and one node dropped out of the load balancer. Monitoring caught it within a few minutes. I fixed the config, told my lead straight away, and then moved the config into Ansible with nginx -t as a check before any reload. It never happened that way again.

2. How have you convinced a team to change how they deploy?

   Why they ask

   DevOps is partly culture. They want someone who brings developers along rather than forcing tools on them.

   How to answer

   Describe the problem in terms the team cared about, a small trial, and the result. Show that you listened to objections.

   Show a sample answerHide the sample answer

   Developers at my last company deployed by SSH-ing into servers and pulling from Git. They didn't want a pipeline because they thought it would slow them down. I set one up for a single small service, showed that deploys went from 20 minutes of manual steps to one merge, and added a one-click rollback. Two other teams asked for the same within a month.

Situational questions

Hypotheticals about problems you'd meet in the job.

1. You deployed at 5pm and error rates jumped. What do you do?

   Why they ask

   They want to see that you restore service first and investigate second, and that you communicate.

   How to answer

   Roll back first, tell people what's happening, confirm the rollback fixed it, then investigate in staging. Mention how you'd prevent it next time.

   Show a sample answerHide the sample answer

   I'd post in the incident channel that the 5pm deploy looks bad and I'm rolling back, then roll back to the previous image. Once error rates are back to normal I'd confirm in the channel. Only then would I dig into what broke, using logs and the diff between versions. Afterwards I'd ask why our checks didn't catch it, maybe a missing integration test or a canary step we should add.

2. Developers complain the pipeline takes 40 minutes. How would you speed it up?

   Why they ask

   Slow pipelines are a constant complaint, and fixing them shows practical skill and empathy for developers.

   How to answer

   Measure before changing anything. Then caching, parallel jobs, splitting tests, only building what changed, and moving slow checks to nightly runs where it's safe.

   Show a sample answerHide the sample answer

   First I'd look at timing for each step over the last few weeks to find where the 40 minutes goes. Common wins are caching dependencies and Docker layers, running lint, unit tests and the build in parallel, and splitting the test suite across several runners. In a monorepo I'd only build services whose files changed. If there's a slow end-to-end suite, I'd talk to the team about running part of it on merge and the full suite nightly.

Remote work questions

How you'll work from Nigeria with a team elsewhere: hours, power, internet, communication.

1. Our team is mostly in the US. How would you handle on-call and deployments from Lagos?

   Why they ask

   They need to know you understand the time difference and won't disappear when you're needed.

   How to answer

   Be specific about the hours: US East is 5 to 6 hours behind Lagos, US Pacific 8 to 9. Say what overlap you'd keep, how you'd handle night pages, and how you'd hand over in writing.

   Show a sample answerHide the sample answer

   New York is 5 or 6 hours behind Lagos depending on the season, so my afternoon and evening overlap with your morning. I'd keep my core hours from about 1pm to 9pm Lagos time. For on-call I'd want the rotation and escalation clear up front, and I'm fine taking night pages on my weeks as long as I can sleep in after a bad night. I'd also offer to cover the early-morning US window as part of a follow-the-sun rotation, since that's normal daytime for me.

2. What happens if your power or internet goes out in the middle of a production change?

   Why they ask

   Employers who've hired in Nigeria know outages happen. They want to hear you've designed around it.

   How to answer

   Explain your backup setup and, more importantly, that you don't run critical changes from your laptop session.

   Show a sample answerHide the sample answer

   I don't run long changes from my laptop's terminal. They go through the pipeline, or inside tmux on a bastion host, so if my connection drops the job keeps running and I reattach. At home I have an inverter that covers about eight hours, a fibre line and a MiFi on a different network. If both connections died during a change, I'd call or WhatsApp a teammate to watch it while I switch to my phone hotspot.

Remote interview tips

Questions people ask