# DevOps and Cloud Interview Questions with Answers 13 DevOps interview questions, each with a model answer, the points to cover, common mistakes and the follow-ups interviewers ask. _Source: Astra (https://useastra.in). Updated 2026-09-05._ ### 1. Explain service mesh and its benefits." Service mesh (e.g., Istio) provides traffic management, security, and observability features for microservices through a dedicated infrastructure layer. Benefits include fine-grained control over service communication and built-in resiliency patterns. **Points a strong answer covers:** - Mesh: sidecars handle service-to-service (mTLS, retries, telemetry) - Uniform without app code - Cost: complexity -- needs scale **Common mistakes:** - Mesh for 3 services **Likely follow-ups:** - Mesh vs resilience library? **What the interviewer is assessing:** - Infra cost-benefit judgment. ### 2. Linux servers often experience performance bottlenecks under heavy load. If a production server suddenly becomes unresponsive or extremely slow, what specific command-line tools would you use to diagnose the issue, and how would you differentiate between high CPU load caused by user processes versus high I/O wait times caused by disk latency? ### Diagnosing Server Performance Issues When a Linux server acts up, a systematic approach is required to identify the resource bottleneck. #### 1. The First Look: `top` or `htop` The primary tool is `top`. Here, you look at the **Load Average** (1, 5, 15 minute intervals). If the load average is higher than the number of CPU cores, the system is overloaded. #### 2. Differentiating CPU vs. I/O Wait In the `top` header, look at the CPU states: * **`us` (User):** High percentage here means application code (like a web server or script) is consuming the CPU. * **`wa` (Wait):** High percentage here (e.g., >30%) indicates the CPU is idle because it is waiting for disk I/O. This points to a storage bottleneck, not a code efficiency problem. #### 3. Drill Down Tools * **Memory:** use `free -m` to check for swapping. If Swap Used is high, you are thrashing. * **Disk:** use `iostat -xz 1` to see which specific disk partition is saturated. * **Network:** use `iftop` or `netstat` to check for bandwidth saturation. **Points a strong answer covers:** - top/htop for load + process CPU; vmstat/iostat for I/O wait - High %us = user CPU; high %wa = disk latency - dmesg, free, sar, strace to narrow; check swap thrash **Common mistakes:** - Restart-first instinct without diagnosis **Likely follow-ups:** - load average 20 with idle CPU -- what does that mean? - How do you find the process hammering the disk (iotop)? **What the interviewer is assessing:** - Linux-triage competence under pressure. ### 3. In the context of Git version control, developers often debate between using `git merge` and `git rebase` when integrating changes from a feature branch. Can you explain the technical difference in how these commands alter the commit history, and provide a scenario where rebasing is dangerous and should be strictly avoided? ### Merge vs. Rebase: Managing History Both commands integrate changes from one branch into another, but they do so with very different effects on your commit history. #### Git Merge * **Mechanism:** Creates a new "merge commit" that ties two histories together. It preserves the exact time and structure of the repository. * **The Look:** It results in a non-linear history (diamond shape) which preserves the context that a feature branch existed. #### Git Rebase * **Mechanism:** It moves or "replays" the entire feature branch on top of the tip of the main branch. It rewrites the commit history as if the work happened sequentially. * **The Look:** It creates a perfectly linear history, which is cleaner to read. #### The Golden Rule of Danger **Never rebase a public branch.** If you rebase a branch that other developers have pulled (like `develop` or `master`), you are rewriting history they already possess. When they try to pull updates, Git will see conflicting histories, forcing them to force-push or manually reconcile effectively duplicated commits. Rebase is strictly for local, unshared cleanup. **Points a strong answer covers:** - Merge: ties histories with a merge commit -- true history - Rebase: replays commits on new base -- linear, rewritten SHAs - Never rebase shared/public branches **Common mistakes:** - Rebasing main because "cleaner" **Likely follow-ups:** - Why do rewritten SHAs break collaborators? - Interactive rebase -- legitimate uses? **What the interviewer is assessing:** - Git-model understanding beyond commands. ### 4. Kubernetes Pods can fail for various reasons, but one of the most common and frustrating states is `CrashLoopBackOff`. Explain what this status actually indicates regarding the Pod's lifecycle, and detail the step-by-step debugging process you would use to identify the root cause of a container that refuses to stay running. ### Decoding CrashLoopBackOff **CrashLoopBackOff** is not an error itself, but a state indicating that Kubernetes is trying to restart a Pod, but the application inside keeps crashing immediately upon startup. #### What is happening? 1. The container starts. 2. The application exits (either with an error code or just stops). 3. Kubernetes restarts it (BackOff logic applies exponential delays between restarts: 10s, 20s, 40s...). #### How to Debug Since the pod isn't running, you cannot `exec` into it. You must rely on forensic data: 1. **Check Logs:** Run `kubectl logs --previous`. The `--previous` flag is crucial because it shows you the STDOUT/STDERR of the *last* crashed instance, which usually contains the stack trace or error message (e.g., "Database connection failed"). 2. **Describe Pod:** Run `kubectl describe pod `. Look at the "Events" section at the bottom. It might reveal issues like a failed Liveness Probe or an OOMKilled (Out of Memory) error. 3. **Config Check:** Verify your environment variables and ConfigMaps. A missing variable often causes apps to panic on boot. **Points a strong answer covers:** - Container starts, crashes, restarts with backoff -- repeatedly - Debug: kubectl describe pod, logs --previous, events - Causes: bad command, missing config/secret, failed liveness, OOMKilled **Common mistakes:** - Deleting the pod and hoping **Likely follow-ups:** - Logs are empty -- next steps? - OOMKilled vs crash -- how do you tell? **What the interviewer is assessing:** - K8s-debugging methodology test. ### 5. When using Terraform for Infrastructure as Code in a team environment, managing the "State File" (.tfstate) is critical. Why is storing the state file on a local developer machine considered a bad practice, and how does using a Remote Backend with State Locking (like S3 with DynamoDB) solve the problems of collaboration and corruption? ### The Importance of Remote State Terraform's **State File** is the database that maps your real-world cloud resources to your configuration code. It is the source of truth. #### Why Local State Fails 1. **No Collaboration:** If the state is on your laptop, your colleague cannot update the infrastructure because they don't know the current ID of the VPC or EC2 instance you created. 2. **Security Risk:** The state file stores unencrypted sensitive data (like initial database passwords) in plain text. Committing this to Git is a massive security violation. #### The Remote Backend Solution By storing the state in a shared remote location (like an **AWS S3 Bucket**): * **Single Source of Truth:** The whole team works off the same infrastructure reality. * **State Locking (via DynamoDB):** This is critical. If two engineers run `terraform apply` at the exact same time, the state could be corrupted. DynamoDB locks the state file during a write operation, forcing the second engineer to wait until the first deployment finishes. **Points a strong answer covers:** - Local state: no team visibility, loss risk, drift - Remote backend: shared truth; locking prevents concurrent-apply corruption - S3 + DynamoDB lock (or Terraform Cloud) **Common mistakes:** - Committing tfstate to git **Likely follow-ups:** - Two applies race without locking -- what corrupts? - Secrets in state -- how do you protect them? **What the interviewer is assessing:** - IaC team-operations maturity. ### 6. Load Balancers are essential for distributing traffic, but they operate at different layers of the OSI model. Compare a Layer 4 (Transport Layer) Load Balancer with a Layer 7 (Application Layer) Load Balancer. Specifically, how does the visibility of data packets differ between the two, and how does this impact your ability to route traffic based on URL paths or HTTP headers? ### Layer 4 vs. Layer 7 Load Balancing The difference lies in how much of the network packet the load balancer "opens up" and inspects before making a routing decision. #### Layer 4 (Transport Layer - TCP/UDP) * **Visibility:** Limited to IP addresses and Ports (e.g., IP 1.2.3.4, Port 80). It does not see the content of the message. * **Mechanism:** It acts as a pure packet forwarder. It uses NAT to forward packets to upstream servers. * **Pros/Cons:** Extremely fast and handles massive throughput, but it cannot make smart decisions. #### Layer 7 (Application Layer - HTTP/HTTPS) * **Visibility:** It decrypts the traffic and reads the HTTP headers, cookies, and URL path. * **Mechanism:** It terminates the connection, inspects the request, and opens a *new* connection to the backend server. * **Pros/Cons:** Allows for "Smart Routing" (e.g., sending `/api/video` to a video server and `/api/cart` to a commerce server). However, it is more CPU intensive due to encryption/decryption overhead. **Points a strong answer covers:** - L4: sees IP/port only -- fast, no content routing - L7: parses HTTP -- path/header routing, TLS termination, WAF - L7 cost: latency + compute; choose per need **Common mistakes:** - No packet-visibility distinction **Likely follow-ups:** - gRPC -- which layer LB and why is it tricky? **What the interviewer is assessing:** - Network-layer precision. ### 7. In an AWS Virtual Private Cloud (VPC), security is managed via subnets. Explain the architectural difference between a Public Subnet and a Private Subnet. If you have a database in a Private Subnet that needs to download patches from the internet, what specific infrastructure component must you provision to allow this outbound connection without exposing the database to inbound attacks? ### Public vs. Private Subnets The distinction is defined by the **Route Table** associated with the subnet. * **Public Subnet:** The route table has a direct entry to an **Internet Gateway (IGW)**. Any instance here has a public IP and can be reached directly from the internet (if Security Groups allow). This is where Load Balancers and Bastion hosts live. * **Private Subnet:** The route table has *no* route to the IGW. Instances here have only private IPs and are completely invisible to the outside world. This is where Databases and Application logic live. #### The Patching Problem (NAT Gateway) If a private database needs to reach `yum.repos.d` or `apt-get` on the internet: 1. You cannot attach an Internet Gateway (that would make it public). 2. **Solution:** You provision a **NAT Gateway** (Network Address Translation) inside the *Public* Subnet. 3. **Routing:** You update the Private Subnet's route table to send all internet traffic (`0.0.0.0/0`) to the NAT Gateway ID. This allows traffic to flow **Out -> In**, but prevents the internet from initiating a connection **In -> Out**. **Points a strong answer covers:** - Public subnet: route to Internet Gateway - Private: no direct inbound; egress via NAT Gateway - DB in private + NAT for patches = outbound-only **Common mistakes:** - Public subnet + security group as "private enough" **Likely follow-ups:** - NAT Gateway vs NAT instance? - How does the DB stay unreachable inbound? **What the interviewer is assessing:** - Cloud-network security design. ### 8. Databases require strict consistency properties to ensure financial and data integrity. Can you explain the ACID properties (Atomicity, Consistency, Isolation, Durability) in the context of relational databases? Why is maintaining ACID compliance often a trade-off with the scalability goals of NoSQL databases in a distributed system (CAP Theorem)? ### The ACID Properties Relational databases (like PostgreSQL or MySQL) prioritize data integrity above all else using ACID: 1. **Atomicity:** "All or Nothing." If a transaction has 4 steps and the 4th fails, the previous 3 are rolled back. No partial data exists. 2. **Consistency:** The database moves from one valid state to another. It respects all constraints (foreign keys, unique constraints) at all times. 3. **Isolation:** Transactions happening at the same time do not interfere with each other. (e.g., two people buying the last ticket simultaneously). 4. **Durability:** Once a transaction is committed, it stays committed, even if the power plug is pulled immediately after. #### The CAP Theorem Trade-off In distributed systems, the **CAP Theorem** states you can only have 2 of 3: Consistency, Availability, or Partition Tolerance. * **ACID (SQL):** Chooses Consistency. If nodes lose connection, the database stops accepting writes to prevent data divergence. * **NoSQL (Base):** Often chooses Availability. It accepts writes even if nodes are out of sync, leading to "Eventual Consistency." **Points a strong answer covers:** - ACID per letter with failure examples - Distributed: coordination cost of ACID across nodes - CAP: partition tolerance forces consistency/availability choice; BASE alternative **Common mistakes:** - ACID recital without the distributed trade-off **Likely follow-ups:** - Which ACID property does eventual consistency relax? **What the interviewer is assessing:** - DB-guarantees-to-scale bridge. ### 9. Secure Sockets Layer (SSL) and its successor TLS are the backbone of secure web communication. Describe the high-level process of the "SSL Handshake." How does the browser verify that the server is legitimate using Certificate Authorities (CA), and at what point does the communication switch from asymmetric encryption to symmetric encryption? ### The SSL/TLS Handshake Simplified The handshake is a negotiation to establish trust and generate a shared secret key for encryption. 1. **Client Hello:** The browser sends supported encryption algorithms and a random number to the server. 2. **Server Hello:** The server replies with its chosen algorithm, its own random number, and its **SSL Certificate**. 3. **Authentication (Crucial Step):** The browser checks the certificate. * Is it expired? * Does the domain name match? * **Chain of Trust:** Was this certificate signed by a Trusted Certificate Authority (CA) that represents the root certificates pre-installed in the browser? If yes, the server is legitimate. 4. **Key Exchange:** The browser uses the server's *Public Key* (from the cert) to encrypt a "Pre-Master Secret" and sends it to the server. Only the server's *Private Key* can decrypt this. 5. **Symmetric Switch:** Both sides now use the random numbers and the secret to generate the same **Symmetric Session Key**. All data following this is encrypted using this faster symmetric key. **Points a strong answer covers:** - Handshake: negotiate cipher, verify cert chain to trusted CA, key exchange - Asymmetric only for establishing the symmetric session key - Symmetric for bulk data (fast); TLS 1.3 trims round trips **Common mistakes:** - "It encrypts traffic" with no handshake stages **Likely follow-ups:** - What exactly does the CA signature prove? - Why switch to symmetric at all? **What the interviewer is assessing:** - TLS-mechanics literacy. ### 10. Microservices architecture is a dominant trend, but it introduces significant operational complexity compared to a Monolithic architecture. Apart from network latency, what are the major challenges a DevOps team faces regarding logging and debugging when a single user request spans across five different microservices? How does "Distributed Tracing" help solve this? ### The Complexity of Microservices While Microservices allow teams to deploy independently, they turn debugging into a detective game. In a Monolith, a stack trace tells you exactly where an error happened. In Microservices, a request might hit Service A -> Service B -> Service C. If Service C fails, Service A just reports "500 Error," giving no clue why. #### Challenges 1. **Fragmented Logs:** Logs are scattered across 5 different containers/servers. You cannot simply `grep` a file. 2. **Data Consistency:** Tracking a transaction that partially failed (e.g., money deducted in Service A, but inventory not updated in Service B). #### The Solution: Distributed Tracing Tools like **Jaeger** or **Zipkin** solve this. * **Trace ID:** When a request enters the system (at the Load Balancer), it is assigned a unique Trace ID. * **Propagation:** This ID is passed in the headers of every internal HTTP/gRPC call between services. * **Visualization:** The tracing tool collects data from all services and builds a timeline (Waterfall view), showing exactly how long each hop took and where the chain broke. **Points a strong answer covers:** - One request, five services: logs scattered, no causality - Distributed tracing: trace ID propagated, spans per hop - Correlation IDs in logs; OpenTelemetry standard **Common mistakes:** - "Check each service's logs" as the plan **Likely follow-ups:** - How does the trace ID actually propagate (headers)? - Sampling -- why needed? **What the interviewer is assessing:** - Microservices-observability grasp. ### 11. Container persistence is a common confusion point for beginners. If a Docker container crashes or is removed, the data inside it is lost. Explain the difference between a "Docker Volume" and a "Bind Mount." Which one is preferred for production database storage and why is it superior to storing data in the container's writable layer? ### Docker Storage: Volumes vs. Bind Mounts Docker containers are ephemeral by design. To keep data (like database files), we must punch a hole through the container to the host filesystem. #### Bind Mounts * **Concept:** You map a specific file or folder on the host (e.g., `/home/user/project`) to a folder in the container. * **Use Case:** Ideal for **Development**. You can edit code on your laptop, and the changes appear instantly inside the running container. * **Downside:** It relies on the host's specific directory structure, making it less portable. #### Docker Volumes * **Concept:** Docker creates and manages a storage area (usually in `/var/lib/docker/volumes`) that is isolated from the host's core filesystem. * **Use Case:** Ideal for **Production** and Databases. * **Why Superior?** 1. **Managed:** You don't need to worry about file permissions or ownership on the host. 2. **Portable:** The volume is an abstract object. You can back it up, migrate it, or share it between containers safely without knowing the underlying OS path. **Points a strong answer covers:** - Writable layer dies with container - Volume: Docker-managed, portable, backup-able -- production choice - Bind mount: host path, dev convenience, host coupling **Common mistakes:** - Data in the container image/layer **Likely follow-ups:** - Where do volumes physically live? - DB in K8s -- what replaces volumes (PVC)? **What the interviewer is assessing:** - Container-persistence fundamentals. ### 12. In the context of Domain Name Systems (DNS), explain the difference between an "A Record," a "CNAME Record," and an "Alias Record." Why would you use an Alias Record over a CNAME at the root (zone apex) of your domain (e.g., example.com vs. www.example.com)? ### DNS Record Types: A, CNAME, and Alias DNS translates human-readable names to IP addresses. * **A Record (Address Mapping):** Maps a hostname (e.g., `www.google.com`) to a specific IPv4 address (e.g., `142.250.190.46`). It is the most fundamental record. * **CNAME (Canonical Name):** Maps a hostname to another hostname. It acts as an alias. * Example: `blog.example.com` -> `ghs.google.com`. * Limitation: You cannot use a CNAME at the root domain (`example.com`). #### The Alias Record Solution Cloud providers (AWS Route53, Cloudflare) created the **Alias Record**. * **Concept:** It works like a CNAME (points to a hostname like an ELB or S3 bucket) but behaves like an A Record. * **Why Use It?** Since the DNS protocol forbids CNAMEs at the zone apex (`example.com`), you *must* use an Alias record to point your root domain to a dynamic cloud resource (like a Load Balancer) that doesn't have a static IP. **Points a strong answer covers:** - A: name -> IP - CNAME: name -> name; forbidden at zone apex - Alias (provider ext): apex-compatible pointer to AWS resources, resolves server-side **Common mistakes:** - No apex-constraint awareness **Likely follow-ups:** - Why does the DNS spec forbid apex CNAMEs? **What the interviewer is assessing:** - DNS-detail competence. ### 13. Explain the concept of "Immutable Infrastructure" versus "Mutable Infrastructure." In a traditional server management model, servers are updated and patched in place. What are the specific security and operational benefits of replacing servers entirely rather than updating them, and how does this relate to the "Golden Image" strategy? ### Immutable vs. Mutable Infrastructure **Mutable Infrastructure** is like a pet. You name it, nurse it back to health when sick, and apply updates/patches directly to the running server. * **Risk:** Over time, this leads to "Configuration Drift" and "Snowflake Servers"--unique, fragile systems that are hard to reproduce. **Immutable Infrastructure** is like cattle. You don't fix a sick server; you replace it. * **Mechanism:** You bake a **"Golden Image"** (AMI/VM Template) containing the OS, patches, and application version. * **Deployment:** To update, you spin up *new* servers from the new image and terminate the old ones. #### Benefits 1. **Security:** If a server is compromised, you don't clean it; you kill it. The new server is guaranteed clean. 2. **Consistency:** Testing the image in Staging guarantees it works in Production because the bits are identical. 3. **Rollback:** Rolling back is as simple as deploying the previous image. **Points a strong answer covers:** - Mutable: patch in place -- drift, snowflakes - Immutable: replace with new image -- consistent, rollback = old image - Golden image pipeline (Packer); pairs with IaC + blue/green **Common mistakes:** - SSH-and-patch habits defended **Likely follow-ups:** - Emergency hotfix under immutability -- process? **What the interviewer is assessing:** - Modern-ops philosophy check. Full topic: https://useastra.in/interview-questions/topic/devops