Question 1

What is the difference between liveness and readiness probes, and how would you set them for a model server?

Accepted Answer

A liveness probe answers "is the process stuck?"; if it fails, Kubernetes restarts the container. A readiness probe answers "can this pod take traffic now?"; if it fails, the pod is removed from the Service endpoints without a restart. For a model server, make readiness pass only after the model has loaded, and keep liveness cheap and independent of downstream services, so slow model loading or a busy dependency does not cause restart loops. Use a startup probe or an initial delay when loading takes a long time.

Question 2

Your model-serving Docker image is 6 GB. How would you make it smaller?

Accepted Answer

Find what is taking the space with docker history or a tool such as dive. Then use a slim base image, a multi-stage build so compilers and build tools stay out of the final image, install only runtime dependencies (for example CPU-only framework wheels if you serve on CPU), clear package caches in the same layer, add a .dockerignore so data and notebooks are not copied, and keep large model files out of the image when they can be pulled from a registry or volume at start-up. Order layers so dependencies are cached before the application code.

Question 3

What do the status codes 200, 201, 202, 400, 401, 403, 404, 409, 429 and 503 mean?

Accepted Answer

200 OK, success with a body. 201 Created, a new resource was created. 202 Accepted, the request was received and will be processed later (common for webhooks and long jobs). 400 Bad Request, the input is invalid. 401 Unauthorized, missing or invalid credentials. 403 Forbidden, authenticated but not allowed. 404 Not Found. 409 Conflict, for example a duplicate or a version conflict. 429 Too Many Requests, you are rate limited. 503 Service Unavailable, a temporary server problem, often worth retrying later.

Question 4

What is the difference between merge and rebase, and when should you not rebase?

Accepted Answer

Merge joins two histories with a merge commit and keeps what happened. Rebase replays your commits on top of another branch, producing a linear history but new commit IDs. Do not rebase commits others have already pulled (shared branches), because their history diverges from yours and force-pushing can destroy their work. A common approach: rebase your own feature branch to update it, and merge (or squash-merge) into main through pull requests.

Question 5

Someone pushed a cloud access key to a Git repository. What do you do?

Accepted Answer

First revoke or rotate the key immediately, because anything pushed may already be copied, especially in public repositories. Then check audit logs for use of the key since it was pushed. Remove it from history (git filter-repo or BFG) and coordinate a force push if the repository must be cleaned, but treat that as secondary. Prevent a repeat: secret scanning in CI and push protection, pre-commit hooks, and moving the workload to short-lived credentials so there is no key to leak.

Question 6

Tell me about a production issue you handled.

Accepted Answer

Use a STAR story. Show how you detected it (alert, user report), how you limited the damage first (rollback, feature flag, scaling), how you found the root cause with evidence (logs, metrics, traces), how you communicated during the incident, and what changed afterwards (a test, an alert, a runbook, a design fix) as part of a blameless review. Interviewers look for calm prioritisation and learning, not heroics.

Question 7

How many addresses are in a /24 and a /20, and how would you split 10.0.0.0/16 into four equal subnets?

Accepted Answer

A /24 has 2 to the power 8 = 256 addresses and a /20 has 2 to the power 12 = 4,096. Cloud providers reserve some in every subnet (AWS reserves five). Splitting a /16 into four means adding 2 bits: four /18s, which are 10.0.0.0/18, 10.0.64.0/18, 10.0.128.0/18 and 10.0.192.0/18, each with 16,384 addresses.

Question 8

A service cannot reach api.partner.com. How do you narrow down the cause?

Accepted Answer

Go layer by layer. Name resolution: getent hosts api.partner.com or dig (wrong record, private DNS zone, stale cache). Routing and firewalls: can you connect to the IP and port, for example with nc -vz or curl -v ? A quick "connection refused" means nothing listens; a timeout usually means a firewall, security group, NACL or missing route (a private subnet without NAT). TLS: openssl s_client -connect host:443 -servername host for certificate and name errors. HTTP: status codes and headers. Compare with the same request from another machine.

Question 9

What is the difference between a security group and a network ACL in AWS?

Accepted Answer

Security groups attach to network interfaces (instances, load balancers, tasks), support only allow rules and are stateful: return traffic is allowed automatically. They can reference other security groups, which is the cleanest way to say "only the load balancer may reach the app". Network ACLs apply to whole subnets, support allow and deny rules evaluated in order, and are stateless, so return traffic (ephemeral ports) must be allowed explicitly. Most designs rely on security groups and keep NACLs simple.

Question 10

A user has one policy that allows s3:DeleteObject on a bucket and another that denies it on part of the bucket. What happens?

Accepted Answer

In AWS policy evaluation an explicit Deny always overrides an Allow, so deletes are denied where the Deny matches and allowed elsewhere in the bucket. Everything not explicitly allowed is denied by default. Organisations use this for guard rails (service control policies, permission boundaries) that no individual policy can override.

Question 11

How would you give a pipeline access to cloud storage securely?

Accepted Answer

Run it with its own role or service identity, not personal keys. Grant only the actions and prefixes it needs (read raw, write clean), with short-lived credentials, encryption on the bucket, public access blocked, and access logged. Keep write paths separate from trigger paths to avoid loops.

Question 12

How should a CI pipeline get credentials to deploy to the cloud?

Accepted Answer

Avoid long-lived keys stored as CI secrets. Use OpenID Connect federation: the CI platform issues a signed token for each job, and the cloud exchanges it for short-lived credentials of a role whose trust policy only accepts tokens from specific repositories and branches. Scope the role's permissions to what the deploy needs, separate roles per environment, and restrict production deploys to protected branches or approved environments.

Question 13

What is Terraform state, and how should a team manage it?

Accepted Answer

State maps resources in your code to real resources and stores their attributes, so Terraform can calculate changes. For a team, keep it in a remote backend (for example an object storage bucket) with locking so two applies cannot run at once, encryption, and restricted access, because state often contains secrets. Split state by environment and component so a mistake has a limited blast radius, and never edit state by hand; use terraform state commands or import and moved blocks.

Question 14

Someone changed a security group in the console, and now terraform plan wants to revert it. What do you do?

Accepted Answer

Find out why the change was made: if it was an emergency fix that should stay, add it to the code and apply so code and reality match; if it was a mistake, let Terraform revert it. Then address the process: restrict console write access in production, detect drift regularly (a scheduled plan that alerts on changes), and make the fast path through code quick enough that people do not need the console.

Question 15

How do you design reusable Terraform modules for many teams?

Accepted Answer

Give each module one clear purpose, a small set of documented inputs with validation and sensible secure defaults, and useful outputs. Version modules and pin versions in callers, so changes roll out deliberately. Avoid hard-coded providers, regions and names; compose small modules instead of building one giant one; and test them (validate, plan against fixtures, policy checks). Publish examples and a changelog so other teams can adopt them without asking you.

Question 16

How would you set up Terraform so changes are safe in a team?

Accepted Answer

All changes go through pull requests. CI runs fmt, validate, a security scanner and terraform plan , and posts the plan for review. Apply only from CI, using the reviewed plan, with a role that has the needed permissions, and require approval for production. Use remote state with locking, separate state per environment, and policy as code to block dangerous changes (public buckets, open security groups). Watch plans for replacements of stateful resources, and use prevent_destroy on critical ones.

Question 17

How does a request from the internet reach a pod in Kubernetes?

Accepted Answer

Typically: DNS points to a cloud load balancer, which forwards to an ingress controller (or gateway) running in the cluster. The ingress routes by host and path to a Service. The Service has a stable virtual IP and name, and forwards to the ready pods matching its selector, through kube-proxy or the CNI's data path. Readiness probes decide which pods receive traffic. Network policies can restrict which pods may talk to which.

Question 18

What are resource requests and limits in Kubernetes, and how do you set them?

Accepted Answer

Requests are what the scheduler reserves for a container and decide which node it fits on; limits are the maximum it may use. Going over the memory limit kills the container (OOMKilled); going over the CPU limit throttles it. Set requests from measured normal usage (for example around the 90th percentile) and memory limits with headroom above peak. Many teams avoid CPU limits or set them generously because throttling hurts latency. Missing requests lead to overcommitted nodes and evictions.

Question 19

What does chmod 640 mean, and what permissions would you give a file holding a service's database password?

Accepted Answer

Each digit is owner, group and others, adding read (4), write (2) and execute (1). 640 gives the owner read and write, the group read, and others nothing. For a secret, make the service's own user the owner and use 600 (or 640 with a dedicated group if another process must read it), keep it out of world-readable directories, and prefer a secrets manager that injects it at runtime.

Question 20

A service will not start because its port is already in use. How do you find out why?

Accepted Answer

ss -ltnp | grep :8080 (or lsof -i :8080 ) shows the listening process and PID. ps -o pid,user,cmd -p PID shows what it is. Often it is an old instance that did not stop, a second copy started by another unit, or a different service configured on the same port. Stop it cleanly with systemctl stop or SIGTERM, and fix the root cause, such as a duplicate unit or a missing stop in a deploy script.

Question 21

What does set -euo pipefail do in a Bash script?

Accepted Answer

-e exits when a command fails; -u treats unset variables as errors instead of empty strings; -o pipefail makes a pipeline fail if any command in it fails, not just the last. Together they stop scripts carrying on after an error, which is how scripts delete the wrong files or deploy broken builds. Know the caveats: -e is ignored in some contexts (conditions, parts of && lists), so still check important commands explicitly.

Question 22

What is the difference between a container and a virtual machine?

Accepted Answer

A virtual machine runs a full guest operating system with its own kernel on a hypervisor. A container is an isolated process on the host's kernel, using namespaces (what it can see) and cgroups (what it can use). Containers start faster and are smaller, but share the kernel, so isolation is weaker; a kernel vulnerability affects all containers on the host. That is why containers should run as non-root with minimal privileges, and why some platforms run containers inside lightweight VMs.

Question 23

What are the four golden signals?

Accepted Answer

From Google's SRE book: latency (how long requests take, separating successful and failed requests), traffic (demand, such as requests per second), errors (rate of failed requests, including wrong content) and saturation (how full the system is: CPU, memory, connection pools, queue length). Monitoring these for every user-facing service catches most problems users feel.

Question 24

How would you secure workloads running in a Kubernetes cluster?

Accepted Answer

Layer controls: RBAC with least-privilege service accounts (no cluster-admin for apps, no auto-mounted tokens where not needed); workload identity for cloud access instead of stored keys; pod security settings (non-root, read-only filesystem, no privilege escalation, dropped capabilities) enforced by admission policies; network policies that default-deny and allow only needed traffic; signed images from a trusted registry; secrets from a secrets manager; and audit logs. Keep the cluster and nodes patched.

Question 25

Tell me about a time you automated away repetitive work.

Accepted Answer

Use a STAR story. Quantify the toil before (hours per week, error rate, delays), explain how you chose what to automate and how you made it safe (tests, dry runs, rollback), how you got people to adopt it, and the result in numbers. Mention what you did not automate and why. Interviewers look for judgement and measurable impact, not just a script.

Question 26

A pod is in CrashLoopBackOff. How do you debug it?

Accepted Answer

kubectl describe pod shows events, the last state, the exit code and the reason (OOMKilled, Error, failed probes). kubectl logs pod --previous shows the output of the crashed container. Common causes: the app exits on bad configuration or a missing secret, the liveness probe fails before the app is ready, the container exceeds its memory limit (exit 137, OOMKilled), or the command is wrong. Fix the cause; do not just raise restart limits.

Question 27

What is the difference between SIGTERM and SIGKILL, and why does it matter for containers?

Accepted Answer

SIGTERM asks a process to stop; it can catch the signal, finish in-flight work, close connections and exit. SIGKILL cannot be caught and ends the process immediately. Docker and Kubernetes send SIGTERM first, wait a grace period (30 seconds by default in Kubernetes), then SIGKILL. Applications must handle SIGTERM to shut down gracefully, and the main process must actually receive it: a shell wrapper that does not forward signals makes every shutdown a SIGKILL.

Question 28

Why should containers not run as root?

Accepted Answer

By default the root user inside a container is root on the host kernel, limited only by namespaces, capabilities and security profiles. If an attacker exploits the application and then a container escape or a misconfiguration (a mounted Docker socket, a privileged container, a host path), root in the container becomes root on the host. Run as a non-root user ( USER in the Dockerfile), drop capabilities, use a read-only root filesystem where possible, and enforce this with admission policies.

Question 29

Which failed API requests should you retry, and how?

Accepted Answer

Retry transient failures: network errors, timeouts, 429 (rate limited) and most 5xx responses. Do not retry 4xx client errors such as 400, 401, 403 or 404, because they will fail again. Use exponential backoff with jitter and a maximum number of attempts, and respect a Retry-After header when present. Only retry operations that are idempotent or protected by an idempotency key. Log each attempt with a request id, and send items that still fail to a dead-letter store for review.

Question 30

A downstream service becomes slow and your whole site starts timing out. What happened and how do you prevent it?

Accepted Answer

Requests to the slow service held threads and connections while waiting, so the calling service ran out of them and started failing too, and the failure spread upstream: a cascading failure. Prevent it with timeouts on every call, a circuit breaker that fails fast when the dependency is unhealthy, bulkheads (separate pools per dependency), limited retries with backoff and jitter, and a fallback. Watch saturation metrics such as pool usage and queue length, not just error rates.

Question 31

A test fails about one run in twenty in CI. How do you deal with it?

Accepted Answer

Treat it as a bug, not bad luck. Reproduce it by running the test many times, in random order and in parallel. Common causes: shared state between tests (a database, static variables, files), dependence on time or timezone, unordered collections, real network calls, and sleeps used instead of waiting for a condition. Fix the cause: isolate state per test, inject a clock, wait on conditions with timeouts, and mock external calls. Quarantining without a fix only hides a real defect or a real race in production code.

Question 32

A server alerts that its disk is 98% full. What do you do?

Accepted Answer

Confirm with df -h which filesystem, then find the largest directories with du -xsh /* | sort -h and drill down. Usual suspects: logs, old releases, container images and volumes, core dumps. Free space safely (compress or remove old logs, docker system prune with care). If df and du disagree, a deleted file is still held open: find it with lsof +L1 and restart that process. Then fix the cause: log rotation, retention, alerts at a lower threshold, and capacity planning.

Question 33

The load average on a 4-core server is 12. Is that a problem, and how do you investigate?

Accepted Answer

Load average counts processes running or waiting for CPU, and on Linux also those in uninterruptible sleep, usually waiting for disk I/O. On 4 cores, a sustained load of 12 means work is queuing. Check top or vmstat 1 : high user or system CPU points to CPU saturation; high wa (I/O wait) and processes in state D point to slow disks or network storage. Then find the responsible processes with top , iotop or pidstat , and compare with recent changes and traffic.

Question 34

Why should you quote variables in Bash? Give an example of what goes wrong.

Accepted Answer

Unquoted variables undergo word splitting and filename expansion. If dir="my backups" , then rm -rf $dir tries to delete my and backups . If a variable is empty, rm -rf $dir/*` becomes `rm -rf /*`. Always write `"$dir" , use "${dir:?}" where an empty value would be dangerous, and run ShellCheck, which flags unquoted expansions.

Question 35

A cron job runs every 5 minutes but sometimes takes 8 minutes. What problems can this cause and how do you prevent them?

Accepted Answer

Two copies run at once and can corrupt shared files, double-process data or overload a database. Prevent overlap with a lock ( flock -n /var/lock/job.lock command ), or use a systemd timer, which will not start a unit that is still running. Also make the job idempotent, log start, end and duration, alert when it fails or runs too long, and ask whether the schedule or the job's efficiency should change.

Question 36

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

Accepted Answer

Continuous integration: every change is merged frequently and automatically built and tested. Continuous delivery: every change that passes the pipeline is releasable, and deploying is a routine, often one-click, decision. Continuous deployment: every passing change is deployed to production automatically without a human step. Each builds on the previous one and needs stronger automated testing, monitoring and rollback.

Question 37

Why should you build an artifact once and promote it through environments, rather than rebuilding for each environment?

Accepted Answer

Rebuilding can produce a different artifact (new dependency versions, a different base image), so what you tested in staging is not what runs in production. Build once, tag the image with the commit SHA and refer to it by digest, then promote the same artifact, supplying environment-specific configuration at deploy time. This also gives a clear audit trail from production back to a commit and makes rollback a matter of redeploying a previous digest.

Question 38

Your CI pipeline takes 40 minutes and developers are frustrated. How do you speed it up?

Accepted Answer

Measure first: which jobs and steps take the time. Then cache dependencies and Docker layers, run independent jobs in parallel, split slow test suites across runners, only run what a change affects (path filters, affected-project detection in monorepos), move slow end-to-end tests to a later stage or a merge queue, and fix or remove flaky tests that cause reruns. Track pipeline duration as a metric so it does not creep back.

Question 39

How does Docker layer caching work, and how should you order a Dockerfile?

Accepted Answer

Each instruction creates a layer, and Docker reuses a cached layer if the instruction and its inputs have not changed; once one layer changes, every later layer is rebuilt. Put rarely changing steps first: base image, system packages, then copying only the dependency manifest and installing dependencies, and only then copying the application code. That way a code change does not reinstall all dependencies. Use a .dockerignore so unrelated files do not invalidate the cache.

Question 40

How does a Kubernetes rolling update work, and how do you make it zero-downtime?

Accepted Answer

The Deployment creates pods of the new version and removes old ones gradually, controlled by maxSurge and maxUnavailable . For zero downtime: readiness probes so new pods only get traffic when ready, graceful shutdown on SIGTERM with a short preStop delay so load balancers stop sending traffic before the pod exits, enough replicas and a PodDisruptionBudget, and backwards-compatible changes (database migrations that both versions can use). Watch the rollout with kubectl rollout status and undo with kubectl rollout undo .

Question 41

What is an SLO, an error budget and a burn-rate alert?

Accepted Answer

An SLO is a target for a user-facing indicator, such as 99.9% of requests succeeding over 30 days. The error budget is what the SLO allows to fail: 0.1% of requests. Burn rate is how fast you are using that budget; a rate of 1 uses it exactly over the window. Burn-rate alerts page when budget is being used fast enough to matter (for example 14.4 times over one hour and five minutes) and open a ticket for slow burns, which catches real problems while ignoring brief blips.

Question 42

The on-call engineer receives 50 alerts a week and most need no action. How do you fix this?

Accepted Answer

Review every alert from the last few weeks: was it actionable, and did it need a human now? Delete alerts nobody acts on, turn cause-based alerts (high CPU) into symptom-based ones (users seeing errors or latency, ideally SLO burn rates), route non-urgent issues to tickets instead of pages, add clear runbooks to the rest, and tune thresholds and durations. Track pages per week and the share that were actionable as a team metric.

DevOps / Platform Engineer interview questions

Concepts

Coding

Case studies

Behavioural