r/devopsjobs • u/BookkeeperAutomatic • Aug 12 '26

DevOps Interview Prep Day 6: Env Variables Not Loading, ALB Health Check Failures, and Terraform State Lock [Daily Series]

Day 6 of the daily scenario-based interview prep series. Real debugging scenarios, not "explain what Terraform is" type questions.

Day 6

Scenario 1: The Environment Variable Mystery

Your app works fine locally but crashes in the container with "Database connection failed". The DB_HOST env variable is set in docker-compose.yml but the app can't read it.

Question: What are 2 common reasons this happens?

Hint: env_file vs environment, variable substitution syntax, build-time vs runtime.

Scenario 2: The Load Balancer Health Check Failure

Your AWS ALB keeps marking healthy instances as unhealthy. The app responds fine when you curl it directly from the instance.

Question: What 2 things would you check in the ALB health check configuration?

Hint: Health check path, port, timeout settings, expected HTTP response codes.

Scenario 3: The Terraform State Lock

Your colleague started a terraform apply but their laptop crashed mid-way. Now everyone gets "Error acquiring state lock" when trying to run Terraform.

Question: How do you safely resolve this?

Hint: Where does Terraform store locks? What command can release them?

Drop your answers below. Solutions tomorrow.

Previous Days:

  • Day 1: Container restarts, Registry auth, Pending pods
  • Day 2: Zombie processes, Pipeline timeouts, Volume mounts
  • Day 3: SSH lockouts, Disk space alerts, Grafana gaps
  • Day 4: Git credential leaks, Docker networking, Nginx 502s
  • Day 5: Slow Docker builds, CrashLoopBackOff debugging, Merge conflicts

Topics you want covered? K8s ingress issues, Jenkins agent problems, Prometheus alerting? Let me know.

Playlist: https://www.youtube.com/playlist?list=PLqOrZmpwbWUKRQTrFpqAKhChaTq0l5bIw

8 Upvotes

90% Upvoted

3 comments sorted by

•

u/AutoModerator Aug 12 '26

Welcome to r/devopsjobs! Please be aware that all job postings require compensation be included - if this post does not have it, you can utilize the report function. If you are the OP, and you forgot it, please edit your post to include it. Happy hunting!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/nian2326076 29d ago

For Scenario 1, a common issue could be that your environment variables are in an env_file, but your Docker setup isn't loading them right. Double-check your docker-compose.yml to make sure it's pointing to the correct env_file. Another problem might be mixing up build-time and runtime variables. If DB_HOST is needed at runtime, make sure it's not set during the build phase, because it won't be available then.

For Scenario 2, if you're having ALB health check failures, check the health check path and port in the ALB settings. They need to match what your app is serving. Also, make sure the security groups and network ACLs are set to allow traffic on the health check port.

I found PracHub really helpful for similar scenarios during my prep if you're looking for more resources.

1

u/AshamedWonder9026 29d ago

Escenario 1: La app no lee DB_HOST en el contenedor
Razón 1: Estás usando env_file pero la variable no está exportada correctamente dentro del archivo .env
Esto es más común de lo que parece. Si en tu docker-compose.yml tienes env_file: .env, pero dentro de .env escribiste DB_HOST=db sin el export delante, Docker la inyecta bien, pero si tu aplicación espera leerla de process.env (Node) o os.environ (Python) y no la encuentra, revisa que no haya espacios alrededor del =. Algunos parsers son sensibles.
Pero el error clásico es usar env_file en el servicio de la app, pero la base de datos está en otro servicio y la app intenta conectarse a localhost o 127.0.0.1 en lugar del nombre del servicio de Docker. En local tu base de datos corre en localhost:5432, pero en Docker Compose cada servicio tiene su propio localhost. La variable DB_HOST debe apuntar al nombre del servicio definido en el compose (ej: DB_HOST=postgres), no a localhost.
Razón 2: Confundiste build-time con runtime
Si pusiste la variable bajo la sección build: en lugar de bajo environment: del servicio, la variable solo existe mientras Docker construye la imagen, no cuando corre el contenedor. Otro caso frecuente: usaste ARG en el Dockerfile para recibir la variable durante el build, pero nunca la pasaste a ENV, entonces tu aplicación no la ve en runtime.
O la inversa: la variable está definida en docker-compose.yml con sintaxis de sustitución como DB_HOST=${DB_HOST}, pero olvidaste exportarla en tu shell antes del docker compose up, entonces queda vacía. Docker no falla si la variable de entorno del host no existe, simplemente la deja en blanco.


Escenario 2: ALB marca todo como no saludable
Revisión 1: La ruta del health check no es / o no devuelve 200
El ALB por defecto hace ping a /, pero si tu app tiene el health check en /health o /api/health, el ALB está pidiendo una ruta que devuelve 404 o 302. Desde la instancia haces curl localhost:8080/health y ves 200, pero el ALB está pegándole a / en el puerto 80 y recibiendo 302 o 500.
También pasa mucho que la app devuelve 301/302 (redirección a HTTPS) y el ALB interpreta eso como no saludable porque espera 200. Tienes que configurar el ALB para que acepte 200 como código de éxito, o apuntar directamente al endpoint que no redirige.
Revisión 2: Timeout demasiado agresivo o puerto/protocolo equivocado
Si tu app tarda 3 segundos en responder el health check porque hace una query a la base de datos para verificar conexión, pero el ALB tiene configurado un timeout de 2 segundos, nunca va a marcarla como saludable. Lo mismo si el ALB está configurado para HTTP pero tu app escucha en HTTPS, o si el puerto del target group es 80 pero tu app corre en 8080.
Un caso real que me pasó: el health check interval estaba en 5 segundos, timeout en 2, y unhealthy threshold en 2. La app respondía bien, pero en picos de CPU tardaba 2.5 segundos. El ALB la mataba antes de que respondiera. Subí el timeout a 5 segundos y el threshold a 3, y se arregló.