題目
客戶經常因 API key 長期不輪換而暴露風險。請評估是否推出憑證輪換控制台，涵蓋目標使用者、最小可行範圍、雙憑證遷移、稽核與成功指標。
場景與限制
平台同時有個人 key、團隊 key 和服務令牌；客戶把憑證放在 CI、雲函式及本地環境。部分系統無法同時保存兩把 key，部分管理員沒有讀取秘密值權限。輪換必須可暫停、可回滾且不顯示完整秘密。
核心考點
考察能否把安全能力轉成可採用的產品流程。Stripe 將 key 建立、過期和輪換視為生命週期能力；Cloudflare 提供服務令牌輪換動作；GitHub push protection 說明預防洩露與處理繞過請求都需要明確責任邊界。
參考解法
先按憑證類型和客戶部署方式分層。MVP 提供到期提醒、擁有者與範圍、輪換預覽、建立新憑證、短暫重疊、驗證新憑證、撤銷舊憑證和稽核事件；預設只顯示前綴、建立時間及最後使用時間。無法雙憑證運作時提供暫停撤銷、匯出遷移清單和人工確認，而非自動失效。
關鍵細節
輪換流程需具備冪等操作與狀態：預覽、建立、驗證、啟用、撤銷。定義最短重疊時間、未使用舊 key 提醒和異常回滾；通知對象包括擁有者、管理員和安全團隊。指標包括輪換完成率、過期憑證數、輪換導致的失敗請求、平均遷移時間和撤銷後殘餘使用量。
常見誤區
強制所有 key 同日輪換；在介面顯示完整秘密；把最後使用時間當成絕對準確；只做提醒不提供遷移路徑；忽略權限委派、服務帳號和跨區域快取。
評估標準
優秀答案能明確風險分層、MVP 邊界、雙憑證與單憑證兩種路徑、權限和稽核設計，並用失敗率與輪換完成率驗證價值。一般答案只說「增加一個輪換按鈕」。
追問
客戶要求平台自動替換其 CI 秘密，你會承諾嗎？
先確認整合範圍與授權，優先提供短期雙憑證、驗證及回滾；無法確認寫入成功時不撤銷舊憑證，並把人工確認作為明確狀態。
如何處理發現 key 可能洩露的緊急情況？
將緊急撤銷與計畫輪換分開，提供影響範圍、最後使用時間和替代憑證建立；撤銷前顯示不可逆後果，透過稽核和通知記錄決定。
如何防止輪換控制台本身成為秘密洩露面？
採用最小權限、一次性顯示、短期操作令牌、敏感欄位脫敏和完整存取稽核；秘密值留在受控儲存，介面只處理識別與狀態。