D5「保護與最佳化自動化」10 題原創模擬題，附正確答案、解析與常見陷阱。選項順序在互動版會隨機排列。
工作流程寫了 run: echo "${{ github.event.pull_request.title }}"。要防範有人把 PR 標題改成惡意指令，官方首選的做法是什麼？
單選題，選項：
正確答案：把值設成環境變數，指令碼內用 $TITLE 引用
解析：${{ }} 在 shell 執行前就被替換成文字；把值放進中間環境變數，再在指令碼中引用，值就不會被用來產生指令碼本身。更好的做法是改用 action 並把值當引數傳入。
常見陷阱：引號與編碼只是表面處理，攻擊字串仍可能跳脫；真正的修法是讓值不進入指令碼的語法層。
在工作流程設定 permissions: id-token: write，就會讓這個工作流程取得修改雲端資源的寫入權限。
是非題：判斷敘述是否正確。
正確答案：錯誤
解析：id-token: write 只是允許工作流程向 OIDC 提供者請求 JWT，不會給它修改任何資源的權限；能做什麼取決於雲端端的信任條件與角色。
常見陷阱：權限名稱裡的 write 容易讓人以為是寫入資源；它只代表可以請求權杖。
團隊設定了 OIDC，工作流程已有 id-token: write，但雲端端沒有設定任何信任條件。下列說明何者正確？
單選題，選項：
正確答案：必須在雲端端定義至少一個信任條件，例如限定 sub
解析：必須在雲端端至少定義一個信任條件，才能避免不受信任的 repository 向你的雲端資源請求存取權杖；sub 的預設格式例如 repo:組織/儲存庫:environment:環境名稱。
常見陷阱：權杖只供單一 job 使用，並不代表任何 repository 都能換得；缺少信任條件等於沒有限制來源。
依據：Configuring OpenID Connect in cloud providers、OIDC reference
環境的必要審核者最多可以指定幾個人或團隊，核准規則是什麼？
單選題，選項：
正確答案：最多 6 個，其中一人核准即可
解析：必要審核者最多可指定 6 個人或團隊，只要其中一人核准，job 就可以繼續；另可啟用防止自我審核。
常見陷阱：多人審核容易被想成需要多數同意；環境保護規則只要求其中一位核准。
你把第三方 action 釘在 @v4 標籤，之後該 action 的 repository 被入侵，v4 標籤被移到惡意 commit。哪種做法能避免這個風險？
單選題，選項：
正確答案：固定到完整 commit SHA，並確認來自原 repository
解析：標籤可以被移動或刪除；固定到完整 commit SHA（並確認 SHA 來自原 repository 而不是 fork）才不會被改寫。已驗證徽章是有用訊號，但不能取代版本固定與檢視。
常見陷阱：更具體的標籤仍是標籤；已驗證徽章只代表身分已驗證，不代表程式碼沒被入侵。
團隊把 actions 都釘在 SHA 後，不再收到 Dependabot 警示。為了持續得到更新，應該怎麼做？
單選題，選項：
正確答案：啟用 Dependabot version updates 開 PR 更新
解析：Dependabot alerts 不涵蓋釘在 SHA 的 actions，所以不會產生警示；用 version updates 開 PR 把 actions 更新到新版，security updates 則把有弱點的版本升到最低修補版。
常見陷阱：沒有警示不代表沒有弱點；SHA 固定只是讓警示機制看不到這些 actions。
在自管 runner 上有一個長達數天的 job，用 GITHUB_TOKEN 呼叫 API 到後半段失敗。最可能的原因是什麼？
單選題，選項：
正確答案：權杖最多只能更新到 24 小時，更長的要改用其他驗證
解析：自管 runner 的 job 可長達 5 天，但 GITHUB_TOKEN 最多只能更新到 24 小時；更長的 job 要改用 PAT 或其他驗證方式。GitHub 代管 runner 的 job 最長 6 小時。
常見陷阱：權杖壽命綁在 job 與 runner 類型；代管 runner 最長 6 小時，自管 runner 的權杖最多更新到 24 小時，不是固定一個時間。
要為建置出來的二進位檔產生 artifact attestation，工作流程至少需要哪組權限？
單選題，選項：
正確答案：id-token: write、contents: read、attestations: write
解析：官方範例的權限是 id-token: write、contents: read、attestations: write；容器映像還要加 packages: write。消費者再用 gh attestation verify 驗證。
常見陷阱：attestation 要簽章，需要 OIDC 權杖與寫入證明的權限；只有讀取權限無法產生。
工作流程用了 concurrency，想讓同一群組排隊最多 100 個等待中的執行，同時又設定 cancel-in-progress: true。結果如何？
單選題，選項：
正確答案：queue: max 不能與 cancel-in-progress: true 同時使用
解析：queue: max 最多允許 100 個等待中的執行，但不能與 cancel-in-progress: true 同時使用，否則工作流程驗證失敗；群組名稱不分大小寫。
常見陷阱：「取消舊的」與「排隊等待」是相反的策略，兩者不能同時選。
批次作業需要連續執行 8 小時。下列哪種做法符合限制？
單選題，選項：
正確答案：用自管 runner，單一 job 上限是 5 天
解析：GitHub 代管 runner 的單一 job 上限是 6 小時，自管 runner 是 5 天；35 天是整個工作流程執行的上限，不是單一 job。
常見陷阱：35 天看起來最寬鬆，但那是整個執行的總長；單一 job 還是受 runner 類型的限制。