DevOps Engineer interview question · Most asked
A rollback after a release made the outage worse because the database had already been migrated. How do you design releases so rollbacks are always safe?
Summary
Make every schema change backward compatible with the previous code version, using expand and contract: add new structures first (both versions work), switch code over, and drop old structures only in a later release. Then rolling back the code never meets a schema it can't use.
Longer Answer
Destructive changes (drop, rename, type change) are one-way doors: code can be rolled back, the schema can't. During any rolling update both versions run at once, so compatibility is needed during the deploy too. Enforce it with migration linting in CI, run backfills as background jobs, and test deploy-then-rollback in staging.
Key Points
- Old code must work with the new schema.
- Expand, migrate, contract over several releases.
- Lint migrations for destructive changes.
- Test rollbacks, not just deploys.
Deep dive: DevOps in Production: The Rollback That Made It Worse
Explanation
What interviewers look for
Understanding the code/schema asymmetry and a concrete multi-release pattern.
Follow-up questions
- How would you rename a column on a 500-million-row table?
More most-asked DevOps Engineer questions
- Design a CI/CD pipeline for a containerised microservice from commit to production.
- Every deployment produces a burst of 502s. What do you check?
- How do you handle database schema migrations in an automated deployment pipeline?
- How do you handle secrets in CI/CD pipelines securely?
- What happens when you type a URL into a browser and press Enter?
- Pods keep restarting with OOMKilled under load. How do you investigate and fix it?
- What are DORA metrics, and how would you use them without gaming them?
- Your CI pipeline takes 45 minutes. How would you speed it up?