Question 1

What is the difference between `git fetch` and `git pull`?

Accepted Answer

`git fetch` retrieves objects and refs from the remote and updates remote-tracking branches (e.g. origin/main) but leaves your working directory and current branch untouched, so it is safe to run at any time. `git pull` is shorthand for `git fetch` followed by `git merge` (or `git rebase` with --rebase), so it does change your current branch. Option D describes `git push`, not either of these commands.

Question 2

What does a container share with the host machine that a virtual machine does not?

Accepted Answer

Containers share the host OS kernel and rely on kernel features (namespaces for isolation, cgroups for resource limits) to keep processes separated. A VM instead virtualizes hardware and boots its own full guest OS and kernel on top of a hypervisor. That is why containers are lighter and start faster: there is no second kernel to boot. Containers still get isolated filesystems and network namespaces, so option B is wrong — they are isolated, just not at the kernel level.

Question 3

What does a CI/CD pipeline primarily automate?

Accepted Answer

Continuous Integration automates building and running tests every time code is pushed, catching integration problems early rather than at one large merge. Continuous Delivery extends that by automatically packaging a release that is ready to ship; Continuous Deployment goes one step further and pushes that release to production automatically once checks pass. None of this writes the code itself — it removes the manual, error-prone steps between written code and a running, verified release.

Question 4

What is the relationship between a Docker image and a Docker container?

Accepted Answer

An image is a static, versioned bundle of application code, dependencies, and filesystem layers — it does not run on its own. A container is what you get when the Docker engine runs that image: a live process with its own writable layer, network namespace, and process space. You can start many containers from the same image, and stopping a container does not delete the image it came from.

Question 5

A team adds more servers behind a load balancer to handle increased traffic, rather than upgrading a single server's CPU and memory. What is this called?

Accepted Answer

Horizontal scaling (scaling out) means adding more machines to share the load, which is exactly what a load balancer distributes traffic across. Vertical scaling (scaling up) means making one machine bigger instead — more CPU, RAM, or disk on the same box. Horizontal scaling generally has a higher ceiling and better fault tolerance, since one machine failing does not take the whole service down, but it requires the application to work correctly across multiple instances. Load shedding means dropping excess requests rather than adding capacity, and blue-green deployment is a release strategy, not a scaling technique.

Question 6

Explain the difference between a container and a virtual machine.

Accepted Answer

A virtual machine virtualizes hardware. A hypervisor (VMware, KVM, Hyper-V) sits on the physical host and lets multiple guest operating systems run on shared physical hardware, each with its own full kernel. Each VM behaves as if it has its own CPU, memory, and disk, and it boots an entire OS to get there. That isolation is strong, but expensive: every VM carries the overhead of a full OS, which means slower startup (minutes, not seconds) and a larger memory and disk footprint.

A container virtualizes at the operating system level instead of the hardware level. All containers on a host share that host's kernel; what a container gets is an isolated view of processes, network interfaces, and a filesystem, using kernel features like namespaces for isolation and cgroups for resource limits such as CPU and memory quotas. Because there is no second kernel to boot, containers start in milliseconds to seconds and are typically megabytes rather than gigabytes.

The trade-off is isolation strength versus efficiency. A VM's boundary is enforced by the hypervisor and is harder to break out of; a container's boundary is enforced by the shared host kernel, so a kernel-level vulnerability can in principle affect every container on that host. In practice, most teams use both: VMs (or bare metal) as the underlying compute a cloud provider offers, and containers as the packaging and deployment unit running on top of that compute, often coordinated by an orchestrator like Kubernetes.

Question 7

Walk through what happens in a typical CI/CD pipeline, from a developer pushing code to it running in production.

Accepted Answer

A typical pipeline looks like this, triggered by a push or a pull request:

1. Source stage: the push (or PR) triggers the pipeline via a webhook from the version control host.
2. Build stage: the code is compiled or bundled and dependencies are installed. For a containerized app this usually means building a Docker image.
3. Test stage: automated tests run, unit tests first because they are fast and cheap, then integration or end-to-end tests. Static analysis and linting often run here too. If anything fails, the pipeline stops and reports back on the commit or PR; nothing further happens until it is fixed.
4. Artifact stage: once tests pass, a versioned, immutable artifact is produced, such as a container image pushed to a registry, tagged with a commit hash or version number so it can be traced back.
5. Delivery stage: the artifact is deployed to a staging or pre-production environment, sometimes with further checks such as smoke tests or security scans.
6. Deployment stage: for continuous delivery, a human approves the promotion to production. For continuous deployment, this step is also automatic once staging checks pass. The rollout itself is usually gradual — a rolling update, a blue-green switch, or a canary that shifts a small percentage of traffic first — rather than an all-at-once cutover, so a bad release affects a limited slice of users and can be caught before it reaches everyone.
7. Observability: after deployment, monitoring and alerting watch error rates, latency, and other health signals so a regression is caught quickly, ideally triggering an automatic rollback.

The throughline is that every step is automated and repeatable, and a failure at any stage stops the pipeline rather than letting a broken change slide through.

Question 8

A new deployment just went out and error rates are spiking. How would you roll it back?

Accepted Answer

First, confirm it is actually the deployment and not something coincidental, such as a dependency outage or a traffic spike, by checking what changed around the time errors started — deployment logs, the diff between the current and previous release. If the timing lines up, do not spend time debugging the new code under pressure; roll back first and investigate after, because restoring service matters more than understanding the root cause in the moment.

The mechanics depend on how the system deploys. If deployments are immutable, versioned artifacts such as container images, rolling back means redeploying the previous known-good version — most CI/CD and orchestration tools support this as a single command, because the previous image is still sitting in the registry. If the release used a blue-green strategy, rollback can be as fast as switching the router or load balancer back to the still-running previous environment. If it was a canary rollout, rolling back may just mean shifting traffic weight back to the old version, which is fast because most traffic never left it. If a database migration shipped with the release, rollback is harder: you generally want migrations to be backward-compatible and additive rather than destructive, specifically so the old application version keeps working against the new schema until you are sure the rollback is not needed.

After rolling back, confirm error rates actually recover, communicate status to whoever is tracking the incident, and only then debug the bad release in a non-production environment. Afterward, a brief postmortem covering what broke and why it was not caught earlier — a missing test, insufficient canary time, no automated rollback trigger — turns the incident into a process fix rather than just a one-off fire.

Question 9

How would you manage secrets — API keys, database passwords, tokens — in a CI/CD pipeline and in production?

Accepted Answer

The core rule is that secrets never live in source control, not even in a private repo, because history persists, forks happen, and access lists change over time — a secret committed once should be considered compromised even if the commit is later removed.

In CI/CD, secrets belong in the CI platform's own secret store, such as GitHub Actions secrets or GitLab CI/CD variables, or in a dedicated secrets manager like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. The pipeline injects them as environment variables or mounted files at run time, scoped to only the jobs that need them, and most CI platforms mask them in logs so a stray print statement does not leak them.

In production, the same principle applies: the running application reads secrets from a secrets manager or from environment variables injected by the orchestrator, such as Kubernetes Secrets, rather than from a config file baked into the image or checked into the repo. Kubernetes Secrets are only base64-encoded by default, so they should be backed by real encryption at rest or an external secrets operator.

Beyond storage, a few practices matter: rotate secrets periodically and immediately after any suspected exposure; give each service its own scoped credentials rather than one shared master key, so a compromise is contained; and use short-lived credentials where possible, such as cloud IAM roles instead of long-lived access keys, so a leaked credential has a small window of usefulness. If a secret does leak into git history, rotating it is mandatory — rewriting history to remove it is not sufficient on its own, since it may already have been cloned or cached elsewhere.

Question 10

What is infrastructure as code, and why do teams use it instead of configuring servers by hand?

Accepted Answer

Infrastructure as code (IaC) means defining infrastructure — servers, networks, load balancers, databases, permissions — in configuration files, using tools like Terraform, AWS CloudFormation, or Pulumi, that a tool applies to create or update real resources, rather than someone clicking through a cloud console or connecting in to run commands by hand.

The main benefit is that the config files become the source of truth and get the same treatment as application code: version control, code review, and a history of who changed what and why. That solves a real problem with manual configuration, sometimes described as treating servers as pets rather than cattle — over time, hand-configured servers accumulate undocumented, inconsistent changes until nobody is quite sure what is actually running or how to reproduce it if it is lost.

IaC also makes infrastructure repeatable: the same configuration can stand up an identical staging environment, rebuild production after a disaster, or spin up a temporary environment for a pull request, without a person re-deriving the steps from memory or stale documentation. Most IaC tools support a plan or dry-run step that shows exactly what will change before it is applied, which catches mistakes before they hit real infrastructure.

The trade-off is upfront investment: learning the tool, writing and reviewing the configuration, and handling state carefully, since most IaC tools track what they have created in a state file, and that state can drift from reality if someone changes things outside the tool. For anything beyond a single throwaway server, most teams find that cost worth it fairly quickly.

DevOps & Cloud Interview Questions

Put this into practice