D4「管理企業的 GitHub Actions」17 題原創模擬題，附正確答案、解析與常見陷阱。選項順序在互動版會隨機排列。
組織把 Actions 政策設成只允許組織自己的 actions 與可重用工作流程，沒有勾選任何其他來源。之後工作流程裡的 actions/checkout 會怎樣？
單選題，選項：
正確答案：被封鎖，因為 GitHub 作者的 actions 也不在允許範圍內
解析：只允許組織自己的 actions 會封鎖所有 GitHub 作者的 actions，所以 actions/checkout 也不能用；要放行需另外勾選 GitHub 建立的 actions。
常見陷阱：checkout 幾乎每個工作流程都用，容易假設它永遠可用；政策沒有為 GitHub 自己的 actions 保留例外。
依據：Disabling or limiting GitHub Actions for your organization
在允許的 actions 清單輸入「*, !space-org/action@*」。這代表什麼意思？
單選題，選項：
正確答案：除了 space-org/action 之外，全部允許
解析：樣式以逗號分隔，* 是萬用字元，前面加 ! 表示封鎖；所以這串是除了 space-org/action 的任何版本之外全部允許。清單最多 1000 個樣式。
常見陷阱：驚嘆號容易被讀成「強調」；在這份清單裡它代表封鎖，且預設只有列出的樣式才被允許。
依據：Disabling or limiting GitHub Actions for your organization
組織啟用「要求 actions 固定到完整 commit SHA」後，可重用工作流程仍然可以用標籤來參照。
是非題：判斷敘述是否正確。
正確答案：正確
解析：這個要求適用於組織的 actions 與 GitHub 作者的 actions；可重用工作流程仍可用標籤參照，已被鎖定檔鎖定的相依項目也滿足要求。
常見陷阱：「全部都要釘 SHA」是直覺的解讀；政策把可重用工作流程排除在這個要求之外。
依據：Disabling or limiting GitHub Actions for your organization
企業停用了某項 Actions 政策，某組織的管理員想在自己的組織重新啟用它。結果如何？
單選題，選項：
正確答案：不行，企業停用的政策下層不能再啟用
解析：企業啟用的政策，組織或 repository 還能選擇性停用；企業停用的政策，個別組織與 repository 不能再啟用。組織只能進一步限制，不能放寬。
常見陷阱：政策只往更嚴格的方向傳遞；覆蓋方向不是「近的優先」，要看企業是啟用還是停用。
公開 repository 要求首次貢獻者的 fork PR 工作流程先經核准。下列哪一類工作流程不受這項核准設定影響，一律執行？
單選題，選項：
正確答案：由 pull_request_target 觸發的工作流程
解析：由 pull_request_target 觸發的工作流程一律執行，不受 fork PR 核准政策影響；這也是它屬於特權觸發條件、需要特別小心的原因。
常見陷阱：核准政策看起來像是對所有 PR 工作流程一視同仁；它管的是 pull_request 這類，不含 pull_request_target。
依據：Disabling or limiting GitHub Actions for your organization
「Allow GitHub Actions to create and approve pull requests」這個設定的預設值是什麼？
單選題，選項：
正確答案：停用，工作流程預設不能建立或核准 PR
解析：這個設定預設停用，工作流程預設不能建立或核准 pull request，需要管理員明確開啟。
常見陷阱：會建立 PR 的自動化很常見，容易以為這是預設能力；它必須手動開啟。
依據：Disabling or limiting GitHub Actions for your organization
團隊停用了自管 runner 的自動更新。新版 runner 釋出後，最多多久內必須完成更新，否則 GitHub 不再把 job 排給它？
單選題，選項：
正確答案：新版釋出後 30 天內
解析：停用自動更新後，必須在新版釋出後 30 天內安裝，否則 GitHub 不再排 job 給它；重大安全更新則會擋住 job 直到更新。
常見陷阱：預設的自動更新是在一週內完成，容易把「一週」和「期限」混為一談；停用後的期限是 30 天。
job 的 runs-on 指定的標籤沒有任何符合的 runner，job 一直留在佇列。多久後會失敗？
單選題，選項：
正確答案：排隊超過 24 小時後自動取消
解析：沒有符合的 runner 時 job 留在佇列，排隊超過 24 小時就會失敗；60 秒是 runner 沒有接起 job 時重新排隊的時間。
常見陷阱：兩個時間都與佇列有關：60 秒是重新排隊，24 小時才是失敗；6 小時則是 GitHub 代管 runner 的 job 執行上限。
組織使用 IP 允許清單，新註冊的自管 runner 連不上 GitHub。除了確認出站 443 之外，還需要做什麼？
單選題，選項：
正確答案：把自管 runner 的 IP 位址加進允許清單
解析：使用 IP 允許清單時，必須把自管 runner 的 IP 位址加進清單；runner 還需要能對外建立 443 的 HTTPS 連線並連到必要網域。
常見陷阱：常見的想法是把 GitHub 的位址加進 runner 端；實際上被擋的是 runner 這一端的來源 IP。
組織預設群組內的自管 runner，預設可以被哪些 repository 使用？
單選題，選項：
正確答案：只有私有 repository，但管理員可以覆寫設定
解析：預設只有私有 repository 能使用群組內的 runner，可以覆寫；官方提醒自管 runner 最好只給私有 repository，因為 fork 的 PR 可能執行危險的程式碼。
常見陷阱：把 runner 加進群組不代表所有 repository 都能用；預設的預設就是只開給私有 repository。
關於以 --ephemeral 註冊的自管 runner，下列哪些正確？（選 2 項）
複選題，選項：
正確答案：註冊後執行完一個 job 就會取消註冊；它的日誌應該轉送到外部的儲存位置保存
解析：暫時性 runner 在執行一個 job 後就由 GitHub 取消註冊，清理由你負責，日誌也要轉送到外部儲存。
常見陷阱：「取消註冊」不等於「清理機器」；機器上的狀態與檔案仍需自己處理。
要為 larger runners 設定靜態 IP 位址範圍，下列哪一項正確？
單選題，選項：
正確答案：需要 Enterprise Cloud，但 macOS 不支援
解析：靜態 IP 範圍需要 GitHub Enterprise Cloud，macOS 的 larger runners 不支援；要在每個 runner 上個別啟用，預設最多 10 個池。
常見陷阱：靜態 IP 不是 larger runners 的預設功能，方案與作業系統都有條件。
同名的 API_KEY 同時存在於組織、repository 與 production 環境。job 指定 environment: production，環境設了必要審核者。實際會怎樣？
單選題，選項：
正確答案：核准後才使用環境的 secret，核准前完全拿不到
解析：環境 secret 優先於同名的 repository 或組織 secret；若環境啟用必要審核者，job 在核准之前無法存取環境 secret。
常見陷阱：「範圍越大越優先」是常見直覺；同名時越具體的層級優先，而且環境還多一道核准關卡。
你寫了 if: secrets.TOKEN != ''，工作流程無效。應該怎麼改？
單選題，選項：
正確答案：放進 job 層級環境變數，再用 env 判斷
解析：secrets 不能直接用在 if 條件；先把它放進 job 層級的環境變數，再用 env context 判斷。
常見陷阱：改存 variable 會把機密暴露在不會遮蔽的位置；問題是 context 的可用範圍，不是引號。
由 Dependabot 事件觸發的工作流程，無法讀取 repository 的一般 secrets。
是非題：判斷敘述是否正確。
正確答案：正確
解析：Dependabot 事件觸發的工作流程拿不到一般 secrets；從 fork 觸發的工作流程除了 GITHUB_TOKEN 之外，也不會傳遞 secrets。
常見陷阱：Dependabot 的 PR 看起來像 repository 內部的 PR，容易以為它和一般分支的工作流程一樣能讀 secrets。
要用 REST API 建立或更新 repository secret，值該如何處理？
單選題，選項：
正確答案：用 LibSodium 與公鑰加密，並帶對應的 key_id
解析：必須先取得該範圍的公鑰與 key_id，用 LibSodium 以公鑰加密 secret 的值，再用 PUT 送出 encrypted_value 與 key_id。
常見陷阱：Base64 只是編碼不是加密，雜湊也無法還原；API 要的是用公鑰加密的結果。
GitHub Free 的組織設定了組織層級的 secrets。組織內的私有 repository 能使用它們嗎？
單選題，選項：
正確答案：不行，Free 的組織 secrets 不能給私有 repository 用
解析：GitHub Free 的組織層級 secrets 與 variables 不能被私有 repository 存取；要讓私有 repository 使用，需要更高的方案。
常見陷阱：存取政策設成所有 repository 看似涵蓋全部，但方案限制先於政策。