Interview Insights · DevOps Engineer
Why DevOps Engineer Candidates Freeze on the Simplest Questions
Quick summary — DevOps basics
Candidates freeze on simple questions because they learned DevOps tools from the top down and skipped the Linux layer beneath them. Many learners start with Jenkins, Docker and Kubernetes because those appear in job posts. The tools hide the basics: processes, ports, permissions, exit codes and environment variables. When an interviewer asks about one of these directly, it feels so simple that the candidate suspects a trick, overthinks and freezes. Rebuilding these fundamentals takes a short time and makes every tool question easier, because every tool is built on them.
In this guide you will learn:
- Why simple questions cause freezes for tool-first learners
- The five fundamentals interviewers ask about most
- Commands to see each one on a real Linux machine
- How each basic shows up inside pipelines and containers
- A short daily drill to rebuild the foundation
SECTION 01Why the easy question feels hard
There are two reasons for the freeze. The first is a real gap: many people learn DevOps from tool tutorials, where everything is a command to copy. They have used chmod +x but never read a permission string. They have mapped ports in Docker but never checked what is listening on a server. The second reason is psychological. A question that sounds too easy makes candidates think there must be a trick, so they search for a complex answer and say nothing.
I ask simple questions because they tell me whether a candidate can debug when tools fail. When a pipeline breaks, the error is usually about one of these basics.
| Simple question | Why I ask it | Where it shows up in DevOps | Typical freeze reason |
|---|---|---|---|
| What does it mean for a process to listen on a port? | Core of every connection problem | Service not reachable, port conflicts | Only used port mapping in Docker |
| What is an exit code? | Pipelines pass or fail on it | A CI step fails or silently passes | Never checked $? after a command |
| Explain chmod 640 | Permission errors are common | Permission denied on scripts, keys, volumes | Only memorised chmod +x |
| How does a program read an environment variable? | Config and secrets use them | Missing config in containers and CI | Thinks of them as tool settings only |
Interviewer: What does it mean when a process listens
on port 8080?
Candidate: (pause) ... In Docker we write -p 8080:8080.
Interviewer: Yes, but what is actually happening on the
machine?
Candidate: (silence)
(The candidate knows the tool syntax but not the idea
underneath it.)Interviewer: What does it mean when a process listens
on port 8080?
Candidate: The process has opened a socket bound to
port 8080 on some address and is waiting for incoming
connections. If it is bound to 127.0.0.1, only programs
on the same machine can connect. If it is bound to
0.0.0.0, it accepts connections on all interfaces.
I can check it with ss -tlnp, which shows listening TCP
sockets and the process that owns each one.The difference between 127.0.0.1 and 0.0.0.0 is behind a very common container problem: an app inside a container listens only on localhost, so the port mapping works but nothing can connect. Knowing the basic makes that bug obvious.
SECTION 02The five fundamentals and how to see them
You do not need a textbook to rebuild the basics. You need a Linux machine, a virtual machine or even a container, and a few commands that let you see each fundamental directly. Seeing them makes them stick.
The table lists the five I ask about most and the command that reveals each one. The tabs show a short session you can run yourself. Run it, read the output carefully and explain each line aloud.
| Fundamental | Command to see it | What to notice | One-line explanation |
|---|---|---|---|
| Processes | ps aux, systemctl status nginx | PID, user, state, parent | Every running program is a process with an ID and an owner |
| Ports | ss -tlnp | Local address and port, owning process | A port identifies one listening service on an address |
| Permissions | ls -l, stat file | rwx for owner, group, others | Read, write and execute bits for three classes of user |
| Exit codes | command; echo $? | 0 or a non-zero number | 0 means success, anything else signals failure |
# Processes: who is running what
ps -eo pid,ppid,user,stat,cmd | head
systemctl status ssh --no-pager
# Ports: what is listening
sudo ss -tlnp
# Permissions: read the string
touch report.txt
chmod 640 report.txt
ls -l report.txt
# -rw-r----- owner rw-, group r--, others ---
# Exit codes
ls /etc > /dev/null; echo $? # 0
ls /nope 2> /dev/null; echo $? # 2 (GNU ls: serious trouble)
grep -q root /etc/passwd; echo $? # 0 (found)
# Environment variables
export APP_ENV=staging
bash -c 'echo "child sees: $APP_ENV"'
env | grep APP_ENVEach digit is a sum: read = 4, write = 2, execute = 1
7 = 4+2+1 = rwx
6 = 4+2 = rw-
5 = 4+1 = r-x
4 = 4 = r--
0 = ---
chmod 755 deploy.sh
owner rwx, group r-x, others r-x
(typical for scripts everyone may run)
chmod 600 id_rsa
owner rw-, nobody else
(ssh refuses private keys that others can read)
chmod 640 app.conf
owner rw-, group r--, others ---Notice the environment variable example: a variable is only visible to child processes if it is exported. That one fact explains many 'my pipeline step cannot see the variable' problems, where a value was set in one shell step and expected in another.
SECTION 03Connecting the basics back to your tools
The final step is to connect each basic to the DevOps tools you already know. This is what turns a simple answer into an impressive one. When you explain that a CI step fails because the script returned a non-zero exit code, or that a container is unreachable because the app binds to localhost, you show that you can debug from first principles.
In Uncodemy DevOps batches, we teach these Linux basics before the tools for exactly this reason. Interviewers can tell quickly whether someone understands the layer underneath.
| Basic | Tool situation | Symptom | Root cause explained |
|---|---|---|---|
| Exit codes | CI step with a pipe: test | tee log | Tests fail but step passes | Pipe returns the last command's code; use set -o pipefail |
| Ports and binding | Container with -p 8080:8080 | Connection refused from host | App listens on 127.0.0.1 inside the container |
| Permissions | Script in a pipeline | Permission denied when running ./deploy.sh | Execute bit not set or not stored in Git |
| Environment variables | Two separate CI steps | Second step cannot see the value | Each step runs in a new shell; use the CI's env mechanism |
#!/usr/bin/env bash
# Without pipefail: the failure is hidden
false | tee out.log
echo "exit without pipefail: $?" # prints 0
# With pipefail: the failure is reported
set -o pipefail
false | tee out.log
echo "exit with pipefail: $?" # prints 1
# A safe header for pipeline scripts
# set -euo pipefail
# -e stop on any failing command
# -u error on unset variables
# -o pipefail fail if any command in a pipe fails# Script fails in CI with: Permission denied
# Check what Git stored
git ls-files -s deploy.sh
# 100644 ... deploy.sh <- not executable
# Fix it in Git, not just locally
git update-index --chmod=+x deploy.sh
git commit -m "Make deploy.sh executable"
git ls-files -s deploy.sh
# 100755 ... deploy.sh <- executableThe execute bit example catches many people who work on Windows, where file permissions do not map directly to Git's mode. The script runs locally through another method, then fails in a Linux CI runner. Explaining that in an interview shows real debugging experience.
SECTION 04A daily drill to rebuild DevOps fundamentals
Spend a short session each day on these tabs for two weeks. Use a Linux virtual machine or a cloud instance you can break freely.
DAILY FUNDAMENTALS DRILL
Pick one topic per day and do all three:
1. Run the commands and read the output
2. Explain it aloud in two sentences
3. Break something on purpose and fix it
Topics:
[ ] Processes and signals (ps, kill, systemctl)
[ ] Ports (ss, curl, binding to 127.0.0.1 vs 0.0.0.0)
[ ] Permissions (chmod, chown, umask)
[ ] Exit codes (echo $?, set -e, pipefail)
[ ] Environment variables (export, env, child shells)
[ ] DNS (dig, /etc/hosts, resolv.conf)
[ ] Disk (df, du, inode usage)ANSWER EACH IN UNDER 30 SECONDS
- What is a process? What is a PID?
- What is the difference between kill and kill -9?
- What does it mean that a process listens on a port?
- What does 127.0.0.1 mean?
- What is chmod 644?
- What does exit code 0 mean?
- What does export do?
- What does /etc/hosts do?
- How do you check free disk space?
- What is a symbolic link?BREAK AND FIX EXERCISES
1. Start a Python server bound to 127.0.0.1:8000.
Try to reach it from another machine. Fix the bind.
2. Remove execute permission from a script; run it.
3. Write a script with a failing pipe; add pipefail.
4. Set a variable without export; read it in a child.
5. Stop a systemd service and read journalctl output.
Note each error message word for word.SECTION 05How to stop freezing on easy questions
These habits help you answer basic questions calmly, even when your mind wants to look for a trick.
- Answer the plain version first — Give the simple, direct answer in one sentence before adding any detail.
- Name the command that shows it — Mentioning ss, ls -l or echo $? makes your answer concrete and gives you something to say next.
- Connect it to a tool — One example of where the basic appears in a pipeline or container turns a definition into experience.
- Learn the layer under each tool — For every DevOps tool you use, ask what Linux feature it depends on and read about that feature.
- Practise the boring questions — Have a friend ask simple questions randomly; speed on basics builds confidence for the whole interview.
SECTION 06Interview Q&A — DevOps basics
Q1What is the difference between kill and kill -9?
kill sends SIGTERM by default, which asks the process to shut down cleanly; it can finish work, close files and exit. kill -9 sends SIGKILL, which the process cannot catch, so the kernel stops it immediately without cleanup. Use SIGTERM first and SIGKILL only if the process does not stop.
Q2A service is running but you cannot connect to it. What do you check?
Check that it is actually listening with ss -tlnp, and on which address. If it is bound to 127.0.0.1, only local connections work. Then check the firewall or security group, then whether you are using the correct port and host. Test locally with curl first to separate app problems from network problems.
Q3What does set -euo pipefail do in a bash script?
-e stops the script when a command fails, -u treats unset variables as errors, and -o pipefail makes a pipeline fail if any command in it fails, not just the last one. Together they stop pipeline scripts from continuing silently after an error.
Q4What is an environment variable and how is it passed to a process?
It is a named value in a process's environment. A child process inherits a copy of its parent's exported variables at start. Changes in the child do not affect the parent. That is why CI tools provide their own way to pass variables between steps.
Q5Why does ssh refuse a private key with permissions 644?
Because others can read it, and ssh treats a readable private key as unsafe. The key should be readable only by its owner, so set it to 600 or 400. This is a common error when keys are copied into containers or CI runners.
SECTION 07Test yourself — DevOps basics quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
What Linux questions are asked in DevOps interviews?
Common ones cover processes and signals, ports and networking commands, file permissions, disk usage, systemd services, logs, environment variables and shell scripting basics such as exit codes and pipes.
Do I need Linux for DevOps?
Yes. Most servers, containers and CI runners use Linux, and many DevOps problems come down to processes, permissions, networking or the shell. Strong Linux basics make every tool easier to debug.
Why do I forget basics in interviews?
Pressure and overthinking are common causes, especially if a question feels too easy. Practising simple questions aloud and starting with a plain one-sentence answer helps prevent freezing.
What is the difference between 127.0.0.1 and 0.0.0.0?
127.0.0.1 is the loopback address, reachable only from the same machine. Binding a server to 0.0.0.0 means it listens on all network interfaces, so other machines can connect if the network allows it.
How can I practise Linux for DevOps at home?
Use a virtual machine, a container or a small cloud instance. Run commands for processes, ports, permissions and logs, break things deliberately and fix them, and explain each command aloud.
Where can I practise DevOps Engineer interview answers with expert feedback?
Yes. Uncodemy's DevOps Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise DevOps Engineer interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Build the foundation under every DevOps tool
Our DevOps Training Course starts with Linux and networking basics before CI/CD, Docker and Kubernetes, so simple interview questions never catch you off guard.
Talk to a counsellor for current fees- Linux and shell scripting
- Networking fundamentals
- CI/CD and container labs
- Weekday & weekend batches