DevOps
Interview Prep.

Whether you understand the pipeline as a real workflow, not a definition.

CI is continuously integrating code changes, every push automatically builds and runs tests so problems show up early. CD is continuously delivering or deploying that tested code, automating the path to staging or production. In my own project I set up a pipeline that ran on every push, linted, ran tests, and deployed automatically when they passed.

What makes this land is a concrete example rather than the textbook definition. I would describe the actual stages I built, on push it lints, runs tests, and if those pass it deploys, and what I learned, for example that adding caching sped up the builds, or that I added a check to stop a broken build from deploying.

Reciting 'CI is continuous integration' with no real pipeline behind it, which falls apart on the first follow-up.

“What happens in your pipeline if the tests fail?”

Debugging methodology applied to automation.

I read the pipeline logs to see which stage failed and what the actual error was, then I try to reproduce that step locally if I can. A lot of failures are a failing test, a missing dependency, or a change in the environment.

I also check what changed, because a pipeline that passed yesterday and fails today usually points at a recent commit or a dependency that moved. A common junior gotcha is 'works on my machine but fails in CI,' which is almost always an environment difference, a version, a missing environment variable, or a path.

Blindly re-running the pipeline hoping it passes, instead of reading the log and finding the cause.

“It passes locally but fails in CI every time. What is usually going on?”

A foundational concept every DevOps role expects.

A virtual machine virtualizes a whole computer including its own operating system, so it is heavier and slower to start. A container shares the host's kernel and packages just the application and its dependencies, so it is much lighter and starts almost instantly.

The practical impact is density and speed: you can run many more containers than VMs on the same hardware, and they start in seconds, which is why they fit CI/CD and scaling so well. The tradeoff is that containers share the host kernel, so isolation is not as strong as a full VM.

Saying a container is 'a small VM,' which misses the shared-kernel distinction that explains all the differences.

“Given containers share the host kernel, when might you still choose a full VM?”

Hands-on Docker basics and debugging, not orchestration depth.

I run it with docker run, check it is running with docker ps, and if it is not behaving I look at docker logs to see what it printed. If it exited immediately, the logs usually show why, a missing environment variable, a config error, or a crash on startup. If it is still running but misbehaving, I exec into that running container to look around from the inside.

My order is: is it even running or did it exit (docker ps -a shows stopped ones), then the logs for the reason, then exec in to inspect if it is still up. Common junior issues are a port not published so nothing can reach it, or an environment variable the app needs that was not passed. I read the exit code, because a container that exits cleanly versus one that crashed are different problems.

Forgetting to publish the port with -p and then wondering why the app is unreachable, or not checking logs on a container that exited.

“The container starts then immediately exits. How do you find out why?”

Real Git fluency, which every DevOps role assumes.

A merge conflict happens when two branches changed the same part of a file and Git cannot automatically decide which version to keep. Git marks the conflicting sections, and I open it, look at both versions, choose or combine the correct result, remove the markers, then stage and commit.

The habit that avoids most conflicts is pulling and integrating often rather than letting a branch drift for weeks. When I do hit one, I actually read both sides to understand the intent instead of just picking mine, because blindly keeping one side can silently drop a teammate's change. After resolving I run the tests, since a mechanically resolved conflict can still be logically broken.

Blindly accepting one side to make the conflict go away, dropping a teammate's change in the process.

“How do you reduce how often you hit merge conflicts in the first place?”

Understanding the core DevOps idea at a junior level.

Infrastructure as code means defining your servers and resources in files rather than clicking through a console by hand. You can version those files, review changes, and recreate the same environment reliably. Tools like Terraform do this.

The real wins are consistency and recoverability. If everything is defined in code, staging and production actually match, and if something is lost you can rebuild it from the definition. It also makes changes reviewable, a change to infrastructure goes through the same pull-request review as application code, so mistakes get caught before they ship.

Treating IaC as just a fancy way to create resources, missing the versioning, review, and repeatability that are the actual point.

“Why is reading the plan before applying it such an important habit?”

Security awareness at a junior level, a common eliminator when answered wrong.

I do not hardcode them in the code or commit them to the repo. I keep them out of version control, use the CI system's secret storage or a dedicated secrets manager, and inject them at runtime.

The wrong answer here is 'environment variables committed to the repo' or secrets pasted into the pipeline file, which is exactly how keys leak. Even at a junior level, knowing that a committed secret is compromised the moment it is pushed, even if you delete it later, shows the right instinct, because it remains in git history.

Hardcoding secrets or committing them, then assuming deleting them later makes them safe, they remain in git history.

“You accidentally committed an API key and pushed it. What do you do?”

The verify step, whether you confirm rather than assume.

A green pipeline is not enough on its own, I confirm the application is actually healthy after deploy: health checks pass, the key functionality works, and the logs and basic metrics look normal. If something is off, I roll back.

The deploy succeeded and the pipeline finished are different claims. The pipeline can go green while the app is broken in a way tests did not catch, so I verify from the outside, hit a health endpoint, check error rates and latency, watch the logs for a spike right after release. Having a rollback ready means I can deploy with confidence and undo fast if verification fails.

Treating a green pipeline as proof the app is healthy and moving on without checking the running system.

“Right after deploy, error rates spike. What do you do, and how fast can you undo it?”