Cloud and DevOps Interview Questions for Junior Roles (With Answers)

A junior cloud or DevOps interview is rarely a trivia contest. Most interviewers want to know three things: do you understand the basics well enough to explain them simply, can you work through a problem you have not seen before, and have you actually built anything. This guide covers the questions that come up again and again for junior roles, with model answers you can adapt, the hands-on practice that makes those answers believable, and a realistic plan for the weeks before your interview.

The model answers are short on purpose. Learn the idea behind each one and say it in your own words. Interviewers can tell when someone is reciting.

How junior cloud and DevOps interviews usually work

The format varies by company, but most junior hiring processes include some mix of these stages:

1. Recruiter or HR screen. A short call about your background, why you want the role, notice period and salary expectations. Be clear and honest.
2. Technical screen. Conceptual questions on Linux, networking, cloud basics, Git and containers. Sometimes a short live exercise.
3. Practical task. Either a take-home (for example, "containerise this app and write a pipeline for it") or a live troubleshooting session where you share your screen.
4. Behavioural or team interview. How you handle mistakes, pressure, learning and working with others.

Remote roles, which many African candidates apply for, often add a check of your written communication. Clear messages, a tidy README and a decent GitHub profile count for more than many people expect.

Linux questions

Linux is the foundation of almost every cloud and DevOps job, and it is where many juniors are weakest. If you need to shore it up, start with Linux skills for cloud jobs and practise in the Linux Arena.

"A service is not responding on a server. How would you investigate?"

Model answer: "I would work from the outside in. First, confirm the problem: can I reach the server at all, and is the port open? Then check whether the service is running, read its logs, and check resources like disk, memory and CPU. Finally, I would check recent changes, because something usually changed."

Show that you know the commands:

# Is the service running?
systemctl status nginx

# What do the recent logs say?
journalctl -u nginx --since "30 min ago"

# Is anything listening on port 80?
sudo ss -tlnp | grep ':80'

# Is the disk full? Is memory exhausted?
df -h
free -h
top

A full disk is one of the most common real causes. Mentioning it shows experience.

"What do file permissions like 755 and 644 mean?"

Model answer: "Each digit covers the owner, the group and everyone else. Read is 4, write is 2 and execute is 1, so 7 is read, write and execute, 5 is read and execute, and 4 is read only. 755 is typical for directories and scripts, 644 for ordinary files."

ls -l deploy.sh
chmod 755 deploy.sh
chown ubuntu:ubuntu deploy.sh

Bonus point: explain that chmod 777 is almost never the right fix, because it lets any user on the machine change the file.

Networking questions

Networking questions catch out a lot of career switchers. You do not need to be a network engineer, but you should be comfortable with these.

"What happens when you type a URL into a browser?"

Model answer (short version): "The browser resolves the domain to an IP address through DNS. It opens a TCP connection to that IP on port 443, performs a TLS handshake to set up encryption, then sends an HTTP request. The server, often behind a load balancer, returns a response, and the browser renders it."

You can demonstrate each step:

dig skill-sch.com +short          # DNS lookup
curl -I https://skill-sch.com     # HTTP response headers
curl -v https://skill-sch.com 2>&1 | grep -i 'SSL\|TLS'   # TLS details

"What is the difference between TCP and UDP?"

Model answer: "TCP is connection-based and guarantees delivery and order, so it is used for web traffic, SSH and databases. UDP has no connection and no delivery guarantee, which makes it lighter and faster. DNS queries and video calls commonly use UDP."

"What is a CIDR block like 10.0.0.0/16?"

Model answer: "The /16 means the first 16 bits are the network part, leaving 16 bits for hosts, so roughly 65,000 addresses. In the cloud, I might give a VPC a /16 and split it into smaller /24 subnets of 256 addresses each, with public subnets for load balancers and private subnets for application servers and databases."

Note: cloud providers reserve a few addresses in each subnet, so a /24 gives slightly fewer than 256 usable addresses. Saying this is a good sign you have actually built one.

Common ports you should know

Cloud fundamentals questions

Most junior roles focus on either AWS or Azure. If you have not chosen yet, read AWS vs Azure: which to learn first. The concepts below apply to both.

"What is the shared responsibility model?"

Model answer: "The cloud provider is responsible for the security of the cloud: the physical data centres, hardware and the underlying infrastructure. The customer is responsible for security in the cloud: their data, identity and access settings, network rules, and the configuration of their services. Where the line falls depends on the service. With a virtual machine I patch the operating system; with a managed database, the provider does more of that."

"What are regions and availability zones?"

Model answer: "A region is a geographic area containing data centres, for example AWS af-south-1 in Cape Town or Azure South Africa North. Availability zones are separate data centre groups within a region with independent power and networking. Spreading resources across zones protects you if one zone fails."

"How would you make a simple web application highly available?"

Model answer: "Run at least two instances in different availability zones behind a load balancer, put them in an auto scaling group so failed instances are replaced, use a managed database with a standby in another zone, and store static files in object storage like S3 or Azure Blob Storage. Then add health checks and monitoring so we know when something fails."

Draw this on paper while you answer if the interview allows it. A simple diagram makes a junior answer sound much more confident.

"How do you control cloud costs?"

This question comes up more and more, and it is one where Nigerian candidates often have a genuine advantage: if you have paid for cloud services with a naira card at a changing exchange rate, you already take costs seriously.

Model answer: "Set budgets and alerts from day one, tag resources by project and owner, shut down or schedule non-production resources out of hours, right-size instances based on actual usage, and delete unused disks, snapshots and IP addresses. For steady workloads, look at commitment discounts such as Savings Plans or reservations."

You can show you have done it:

# AWS: create a monthly cost budget with an email alert at 80% of the limit
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{"BudgetName":"monthly-limit","BudgetLimit":{"Amount":"10","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80,"ThresholdType":"PERCENTAGE"},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"you@example.com"}]}]'

Replace the account ID and email with your own. For more on this area, see our FinOps guide.

"What is IAM, and what is least privilege?"

Model answer: "IAM controls who can do what on which resources. Least privilege means giving each user or service only the permissions it needs and nothing more. In practice: no daily work as the root account, multi-factor authentication on, roles for applications instead of long-lived access keys, and permissions reviewed regularly."

Git questions

"What is the difference between git merge and git rebase?"

Model answer: "Both bring changes from one branch into another. Merge keeps the full history and adds a merge commit. Rebase replays my commits on top of the other branch, giving a straight line of history. I avoid rebasing branches that other people are already working on, because it rewrites history."

"You committed a secret to Git. What do you do?"

Model answer: "First, treat the secret as compromised and rotate it immediately, because removing it from the latest commit does not remove it from history or from anyone who has already cloned the repository. Then remove it from the code, move it to a secrets manager or CI secret, and add the file to .gitignore. If needed, clean the history with a tool like git filter-repo."

This is a favourite question because the wrong answer ("I deleted the file and pushed again") is very common. Practise everyday Git in the Git Arena.

Docker and container questions

"What is the difference between an image and a container?"

Model answer: "An image is a read-only template containing the application and everything it needs. A container is a running instance of an image. You can run many containers from one image."

"Write a Dockerfile for a small Python web app."

Expect to write or explain something like this:

FROM python:3.12-slim

WORKDIR /app

# Install dependencies first so this layer is cached
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

# Do not run as root
RUN useradd --create-home appuser
USER appuser

EXPOSE 8000
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]

Then explain your choices: a slim base image for a smaller size, copying requirements.txt before the rest of the code so dependency installs are cached, and a non-root user for security. That explanation is what turns a copied Dockerfile into a strong answer.

docker build -t myapp:1.0 .
docker run -d -p 8000:8000 --name myapp myapp:1.0
docker logs myapp
docker exec -it myapp sh

"A container keeps exiting straight away. How do you debug it?"

Model answer: "Check docker ps -a for the exit code, then docker logs for the error. A container stops when its main process ends, so common causes are a crashing app, a wrong command, or a missing environment variable. I can also run the image with a shell to look inside."

docker ps -a
docker logs myapp
docker run -it --entrypoint sh myapp:1.0

Our Docker for beginners guide and the Docker Arena cover this in more depth.

Kubernetes questions

Many junior roles only expect basic Kubernetes knowledge, but you should be able to answer these.

"What is the difference between a Pod, a Deployment and a Service?"

Model answer: "A Pod is the smallest unit, one or more containers running together. A Deployment manages a set of identical Pods, keeps the right number running and handles rolling updates. A Service gives those Pods a stable network address and load-balances traffic between them, because Pod IPs change when Pods are replaced."

"A Pod is in CrashLoopBackOff. What do you do?"

kubectl get pods
kubectl describe pod <pod-name>        # events, exit codes, image errors
kubectl logs <pod-name>                # current logs
kubectl logs <pod-name> --previous     # logs from the crashed container

Model answer: "CrashLoopBackOff means the container starts, crashes and Kubernetes keeps restarting it with increasing delays. I would read the events in describe and the logs from the previous container. Common causes are application errors, missing config or secrets, a wrong command, or a failing liveness probe."

Practise this in K8s Commander or read Kubernetes for beginners.

Infrastructure as code and CI/CD questions

"Why use Terraform instead of clicking in the console?"

Model answer: "Infrastructure as code makes environments repeatable, reviewable and version-controlled. Changes go through pull requests, I can see the plan before applying it, and I can rebuild an environment from code if it is lost."

Know the core workflow:

terraform init      # download providers, set up the backend
terraform fmt       # format the code
terraform validate  # check the syntax
terraform plan      # preview changes
terraform apply     # make changes
terraform destroy   # remove everything (great for keeping lab costs down)

A common follow-up: "What is the state file?" Answer: "It is Terraform's record of the real resources it manages. In a team it should live in a remote backend, such as an S3 bucket or Azure Storage account, with locking, and it should never be committed to Git because it can contain secrets."

"Describe a CI/CD pipeline you have built."

This is where a real project pays off. A simple GitHub Actions example you can explain line by line:

name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test-and-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest
      - run: docker build -t myapp:${{ github.sha }} .

Model answer: "On every pull request and push to main, the pipeline checks out the code, installs dependencies, runs the tests and builds a Docker image tagged with the commit SHA. If tests fail, the change is not merged. The next step would be pushing the image to a registry and deploying it."

See the CI/CD with GitHub Actions guide for a full walkthrough.

Behavioural questions

Do not underestimate these. Many juniors with similar technical skills are separated here.

Use the STAR format: Situation, Task, Action, Result. Prepare three or four real stories from your labs, projects, previous jobs or even non-tech work.

"Tell me about a time something broke and how you fixed it."

Pick a real lab failure. For example: "My pipeline kept failing at the Docker build step. I read the logs, found that a dependency needed a system library missing from the slim image, added it, and wrote a note in the README. I learned to read the full error before searching online."

"What do you do when you don't know the answer?"

Model answer: "I say so honestly, then explain how I would find out: the official documentation, logs, testing in a safe environment, and asking a colleague once I have tried the obvious steps." Interviewers value this far more than a confident guess.

Common mistakes in junior interviews

• Memorising definitions without hands-on practice. One follow-up question exposes it.
• Bluffing. "I haven't used that, but here is how I would approach it" is a strong answer. Making something up is not.
• Listing tools without projects. A CV with fifteen tools and no GitHub links is weaker than one with four tools and two documented projects. See cloud portfolio projects for ideas.
• Ignoring security and cost. Mention least privilege, secrets handling and budget alerts unprompted.
• Poor setup for remote interviews. Test your camera, microphone and screen sharing beforehand. Have a backup for power and data: a charged power bank or inverter, and a mobile hotspot in case your main connection drops. If it does drop, rejoin quickly and send a short message to the interviewer.
• Not asking questions at the end. Ask about the team's stack, how they do on-call, or what a new junior would work on in the first three months.

A six-week practice plan

This assumes about 8 to 10 hours a week alongside work or school. Use free tiers and free credits where you can, set a budget alert before you create anything, and run terraform destroy or delete resources at the end of each session. Check the official sites for current free tier terms, because they change.

Week 1: Linux and networking. Practise navigation, permissions, processes, systemd and logs every day. Use dig, curl and ss. Write answers to the Linux and networking questions above in your own words.

Week 2: Cloud fundamentals. Create an account on one provider, enable MFA and set a budget alert. Build a VPC with public and private subnets and launch a small VM serving a web page. Write a short README explaining the architecture.

Week 3: Git and Docker. Put a small app on GitHub with sensible branches and commits. Containerise it, run it locally and fix every error you hit. Keep notes of what broke.

Week 4: CI/CD and Terraform. Add a GitHub Actions pipeline that tests and builds the image. Rebuild your Week 2 infrastructure with Terraform and destroy it afterwards.

Week 5: Kubernetes basics and troubleshooting. Run your container on a local cluster (kind or minikube) with a Deployment and a Service. Deliberately break things: wrong image tag, missing environment variable, and practise diagnosing them.

Week 6: Mock interviews. Ask a friend to quiz you using this guide, or record yourself answering out loud. Do one timed take-home style task. Prepare your STAR stories and your two-minute introduction. Tidy your GitHub profile and pin your best projects.

If you want structured practice, the CloudArcade labs are built for exactly this kind of repetition.

FAQ

Do I need a certification to get a junior cloud role?

Not always, but an entry-level certification such as AWS Certified Cloud Practitioner or Microsoft Azure Fundamentals (AZ-900) shows commitment and gives you a shared vocabulary with interviewers. Hands-on projects usually matter more in the technical rounds. Check the official AWS and Microsoft sites for current exam prices and any discount offers.

How much coding do I need for a junior DevOps interview?

You should be able to read and write simple Bash and Python scripts, for example to parse a log file or call an API. You are unlikely to face hard algorithm puzzles for most junior DevOps roles, but some companies do include basic coding tests, so ask the recruiter what to expect.

Should I apply for remote roles abroad or local roles first?

Both are worth trying. Local roles can be easier to get into and give you production experience; remote roles often have more competition. Whichever you choose, strong written communication and a visible portfolio help.

What if I freeze during a live exercise?

Talk through what you are thinking, even if you are stuck. Say what you would check next. Interviewers are usually more interested in your approach than in whether you finish.

How do I explain a career switch?

Keep it short and positive: what you did before, why cloud interests you, and what you have built since. Skills from previous work, such as customer support, accounting or teaching, are often relevant to troubleshooting, cost awareness and documentation.

Get help preparing

If you want a clear plan for your next interview, help choosing between AWS and Azure, or feedback on your projects, book a free consultation with SKILL.SCH. You can also look at our courses for structured, hands-on training.