Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Inventory credential issuers, consumers, resources, environments, and machine-to-machine trust. Define identity attestation available on each runtime and the maximum dual-authentication window.
Establish scale assumptions
- Use access logs to map hundreds of workloads and millions of calls, including cron jobs and disaster-recovery paths. Plan issuer capacity for synchronized deployments and token refresh.
Functional and non-functional requirements
- Every workload has a unique attestable identity, permissions shrink to observed and approved need, migration is reversible by cohort, and unknown shared-secret use becomes detectable.
High-level architecture
- Introduce an identity issuer, policy engine, short-lived resource credentials, and sidecar or SDK integration. Resources accept both legacy and identity paths temporarily while logging the resolved principal and policy.
Data model and flow
- A workload attests runtime metadata, receives a scoped token, and exchanges it for resource access. Authorization logs feed least-privilege recommendations that owners review before enforcement.
Consistency and transaction boundaries
- Policy changes are versioned and cached within bounded validity; emergency revocation overrides normal cache. Dual mode does not merge identities—each access records which principal path authorized it.
Failure modes and recovery
- Canary by workload and resource, preserve a time-bounded legacy fallback, and ensure issuer outage affects only new token acquisition. Detect clock skew and refresh storms before broad rollout.
Security and privacy
- Bind identity to workload, environment, and deployment provenance; prevent token forwarding and confused-deputy use. Remove shared credentials from images and CI only after traffic proves zero use.
Observability and SLOs
- Track legacy versus identity calls, denied permissions, unused grants, token age, issuer latency, fallback activation, and ownerless consumers. Gate secret revocation on sustained zero-use evidence.
Capacity and cost
- Token exchange adds infrastructure and calls but removes manual rotation and breach scope. Cache tokens safely and scale issuers regionally without creating independent trust roots.
Alternatives and trade-offs
- Dual acceptance reduces outage risk but extends attack surface; aggressive revocation reduces risk but may break hidden jobs. Time-box dual mode and use observed traffic plus owner sign-off.
Evolution and migration
- Discover, issue identity in audit mode, dual-authorize, enforce per cohort, revoke shared credentials, then delete distribution paths. Repeat in disaster-recovery environments, not only primary production.
What Staff and Principal candidates should emphasize
- Staff answers include unknown-consumer discovery, dual-mode semantics, permission shrinkage, issuer failure, and the evidence required to revoke the old secret.
Decision trade-offs
Authorization rollout
Option A
Switch each resource from secret to identity at once
Option B
Time-bounded dual acceptance with principal telemetry
Recommendation:Use dual acceptance per cohort, then revoke promptly once observed use and owner tests prove the legacy path is idle.
Policy baseline
Option A
Copy existing broad shared permissions
Option B
Derive scoped policy from observed and reviewed need
Recommendation:Use observed access as input, not automatic truth; owners approve least-privilege policy including rare recovery actions.
Follow-up interview questions
- 01How do you discover a monthly job that uses the shared credential?
- 02What prevents one workload from forwarding its token to another?
- 03How does identity work during regional disaster recovery?
- 04When is it safe to delete the old credential?
Common weak answers and mistakes
- 01Giving unique identities the same shared administrator permission and calling it least privilege.
- 02Revoking secrets after only a short observation window.
- 03Ignoring token issuer capacity, clocks, and refresh storms.
- 04Migrating primary services but missing batch and recovery paths.
Interviewer evaluation rubric
Introduces service accounts but cannot discover consumers, shrink permissions, or stage revocation safely.
Uses attestation, short-lived tokens, dual authorization, access telemetry, canaries, and owner review.
Adds provenance binding, confused-deputy controls, issuer resilience, rare-path policy, and zero-use revocation gates.
Turns identity migration into a durable ownership and least-privilege operating model across runtimes, regions, and recovery.