Migrations, Zero-Downtime Releases, Containers & Monitoring — Interview Questions

How to use this lesson

Zero-downtime deployment is where application code, database schema and infrastructure meet. The key idea interviewers probe is compatibility across versions. During a rollout, old and new instances run at the same time, against the same database.

Q1. How do you handle database migrations during deployments?

Short answer:

• Manage schema changes as versioned migration scripts with Flyway or Liquibase, kept in the repository, reviewed, and applied automatically (at application startup, or as a separate pipeline step or Kubernetes Job before the rollout).
• Make them backward-compatible, using expand → migrate → contract:
  1. Expand: add new nullable columns or tables. The old code keeps working.
  2. Deploy code that writes both the old and new columns, then backfill the data in batches.
  3. Switch reads to the new structure.
  4. Contract: drop the old columns in a later release.

-- V42__add_customer_email_normalized.sql (expand: safe with old and new code running together)
ALTER TABLE customer ADD COLUMN email_normalized VARCHAR(320);
CREATE INDEX CONCURRENTLY idx_customer_email_norm ON customer (email_normalized);   -- PostgreSQL: no table lock

Key points to cover:

• Prefer roll-forward over "down" migrations. Rollback scripts are rarely tested, and they can lose data.
• Watch out for locking DDL on big tables. Use online schema-change tools, or CONCURRENTLY.
• Run a migration from exactly one place, and let Flyway's lock handle concurrent instances.

Q2. Scenario: the application must have zero downtime during deployments. What strategies do you use?

Short answer:

• Rolling updates (the Kubernetes default), with maxUnavailable: 0 and maxSurge: 1, so capacity never drops.
• Readiness probes, so traffic only reaches pods that are warmed up.
• Graceful shutdown (server.shutdown=graceful, plus a preStop delay, so the load balancer stops sending traffic before the pod exits).
• Blue-green or canary, for fast switching and limited blast radius.
• Backward-compatible database and API changes (expand/contract, tolerant readers).
• Feature flags, to separate deploying from releasing.
• Connection draining at the load balancer.
• PodDisruptionBudgets, and several replicas across AZs.

Learn it in depth → Deployments & Rollouts

Q3. Why do health checks matter in deployments, and how do you implement them?

Short answer: Health checks let the platform decide automatically when to send traffic to an instance, and when to restart it. Without them, rollouts send users to instances that are still starting or already broken. Implement them with Spring Boot Actuator's probe groups:

• Readiness (/actuator/health/readiness): the app has started and can serve. Include the critical dependencies the app truly can't work without.
• Liveness (/actuator/health/liveness): the process isn't stuck. Don't include external dependencies here, or a database blip restarts every pod.
• A startup probe, for slow starters.

readinessProbe: { httpGet: { path: /actuator/health/readiness, port: 8081 }, periodSeconds: 5, failureThreshold: 3 }
livenessProbe:  { httpGet: { path: /actuator/health/liveness,  port: 8081 }, periodSeconds: 10, failureThreshold: 3 }
startupProbe:   { httpGet: { path: /actuator/health/liveness,  port: 8081 }, periodSeconds: 5, failureThreshold: 30 }

Learn it in depth → Probes & Autoscaling

Q4. How do you manage configuration changes across environments?

Short answer: One artifact, configuration injected per environment:

• Defaults in application.yml.
• Behavioural differences in Spring profiles.
• Environment values through environment variables, Kubernetes ConfigMaps, or Spring Cloud Config.
• Secrets from a secrets manager.

Keep the environment configuration in Git (GitOps), reviewed like code, validated at startup (@Validated configuration properties), and rolled out as gradually as a code change.

Common trap: rebuilding the application per environment, or baking configuration into images. You then can't be sure that what you tested is what you ship.

Learn it in depth → Config & Secrets

Q5. Scenario: you're deploying to the cloud for the first time. What should you keep in mind?

Short answer:

• Architecture: stateless instances, managed databases and caches, object storage for files, and multiple AZs.
• Security: least-privilege IAM (roles, not access keys), private subnets, security groups, TLS everywhere, a secrets manager, encryption at rest, and WAF protection for public endpoints.
• Infrastructure as code (Terraform, CDK), with separate accounts or projects per environment.
• Observability from day one: logs, metrics, traces and alerts.
• Scalability: autoscaling policies and load testing.
• Reliability: backups with tested restores, a DR plan (RPO/RTO), health checks.
• Cost: right-sizing, budgets and alerts, tagging, reserved or savings plans once usage is stable.
• Compliance: data residency, and audit logging.

Learn it in depth → Cost Awareness

Q6. How does containerisation with Docker improve deployments?

Short answer:

• Consistency: the same image, with the runtime and dependencies included, runs in dev, CI and prod. No more "works on my machine".
• Immutable, versioned artifacts: easy rollbacks, and an exact reproduction of what's running.
• Fast startup and density compared with VMs.
• Isolation of dependencies between services.
• The foundation for orchestration: Kubernetes scheduling, scaling, self-healing and rolling updates.

Key points to cover:

• Keep images small and secure: JRE or distroless bases, a non-root user, layered builds, and vulnerability scanning.

Learn it in depth → Docker Fundamentals

Q7. Describe dealing with performance problems after a deployment.

Short answer (a model story): "Right after a release, p95 latency on the order API doubled, and database CPU rose sharply. The canary dashboards caught it. We rolled back within minutes, restoring the service, then compared traces from the two versions. The new version added a lazy-loaded association to a DTO mapping, which caused N+1 queries per order. We fixed it with a fetch join, added a query-count assertion to the integration test, and added a latency and error-rate analysis step to the canary, so a regression like that now fails the rollout automatically."

Key points to cover:

• Stabilise first (roll back, or turn off the flag), investigate second (compare metrics and traces between versions), then prevent recurrence (tests, canary gates).

Q8. Explain blue-green deployment and its advantages.

Short answer: You keep two identical production environments. Blue serves users, and green receives the new version. Once green passes its smoke tests and health checks, the load balancer switches all traffic to green. Blue stays up as an instant rollback target, and is then updated for the next release.

Advantages:

• Near-zero downtime.
• Instant rollback (switch back).
• Testing the new version in a production-identical environment before users see it.

Costs:

• Double the capacity during releases.
• Shared database compatibility (expand/contract).
• In-flight sessions and long-running connections need draining.
• The switch is all-or-nothing, unlike a canary's gradual exposure.

Q9. Scenario: your deployment process is too slow. How do you analyse and improve it?

Short answer: Measure each stage (queue time, build, tests, image build, push, deploy, rollout, verification), then attack the largest ones:

• Build: dependency caches, build caches (Gradle, or the Maven extension), parallel modules.
• Tests: parallelise, split fast and slow suites, reuse Testcontainers, run only the affected modules on PRs.
• Images: layered JARs, so only the application layer changes; smaller base images; registry close to the cluster.
• Rollout: tune the readiness probes and surge settings, reduce startup time (lazy initialisation, CDS/AOT).
• Process: remove manual approvals that add no value, and deploy smaller changes more often.

Track lead time for changes as a DORA metric.

Q10. Which monitoring tools do you use to check the health of deployed applications?

Short answer:

• Metrics: Micrometer, then Prometheus (or a managed version), with Grafana dashboards and Alertmanager alerts (or Datadog or New Relic).
• Logs: structured JSON logs, shipped to the ELK/OpenSearch stack or Loki.
• Traces: OpenTelemetry, exported to Jaeger or Tempo.
• Uptime and synthetic checks: Pingdom or Grafana synthetic monitoring. Error tracking: Sentry.

Alerts are based on SLOs (the error rate and latency users experience), and they route to on-call rotations (PagerDuty, Opsgenie).

Learn it in depth → Monitoring in Production

Follow-up questions this topic invites — and their answers

Q: What are the four DORA metrics? A: Deployment frequency, lead time for changes, change failure rate, and time to restore service (MTTR). Together they measure both delivery speed and stability.

Q: Should Flyway run at application startup or as a separate job? A: Startup is simple, and Flyway's lock keeps concurrent instances safe. A separate pre-deploy job gives better control and clearer failure handling for large or risky migrations, and avoids slow startups. Many teams use a Kubernetes Job or init step for production.

Q: What does maxSurge/maxUnavailable control? A: In a Kubernetes rolling update, maxSurge is how many extra pods may be created above the desired count, and maxUnavailable is how many may be unavailable during the rollout. maxUnavailable: 0 keeps full capacity throughout.

Q: What is a canary analysis? A: An automated comparison of the canary's metrics (error rate, latency) with the stable version's during a progressive rollout. The rollout is promoted automatically if the canary is healthy, and rolled back if it isn't.