Practice a Permissions Migration Interview

TL;DR

• In this fictional interview, a project application is replacing a broad “editor” role with separate permissions for editing documents, inviting members and exporting data.
• Review results against the approved matrix rather than optimising for identical outputs.
• Use version or migration-state evidence to distinguish untouched records from records a user or administrator has already updated.

Define the permission change before the migration

In this fictional interview, a project application is replacing a broad “editor” role with separate permissions for editing documents, inviting members and exporting data. Existing users must keep legitimate workflows, but document editors should not automatically receive administrative capabilities. The interviewer asks how you would migrate safely.

Start by identifying the intended policy, not by copying old role names into a new table. Ask who owns the policy decision and what existing editor access actually allowed. The migration can expose uncertainty that engineering should not resolve by silently granting every permission.

A successful answer keeps availability and privilege boundaries in view together. Preserving every old capability may contradict the new policy, while revoking everything without planning can interrupt essential work.

Write a mapping with exceptions

Create a small practice matrix showing old state, proposed new state and the evidence needed to approve it. Use fictional accounts rather than real customer data.

Do not infer ownership from recent activity alone. A person who performed an administrative action under the old broad role may not be entitled to retain it under the new policy. Usage evidence can inform a review, but it is not the policy itself.

Record explicit exceptions with an owner and review plan. An unexplained “temporary admin” fallback can become the permanent result of the migration.

Inventory every enforcement path

List web routes, APIs, background jobs, exports, shared links and service-to-service calls that depend on the old role. The migration is not complete when the visible menu looks correct. A hidden endpoint can continue granting the old capability.

Choose how old and new application versions behave during rollout. If some servers understand only the old editor role, switching the database representation alone can produce inconsistent authorization. Discuss compatible deployment stages and the point at which old versions must no longer serve protected operations.

For newly created users during migration, define which model is authoritative. Otherwise, an old signup or invitation path can keep creating records that the backfill has already passed. This is a permissions-policy transition, not merely a one-time data transformation.

Compare decisions without granting shadow access

A shadow comparison can evaluate what the new policy would decide while the current policy remains enforced. Log carefully scoped discrepancies for review without exposing sensitive request contents. A shadow allow should never itself authorise a request.

Separate expected differences from defects. If the new policy deliberately removes export access from ordinary editors, a changed decision is not automatically a regression. Review results against the approved matrix rather than optimising for identical outputs.

Test both allowed and denied cases across project boundaries. Include a user who edits one project but has no membership in another. A migration that preserves capabilities while losing resource scope can be more dangerous than an obvious denial.

Plan rollback around privilege safety

Ask what rollback means if the new policy has intentionally removed a capability. Restoring a previous broad role representation could regrant access that should now remain revoked. A code rollback and a policy rollback are different decisions.

Prefer a recovery plan that can restore service while preserving the approved permission boundary. The exact mechanism depends on the system, but it may involve a compatible enforcement version rather than blindly restoring an old role snapshot. Name the authority needed for any temporary exception.

Our system design frameworks guide can help organise the distinction between data representation, policy decisions and runtime enforcement.

Include an audit view that explains the effective permissions after migration, so support can investigate a denial without granting broad access merely to make the complaint disappear.

Rehearse adversarial transition cases

Have a practice partner introduce a delayed invitation, an old worker processing an export job and a user whose role changes halfway through the rollout. Explain which policy each path checks and how stale state is handled. A cache expiration statement is insufficient unless its delay fits the required policy.

Also test migration reruns. A retry should not overwrite a deliberate post-migration permission change with the original mapping. Use version or migration-state evidence to distinguish untouched records from records a user or administrator has already updated.

Finish with an approval matrix, enforcement inventory and rollback boundary. In the mock interview rehearsal, assess whether your answer names concrete denied cases as well as happy paths. The goal is to explain how the new policy becomes consistently true, not just how a role column gets renamed.