Deployment Basics interview questions
Deployment Basics questions a Backend developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What is the difference between a region and an availability zone?
The strongest answer: A region is a geographic area with several availability zones; each zone is one or more separate data centres with its own power and network, so spreading across zones survives a data-centre failure
Why it works: Right. The zone is the fault boundary you design around; the region is where your data lives.
- Region: a geography with multiple zones.
- Zone: isolated power, cooling and network.
- Spread across zones for availability.
- Spread across regions for disaster recovery.
IaaS, PaaS, SaaS — what does each one leave to you?
The strongest answer: IaaS gives you machines and networks and you run everything on them; PaaS runs the platform and you bring code and data; SaaS is a finished application you configure
Why it works: Exactly. The line that moves is who patches, scales and operates the layer underneath.
- IaaS: VMs, disks, networks — you run the rest.
- PaaS: bring code and data, the platform runs it.
- SaaS: a finished product you configure.
- The difference is who operates each layer.
When would you use object storage rather than a block volume?
The strongest answer: For files you read and write whole over HTTP — uploads, backups, static assets, data-lake files — because object storage is durable, cheap and shared, while a block volume is a disk attached to one machine
Why it works: Right. Whole-object access, shared, durable and cheap; a disk is for a filesystem or a database.
- Object: whole files over HTTP, shared, cheap, durable.
- Block: a disk for one machine's filesystem or database.
- Pick by access pattern, not by speed.
- Static assets and backups belong in object storage.
You create a new storage bucket for user uploads. Who can read it by default, and what should you check?
The strongest answer: Nobody outside your account — buckets are private by default; check that public access stays blocked and grant access through the application's role or signed URLs, never by making the bucket public
Why it works: Right. Private by default, and keep it that way; a signed URL is how a user gets one file.
- Buckets are private by default.
- Keep public access blocked at the account level.
- Serve user files by signed URL or through a role.
- A public bucket of uploads is a data breach waiting.
What is the difference between an IAM user and an IAM role?
The strongest answer: A user is a permanent identity with long-lived credentials for a person; a role is a set of permissions any trusted identity — a service, a machine, a person — assumes temporarily, and workloads should use roles rather than keys
Why it works: Exactly. Temporary credentials via roles are why you never bake access keys into a server.
- User: long-lived identity, for a person.
- Role: assumed temporarily by a trusted principal.
- Workloads get roles, never stored keys.
- Temporary credentials limit the blast of a leak.
A security group allows inbound port 443. Do you also need an outbound rule for the responses?
The strongest answer: No — security groups are stateful, so return traffic for an allowed connection is permitted automatically; a network ACL, by contrast, is stateless and would need both directions
Why it works: Right. Stateful means the response follows the request; NACLs are where both directions are written.
- Security groups are stateful.
- Network ACLs are stateless.
- Return traffic for allowed connections is automatic.
- Write both directions only in a NACL.
What is a VPC, in one sentence?
The strongest answer: A private, isolated network you define inside the cloud — your own address range, subnets, route tables and gateways — where your resources live and which decides what can talk to what
Why it works: Exactly. It is the network boundary everything else sits inside.
- Your own isolated network in the cloud.
- Subnets, route tables, gateways.
- Decides what can reach what.
- Everything else is placed inside it.
Why put a load balancer in front of two web servers instead of pointing DNS at one?
The strongest answer: It spreads traffic across healthy servers, drops a server that fails its health check, ends TLS in one place and lets you add or replace servers without touching DNS
Why it works: Right. Availability, health checking and a stable front door are the reasons.
- Distributes across healthy servers.
- Removes a failing server via health checks.
- One place to terminate TLS.
- Add and replace servers behind a stable address.
What does autoscaling actually do, and what does it not do?
The strongest answer: It adds or removes identical instances according to a metric or schedule so capacity follows demand; it does not make a single slow request faster or fix an application that cannot run as more than one copy
Why it works: Exactly. Horizontal, metric-driven, and it assumes the app is stateless enough to copy.
- Adds and removes copies on a metric.
- Assumes the app runs as many identical copies.
- Throughput, not per-request speed.
- Not a fix for leaks or single-copy apps.
Why choose a managed database service over running the database yourself on a VM?
The strongest answer: Backups, patching, failover and monitoring come with it, so a small team gets reliability it would struggle to build; you pay more per hour and give up some low-level control
Why it works: Right. You are buying operations you would otherwise have to staff.
- Managed: backups, patching, failover included.
- You pay for operations you do not have to staff.
- Less low-level control.
- Self-hosted only when you need what managed cannot do.
What is a cold start in a serverless function?
The strongest answer: The delay when a function runs on an instance that has to be created first — code loaded, runtime started — so the first request after idle is slower than the ones that follow
Why it works: Right. It is why latency-sensitive paths keep instances warm or use provisioned concurrency.
- A fresh instance must start before it can serve.
- First request after idle pays the cost.
- Smaller packages and warm instances reduce it.
- Matters most on user-facing paths.
Cloud is pay for what you use. What is the cost people forget most often?
The strongest answer: Data transfer out — egress to the internet or between regions is billed per gigabyte, so a chatty design or a big download feature can cost more than the compute behind it
Why it works: Right. Egress is the line that surprises new teams; keep data near its consumers and cache at the edge.
- Egress is billed per gigabyte.
- Cross-region traffic counts too.
- Idle resources bill while they exist.
- Design to keep data near where it is read.
The interviewer asks: “How do you log from a service in production?” Strongest answer?
The strongest answer: A logger with levels, a request id, and no secrets in the message. Console.log / print is for a local experiment, not the traffic path.
Why it works: Exactly. Structured logs + correlation id beat a wall of prints. Levels let you turn debug on without shipping secrets.
- Logger, levels, request id.
- Stdout is the sink; structure is the format.
- Don't log bodies or secrets.
- print is not production observability.
The interviewer asks: “Liveness versus readiness — what do you expose?” Strongest answer?
The strongest answer: Liveness: is this process up? Readiness: can it take traffic (database, critical deps)? A failing ready probe should stop new traffic, not necessarily kill the pod.
Why it works: Exactly. Kubernetes (and load balancers) use them differently: not-ready = drain; not-live = restart. Mixing them causes flapping or black holes.
- Live = process; ready = can take traffic.
- Fail ready to drain, not to suicide-loop.
- Keep ready checks cheap.
- Never lie 200 on health.
The interviewer asks: “A user says checkout failed at 16:02. How do you find it in logs?” Strongest answer?
The strongest answer: A request / correlation id on every log line and in the error body I showed them. I search that id, not “checkout” around 16:02.
Why it works: Exactly. Propagate the id from the gateway through services. That's the difference between 30 seconds and an afternoon.
- Put a request id on logs and errors.
- Search the id, not the clock.
- Don't debug-log the world.
- Never log payment secrets.
The interviewer asks: “How do you observe a production service?” Strongest answer?
The strongest answer: All three: metrics for SLIs (latency, traffic, errors, saturation), traces for a single request across services, logs for the details. I correlate them with a trace id — I don't pick a favourite pillar.
Why it works: Exactly. RED/USE metrics tell you it is broken; traces tell you where; logs tell you why. OpenTelemetry is the 2026 common language.
- Metrics page; traces locate; logs explain.
- One trace id across the path.
- SLIs are user-facing, not just CPU.
- Sample and retain on purpose.
The interviewer asks: “A request touches four services. How do you see the whole path?” Strongest answer?
The strongest answer: Propagate W3C trace context (traceparent) on every outbound call and queue message, sample consistently, and view one trace. I don't invent a new id per hop.
Why it works: Exactly. One trace id, parent spans, baggage if you must. That's what the APM is for.
- One trace id across hops.
- W3C traceparent on HTTP and messages.
- Don't join by timestamp.
- Don't put access tokens on the bus.
The interviewer asks: “Kubernetes sent SIGTERM. What does your process do?” Strongest answer?
The strongest answer: Fail readiness immediately, drain in-flight requests within the terminationGracePeriod, close the listener, then exit 0. I don't die mid-write and I don't ignore the signal.
Why it works: Exactly. That's graceful shutdown: stop new traffic, finish old, then go. Pair it with a ready probe that already flipped.
- SIGTERM → not ready, then drain.
- Finish in-flight work; stop accepting new.
- Exit cleanly before SIGKILL.
- Don't crash and don't ignore the signal.
The interviewer asks: “We want 99.9% availability. What does that change in the team?” Strongest answer?
The strongest answer: It becomes an SLO with a measured SLI and an error budget. We page on burn rate, not on vibes, and we spend the budget on change — or freeze when it's gone. I don't promise 99.9% without a denominator.
Why it works: Exactly. An SLO is a contract: good events over total events. The budget tells you whether to ship or to stabilise. That's SRE practice, not a poster.
- SLO = SLI + target + window.
- Error budget drives ship vs freeze.
- Alert on burn, not every 5xx.
- Don't round the truth to 100%.
The interviewer asks: “Production is down. Who does what in the first fifteen minutes?” Strongest answer?
The strongest answer: One incident commander owns decisions and comms; others investigate. Mitigate first (rollback, shed load, failover), then cause. Status to users on a clock. Blameless notes after — not a hunt in the channel.
Why it works: Exactly. Command, mitigate, communicate, then learn. That's how you stop a fifteen-minute outage becoming a two-hour pile-on.
- One commander; mitigate before archaeology.
- Comms on a clock.
- Don't wait for “who shipped.”
- Blameless outside and inside.
The interviewer asks: “A new ranking feature is burning CPU in production. What do you want already built?” Strongest answer?
The strongest answer: A kill switch / feature flag that turns it off without a deploy, with a default-safe value if the flag service is itself down. I don't wait for a rollback to compile.
Why it works: Exactly. Flags are an operational control. Fail-safe defaults matter as much as the flag. That's how you stop a bleed in minutes.
- Ship a kill switch with the feature.
- Default safe if flags are unavailable.
- Rollback is slower than a flag.
- Don't make the flag service a SPOF.
The interviewer (as hiring manager) asks: “How do you interview for on-call readiness?” Strongest answer?
The strongest answer: Give a realistic incident: metrics that lie, a bad deploy, a dependency timeout. Listen for mitigate-first, communication, and what they'd change after — not for a perfect root cause in ten minutes.
Why it works: Exactly. On-call is a skill you can sample: composure, hypothesis order, and respect for users. The postmortem instinct is the senior signal.
- Sample an incident, not a quiz.
- Score mitigate, comms, follow-through.
- Shadow before solo on-call.
- Hire system-fixers, not martyrs.
The interviewer asks: “The last outage was fixed by one person who “just knew.” What do you change?” Strongest answer?
The strongest answer: A runbook: symptoms → checks → mitigate → escalate, plus dashboards that match it. I rotate the next incident through someone else with the author on voice — heroics are a bus factor, not a strategy.
Why it works: Exactly. Operability is a deliverable. If only one brain can mitigate, you don't have a system — you have a dependency on a human.
- Write the mitigate path down.
- Practice it with someone else.
- Don't centre the hero on every page.
- Runbooks over folklore.
The interviewer asks: “How do you know failover works?” Strongest answer?
The strongest answer: I run it: game days or controlled chaos — kill a pod, a zone, a dependency — in a budgeted window, with a rollback. An untested runbook is a story. I don't first-discover failover during a real incident.
Why it works: Exactly. Rehearsal builds the muscle and finds the lie in the diagram (DNS TTLs, sticky sessions, a split brain). That's why serious teams game-day.
- Rehearse failover on purpose.
- Config ≠ a tested behaviour.
- Don't wait for the real incident.
- Chaos needs a commander and a blast radius.