D6 模擬題：實作護欄與課責

Question 1

團隊的分級規則是：出錯後無法靠 revert PR 還原的動作才需要人工核准，其餘交給 CI 與 review。下列哪些動作可以不設人工核准？

Accepted Answer

修改正式環境 workflow 的排程時間；調整正式站的樣式表並重新部署。D6-O1 要求依風險分類代理的動作，決定人工介入的程度；這題的分級規則是「能不能用 revert 還原」。workflow 排程與樣式表都存在 repository 中，出錯時 revert PR 再部署即可還原，交給 CI 與 review 把關就夠了，不需要人工核准。刪除的資料列不會因為 revert 遷移檔而回來，寄出的信也收不回，這兩項仍需人工核准。

Question 2

你想在 cloud agent 執行 shell 指令前，自動擋下危險指令（例如 rm -rf）。關於 preToolUse hook，哪些敘述正確？

Accepted Answer

可回傳 deny 並附上拒絕理由；腳本崩潰時會拒絕該次工具呼叫。hooks 設定放在 repository 的 .github/hooks/*.json，只有 preToolUse 能核准或拒絕工具呼叫：輸出 permissionDecision 為 deny，並附上 permissionDecisionReason（拒絕時必填）。preToolUse 採 fail-closed，腳本崩潰或以非零代碼結束都會拒絕該次呼叫；但逾時是例外，會 fail-open 讓工具繼續執行。postToolUse 在工具執行後才觸發，無法阻擋。

Question 3

某個人工核准關卡過去一年從未攔下任何變更，但它把關的是正式資料的刪除。依 D6-O2，它屬於應該移除的多餘摩擦。

Accepted Answer

錯誤。D6-O2 要求移除「不實質降低風險」的核准。這個關卡擋的是不可逆的資料刪除，一旦出錯就無法撤回，它降低的是嚴重度，不是出錯頻率；一年沒攔下任何變更，只代表那一年沒有發生錯誤，不代表風險不存在。應該移除的是那些只增加等待、卻不改變結果的核准。

Question 4

動作 X 的成功率是 99%，但失敗時會刪除正式資料；動作 Y 的成功率是 80%，失敗時只會留下一個需要重跑的 draft PR。依 D6-O1，應該如何設定？

Accepted Answer

X 保留人工核准，Y 可以自動執行。D6-O1 依作業、資安與合規風險決定自主程度，風險要同時看出錯的機率與出錯的後果。X 很少出錯，但一出錯就不可逆，需要人工核准；Y 常出錯，但後果只是重跑一個 draft PR，可以自動執行。只看成功率會把兩者的處置顛倒；等成功率達標再放行，對 X 沒有意義，因為它的問題不在成功率。

Question 5

cloud agent 的流程中有四個人工關卡。依 D6-O2，哪一個不實質降低風險、最適合移除？

Accepted Answer

代理推送到自己的 copilot/ 分支前需確認。cloud agent 只能推送到自己的 copilot/ 分支，分支上的變更在合併前本來就要經過 PR 審查，推送前再確認一次不會改變任何結果，只增加等待。其餘三項都實質降低風險：cloud agent 開的 PR 上，workflow 預設要等有寫入權的使用者按下 Approve and run workflows 才執行，避免未經審查的程式碼使用 secrets 與權限；Code Owners 審查保護代理設定檔；資料刪除不可逆。

Question 6

合規要求：cloud agent 每執行一個 shell 指令，都要自動把指令內容與執行結果送到稽核系統；不需要阻擋任何指令。應該設定什麼？

Accepted Answer

postToolUse hook，送出指令與執行結果。postToolUse 在工具執行後觸發，輸入包含工具名稱、參數與執行結果，適合自動送出稽核紀錄；它不能阻擋，而題幹也不需要阻擋。preToolUse 在執行前觸發，拿不到執行結果；移除 execute 會讓代理無法執行任何 shell 指令；要求代理自行回報沒有強制力，也可能遺漏。

Question 7

你希望 .github/agents/ 被修改時，自動請平台團隊審查，但團隊人力有限，不能因此擋住合併。應該設定什麼？

Accepted Answer

只用 CODEOWNERS 指定平台團隊，不啟用審查規則。CODEOWNERS 會在 PR 修改到對應路徑時，自動請擁有者審查；只有再搭配 ruleset 的「Require review from Code Owners」，擁有者的核准才會成為合併條件。題幹要的是通知而不阻擋，所以只設定 CODEOWNERS 即可。注意 draft PR 不會自動請擁有者審查，要等標記為 ready for review 才會通知；cloud agent 開的是 draft PR，所以審查請求會在它轉為 ready 時送出。要求 Code Owners 審查與要求一位核准都會擋住合併；hook 直接禁止代理修改，也不會請任何人審查。

Question 8

代理要調整 staging 一個 feature flag 的預設值：隨時可改回，不涉及權限與資料。團隊只要求事後查得到代理做了什麼，不增加人工關卡。哪一種做法最合適？

Accepted Answer

代理直接以受限權杖套用，保留 session log。D6-O1 要求依風險決定自主程度。這個變更可隨時撤回、不涉及權限與資料，屬於低風險，可以讓代理自動執行；session log 已能說明代理做了什麼，符合「事後查得到」。PR 核准與主控台手動套用都增加了人工關卡；以管理員權杖套用則給了超出需求的權限，還多了一道聊天中的核准。

D6 模擬題：實作護欄與課責

第 53 題（D6-O1）

第 54 題（D6-O2）

第 55 題（D6-O2）

第 56 題（D6-O1）

第 57 題（D6-O2）

第 58 題（D6-O2）

第 59 題（D6-O2）

第 60 題（D6-O1）