DevOps for Data Interview Questions cheat sheet

CI for dbt, infrastructure as code, secrets, containers, and the platform questions that separate pipeline authors from people who can ship them.

Interview PrepIntermediate6 sections

CI/CD for data

What belongs in a pre-merge check for a dbt project?: sqlfluff or sqlfmt, dbt parse, unit tests, and a slim CI build of state:modified+ into a PR schema. A full prod refresh in CI is slow and expensive. The point is to catch compile errors and grain breaks before merge, not to recompute the warehouse.
How does Slim CI work, and what does it miss?: It builds only modified models plus downstream, deferring unchanged refs to production artifacts. It misses issues that only appear on a full refresh or on a source that CI cannot see. Pair it with a nightly full build. Relying on Slim CI alone is how a Sunday full refresh fails.
How do you keep two PRs from writing the same CI schema?: A schema per PR, named with the PR number, and a cleanup job on merge or close. A shared ci schema is a race. The same rule applies to Airflow: do not point every branch at the prod metadata database.
What do you run in CD versus CI?: CI is parse, lint, unit tests, slim build. CD is dbt build against prod (or a release job that Airflow then runs). Do not apply prod from a laptop. Blue-green or a clone-and-swap matters when the build itself is the release.
How do you CI an Airflow repo?: Import every DAG file, run airflow dags test for critical DAGs, and fail on import errors. An import error hides a DAG from the UI entirely. pytest on the business logic modules, not on the DAG file as a script. Top-level Variable.get will fail CI unless you mock it — which is a hint it should not be top-level.

Infrastructure as code

What do you put in Terraform versus dbt versus the orchestrator?: Terraform owns accounts, warehouses, roles, buckets, and networks. dbt owns tables and views inside the warehouse. The orchestrator owns schedules and retries. Putting table DDL in Terraform and privileges in a wiki is how drift starts.
Why is remote state with locking non-negotiable?: Two engineers applying local state will destroy each other's warehouses. S3 plus a lock, or Terraform Cloud, is the minimum. State also contains secrets, so encrypt it and restrict who can read it.
How do you adopt an existing Snowflake account into Terraform without recreating it?: terraform import, or generate config from the provider, then plan until empty. Recreating a production database because you wanted it 'in code' is not a migration. moved blocks, not state mv, for later refactors.
What is prevent_destroy for, and when is it a false sense of safety?: It turns an accidental destroy of a bucket or database into a plan-time error. It does not stop someone from emptying the bucket or dropping the database in the console. Combine it with denied console privileges and an apply-only-from-CI rule.

Secrets and identity

How should a pipeline authenticate to the warehouse?: A role assumed via OIDC from CI or the orchestrator, or a key-pair service user, with credentials fetched at runtime from a secret store. Long-lived access keys in an Airflow Variable or a .env committed to Git are the two most common findings. Rotate automatically or it will not happen.
What is OIDC federation and why do data teams care?: GitHub Actions or GitLab presents a short-lived token that the cloud trusts, so there is no stored cloud key in the repo. The trust policy pins the repo and the branch. It is the correct answer for CI-to-cloud in 2026.
Where must secrets never appear?: Git history, container images, Terraform state you then commit, Airflow logs, and dbt docs. Mask them in logging config. A secret in a log is the second most common leak after Git. Rotating after a leak is part of the answer, not optional.
How do you scope a pipeline's IAM role?: One role per pipeline, s3:GetObject and PutObject on the exact prefix, ListBucket on the bucket ARN with a prefix condition. A shared 'data-eng' role that can read the whole lake makes CloudTrail attribution meaningless and every incident larger.

Containers and runtime

What goes in a pipeline Dockerfile, in what order?: Base image, dependency file, install, then source. Dependencies before source so code edits rebuild in seconds. Non-root user, PYTHONUNBUFFERED=1, and a .dockerignore that drops .git and local databases. Running as root is an audit finding and some runtimes reject it.
Why do you pin image tags to a digest or a version, not latest?: latest moves. A rollback then means 'whatever latest was on Tuesday'. Immutable tags plus a Git SHA make deploy and rollback the same operation. latest is for local convenience only.
How do you keep CI image builds fast?: Layer caching (GitHub Actions cache-from), a lockfile, and not copying the whole repo into the build context. A five-minute rebuild on every docs-only change is a process bug. Multi-stage builds drop the compiler from the runtime image.
What does exit code 137 on a container usually mean?: OOM killed. The job exceeded its memory limit. That is a sizing or a code problem, not a 'transient Kubernetes issue'. docker stats and a memory profile beat bumping the limit blindly every week.

Environments

How many warehouse environments do you actually need?: Dev for iteration, a CI schema per PR, and prod. A long-lived staging that nobody resets becomes a second prod with worse data. Clones or zero-copy clones beat a weekly staging refresh that is always stale.
What must be identical across environments, and what must differ?: Code, tests, and role structure identical. Object identifiers, warehouse sizes, and secret values differ. Environment-specific branches of DAG code drift and break on promotion. Config via env vars, not if target.name forks of business logic.
How do you test a migration that might lock or rewrite a large table?: Clone prod, run the change, compare row counts and a checksum, then apply in a window. A migration first tried in prod is a story, not a strategy. Time Travel or a table clone is the warehouse equivalent of a backup.
What is your rollback for a bad dbt deploy?: Revert the Git commit and rebuild the affected models, or swap back a clone taken before the run. Incremental models that already wrote bad data need a bounded re-run, not hope. Rollback is a tested path or it is not a rollback.

Observability of the platform

What do you alert on besides DAG failure?: Freshness SLO misses, warehouse credit burn rate, scheduler parse time, and a drop in source row volume. Success is not the same as on time or correct. A DAG that succeeds in 10 seconds because it loaded zero rows should page.
How do you attribute warehouse cost to a team or a model?: QUERY_TAG or job labels set by the orchestrator, then ACCOUNT_USAGE or INFORMATION_SCHEMA.JOBS. Without tags, cost meetings become folklore. Set the tag in code, never by hand.
A Terraform apply and a dbt run raced. What happened?: Terraform recreated a warehouse or revoked a future grant while dbt was running. Split state by lifecycle and do not apply platform changes during the nightly build window. This is why 'one state file for the company' is an interview smell.
What platform question do you ask in a data-engineer interview if you are the interviewer?: Walk me through how a secret gets from the vault to a running task, and how you would rotate it. The answer reveals whether they have shipped a pipeline or only written SQL in a notebook.

From DataLane — tutorials at/blog, practice SQL live in theplayground.