題幹與適用場景
你的平台在 OCI registry 保存映像檔，發布流程還要關聯簽章、SBOM 與漏洞掃描結果。請設計查詢與驗證服務：輸入 repository 名稱和映像檔 digest，回傳關聯制品，支援依 artifactType 篩選，相容尚未實作 Referrers API 的舊 registry，並在部署前阻擋未驗證映像檔。目標職位是後端或平台工程師；題目聚焦 registry 協定與服務邊界，不要求特定雲端 SDK。
面試官考察點
強回答會把映像檔 digest 當成不可變 subject，而不是把 tag 當成身分；理解 subject 建立關聯、artifactType 描述用途、Referrers API 回傳 OCI Index。也要涵蓋舊 registry 的 fallback tag、分頁與快取一致性，以及「發現關聯制品」和「驗證簽章」是不同步驟。只說查映像檔標籤或把 SBOM 當可信證明，代表安全模型不完整。
回答前需要釐清的問題
- 輸入是 tag 還是 digest？若是 tag，先解析成 digest，再固定後續驗證物件。
- 是否必須相容回傳 404 的舊 registry？若必須，實作 OCI fallback tag 並處理並行更新。
- 回傳結果是否用於准入阻擋？若是，驗證簽章、發布者身分與 digest 必須在信任邊界內完成。
- 關聯制品可能超過單頁大小嗎？若是，透傳 opaque
nextToken，不能自行解讀或拼接 token。
30 秒回答框架
「我先把 tag 解析成 digest，所有關聯都以 digest 為 subject。優先呼叫 /v2/{name}/referrers/{digest}，依 artifactType 篩選簽章、SBOM 或報告；舊 registry 回傳 404 時讀取由 digest 產生的 fallback tag。找到制品後再驗證簽章與發布者身分，最後依策略決定是否允許部署。列表介面要分頁、短 TTL 快取，快取鍵包含 digest 與篩選條件。」
分步驟深入解答
OCI 1.1 使用 manifest 的 subject 指向被關聯的 manifest，artifactType 描述關聯制品。Referrers API 回傳 OCI Index，索引項包含 digest、媒體型別與制品型別；查詢路徑是：
GET /v2/{name}/referrers/{subject-digest}?artifactType={type}服務應先拒絕沒有 digest 的驗證請求。tag 只是可變指標，不能作為簽章驗證主鍵。解析 tag 後記錄當下 digest，並把它傳給查詢、快取與部署准入。
遇到支援 API 的 registry，200 空 Index 表示沒有關聯制品；遇到舊實作的 404，客戶端讀取把 sha256: 替換成 sha256- 的 fallback tag。fallback tag 由客戶端維護，追加新 referrer 時存在讀改寫競爭；因此寫入端要用 registry 的並行控制或重試策略，讀取端不能把 fallback 當成強一致事實。
找到簽章、SBOM 與掃描報告後分三步處理：按 artifactType 與發布策略篩選；取得關聯 manifest 與內容；驗證簽章是否涵蓋目標 digest、發布者身分是否在信任根內、制品是否仍為允許狀態。Microsoft 的指引把完整性、真實性與消費前阻擋分開，說明「查得到簽章」不等於「映像檔可信」。
API 結果可能分頁。服務應原樣保存並透傳 opaque nextToken，限制每頁大小，快取鍵使用 registry、repository、subject digest、artifactType 與權限上下文。digest 不可變，列表快取可以短期重用；簽章撤銷或狀態變更仍需要明確 TTL 與重新驗證策略。安全准入路徑中，快取只能加速發現，不能跳過最後驗證。
高品質示範回答
我會把 digest 當成唯一 subject。客戶端先把 tag 解析成 digest，再呼叫 OCI Referrers API 查詢關聯制品；artifactType 用來區分簽章、SBOM 與掃描報告。支援 API 的 registry 回傳 OCI Index，舊 registry 回傳 404 時走由 digest 產生的 fallback tag，並對更新競爭重試。查詢只負責發現，准入服務還要驗證簽章涵蓋的 digest、發布者身分與信任根，再依策略阻擋未驗證映像檔。介面支援 opaque token 分頁，快取鍵包含 digest 與篩選條件；安全路徑每次部署仍重新驗證，避免把快取當信任結論。
常見錯誤
- 錯誤表現 → 用 tag 當簽章主鍵 → 失敗原因是 tag 可被重新指向 → 修正方法是先解析並固定 digest。
- 錯誤表現 → 404 一律當成沒有關聯制品 → 失敗原因是舊 registry 可能未實作 Referrers API → 修正方法是讀取規範定義的 fallback tag。
- 錯誤表現 → 查到簽章就允許部署 → 失敗原因是未驗證發布者身分、涵蓋範圍或映像檔 digest → 修正方法是把發現與密碼學驗證分成兩階段。
- 錯誤表現 → 自行解讀或拼接
nextToken→ 失敗原因是 token 是服務端不透明游標 → 修正方法是原樣透傳，並限制頁大小與逾時。
追問及應對
追問一：fallback tag 更新時兩個建置同時寫入怎麼辦？
把 fallback Index 更新視為讀改寫交易，使用 registry 的條件寫入、樂觀重試或單寫入佇列。寫入失敗時重新讀取最新 Index，再合併新 descriptor；不能覆蓋另一個建置剛寫入的關聯。
追問二：簽章存在但 SBOM 指向舊 digest 怎麼處理？
以目前 subject digest 做一致性檢查。簽章、SBOM 與報告都必須明確關聯同一個 digest；任何關聯物件指向舊 digest，就標記不適用並阻擋准入，不能只按映像檔 tag 名稱匹配。
追問三：registry 回傳大量 referrers，如何避免查詢拖垮服務？
限制 maxResults、透傳 opaque token，並依 digest 與 artifactType 做短 TTL 快取。准入只查策略需要的型別；背景索引可非同步預熱，但最後部署仍需驗證回傳 manifest digest 與信任狀態。