Data Engineering Interview: How Would You Use Iceberg Branches and Tags for WAP?

Prompt and context

A production Iceberg table receives daily increments. Engineers need an isolated write, quality checks, atomic publication, audit markers, and automatic cleanup of old snapshots. Design branches, tags, snapshot references, concurrent commits, retention, and rollback. This is a data question about table-format metadata and release governance.

What the interviewer evaluates

1. Distinguish a mutable branch from an immutable tag.
2. Explain snapshot references, main, and the current snapshot.
3. Design WAP checks, atomic publication, and conflict handling.
4. Configure branch/tag retention without deleting rollback evidence.
5. Prove readers see one consistent snapshot, not partial files.

Clarifying questions to ask

• Do the catalog, engine, and versions support branches, tags, and WAP?
• Do production readers always use main or an explicit reference?
• Which table, partition, and cross-table quality constraints are required?
• Can multiple write branches merge concurrently, and how are conflicts resolved?
• How long must audit points remain, and who cleans orphan files?

A 30-second answer

“I would write each job to an isolated branch and run quality checks against its snapshot. After approval, atomically advance main and create an immutable tag for the audit point. Branches and tags get independent retention rules; expiration can remove only snapshots that are not referenced and meet policy. Compare snapshot IDs, row counts, key metrics, and query results before and after release; conflicts are retried or adjudicated.”

Deep-dive answer

Step 1: Establish the reference model

Iceberg stores branches and tags as snapshot references. A branch is a mutable snapshot chain; a tag points to one snapshot and is suited to releases, month-end closes, and audits. Production main needs an owner, and services must not edit table metadata directly.

main -> snapshot 120
audit-2026-08-01 (tag) -> snapshot 118
daily-load (branch) -> snapshot 121

The diagram shows references; catalog commit checks protect the actual update.

Step 2: Implement Write-Audit-Publish

The write phase commits data and delete files to a work branch without changing main. Audit runs schema, uniqueness, range, row-count, and cross-table checks against that branch snapshot. Only an approved snapshot advances the production reference, with the actor, version, and report recorded.

Step 3: Handle concurrent commits

Optimistic catalog checks reject updates based on an old ancestor. The job must reread the latest snapshot, merge or rebase its change, and rerun required checks. It must not overwrite a reference; even disjoint partition writes need an explicit merge policy.

Step 4: Preserve read consistency

Queries pin a snapshot ID or reference version at start. Publication changes metadata references after data files are complete and readable. Failed jobs may leave unreferenced files, but orphan cleanup waits for the commit and safety windows.

Step 5: Set retention and audit policy

Tags retain important release snapshots; branches can have maximum age and snapshot-count policies. Expiration first computes the snapshots referenced by main, branches, and tags, then removes only eligible history. Audit-tag retention must cover compliance and rollback windows.

Step 6: Design rollback

Rollback moves main to a verified older snapshot or tag and records a new metadata commit. Do not delete the bad snapshot first. Refresh downstream jobs and materialized views, ensuring caches no longer serve the failed version.

Step 7: Define acceptance metrics

Track branch commit latency, check pass rate, publish success, conflict retries, referenced snapshot count, expiration volume, orphan files, and rollback time. Compare snapshot IDs, row counts, key aggregates, and downstream results before expanding rollout.

Model answer

“Daily jobs write to an isolated branch and run checks against a fixed snapshot. Approval atomically advances main and creates an immutable audit tag. Expiration protects every snapshot still referenced by main, a branch, or a tag before cleaning history and orphan files.

Catalog optimistic checks reject stale commits; the job rereads the latest ancestor and reruns validation instead of overwriting a reference. Readers pin a snapshot, and rollback points main to an old tag through a new metadata commit. Acceptance compares snapshot IDs, rows, aggregates, publish success, conflicts, and recovery time.”

Common mistakes

• Treating a branch as immutable → later commits move it → use a tag for audit.
• Overwriting main metadata → bypasses concurrency protection → commit through the catalog.
• Deleting history before rollback → loses evidence → retain the tag and create a new rollback commit.
• Expiring only by age → deletes referenced snapshots → compute the reference set first.
• Not pinning a query snapshot → long reads mix versions → pin a reference or snapshot ID.
• Cleaning orphans immediately → can delete uncommitted files → wait for safety windows.

Follow-up questions and responses

Follow-up 1: Why use a tag for publication?

A branch advances; a tag fixes one snapshot, making it suitable for audit, month-end, and rollback. They can have separate lifecycles.

Follow-up 2: What if two branches write the same partition?

Reject the stale commit, merge from the latest ancestor, or require human adjudication. Never overwrite by filename.

Follow-up 3: Can expiration delete a rollback point?

Not while the snapshot is referenced by a branch or tag and within retention policy. References must be part of expiration’s protected set.

Follow-up 4: How do you prevent partial data reads?

Write files completely first, publish one atomic main snapshot, and keep unpublished branches out of production queries.