DevOps Interview Prep

Git interview questions cover the version control system every developer touches daily — the difference between merge and rebase (and when to use each), interactive rebase for cleaning history, git bisect for finding the commit that broke a test, cherry-pick vs merge for backporting, resolving merge conflicts, Git hooks for code quality, monorepo vs polyrepo trade-offs, GitFlow vs trunk-based development, and the production scenarios interviewers love ("someone committed a secret to git — what now?"). For Maven/Gradle build-tool questions, see the Java Build Tools page.

Git is a content-addressable file system + a DAG of commits.

• Commit = tree + parent(s) + author + message.
• Branch = a movable pointer to a commit.
• Rebase rewrites history; merge preserves it. Use rebase locally, merge for the shared trunk.
• Bisect finds the bad commit in O(log n).
• Hooks + CI gates keep the trunk green.

The interview surface for this module breaks into these focus areas:

• Code quality gates — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Git internals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Git workflows — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Force-push to shared branch = destroy work; never on main.
• Rebase vs merge — rebase your feature branch, merge the PR.
• Cherry-pick — single commit across branches; good for backports.
• Reflog is the parachute — almost nothing in Git is truly lost.
• Trunk-based vs GitFlow — TBD wins for CD; GitFlow for release-train shops.

"My team works trunk-based with short-lived branches, rebases before push, merges via PR, and uses `git bisect` to find regressions. We never force-push the trunk and protect it with required checks + signed commits."

Java build tool interview questions cover Maven and Gradle in interview depth — Maven lifecycle phases, dependency scopes and conflict resolution, multi-module projects, profiles, publishing artifacts; Gradle build scripts, the dependency DSL, the wrapper, multi-module builds, incremental builds, and the Maven-vs-Gradle decision (and Bazel as the third option). Use this page for any role that touches CI builds, library publishing, or migrating between build tools.

Maven and Gradle solve the same problem differently:

• Maven — declarative XML, fixed lifecycle, batteries-included.
• Gradle — programmable Groovy/Kotlin DSL, incremental builds, configurable cache.
• Bazel — the third option for monorepos at scale.
• Wrapper (mvnw / gradlew) is non-negotiable — pin the build tool version.
• Reproducible builds — no SNAPSHOT in releases.

The interview surface for this module breaks into these focus areas:

• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Gradle build — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Maven build — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Maven scopes — compile / provided / runtime / test; mention provided for servlet APIs.
• Gradle config-cache — modern speedup; opt-in via flag.
• Multi-module builds — in Maven, include 'a','b' in Gradle.
• Dependency conflict — Maven nearest-wins, Gradle highest-version-wins.
• Publishing — mvn deploy vs gradle publish; both need credentials in settings, not in code.

"For a new Spring Boot project I'd reach for , pin the version via wrapper, manage deps with BOMs, fail the build on convergence conflicts, and publish via CI with credentials from the secret store."

CI/CD interview questions cover the pipelines that ship every modern Java backend — GitHub Actions vs Jenkins vs GitLab CI, declarative Jenkins pipelines, secret management, deployment strategies (blue/green, canary, rolling, feature flags), trunk-based development, automated rollback on SLO regression, and the production debugging questions interviewers love ("the pipeline is suddenly 4x slower — what now?"). For Terraform/IaC questions, see the dedicated Terraform page; for Jenkins-specific deep dives, see the Jenkins page.

CI ≠ CD ≠ CDeployment. Always disambiguate.

• CI — every commit builds + tests on the trunk.
• Continuous Delivery — every passing build is releasable.
• Continuous Deployment — every passing build is released.
• Pipeline stages: build → test → security scan → package → deploy → smoke → monitor.
• Rollback is a feature, not an afterthought.

The interview surface for this module breaks into these focus areas:

• Cicd fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Deployment strategies — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Github actions — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Rollback strategies — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Blue/green vs canary — full-cutover vs progressive; pick by blast radius tolerance.
• Feature flags > long-lived branches; merge quickly, expose progressively.
• Secrets in CI — short-lived OIDC tokens > static keys.
• Pipeline as code — Jenkinsfile / .github/workflows; review in PR.
• SLO-based deploy — auto-rollback on regression; the modern target.

"I'd run trunk-based with PR builds, deploy on merge to staging, gate prod on a manual approval (or auto-promote on green SLOs), use canary + auto-rollback, and feature-flag risky changes so deploys are decoupled from releases."

Jenkins interview questions cover the CI server still running half the world's Java backend pipelines — declarative vs scripted pipelines, Jenkinsfile structure, agents, shared libraries, credentials and secrets, plugin ecosystem, multi-branch pipelines, and the upgrade-and-stability concerns that come up in interviews for Jenkins-heavy shops. For broader CI/CD comparisons (GitHub Actions, GitLab CI), see the CI/CD page.

Jenkins = a job orchestrator with a pipeline DSL.

• Declarative pipeline = recommended; scripted = full Groovy.
• Agents — controllers shouldn't run jobs; pin agents by label.
• Shared libraries — code reuse across Jenkinsfiles.
• Credentials — bound at step level; never echoed.
• Multi-branch — auto-discovers branches, builds PRs.

The interview surface for this module breaks into these focus areas:

• Jenkins pipelines — drill the named patterns, the failure modes, and the recommended Java / framework idiom.

• Don't run on the controller — security + scaling.
• Plugins are the failure surface — pin versions, treat as code.
• Pipeline parallelism — parallel { ... } block; quick win for slow tests.
• Stash / unstash — workspace handoff between agents.
• Migration off Jenkins is common; but legacy hosts make it sticky.

"I'd run declarative pipelines with versioned shared libraries, pin agents by label, scope credentials per-step, and treat plugin upgrades as code review. For new shops I'd consider GitHub Actions or GitLab CI before standing up Jenkins."

Terraform and Infrastructure-as-Code interview questions cover the tool that provisions most modern cloud infrastructure — providers, resources, state management (and remote state), modules, workspaces, the plan/apply lifecycle, drift detection, secrets handling, and the patterns for multi-environment deployments. Use this page for any DevOps/SRE role where IaC ownership is part of the job spec.

Terraform = declarative infra, with state as the source of truth.

• Providers — pluggable (AWS, GCP, Azure, K8s, GitHub).
• State — terraform.tfstate, remote in S3+DynamoDB / GCS / Terraform Cloud.
• Modules — reusable units; pin versions.
• Workspaces — environment isolation (dev / stage / prod).
• Plan → apply is the immutable contract.

The interview surface for this module breaks into these focus areas:

• Terraform core — drill the named patterns, the failure modes, and the recommended Java / framework idiom.

• State locking — non-negotiable for teams; DynamoDB lock for S3 backend.
• Drift — out-of-band changes break plan; fix with import or rebuild.
• Secrets — never in .tf; pull from a vault data source.
• Destroy is permanent — always read the plan before applying.
• `terraform_remote_state` — share outputs between root modules.

"State lives remotely with locking, modules are versioned, secrets come from , environments are split via workspaces, and every change goes plan → review → apply through CI — manual `apply` from a laptop is a smell."

Docker interview questions cover the container runtime every backend engineer is expected to know — image layers and caching, Dockerfile best practices, multi-stage builds, the difference between ENTRYPOINT and CMD, networking modes, volumes and bind mounts, image security (non-root, distroless), and the Spring Boot-specific patterns (layered jars, jib). For orchestration, see the Kubernetes page.

Docker = process isolation via Linux namespaces + cgroups.

• Image = layered FS + manifest.
• Container = running instance + writable top layer.
• Multi-stage builds — separate build deps from runtime image.
• Non-root by default; distroless as the modern best practice.
• `ENTRYPOINT` vs `CMD` — entrypoint = executable, cmd = default args.

The interview surface for this module breaks into these focus areas:

• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Docker compose — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Docker fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Docker networking — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Docker security — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Multi stage builds — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Layer order matters — least-frequently-changed first.
• `.dockerignore` — both build speed and image-size win.
• `HEALTHCHECK` — declared in Dockerfile, surfaced by orchestrator.
• Spring Boot layered jars / jib — JVM-aware tooling.
• Don't run `latest` — pin tags, prefer immutable digest references.

"I'd build a multi-stage Dockerfile, base on distroless, run as non-root, declare a `HEALTHCHECK`, leverage Spring Boot layered jars for cache hits, and pin the digest in production manifests."

Kubernetes interview questions are now standard for any senior Java backend role — pods, deployments, services, ingress, ConfigMaps and Secrets, HPA and resource requests/limits, StatefulSets and persistent volumes, rolling updates and rollback, network policies, RBAC, and the production-debugging questions interviewers ask ("a pod is in CrashLoopBackOff — walk me through your debug"). Pair this page with the Docker, CI/CD and Cloud-Native pages for the full container-platform interview surface.

K8s = control loops over a desired-state spec.

• Pod is the atom; Deployment owns replica sets.
• Service = stable virtual IP; Ingress = HTTP routing.
• ConfigMap / Secret for config; PVC for storage.
• Probes — liveness restarts the pod, readiness gates traffic.
• HPA / VPA — scale on CPU / memory / custom metrics.

The interview surface for this module breaks into these focus areas:

• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Helm — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes configuration — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes networking — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes scaling — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes workloads — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• CrashLoopBackOff debug — kubectl describe for events, logs --previous for the prior crash.
• Resource requests + limits — requests reserve, limits cap; OOMKilled if you hit memory limit.
• StatefulSet vs Deployment — stable identity + ordered start; for databases, kafka.
• Network policies — deny by default, allow per-namespace.
• Helm vs Kustomize — templates vs overlays; both fine, pick one.

"I'd deploy stateless apps as a Deployment with readiness + liveness probes, set realistic requests/limits, expose via Service + Ingress, manage config in ConfigMap / Secrets, and scale with HPA on a metric that tracks user-perceived load."