Devriston DevOps Interview Guide

Question 1

What is Infrastructure as Code (IaC)?

Accepted Answer

Managing infrastructure through version-controlled code instead of manual configuration.

Question 2

What is Docker?

Accepted Answer

A platform for packaging applications and their dependencies into portable, consistent containers.

Question 3

What is Docker Compose?

Accepted Answer

A tool for defining and running multi-container applications from a single YAML file.

Question 4

What is Ansible?

Accepted Answer

An agentless automation tool for configuration management and deployment, using YAML playbooks.

Question 5

What is an Ansible Inventory / Playbook / Role?

Accepted Answer

Inventory defines target hosts; a playbook is a set of tasks run against them; a role packages reusable automation into a structured, shareable unit.

Question 6

What does idempotent mean in Ansible?

Accepted Answer

Running the same playbook repeatedly produces the same end state without causing unintended changes on repeat runs.

Question 7

What is configuration drift?

Accepted Answer

When servers that should be identical gradually diverge due to manual changes — automation (like Ansible) prevents this.

Question 8

What is Terraform?

Accepted Answer

A tool for defining and provisioning infrastructure through declarative, version-controlled code (Infrastructure as Code).

Question 9

What is a VPC?

Accepted Answer

A logically isolated virtual network within AWS where you control IP ranges, subnets, and routing.

Question 10

What's the difference between a public and private subnet?

Accepted Answer

A public subnet has a route to an Internet Gateway; a private subnet doesn't, so its resources aren't directly reachable from the internet.

Question 11

What is a Security Group?

Accepted Answer

A virtual firewall attached to AWS resources that controls inbound and outbound traffic at the instance level.

Question 12

What is Prometheus?

Accepted Answer

An open-source metrics collection and alerting system that scrapes HTTP endpoints on a schedule.

Question 13

What is Grafana?

Accepted Answer

A visualization layer that turns data from sources like Prometheus and Loki into dashboards.

Question 14

What is Node Exporter / cAdvisor?

Accepted Answer

Node Exporter exposes host-level Linux metrics; cAdvisor exposes per-container metrics (CPU, memory, network, filesystem). Both feed Prometheus.

Question 15

What is Active Directory?

Accepted Answer

A centralized directory service for managing users, computers, groups, authentication, and authorization.

Question 16

What is Kerberos?

Accepted Answer

A ticket-based authentication protocol that enables secure Single Sign-On without repeatedly sending passwords.

Question 17

What's the difference between authentication and authorization?

Accepted Answer

Authentication verifies who you are (e.g. username + password); authorization determines what you're allowed to access once verified.

Question 18

What problem does the Terraform AWS 3-Tier Platform solve?

Accepted Answer

It provisions a complete, production-shaped AWS 3-tier network — public/private subnets, a frontend and backend EC2 instance, and least-privilege security groups — entirely from Terraform code, so the whole environment can be destroyed and rebuilt identically instead of being clicked together in the console.

Question 19

Explain this project in one minute.

Accepted Answer

I built a modular Terraform project that provisions a custom AWS VPC with public and private subnets, an Internet Gateway, route tables, and security groups. A frontend EC2 instance sits in the public subnet running a Dockerized app on port 8080, and a backend EC2 instance sits in the private subnet on port 3000, reachable only from the frontend's security group — not directly from the internet.

Question 20

Why build a custom VPC instead of using the AWS default VPC?

Accepted Answer

The default VPC gives no control over subnet layout or security boundaries. Building it explicitly let me decide exactly which subnets are public vs private, and which traffic is allowed between them — which is the whole point of demonstrating a real 3-tier design.

Question 21

Why split the architecture into separate Terraform modules rather than one file?

Accepted Answer

Separating networking, security groups, and compute into their own modules meant each piece could be reasoned about, tested, and reused independently — adding an RDS tier later doesn't mean rewriting the VPC module.

Question 22

Why put the backend EC2 instance in a private subnet instead of public?

Accepted Answer

The backend has no reason to be reachable from the internet directly — only the frontend needs to talk to it. Keeping it private shrinks the attack surface: even if someone scans for open ports, the backend simply isn't reachable from outside the VPC.

Question 23

Why does the frontend expose port 8080, but the backend only allows port 3000 from the frontend's security group specifically?

Accepted Answer

That's the actual enforcement of the 3-tier boundary — the backend's security group rule references the frontend's security group ID as the source, not 0.0.0.0/0. Only traffic originating from the frontend instance can reach the backend, regardless of what subnet routing allows.

Question 24

Why pin provider versions instead of letting Terraform use the latest?

Accepted Answer

An unpinned provider can introduce breaking changes between apply runs months apart. .terraform.lock.hcl locks the exact versions used, so re-running this project later gives the same result it gave the first time.

Question 25

Walk me through how a request actually reaches the backend.

Accepted Answer

A client hits the frontend EC2 instance's public IP on port 8080. The frontend application then makes its own request to the backend instance's private IP on port 3000 — that internal call is only possible because the backend's security group explicitly allows inbound traffic from the frontend's security group.

Question 26

What's actually enforcing the difference between the public and private subnet, mechanically?

Accepted Answer

The route table. The public subnet's route table has a route to the Internet Gateway for 0.0.0.0/0; the private subnet's route table doesn't — so even with the private instance's IP, there's no path to it from the internet.

Question 27

What's missing from this for a real production environment?

Accepted Answer

No load balancer (traffic goes straight to one EC2 instance), no Auto Scaling, no CloudWatch monitoring, and state is local rather than stored remotely in S3 with locking — so two people running terraform apply at once could conflict.

Question 28

How would you evolve this into something closer to production?

Accepted Answer

Add an Application Load Balancer in front of the frontend instances, put them in an Auto Scaling Group instead of a single instance, move state to an S3 backend with DynamoDB locking, add CloudWatch alarms, and likely add an RDS instance in the private subnet for the backend's data layer.

Question 29

What was the trickiest part of getting the networking right?

Accepted Answer

Making sure the backend's security group rule referenced the frontend's security group ID rather than a CIDR block — it's an easy mistake to open the backend to the whole VPC CIDR instead of just the one instance that should reach it, and that mistake doesn't show up unless you test from outside the frontend.

Question 30

What problem does the Monitoring Stack project solve?

Accepted Answer

It provides a complete observability platform — metrics, dashboards, alerting, and centralized logs — for infrastructure that would otherwise be a black box. Without it, you only find out something's wrong when a user complains.

Question 31

Explain this project in one minute.

Accepted Answer

I automated the deployment of a full observability stack — Prometheus, Grafana, Alertmanager, Loki, and Promtail — on a Vagrant-provisioned Debian VM using Ansible. Prometheus scrapes Node Exporter for system metrics, Grafana visualizes them alongside Loki logs, and Alertmanager fires notifications when a CPU threshold is breached. I tested the alert path end-to-end by artificially loading the CPU until it transitioned from pending to firing.

Question 32

Why Vagrant instead of just running this locally?

Accepted Answer

It gives a reproducible, throwaway VM — I can destroy and rebuild the exact same environment with one command, which matters when testing provisioning steps that should also work on a real server later.

Question 33

Why Docker Compose instead of installing each tool directly on the VM?

Accepted Answer

Each piece — Prometheus, Grafana, Alertmanager, Loki, Promtail — has its own config format, port, and update cycle. Running them as separate containers on one Compose file let me version and restart each independently, without the host's package manager getting involved.

Question 34

Why Ansible to provision this instead of a shell script?

Accepted Answer

Idempotency. The same playbook can run against a fresh VM or one that's already partially configured, and it won't break anything on a second run — a plain shell script doesn't give you that for free.

Question 35

Why add Loki on top of Prometheus, instead of stopping at metrics?

Accepted Answer

Metrics tell you that something is wrong (CPU spiked); logs tell you why. Loki centralizes the /var/log output so I could correlate a firing alert with what was actually happening in the system logs at that moment, viewed straight from Grafana Explore.

Question 36

Why Loki instead of something like Elasticsearch for logs?

Accepted Answer

Loki indexes only labels, not full log text, which keeps it lightweight for a single-VM lab setup. Elasticsearch's full-text indexing is more powerful but heavier than this project needed.

Question 37

How does Prometheus actually get the data?

Accepted Answer

It scrapes Node Exporter's HTTP endpoint on a schedule defined in prometheus.yml — Node Exporter doesn't push anything, Prometheus pulls.

Question 38

How do Prometheus and Alertmanager talk to each other?

Accepted Answer

Through the alerting block in prometheus.yml, which points to Alertmanager's address. When a rule's condition is met, Prometheus sends the alert there for routing.

Question 39

Walk me through what happens when CPU usage crosses the threshold.

Accepted Answer

The Prometheus rule evaluates on each scrape interval. Once CPU stays above the threshold for the configured 'for:' duration, the alert moves from pending to firing and gets pushed to Alertmanager, which then handles routing/grouping for notification.

Question 40

How did you actually test that the alert worked, rather than just trusting the config?

Accepted Answer

I artificially loaded the CPU (stress-testing it past the threshold) and watched the alert state transition from inactive → pending → firing in the Prometheus UI, then confirmed it appeared in Alertmanager.

Question 41

Why do your Prometheus configs reference containers by name instead of IP?

Accepted Answer

Docker's internal DNS resolves container names automatically on the bridge network, so 'node-exporter:9100' keeps working even if the container's IP changes on restart — raw IPs would break on every redeploy.

Question 42

What's the actual difference between monitoring and observability, in context?

Accepted Answer

Monitoring here is the CPU alert — a known metric with a known threshold. Observability is the bigger picture: when something unexpected breaks, I can pivot from a Grafana metric to the Loki logs from the same time window to investigate, without knowing in advance what I was looking for.

Question 43

What's missing from this setup if it had to run in production?

Accepted Answer

No TLS between components, no authentication on Grafana/Prometheus beyond defaults, no secrets management, and metrics/logs aren't persisted with a backup strategy — they'd be lost if the volume was wiped.

Question 44

How would you scale this beyond one VM?

Accepted Answer

Move from Node Exporter on a single host to scraping multiple hosts via service discovery, run Alertmanager in HA mode, and consider remote storage (e.g. Thanos or Mimir) so Prometheus isn't a single point of failure for retention.

Question 45

What was the hardest part of building this?

Accepted Answer

Getting the alert path fully working end-to-end — not just defining a Prometheus rule, but proving it actually reaches Alertmanager and fires under real load, rather than just looking correct in a config file.

Question 46

What problem does the Self-Healing Container Platform solve?

Accepted Answer

Containers fail in ways a basic restart:always policy doesn't catch — a container can stay 'running' while the app inside it has hung or stopped responding. This project adds a layer that actually checks health, not just process state, and recovers automatically while logging what happened.

Question 47

Explain this project in one minute.

Accepted Answer

I built a Docker Compose platform with cAdvisor and Node Exporter feeding Prometheus, visualized in Grafana, plus a Bash recovery script run by cron every minute. The script checks each container's actual running and health status via Docker inspection commands — if a container is stopped or marked unhealthy, it's automatically restarted and the incident is logged.

Question 48

Why not just rely on Docker's built-in restart policies?

Accepted Answer

Restart policies only react to a container stopping — they do nothing if a container is still running but its application has hung or stopped responding to requests. My script checks Docker's health status separately, catching 'running but broken' containers a restart policy alone would miss, and logs every incident.

Question 49

Why a cron-driven Bash script instead of a more sophisticated tool?

Accepted Answer

At this scale, a Bash script running every minute is simple enough to fully understand and debug line by line — no orchestrator dependency. It's a deliberate starting point I'd outgrow if I needed multi-node coordination, which is exactly what I'd reach for Kubernetes or a proper watchdog daemon for.

Question 50

Why add cAdvisor on top of Node Exporter — isn't host-level monitoring enough?

Accepted Answer

Node Exporter only sees the host (CPU, memory, disk) — it has no idea which container is responsible for a spike. cAdvisor gives per-container metrics, so when something looks wrong in Grafana, I can tell which container is using the resources, not just that the host is under load.

Question 51

Walk me through what happens when a container crashes.

Accepted Answer

The cron-triggered script runs docker inspect against each container every minute. If a container's state shows it's not running, the script restarts it and writes a timestamped entry to the recovery log — a record of exactly when and what failed, not just that it's running again now.

Question 52

What's the difference between how you handle a stopped container vs an unhealthy one?

Accepted Answer

A stopped container is caught by checking its running state directly. An unhealthy one is still running, but Docker's own HEALTHCHECK (a command run periodically inside the container) has failed enough times in a row that Docker marks it unhealthy — a different failure mode than a crash, checked separately.

Question 53

What's the biggest limitation of this setup?

Accepted Answer

It's single-node and check-interval-based — a failure can persist for up to a minute before the cron job catches it, and there's no notification when a recovery happens; you'd have to go look at the logs or Grafana yourself.

Question 54

How would you improve it?

Accepted Answer

Add Alertmanager so a Slack/email notification fires the moment a recovery action happens, move from cron to a real watchdog process for faster detection, and extend it to multiple nodes if it needed to cover more than one host.

Question 55

What was the hardest part of building this?

Accepted Answer

Getting the detection logic to correctly distinguish a stopped container from an unhealthy-but-running one — they need different docker inspect fields, and conflating them meant the script either missed failures or restarted containers that didn't actually need it.

Question 56

What does "self-healing" actually mean as a system property?

Accepted Answer

It's the ability of a system to detect a failure and recover from it on its own, without a human restarting a service or paging anyone. In this project specifically, that means failure detection (health checks), automated remediation (the recovery script), and an audit trail (the recovery log) — not just "it restarts sometimes."

Question 57

Mechanically, how does a Docker HEALTHCHECK actually mark a container unhealthy?

Accepted Answer

You define a HEALTHCHECK command in the Dockerfile or Compose file — Docker runs it inside the container on a fixed interval. If that command fails enough consecutive times (the 'retries' threshold), Docker flips the container's status to unhealthy. The container keeps running the whole time; only its reported health status changes — which is exactly the signal my recovery script polls for via docker inspect.

Question 58

What metrics does the stack actually collect, end to end?

Accepted Answer

cAdvisor reports per-container CPU, memory, and network usage. Node Exporter reports host-level CPU, memory, and filesystem usage. Both get scraped by Prometheus and rendered in Grafana — so a dashboard can show whether a spike is one misbehaving container or the whole host running hot.

Question 59

What problem does the Samba4 Enterprise Identity Suite solve?

Accepted Answer

It replaces per-machine local user accounts with centralized authentication — Linux clients authenticate against a Samba4 Domain Controller the same way they would against Windows AD, but on open-source infrastructure with no licensing cost.

Question 60

Walk me through the login flow in your project.

Accepted Answer

A user logs into a Linux client → SSSD picks up the authentication request → it's forwarded to the Samba4 Domain Controller → Kerberos validates the credentials and issues a Ticket Granting Ticket → the user gets an authenticated session, with access permissions determined by their AD group membership.

Question 61

Why Samba4 instead of Windows Active Directory?

Accepted Answer

Samba4 provides the same core AD functionality — LDAP, Kerberos, DNS, domain services — running on Linux servers, which avoids Windows Server licensing costs entirely while staying compatible with AD-joined clients.

Question 62

Why use SSSD and Realmd instead of creating local Linux user accounts?

Accepted Answer

Local accounts don't scale and don't give centralized control — every server has its own user list, with no Single Sign-On and inconsistent permissions across machines. SSSD and Realmd join Linux clients to the same domain, centralizing authentication, group membership, and auditing.

Question 63

Why does time synchronization matter enough to call out specifically?

Accepted Answer

Kerberos tickets are timestamped, valid only within a defined time window. If a client's clock drifts too far from the Domain Controller's, valid credentials get rejected — purely because of clock skew, not misconfiguration. It's one of the first things to check when authentication suddenly breaks.

Question 64

What actually happens during a Kerberos login, step by step?

Accepted Answer

The user authenticates with their credentials. The Domain Controller validates them and issues a Ticket Granting Ticket (TGT). The client uses the TGT to request service tickets for specific resources. The target service validates the ticket. Access is granted — without the password being sent again for each service.

DevOps Interview Guide

No questions found

Need help implementing any of this?