All jobs / Full-stack developer
DevOps Basics interview questions
DevOps Basics questions a Full-stack 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.
A new developer spends two days getting the API, the database and the web client running on their laptop.
What would you set up so that the next one does not?
The strongest answer: A compose file that starts the database, the API and the client with one command and a little seed data, with versions pinned, so everybody runs the same stack
Why it works: Exactly — one command, real dependencies, pinned versions. Onboarding becomes a check that the stack starts, not a treasure hunt.
- One command to the whole stack.
- Real database, seeded data.
- Pin versions for everyone.
- Never pass .env files around.
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.
Someone wants to put the API URL and the database password in `.env` for Vite.
What can go in the frontend env?
The strongest answer: The public API base URL — anything in a `VITE_` / `NEXT_PUBLIC_` variable is visible in the downloaded JS
Why it works: Exactly. Frontend env is not a secret store. Put only what a stranger with View Source may see.
- Frontend env is public by construction.
- API origin, feature-flag client key — maybe.
- Database, payment, admin tokens — never.
- If it must stay secret, it never ships in JS.
A user says 'save failed'. You have UI logs and API logs and no join.
How do you trace one click?
The strongest answer: A request id (or `traceparent`) the UI sends or echoes, the API logs, and the error screen can show — one string across browser, gateway and service
Why it works: Exactly. Correlation is a header, not a hunt. W3C Trace Context is the 2026 default; a UUID you log both sides is the minimum.
- One id on the way in, the same id in every log.
- Prefer `traceparent`; accept a `X-Request-Id`.
- Show it on the error screen so support can search.
- Do not debug prod with email and a clock.
You are deploying a SPA and its API for the first time on the same domain.
How do you host them?
The strongest answer: Hashed static assets on a CDN, `index.html` with a short cache, API on its own origin or path, and a fallback so deep links do not 404 on refresh
Why it works: Exactly. The SPA refresh problem and the cache problem are deploy problems. Split asset cache from HTML; give the API a real origin.
- CDN for hashed JS/CSS; short TTL for HTML.
- API uncached or explicitly cached.
- Server fallback to `index.html` for client routes.
- Do not freeze HTML and API on the asset TTL.
The application image is over a gigabyte and takes several minutes to pull on every deploy.
How do you make it smaller, and what should not be in it at all?
The strongest answer: A multi-stage build: compile in a stage that has the toolchain, then copy only the built output and the runtime dependencies into a slim base — source, dev dependencies, caches and credentials stay behind
Why it works: Exactly — the build environment never ships. Smaller images pull faster, start faster and give a scanner less to find.
- Build stage, then runtime stage.
- Copy only the built output.
- Deleted layers still weigh.
- No secrets baked into images.
APM shows fast API spans. Users still wait two seconds after click.
How do you see one click in the tracer?
The strongest answer: The browser starts or continues a W3C `traceparent`; the BFF and API create child spans; the UI error shows the trace id
Why it works: Exactly. User-perceived latency is a frontend span plus everything after. Breaking the parent at the edge is how you never see the join.
- Propagate `traceparent` from the click.
- One trace, many spans, including the BFF.
- Surface the id to support.
- Do not start a fresh root on every hop.
The pipeline builds the client three times, once per environment, because the API URL is baked in at build time.
What do you change, and what stays at build time?
The strongest answer: Build once and promote that artifact: the client reads its API URL and flags at runtime from a small config the server serves, so what you tested ships — and no secret goes in either
Why it works: Right — one artifact through every environment; a build per environment means production runs a binary nobody tested.
- Build once, promote the artifact.
- Configuration arrives at runtime.
- Test the bytes you will ship.
- No secrets in the client, ever.
A feature flag has been on for everyone for four months. Both code paths are still there.
When is the flag done?
The strongest answer: When the new path is default, the old path is deleted on both sides, and the flag key is gone from the catalogue — a permanent flag is a second codebase
Why it works: Exactly. Flags are rental. The ticket is not done at 100% — it is done when the dead branch is gone from JS and API.
- Launch, soak, delete both sides.
- 100% is the start of cleanup.
- A flag in only one layer is a trap.
- Catalogue hygiene is part of the feature.
Prod: 'submit does nothing'. API dashboards look calm. The SPA error rate ticked up after a mixed deploy.
Where do you start?
The strongest answer: Reproduce with the request id, then ask whether the HTML, the JS version, the BFF and the service agree on the same contract — do not start by blaming 'the frontend' or 'the backend'
Why it works: Exactly. Staff debugging is locating the join that broke. Version of the bundle, payload, status, span — then a team. Layer-blame is how you lose the first hour.
- Get the id, the bundle, the payload.
- Compare what each layer thought the contract was.
- Blame the join, then the owner.
- Do not reboot your way past evidence.
API 5xx is 0.1%. Users still report 'save failed' because the SPA cannot reach a new path.
Which errors go in the SLO?
The strongest answer: The ones the user saw fail — including 200 HTML that then cannot load its API, client timeouts, and 499s — not only the API's 5xx rate
Why it works: Exactly. Fullstack reliability is user-perceived. A green API behind a broken bundle is an outage. A health check that never runs the SPA is a night-light.
- SLO the journey, not the process.
- Count failed checkouts the user hit.
- Exclude expected 4xx.
- Browser RUM plus API traces, not only `/health`.
Platform wants daily UI deploys and weekly API deploys from the same repo.
When may UI and API ship on different clocks?
The strongest answer: When the contract is additive, the window is explicit, and each side can roll back alone — lockstep only when you are mid-contract
Why it works: Exactly. Independent deploys are earned by compatibility. A monorepo is a source layout, not a release train. Lockstep is a tool you pick for a breaking hour, not a lifestyle.
- Independent when the wire stays compatible.
- Lockstep for the breaking hour only.
- Monorepo ≠ monolith release.
- Rollback each side without the other when you can.