Describe a robust strategy for GitOps database schema migrations
Tests imperative-to-declarative schema reconciliation. Strong answers version idempotent pre-sync jobs and colocate schema state in Git. They use dedicated operators, not infra tools, for live execution.
What's really being asked
This question tests whether you understand the impedance mismatch between imperative stateful operations like database schema migrations and declarative stateless GitOps workflows. Interviewers want to see that you recognize why tools like Argo CD or Flux cannot naively apply schema changes the way they apply Kubernetes manifests, and that you can design a pipeline where Git remains the source of truth without pretending that a database schema is just another YAML file.
The full answer
A good answer hits four things in order. First, version control: migration files live in the same Git repository as application code, using tools like Flyway, Liquibase, or golang-migrate, with sequential or timestamped filenames so ordering is explicit. Second, execution mechanics: migrations run as idempotent jobs triggered before the application deployment, such as Argo CD pre-sync hooks, Kubernetes Jobs, or init containers, ensuring the schema is ready before new app code starts. Third, safety and rollback: the strategy includes backward-compatible migrations, expand-contract patterns for zero-downtime deploys, and a clear rollback path that does not rely on Git revert alone because you cannot un-apply a destructive ALTER TABLE. Fourth, separation of concerns: infrastructure tools like Terraform manage the database instance and credentials, while schema tools manage the logical state inside it; never let Terraform execute live schema changes.
The mistakes people make
Common wrong answers include suggesting Terraform should manage schema state via SQL providers, which couples infrastructure and data lifecycle and risks partial failures. Another red flag is proposing that the application itself runs migrations on startup in a distributed system, which creates race conditions when multiple replicas start simultaneously. Saying you will just have a manual step for schema changes also undermines the GitOps goal of full automation and auditability.
What usually comes next
Interviewers often follow up by asking how you handle long-running migrations on large tables without locking, how you manage secrets for database credentials in a GitOps pipeline, or how you would recover if a migration fails halfway through and leaves the database in a dirty state. They may also ask how to keep schema changes backward compatible across multiple microservices sharing a database.
A concrete example
Imagine a team using Argo CD and Flyway. The Git repo contains a migrations directory with V001__add_index.sql. The Argo CD Application manifest defines a pre-sync hook that runs a Kubernetes Job using the Flyway container against the database. The job must complete successfully before the app Deployment sync proceeds. If the migration fails, the sync aborts, the app does not roll out, and an alert fires. For a large table, V001 uses an online DDL tool like pt-online-schema-change or native ONLINE ALTER to avoid locking, and the application code is deployed only after the schema change succeeds.
Interview question
In a GitOps pipeline deploying a microservice to Kubernetes, which approach best handles database schema migrations while preserving declarative source-of-truth principles?
- a.Embed migration logic in the application startup so each replica synchronizes schema before serving traffic
- b.Keep migrations outside of Git and require a DBA to run them manually prior to each Argo CD sync
- c.Use Terraform with a SQL provider to manage both the database instance and the live schema state in a single declarative apply
- d.Version migration files in Git and execute them through an idempotent pre-sync job using a dedicated schema tool, separate from infrastructure provisioningCorrect
Why? this is the answer
Versioned migration files executed by a dedicated schema tool via a pre-sync hook preserve Git as the source of truth while ensuring the schema is ready before the app starts. Using a Terraform SQL provider to manage live schema state incorrectly couples infrastructure provisioning with imperative data lifecycle operations and risks partial failures.
Just read this? Test yourself on what you have been reading.
Read the original → thenewstack.io
- #gitops
- #database
- #schema-migrations
- #cicd
- #kubernetes
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on gitops — each one lists the topics its interview covers.
See open roles