Prompt
Customers leave API keys active for years. Evaluate a credential-rotation console, including target users, MVP scope, dual-key migration, auditability, and success measures.
Scenario and constraints
The platform has personal keys, team keys, and service tokens. Customers place credentials in CI, functions, and local environments; some systems cannot hold two keys and some administrators cannot read secret values. Rotation must pause, roll back, and never display the full secret.
What this tests
The test is turning a security capability into an adoptable workflow. Stripe treats key creation, expiration, and rotation as lifecycle capabilities; Cloudflare exposes a service-token rotation action; GitHub push protection shows that prevention and bypass handling need explicit responsibility boundaries.
Reference approach
Segment by credential type and deployment model. An MVP offers expiry reminders, owner and scope, rotation preview, new-key creation, short overlap, new-key verification, old-key revocation, and audit events. Show only prefixes, creation time, and last use by default. For single-key systems, offer a revocation pause, migration checklist, and human confirmation instead of automatic invalidation.
Critical details
Use idempotent operations and states: preview, create, verify, activate, revoke. Define minimum overlap, unused-old-key reminders, and failure rollback. Notify owners, administrators, and security teams. Measure completion rate, expired credentials, rotation-caused failures, migration time, and residual use after revocation.
Common traps
Forcing every key to rotate on one date; displaying full secrets; treating last-use time as perfect; offering reminders without migration; and ignoring delegated permissions, service accounts, or regional caches.
Evaluation rubric
Strong answers define risk tiers, MVP boundaries, dual-key and single-key paths, permission and audit design, and value metrics using failure and completion rates. “Add a rotate button” is insufficient.
Follow-up questions
Would you promise to replace a customer's CI secret automatically?
Confirm integration scope and authorization. Prefer short dual-key overlap, verification, and rollback. If write success cannot be confirmed, do not revoke the old key; expose human confirmation as an explicit state.
How do you handle a key suspected of being leaked?
Separate emergency revocation from planned rotation. Show blast radius, last use, and replacement creation; warn about irreversible impact before revocation and record the decision in audit and notifications.
How do you keep the console from becoming a secret-leak surface?
Use least privilege, one-time display, short-lived operation tokens, redaction, and complete access audit. Keep secret values in controlled storage; the UI handles identifiers and state only.