DevOps Interview Questions and Answers

sudo lsof -i :<port> or sudo netstat -tulpn | grep <port> — both show the process ID bound to that port, which you can then inspect with ps -p <pid> or kill with kill <pid>.

Check the actual cron schedule syntax first — a day-of-week field typo is the most common cause of this exact symptom. Also check whether a weekend maintenance window (backups, a different cron user's job) is competing for a resource the job needs, and confirm the cron daemon's timezone matches what you assumed when writing the schedule.

Run it in the background and let the deploy proceed independently if ordering allows, use `find` with `-exec` and parallelism (or `xargs -P`) instead of a single recursive command, or — better — avoid needing a mass permission fix at deploy time at all by getting the base image/provisioning to create files with correct ownership from the start.

A forward proxy sits in front of clients, making requests on their behalf to the internet (hiding the client from the server) — common for corporate outbound filtering. A reverse proxy sits in front of servers, receiving client requests and routing them to backend services (hiding the servers from the client) — like Nginx or an ALB in front of an application.

Check for port exhaustion — under heavy outbound connections (e.g., to a database or external API), the OS's ephemeral port range can run out, especially with short-lived TCP connections not using keep-alive. Check the server's file descriptor limits and TCP connection backlog (somaxconn) too — both are common bottlenecks that only appear under real load.

TLS 1.3 removes several outdated, insecure cipher suites (simplifying secure configuration), requires forward secrecy by default, and completes its handshake in one round trip instead of two — meaning less latency on new connections. Practically, it means fewer cipher-suite decisions to get wrong and a small but real performance win.

It lets you control how Git treats specific files or patterns — a common practical use is normalizing line endings consistently across a team working on Windows and Linux/macOS, so line-ending differences don't show up as noisy diffs on every file someone touches.

Merge the smaller, unrelated bot PRs into main first and regularly rebase or merge main into the large feature branch incrementally, rather than letting the feature branch sit untouched for weeks and facing one enormous conflict resolution at the end. Smaller, frequent syncs are far cheaper than one large one.

It adds a manual approval gate before a GitHub Actions job can deploy to that environment (like production) — the workflow pauses and waits for an authorized reviewer to approve, giving a deliberate human checkpoint on an otherwise fully automated deployment pipeline.

`os.system()` just shells out and gives you the exit code — no easy access to stdout/stderr, and it's vulnerable to shell injection if you build the command from user input. `subprocess.run()` gives you captured output, separate stdout/stderr, timeouts, and (when you pass a list instead of a shell string) avoids shell injection entirely.

Use concurrent.futures.ThreadPoolExecutor (or asyncio with an async HTTP client) to fire the independent API calls concurrently instead of one after another — since the bottleneck is I/O wait, not CPU, threads/async give a real speedup here without needing multiprocessing, which is for CPU-bound work.

Automation scripts often end up running unattended in production-critical paths (deploys, backups, data migrations) despite their humble origins — a test catches a regression before it runs unsupervised against real infrastructure, which matters just as much as it would for any other piece of production code, regardless of how the script started out.

Continuous delivery means every change that passes the pipeline is ready to deploy, but a human still approves the release. Continuous deployment goes further — every passing change deploys to production automatically, no manual gate.

A documented, rarely-used manual deployment runbook — exact commands or a break-glass script that can push a known-good build directly, bypassing the CI platform — tested occasionally so it's not the first time anyone's tried it during an actual emergency, when it matters most.

It shows exactly what the tool would do (which resources would change, which version would deploy) without actually making the change — letting you review a pipeline's intended action before committing to it, similar in spirit to reviewing a `terraform plan` before an `apply`.

If an attacker breaks out of the application, running as root inside the container makes a container-escape far more damaging, and root inside often maps to root-equivalent access on the host in misconfigured setups. Fix it by creating a non-root user in the Dockerfile (`RUN useradd -m appuser`) and switching to it with `USER appuser` before the app runs.

It defines a command Docker runs periodically to determine if the container is actually working, not just running. Orchestrators (like Kubernetes or Docker Swarm, or `docker ps` itself) use this status to decide whether to route traffic to the container or restart/replace it if it's marked unhealthy.

`--memory` and `--cpus` (or the equivalent `resources.limits` in an orchestrator) set hard caps enforced by the kernel's cgroups — the container is killed (OOM) or throttled if it exceeds these, rather than being able to consume unlimited host resources and degrade every other workload sharing that machine.

A ResourceQuota per namespace capping total CPU/memory requests and limits (and often object counts), combined with a LimitRange to set sane per-Pod defaults so individual Pods can't request unreasonable amounts within that quota.

Both store key-value configuration, but Secrets are intended for sensitive data — base64-encoded (not encrypted by default, though clusters can add encryption-at-rest) and treated differently by RBAC and tooling to reduce accidental exposure (like not showing values in `kubectl describe` output the way ConfigMap values are shown). Using a ConfigMap for genuinely sensitive data bypasses those protections entirely.

`RollingUpdate` replaces Pods gradually, keeping some old and new versions running simultaneously during the transition. `Recreate` terminates all old Pods before creating new ones, guaranteeing no overlap — the right choice for an application that genuinely cannot run two versions simultaneously (like one holding an exclusive lock or lease that a second instance would conflict with).

Vertical scaling means making one machine bigger (more CPU/RAM) — simple but has a hard ceiling and usually needs downtime. Horizontal scaling means adding more machines and spreading load across them — the cloud is built for this (auto-scaling groups, managed Kubernetes), since it removes the ceiling and improves fault tolerance at the cost of needing a stateless or coordinated-state design.

A region is a geographic area (e.g., `us-east-1`); each region contains multiple availability zones — physically separate data centers with independent power/networking, close enough for low-latency replication. Spreading resources across AZs protects against a single data center failure; spreading across regions protects against a regional outage (and helps with latency to different user bases).

Start with visibility (tag resources by team/project, use the cost breakdown tools) before changing anything, then look for the low-risk wins first — rightsizing over-provisioned instances based on actual utilization data, cleaning up unattached storage/unused resources, and moving eligible steady-state workloads to reserved/committed pricing — before touching anything architecturally risky.

Run EC2 instances (or ECS/EKS tasks) in an Auto Scaling Group spread across at least two AZs, behind an Application Load Balancer that health-checks and routes only to healthy instances. Use a Multi-AZ RDS database for automatic failover, and store session state outside the instances (e.g., in ElastiCache or DynamoDB) so any instance in any AZ can serve any request.

A Region is a full-scale data center cluster running general-purpose compute (EC2, RDS, etc.). An Edge Location is a smaller CloudFront/Route 53 point of presence used for caching content and resolving DNS closer to end users — it doesn't run general compute the way a Region does.

Add the column as nullable (or with a default) first, deploy application code that handles both old and new schema, backfill existing rows in batches to avoid long locks, then add the NOT NULL constraint only after the backfill completes. Adding a NOT NULL column with no default directly locks the table for the full rewrite.

A hub-and-spoke topology: a central hub VNet (often in a dedicated networking subscription) peered to each application's spoke VNet in its own subscription. Shared services like a firewall or VPN gateway live in the hub; spokes don't need to peer directly with each other.

An availability set spreads VMs across fault and update domains within a single data center. Availability zones spread resources across physically separate data centers within a region, protecting against a whole-data-center failure that availability sets can't cover.

Check Application Insights for the real backend error — a 502 from App Service usually means the worker process crashed or didn't respond in time. Check for memory pressure causing worker recycling, confirm the App Service Plan tier isn't undersized for the load, and confirm Always On is enabled if it sits idle between bursts.

A zonal resource (like a single Compute Engine VM or a zonal Persistent Disk) lives in one specific zone and goes down if that zone has an outage. A regional resource (like a regional Persistent Disk, or a Managed Instance Group spanning zones) is replicated or distributed across multiple zones in a region, surviving a single zone failure — the tradeoff is usually cost and setup complexity.

Cloud Storage is object storage accessed via API/SDK — files, backups, static content, reachable from anywhere. Persistent Disk is block storage attached to one specific Compute Engine VM, behaving like a traditional local hard drive.

Implement exponential backoff with jitter on retries instead of retrying immediately or in a tight loop, which makes rate limiting worse — most GCP client libraries support this natively. Also check whether the API offers a batch endpoint to cut the total number of calls instead of one call per resource.

It tears down every resource currently tracked in the state file. Before running it: confirm you're pointed at the right state/workspace (a `dev` state and `prod` state should never be ambiguous), and run `terraform plan -destroy` first so you see the full list of what's about to be deleted.

Some resource attributes are immutable at the provider/API level (like an EC2 instance's availability_zone) — changing them can't be done in-place, so Terraform must destroy and recreate the resource entirely. Check the provider documentation for that resource to see which attributes force replacement, and plan around that (e.g., using create_before_destroy lifecycle rules to avoid downtime during the swap).

A .tfvars file supplies actual values for declared variables (e.g., environment = "production"), kept separate so the same reusable configuration can be applied with different .tfvars per environment (dev.tfvars, prod.tfvars) without duplicating or editing the core logic each time.

Terraform runs first to provision the infrastructure (VMs, networking) and typically outputs the new hosts' IPs, which feed into Ansible's dynamic inventory or are passed directly as a target list. Ansible then runs second, configuring the software/state on those now-existing hosts — the two aren't competing tools, they're sequential stages of one pipeline.

A public repository of community-maintained, reusable Ansible roles for common tasks (installing and configuring Nginx, Docker, PostgreSQL, etc.). Using an established, well-tested role saves time and avoids re-solving edge cases (OS differences, version compatibility) that the community role has likely already handled — worth reviewing before writing a bespoke role for something common.

It adds a web UI, role-based access control over who can run what against which hosts, centralized logging/audit trail of every run, scheduling, and a REST API for integration — turning ad hoc CLI execution into a governed, team-shared automation platform rather than something only whoever has CLI access and the right credentials can run.

An SLI is the measured metric itself (e.g., 99.95% of requests succeeded). An SLO is the internal target for that metric (e.g., "we aim for 99.9% success"). An SLA is the external, often contractual, commitment tied to consequences if missed. SLOs are usually stricter than SLAs, giving a buffer before a breach becomes a real problem.

Push-based means the application actively sends metrics to a collector (like StatsD). Pull-based means the collector periodically scrapes metrics from an endpoint the application exposes — Prometheus uses pull, scraping a /metrics endpoint on each target on a schedule, which also makes it easy to detect a target that's down (scrape fails) without separate dead-man's-switch logic.

A linked runbook — the alert itself should point directly to documented steps for diagnosing and responding to that specific condition, rather than leaving the responder to figure out the right response from scratch at 3am under pressure, which is exactly when clear guidance matters most.

It does not rewind. `helm rollback my-app 3` creates a new revision whose content is a copy of revision 3, so the history stays a complete record. If the release was at revision 5, the rollback makes it revision 6 with revision 3's configuration.

A chart's public interface is its values, so removing or renaming a value, changing a default in a way that alters behaviour, or anything that forces users to edit their values is a MAJOR change. A new optional value is MINOR, and a fix with no values change is PATCH.

Build and test the image once, tag it with the commit SHA, and deploy that same image and the same chart version through each environment, changing only the environment's values file. Pass the tag from the build with `--set-string image.tag=...`. Do not rebuild between environments, so production runs exactly what was tested, and gate production with approvals.

A workflow is one automation defined in a YAML file and started by an event. It contains jobs, each of which runs on its own runner (a fresh machine), and jobs run in parallel unless you order them with `needs`. A job contains steps, which run in order on that one machine and are either a shell command (`run`) or a reusable action (`uses`).

A reusable workflow (`on: workflow_call`) shares a whole pipeline or job, is called at job level with `uses:`, runs on its own runner and can define jobs, matrices and environments. A composite action shares a list of steps, is used as a step, and runs on the caller's runner inside the caller's job. Every `run` step in a composite action needs an explicit `shell:`.

That event runs the base branch's workflow with secrets and a write-scoped token, but the PR can come from a stranger. Checking out and running the PR's code there executes their code with your secrets. Use plain `pull_request` for building fork code, and pass only results to a separate trusted `workflow_run` workflow.