Question 1

What does DevOps actually mean to you?

Accepted Answer

Shared ownership of software from commit to production — developers accountable for how their code runs and operations engineers building the platform and automation that makes that safe. In practice it shows up as automated delivery, infrastructure as code, observability owned by the team that writes the code, and a blameless culture around failure. The answer to avoid is "DevOps is a role that does CI/CD". Interviewers listen for whether you describe it as a way of working with cultural and organisational components, and naming the four DORA metrics as how you would measure it is a strong close.

Question 2

What is a container image layer and why does layer order matter?

Accepted Answer

A Docker image is built from stacked read-only layers, one per instruction, cached and reused across builds. Order matters because a change in one layer invalidates every layer after it — so you copy dependency manifests and install dependencies before copying application source, and the frequently-changing source last. This is the single most common Dockerfile optimisation and it turns a two-minute rebuild into ten seconds. The other point is that deleting a file in a later layer does not remove it from the image, which is why secrets baked into an early layer remain recoverable.

Question 3

How do you reduce container image size and why does it matter?

Accepted Answer

Use multi-stage builds so the runtime image contains only artefacts, choose a minimal or distroless base, combine RUN commands to avoid intermediate layers, clean package manager caches in the same layer, and add a .dockerignore. It matters for pull time — which affects cold start and autoscaling speed — and for the vulnerability surface. The security argument is the stronger one: a build-tool-laden image gives an attacker a compiler and package manager inside your container. Naming distroless specifically, and that it has no shell so exec debugging changes, shows practical familiarity.

Question 4

What is the difference between CMD and ENTRYPOINT?

Accepted Answer

ENTRYPOINT defines the executable that always runs; CMD provides default arguments that can be overridden at run time. Using ENTRYPOINT with the exec form and CMD for defaults gives a container that behaves like a command with sensible defaults but accepts arguments. The exec-form point matters operationally: shell form runs the process as a child of a shell, so it does not receive SIGTERM directly and graceful shutdown silently breaks. That is a real cause of dropped requests during deployments.

Question 5

How does a container receive a shutdown signal and why should you care?

Accepted Answer

The runtime sends SIGTERM and then, after a grace period, SIGKILL. The application should stop accepting new work, finish in-flight requests and exit before the grace period. If it ignores SIGTERM — or the process is not PID 1 because of shell-form entrypoints — requests are cut off on every deploy and scale-down. This causes the low-rate 5xx blip many teams accept as normal during deployments, which is entirely avoidable. Being able to connect the platform behaviour to an application code requirement is exactly what a DevOps interviewer is testing.

Question 6

What Linux commands would you use to diagnose a slow server?

Accepted Answer

top or htop for CPU and memory, vmstat and iostat for system-wide CPU, memory, swap and disk I/O, df and du for disk space, ss or netstat for connections, dmesg for kernel messages including OOM kills, and journalctl for service logs. Then strace or perf if you need to go deeper into a specific process. Knowing that an OOM kill appears in dmesg is the practical detail that identifies "the process just disappeared" quickly. On GCP the equivalent starting point is the serial console output when the VM is unreachable, which is worth naming as the cloud-specific version.

Question 7

A disk is full but du does not account for the space. What is happening?

Accepted Answer

Almost certainly a deleted file still held open by a running process — the space is not released until the file descriptor is closed. Find it with lsof and look for deleted entries, then restart the holding process. It is usually a log file that was removed rather than rotated. This is a classic Linux question and knowing the lsof diagnosis immediately is a strong signal. The preventive answer is proper log rotation with logrotate and copytruncate, or shipping logs off the machine entirely so they never accumulate locally.

Question 8

What is the difference between a Kubernetes Deployment, StatefulSet and DaemonSet?

Accepted Answer

A Deployment manages interchangeable stateless replicas with rolling updates. A StatefulSet gives stable identities and per-pod persistent storage with ordered operations, for databases and queues. A DaemonSet runs one pod per node, for log collectors, monitoring agents and CNI plugins. The judgement to add is that a StatefulSet means you own backup, failover and upgrades for that data store, and on GCP a managed database usually beats self-managing one on Kubernetes. Recommending against a StatefulSet is often the better engineering answer.

Question 9

How does Kubernetes decide where to schedule a pod?

Accepted Answer

The scheduler filters nodes by feasibility — resource requests, node selectors, affinity and anti-affinity rules, taints and tolerations, and volume topology — then scores the remaining nodes and picks the best. If no node passes the filter, the pod stays Pending and the cluster autoscaler may add capacity. The point that matters operationally is that scheduling uses *requests*, not actual usage, so under-set requests cause overcommitment and over-set requests waste money. That single fact explains most Kubernetes capacity problems.

Question 10

What are taints and tolerations, and when have you used them?

Accepted Answer

A taint on a node repels pods that do not tolerate it; a toleration on a pod allows it to schedule there. They are used to reserve node pools — a GPU pool, a Spot pool, a compliance-isolated pool — so only the intended workloads land on them. The complementary mechanism is node affinity, which attracts pods to nodes, whereas taints repel. You usually need both: the taint keeps other pods off, and the node selector or affinity directs the right pods on.

Question 11

What is a Kubernetes Service and how does traffic reach a pod?

Accepted Answer

A Service gives a stable virtual IP and DNS name for a changing set of pods selected by labels. Traffic to the ClusterIP is redirected to a pod by kube-proxy through iptables or, in GKE Dataplane V2, eBPF. On GKE with container-native load balancing, an external load balancer targets pod IPs directly through a network endpoint group, skipping the node hop. The endpoints controller keeping the backing pod list in sync with readiness is the mechanism worth naming, because it is why a pod failing readiness stops receiving traffic without being restarted.

Question 12

What is the difference between a ConfigMap and a Secret?

Accepted Answer

Both hold key-value configuration injected as environment variables or mounted files. A Secret is intended for sensitive data and is only base64-encoded in etcd by default, not encrypted. On GKE you should enable application-layer secrets encryption with a KMS key, or better, keep secrets in Secret Manager and pull them with Workload Identity. The base64 point is what interviewers check — candidates who describe Secrets as encrypted are wrong. Naming the Secret Manager CSI driver as the production pattern shows you have solved this rather than just read about it.

Question 13

How would you debug a pod that cannot reach another service in the cluster?

Accepted Answer

Check the Service exists and its selector matches the target pod labels; check endpoints are populated, which they are not if readiness is failing; test DNS resolution from inside the pod; check NetworkPolicy is not blocking the flow; and use an ephemeral debug container or a temporary pod with networking tools to test connectivity directly. Empty endpoints from a label typo or failing readiness probe is the most common cause and it is invisible unless you look. Naming kubectl get endpoints as the specific check is what turns a list of ideas into a diagnostic path.

Question 14

What is Helm and what problem does it solve?

Accepted Answer

Helm packages Kubernetes manifests as templated charts with values files, so one chart deploys to several environments with different configuration, and it tracks releases so you can upgrade and roll back. It solves the copy-paste-YAML problem and provides versioned, shareable application packaging. The alternative worth naming is Kustomize, which overlays patches on plain manifests without templating, and is preferred by teams who dislike Go templates in YAML. Having a view on the trade-off is better than treating Helm as the only option.

Question 15

How do you handle a Git merge conflict, and how do you avoid them?

Accepted Answer

Resolve by understanding both changes rather than picking one side blindly, testing after resolution, and committing. Avoid them with small, frequent, short-lived branches, regular rebasing or merging from main, and clear ownership so two people rarely edit the same code simultaneously. The structural answer is trunk-based development with feature flags: long-lived branches guarantee painful merges. Interviewers use this question to probe working practice as much as Git mechanics.

Question 16

What is the difference between git merge and git rebase?

Accepted Answer

Merge creates a commit joining two histories, preserving exactly what happened including the branch structure. Rebase replays your commits on top of the target branch, producing a linear history but rewriting commit hashes. Never rebase a branch others have pulled, because their history diverges. The rule about not rebasing shared branches is the safety point interviewers check. A common team convention worth naming is rebasing locally before pushing to keep history readable, and merging pull requests with a squash or merge commit.

Question 17

What would you automate first in a team that does everything manually?

Accepted Answer

Whatever is most frequent, most error-prone and most painful — usually the deployment itself, because manual deployment is both risky and blocks release frequency. Then environment provisioning with Terraform, then testing, then routine operational tasks. Measure the toil to decide rather than guessing. The reasoning to state is frequency multiplied by risk, not "what is easiest to automate". Naming that you would measure where time actually goes before choosing shows you optimise for impact rather than for the satisfying project.

Question 18

Write a script to find the ten largest files in a directory tree.

Accepted Answer

Use find to list files with sizes, sort numerically and take the top ten. The equivalent for directories is du with sort. The point is comfort with composing standard tools rather than memorising a specific incantation. Interviewers ask small scripting questions to check whether you can actually operate a machine. Being able to explain each part of the pipeline — why -print0 and -z handle filenames with spaces — matters more than producing the shortest one-liner.

Question 19

How do you make a shell script safe for automation?

Accepted Answer

Start with set -euo pipefail so it exits on error, on undefined variables and on a failure anywhere in a pipeline. Quote all variable expansions, use trap for cleanup, check preconditions explicitly, log what it is doing, and make it idempotent so a re-run after partial failure is safe. Idempotency is the requirement that matters most in automation, because scripts get re-run after failures. A deployment script that appends rather than sets, or creates without checking, causes duplicates on the second run.

Question 20

What is the difference between a blue-green and a canary deployment, operationally?

Accepted Answer

Blue-green runs two complete environments and switches all traffic at once, so rollback is instant but the change is all-or-nothing and you pay for double capacity. Canary shifts a small percentage of real traffic to the new version and increases it while monitoring, so problems affect few users but the rollout takes longer and both versions run simultaneously. The requirement canary imposes is backwards compatibility, since both versions serve concurrently against the same database. Naming that constraint is what distinguishes an operational answer from a diagram-level one.

Question 21

How do you manage configuration across environments without duplicating it?

Accepted Answer

Keep a shared base with environment-specific overlays — Kustomize overlays, Helm values files, or Terraform variable files per environment — so the difference between environments is small, visible and reviewable. Secrets come from Secret Manager per environment, never from the configuration files themselves. The test of a good setup is whether you can see the entire difference between staging and production in one small diff. If you cannot, the environments will drift and staging will stop predicting production behaviour.

Question 22

What is the on-call experience you would design for a new team?

Accepted Answer

Enough engineers that the rotation is sustainable; runbooks linked from every alert; a documented escalation path; alerts that are actionable, urgent and user-affecting only; a handover process; compensation or time in lieu; and a standing agreement that a noisy alert is a defect to be fixed rather than tolerated. Tracking pages per shift as a health metric is the concrete mechanism, with a threshold above which alert tuning becomes the priority. A candidate who has been on call describes the human side unprompted, which is what this question surfaces.

Question 23

How do you introduce infrastructure as code to a team that resists it?

Accepted Answer

Start where the pain is — a repeated manual task or an environment nobody can recreate — and demonstrate value on something low-risk. Import existing infrastructure gradually rather than demanding a rewrite, provide modules so the easy path is the correct path, and pair with people rather than mandating a standard. The paved-path idea is the important one: adoption happens when the governed way is also the easiest way. Mandates without tooling produce compliance theatre, and interviewers assessing seniority listen for that distinction.

Question 24

What is the difference between imperative and declarative infrastructure management?

Accepted Answer

Imperative specifies the steps — create this, then modify that — and depends on knowing the current state. Declarative specifies the desired end state and the tool computes the difference. Declarative is preferred because it is idempotent, reviewable and converges regardless of starting state. Kubernetes manifests and Terraform configurations are declarative; a shell script full of gcloud commands is imperative. Naming that comparison makes the abstract distinction concrete and shows why the industry moved.

Question 25

How do you decide what belongs in the platform versus in each application team?

Accepted Answer

The platform owns what should be consistent and is expensive to get right repeatedly — networking, identity, delivery pipelines, observability standards, guardrails. Teams own what is specific to their product. The platform should provide paved paths rather than approval gates, so teams move quickly along the supported route. The failure mode to name is a platform team that becomes a ticket queue, recreating the bottleneck the cloud was meant to remove. Framing the platform as a product with internal customers is the framing that avoids it.

Question 26

What is the difference between a rolling restart and a rolling update?

Accepted Answer

A rolling update replaces pods with a new version, creating a new ReplicaSet. A rolling restart replaces pods with the same version — used to pick up a changed ConfigMap, Secret or to clear bad state — and is triggered by patching an annotation so the pod template changes. The gotcha it addresses is that changing a ConfigMap does not restart pods that consume it as environment variables, so the change silently does not apply. Knowing kubectl rollout restart, and why it works by mutating an annotation, is a practical detail.

Question 27

How do you handle dependencies between services during deployment?

Accepted Answer

Design so ordering does not matter: make APIs backwards and forwards compatible, use expand-and-contract for contract changes, and have services tolerate a dependency being briefly unavailable with retries and circuit breakers. Where ordering genuinely matters, express it in the pipeline explicitly rather than relying on timing. The general rule is that a deployment requiring a specific order across teams will eventually be done in the wrong order. Designing for order-independence is more robust than coordinating, and saying so demonstrates systems thinking.

Question 28

What monitoring would you set up on day one for a new service?

Accepted Answer

An uptime check from outside; SLIs for success rate and latency with an SLO and burn-rate alerting; the four golden signals on a dashboard with deployment markers; structured logs with trace correlation; Error Reporting; and an alert on the service hitting its maximum instance count or saturation limit. Starting with an external uptime check is the pragmatic first step because it catches the whole class of "the service is fine but unreachable" failures. Defining the SLO on day one is what forces the team to decide what "working" means.

Question 29

A developer asks for production access to debug an issue. How do you respond?

Accepted Answer

Ask what they need to see and provide it through logs, metrics, traces or a read-only view rather than shell access, since that solves most cases. If direct access is genuinely required, grant time-bound elevated access with an IAM condition, through IAP rather than a bastion, with an alert on the grant and a review afterwards. The response to avoid is a flat refusal, which pushes people towards shared credentials and workarounds. Offering a better path first, and a controlled path second, is what a mature platform engineer does.

Question 30

How do you keep a Kubernetes cluster up to date safely?

Accepted Answer

Enrol in a release channel — Regular for production, Rapid in a staging cluster so deprecations surface early — with maintenance windows and exclusions around peak periods. Use surge or blue-green node upgrades respecting PodDisruptionBudgets, and check deprecated API usage before each minor version with the deprecation insights. Checking deprecated API usage before upgrading is the step that prevents workloads breaking on a version bump, and GKE surfaces it directly. Running staging on Rapid is the pattern that gives you warning without risking production.

Question 31

What would you do in your first month as the DevOps engineer on an unfamiliar GCP estate?

Accepted Answer

Inventory with Cloud Asset Inventory and the billing export to find what exists and what matters; map how code reaches production; check the state of IAM, org policies and audit logging; find out what wakes people up; and talk to the teams. Then fix the highest-risk gap — usually credentials, backups or an untested rollback — rather than starting a rewrite. The instinct to understand and stabilise before changing is what interviewers assess. Naming a specific first fix — verifying that backups restore, or removing exported service-account keys — is more convincing than a general plan.

Question 32

How do you balance speed of delivery against stability?

Accepted Answer

They are not opposed: smaller, more frequent changes are easier to review, test and roll back, so high performers achieve both. Use error budgets to make the trade-off explicit — ship while budget remains, prioritise reliability when it is exhausted — so the decision is data-driven rather than an argument. Citing the DORA research finding that speed and stability correlate positively is the strongest version of this answer. The error budget as the arbitration mechanism turns a values disagreement into a policy, which is what makes it work in practice.

Question 33

What is immutable infrastructure and why does it help?

Accepted Answer

Servers and containers are never modified after deployment — to change anything you build a new artefact and replace the old one. It helps because running instances always match a tested build, configuration drift is impossible, rollback is redeploying the previous artefact, and debugging does not have to account for accumulated ad-hoc changes. The contrast is with in-place patching and configuration management, where every server's state is the result of a unique history. Naming golden images built with Packer, or containers, as the mechanism makes it concrete.

Question 34

How do you handle secrets rotation without downtime?

Accepted Answer

Support two valid credentials during the rotation window: create the new one, deploy consumers that accept both, switch producers to the new one, verify, then revoke the old. Store versions in Secret Manager and have workloads read at startup or refresh periodically, so rotation does not require a coordinated deploy. The dual-validity window is the mechanism that makes rotation non-disruptive, and it applies to database passwords, API keys and certificates alike. Teams that rotate by changing the value and redeploying everything simultaneously usually stop rotating.

Question 35

What is the difference between reliability engineering and just keeping things running?

Accepted Answer

Keeping things running is reactive — respond to alerts, restart failures, repeat. Reliability engineering is treating operations as an engineering problem: measuring with SLOs, capping toil, automating the repetitive work, and using postmortems and error budgets to change the system so the same failure cannot recur. The measurable expression is the toil cap — roughly half an SRE's time on engineering that reduces future operational load. A team where everyone spends all week firefighting is not doing reliability engineering regardless of job titles.

Question 36

How would you test disaster recovery?

Accepted Answer

Actually execute it: fail over to the secondary region in a scheduled exercise, restore a database from backup into a test instance and validate the data, and measure the real RTO and RPO against the stated objectives. Document what went wrong and fix it. Anything less than executing it leaves the objectives unverified. The line worth stating is that an untested DR plan has an unknown recovery time, which is functionally the same as having none. Restoring backups regularly is the minimum, since an unverified backup is a hope rather than a control.

Question 37

What do you look for when reviewing someone's Terraform or Kubernetes pull request?

Accepted Answer

Whether anything is being destroyed or replaced; whether permissions granted are least-privilege; whether secrets appear anywhere they should not; whether resources are labelled for cost attribution; whether the change is reversible; whether resource limits and probes are set sensibly; and whether the change matches what the description claims. Scanning the plan for destroy and replace lines first is the practical habit, because those are the lines that cause outages and are easy to miss in a long diff. Naming that as the first thing you look at is a concrete, credible answer.

Question 38

How do you decide between GKE, Cloud Run and Compute Engine for a new workload?

Accepted Answer

Start at the most managed option and step down only when a real constraint forces it. Cloud Run for stateless HTTP or event-driven containers. GKE when you need orchestration features Cloud Run lacks — sidecars beyond its support, DaemonSets, operators, complex scheduling, or an existing Kubernetes ecosystem. Compute Engine for full OS control, legacy software or specialised hardware. Naming the specific constraint that forces each step is what makes this a decision framework rather than a preference. Choosing GKE because the team likes Kubernetes, without a workload requirement, is a cost the interviewer will probe.

Question 39

Tell me about a time automation you built caused a problem.

Accepted Answer

A good answer describes real automation, the failure mode — usually acting on wrong input, running when it should not, or acting too fast to be stopped — the impact, how you detected and stopped it, and the guardrail you added afterwards: a dry-run mode, a blast-radius limit, a confirmation for destructive actions, or a rate limit. Interviewers ask this to see whether you build guardrails into automation by default. The specific lesson they want is that automation amplifies mistakes, so anything destructive needs a limit on how much damage it can do before a human notices.

Question 40

How do you keep learning in a field that changes this fast?

Accepted Answer

Depth over breadth on fundamentals — networking, Linux, distributed systems concepts — because those transfer across every platform, while service names change. Then hands-on work with new services on real problems, release notes for the products you operate, and postmortems from other organisations, which teach failure modes cheaply. The point that lands is distinguishing durable knowledge from vendor-specific detail: someone who understands TCP, DNS and consistency models learns any cloud quickly, while someone who memorised service names has to relearn everything each cycle.

GCP DevOps Engineer Interview Questions Interview Questions and Answers

How to use this set