DevOps Interview Questions for Freshers

Use these questions to practise walking through an application you have actually built or operated in a learning environment. They are written for freshers in India and for developers, testers and support engineers moving towards DevOps. For each question we note what a strong answer shows and what a weak answer sounds like. The common thread is that interviewers want evidence you understand how software reaches production and how it fails, not a list of tools you have heard of.

Delivery and pipelines

What happens after a code change?

Describe the branch, the review, the automated checks, the artifact, the release and the observation afterwards. State which parts are automated and which need a person.

A strong answer walks through a real pipeline you built and names the human decision points. A weak answer assumes continuous integration means automatic production deployment.

A pipeline fails. How do you investigate?

Identify the failing step and compare it with the previous successful run. Inspect the relevant log without exposing secrets. Check code, dependencies, environment and permissions, in that order or with a reason for a different order.

A strong answer distinguishes a transient failure from a reproducible one. A weak answer is "I would rerun it".

What is the difference between continuous integration, continuous delivery and continuous deployment?

Integration runs checks on every change. Delivery keeps every passing build ready to release with a human decision. Deployment releases automatically. Explain which one your project uses and why.

A strong answer ties the choice to risk and team size. A weak answer uses the three terms interchangeably.

How do you know a release succeeded?

A successful upload or deployment command is not enough. Verify the intended version is running and the relevant application behaviour works. Use health checks and observation appropriate to the service.

A strong answer names a specific check. A weak answer trusts the green tick.

Containers and configuration

What is the difference between an image and a container?

An image is the packaged definition used to create a runtime instance; a container is an instance running from it. Explain what configuration is supplied separately and where persistent data lives.

A strong answer mentions volumes and environment variables. A weak answer says they are the same thing.

Why keep configuration outside the image?

So the same image can run in development, staging and production with different settings, and so secrets never end up baked into a layer that is shared or pushed to a registry.

A strong answer refers to a case where it mattered. A weak answer cannot say what would go wrong.

How do you manage secrets?

Keep them outside source code, images and public logs. Use the environment's approved secret mechanism and grant only the access needed. If a secret was committed, deleting the line alone does not erase history or make the credential safe again; it must be rotated.

A strong answer says "rotate". A weak answer says "delete the line".

What would you check if a container keeps restarting?

Read its logs, check the exit code, confirm the start command and environment variables, check resource limits and verify that dependencies such as a database are reachable.

A strong answer follows an order and explains it. A weak answer suggests rebuilding the image first.

Linux, Git and networking

A service is slow. Where do you look on a Linux host?

CPU, memory, disk and network, in some order, with commands you have actually used. Then the application's own logs. Then recent changes.

A strong answer names tools and what each tells you. A weak answer says "I would check the server".

Explain a merge conflict and how you resolve one.

Two branches changed the same lines. Git marks the region; you choose or combine the changes, test, and commit. Explain how you avoid them with smaller, more frequent merges.

A strong answer includes prevention. A weak answer describes it as something scary that happened once.

What is DNS, and what breaks when it is wrong?

DNS maps names to addresses. If a record is wrong or has not propagated, users reach the wrong place or nothing, even though the service itself is healthy.

A strong answer mentions time-to-live. A weak answer stops at the definition.

Operations and reliability

Is rollback always safe?

No. A prior code version may be incompatible with changed data or configuration, and some actions, such as sent emails or external payments, cannot be undone. Explain what your rehearsal covered and which dependencies need separate consideration.

A strong answer talks about database migrations. A weak answer says yes.

What is the role of monitoring?

Monitoring helps detect conditions and understand behaviour. An alert should have a useful action and an owner; collecting many signals without a response plan creates noise and fatigue.

A strong answer gives one alert you set and why. A weak answer lists metrics.

What would you do in the first ten minutes of an incident?

Confirm the impact, tell people, look at what changed recently, and decide whether to roll back or fix forward. Write down times as you go. Root cause comes later.

A strong answer prioritises restoring service and communication. A weak answer starts debugging in silence.

How to talk about your project

Prepare a three-minute version. Walk through one intentionally failed release in a local or staging environment: the trigger, the observed symptoms, the diagnosis and the recovery evidence. Show the pipeline file and explain each step in one sentence. Mention one trade-off you made and one thing you would change.

Be precise about your experience. A learning project can demonstrate useful habits without being described as production operations at scale. If you have operated anything in a real job, even a shared test server, say so plainly and describe what you were responsible for.

Questions to ask the interviewer

• How does a change reach production here, and how long does it typically take?
• What does on-call or support look like for this team?
• Which parts of the pipeline are owned by this team and which by others?
• How are incidents reviewed afterwards?
• What would a new joiner be expected to learn in the first three months?

Questions about incidents and ownership show you think about operations, not only tools.

Free practice resources

The Linux Foundation's free Introduction to Linux and Introduction to DevOps and Site Reliability Engineering courses cover vocabulary and fundamentals. The Pro Git book and GitHub Skills are free for Git and pipelines. Docker's getting-started guide and the GitHub Actions documentation are enough to build the project you will be asked about.

How GullyMentor approaches it

On the DevOps track (/career-tracks/devops) a mentor asks these questions about your own repository and pipeline, pushes back where an answer is vague and makes you repeat it until it is clear. We sell no courses; rehearsal with someone who has operated real systems is the point. We do not guarantee jobs, interviews or salaries.

Sources & further reading

• Docker getting started
• GitHub Actions concepts
• Linux Foundation: Introduction to Linux (free course)
• Linux Foundation: Introduction to DevOps and Site Reliability Engineering (free course)
• Pro Git book (free online)
• GitHub Skills (free hands-on courses)

Examples and practice recommendations are educational illustrations. Tool documentation and programme inclusions should be checked for your intended use.