GitHub Foundations #10 ボーナス — フルスケール模擬試験（50問 + 解説）
読了 29分
#1から#9まで整理してきた概念が頭の中にしっかり定着したかを確認する段階です。実際のGitHub Foundations試験の7ドメイン構成に合わせて50問を解きます。この記事がシリーズの最終回です。
実際の試験では採点対象75問を120分で解きます。本模擬試験は50問構成なので、時間と合格ラインを比例して設定しました。38問（76%）以上正解できれば合格圏と見なして、試験を予約してよいでしょう。
解き方 #
- 90〜110分以内に解いてみます（実際の試験は75問/120分ですが、本模擬試験は50問基準です）
- 1問ずつ解きつつ、すぐに解説を見ずに、最後まで解いてから採点します
- 38問（76%）以上正解できれば合格圏と見なします
- 弱いドメインが見えたら、該当する回（#2〜#9）に戻って整理し直します
ドメイン配分 #
実際の試験のドメイン別比重は公式study guideで公表され、改定されることがあります。本模擬試験はコラボレーション機能とGit・GitHub入門の比重を高めに取った独自の配分です。
| ドメイン | 問題数 | 範囲 |
|---|---|---|
| Domain 1: GitとGitHub入門 | 10 | Q1〜Q10 |
| Domain 2: リポジトリの扱い | 7 | Q11〜Q17 |
| Domain 3: コラボレーション機能 | 14 | Q18〜Q31 |
| Domain 4: モダン開発 | 7 | Q32〜Q38 |
| Domain 5: プロジェクト管理 | 3 | Q39〜Q41 |
| Domain 6: プライバシー・セキュリティ・管理 | 6 | Q42〜Q47 |
| Domain 7: GitHubコミュニティ | 3 | Q48〜Q50 |
Domain 1: GitとGitHub入門（Q1〜Q10） #
Q1. GitとGitHubの関係を正しく説明しているのはどれですか。
解説
Gitは2005年に作られた独立した分散バージョン管理システムで、GitHubはGitリポジトリを置いてPull RequestやIssueといったコラボレーション機能を提供するホスティングサービスです。GitはGitHubなしでも完全に動作し、GitLabやBitbucketなど他のホスティングサービスとも併用できます。
Q2. 次のコミットに含める変更をあらかじめ選んでおくGitの領域はどれですか。
解説
staging areaは次のコミットに入れる変更を選別しておく待機領域です。working directoryはファイルを実際に編集する空間で、repository（.git）はコミットが永久に記録される場所です。3つの領域モデルはGitの動作理解の基本の枠組みです。
Q3. 修正したファイルをstaging areaに上げるコマンドはどれですか。
解説
git addがworking directoryの変更をstaging areaに上げ、git commitがその内容をスナップショットとして確定します。git pushはローカルのコミットをリモートリポジトリへ送るコマンドなので、段階が異なります。
Q4. Gitがコミットごとに保存するものはどれですか。
解説
Gitはデルタではなくスナップショットモデルを使います。コミットはその時点の全ファイルの状態を指す記録で、内容が変わっていないファイルはすでに保存された同一オブジェクトを参照して重複保存を避けます。このモデルのおかげでブランチ作成や時点間の移動が軽いのです。
Q5. git initが実際に行うことはどれですか。
解説
git initがすることは、現在のディレクトリの中に.gitという隠しディレクトリを作ることがすべてです。以後のすべてのコミットと設定がその中に保存されます。リモートリポジトリの作成はGitHubのWebやAPIで別途行い、ファイルの記録はaddとcommitを経る必要があります。
Q6. 分散バージョン管理システムの特徴として正しいのはどれですか。
解説
分散バージョン管理では、cloneしたリポジトリごとに最初のコミットから現在までの全履歴が入っています。だからネットワークがなくてもコミット、ブランチ、履歴照会がすべて可能です。サーバーに接続しないとコミットできない中央集権型システムと区別されるポイントです。
Q7. コミットに記録される作成者の名前とメールアドレスを設定する方法はどれですか。
解説
git config –globalのuser.name、user.email設定が、以後のすべてのコミットの作成者情報として記録されます。GitHubのプロフィールとローカルのGit設定は別物で、コミットのメールアドレスがGitHubアカウントのメールと一致してはじめてコントリビューショングラフに反映されます。
Q8. GitHubのorganizationアカウントを正しく説明しているのはどれですか。
解説
GitHubのアカウントは個人（personal）、organization、enterpriseの階層に分かれます。organizationは個人の所有ではなく、メンバーとチーム単位の権限でリポジトリを共同管理するアカウントです。有料かどうかや二要素認証はアカウント種別とは別の設定です。
Q9. git statusが見せてくれる情報はどれですか。
解説
git statusは、どのファイルが未追跡で（untracked）、修正され（modified）、コミット待ちか（staged）を要約します。履歴の照会はgit logの領域です。statusの出力には次に使うコマンドのヒントも一緒に表示されます。
Q10. コミットオブジェクトに含まれないものはどれですか。
解説
コミットは自分の親だけを指し、未来の子コミットを知ることはできません。履歴は最新のコミットから親の方向へさかのぼって復元されます。スナップショット、親ポインタ、作成者・時刻・メッセージのメタデータがコミットの構成要素です。
Domain 2: リポジトリの扱い（Q11〜Q17） #
Q11. forkを正しく説明しているのはどれですか。
解説
forkはGitHubのサーバー内でリポジトリを自分のアカウントへコピーする機能で、元リポジトリとの連結が残っているためPull Requestで変更を提案できます。ローカルへのダウンロードはgit cloneで、2つは段階が異なります。オープンソース貢献の標準フローがfork後のcloneです。
Q12. template repositoryから新しいリポジトリを作るときの特徴はどれですか。
解説
template repositoryからUse this templateで作ったリポジトリは、ファイルとディレクトリ構造だけを受け継ぎ、履歴は最初のコミット1つから新しく始まります。forkと違って元との連結もありません。プロジェクトのボイラープレートを配布するのに適した方式です。
Q13. タグ（tag）とリリース（release）の関係を正しく説明しているのはどれですか。
解説
タグはv1.0.0のように特定のコミットに付けるGit自体のポインタです。リリースはそのタグを土台に、GitHubがリリースノート、ビルド成果物の添付、ダウンロードページを提供する機能です。リリースを作るとタグが一緒に作成されることはありますが、逆は自動ではありません。
Q14. gistの主な用途はどれですか。
解説
gistはファイル数個程度のコード片、設定例、メモを共有する軽量な手段です。gistの1つ1つがGitリポジトリでもあるため、cloneとバージョン管理が可能です。公開（public）と非公開（secret）から選べます。
Q15. リポジトリのルートにあるREADME.mdファイルが果たす役割はどれですか。
解説
ルートのREADME.mdはリポジトリの最初の画面に自動表示されるドキュメントで、プロジェクトが何であるか、どう始めるかを案内する入口の役割を果たします。リポジトリのdescriptionは別の短い1行フィールドです。プロフィール用の特殊リポジトリのREADMEはプロフィールページに表示されます。
Q16. LICENSEファイルのない公開リポジトリのコードについて正しい説明はどれですか。
解説
ライセンスがなければデフォルトの著作権法が適用され、コードを読むことはできても再利用する法的権利は付与されません。ソースが公開されていることとオープンソースライセンスが付与されていることは別の問題です。だから公開プロジェクトにはLICENSEファイルを明示するのが慣例です。
Q17. internalの可視性（visibility）を持つリポジトリを見られる範囲はどこまでですか。
解説
可視性はpublic、private、internalの3種類です。internalはenterpriseアカウントで使える段階で、同じenterpriseのメンバー全員に見えつつ外部には非公開です。組織内部の共有（InnerSource）に活用される設定です。
Domain 3: コラボレーション機能（Q18〜Q31） #
Q18. Pull Requestの本文に書くと、マージ時に12番のIssueが自動的に閉じられる表記はどれですか。
解説
closes、fixes、resolvesといったクロージングキーワードの後にIssue番号を書くと、PRがデフォルトブランチにマージされた時点で該当Issueが自動的に閉じられます。番号だけを書いたりrefで言及したりすると相互参照リンクが作られるだけで、閉じられはしません。
Q19. ラベル（label）の用途はどれですか。
解説
ラベルはIssueとPRを種類や状態で分類してフィルタリングするタグです。コミットに名前を付けるのはタグ（tag）で、権限はroleで管理するため、それぞれ別の機能です。リポジトリごとにデフォルトのラベルセットが提供され、自由に追加できます。
Q20. マイルストーン（milestone）を正しく説明しているのはどれですか。
解説
マイルストーンはv2.0リリースのように1つの目標の下にIssueとPRをまとめ、完了の割合と期限を一緒に見せてくれます。リリース単位の作業管理に使う道具で、ラベルが分類の軸なら、マイルストーンはスケジュールの軸です。
Q21. Issueテンプレートはどこに置きますか。
解説
Issueテンプレートは.github/ISSUE_TEMPLATEディレクトリにMarkdownまたはYAMLフォーム形式のファイルとして保存します。テンプレートがあると新規Issue作成画面で種類を選ぶ段階が加わり、バグ報告や機能リクエストの品質が一定になります。PRテンプレートは.github/pull_request_template.mdを使います。
Q22. Issueのコメントで@usernameとメンションすると何が起きますか。
解説
メンションは該当ユーザーに通知を送って会話に呼び込む機能です。権限付与やレビュアー指定とは無関係です。チームメンション（@org/team-name）を使うとチームメンバー全員に通知が届きます。
Q23. GitHub Flavored Markdownでチェックリストの項目を作る文法はどれですか。
解説
ハイフンの後に角括弧を付けた
- [ ]が未完了、- [x]が完了の項目です。IssueとPR本文のチェックリストはクリックで切り替えられ、進捗率として集計されます。角括弧の前のリストマーカーと空白があってはじめてチェックボックスとしてレンダリングされます。Q24. GitHub Flavored Markdownで複数行のコードブロックを作る文法はどれですか。
解説
バッククォート3つで囲んだブロックがコードブロックになり、開きのバッククォートの後にpythonのように言語を指定すると構文ハイライトが適用されます。4文字インデントでもコードブロックになりますが言語指定ができないため、バッククォート方式が標準として使われます。
Q25. Pull Requestを正しく説明しているのはどれですか。
解説
PRはブランチの変更を対象ブランチへ合流させてほしいというリクエストで、その上でコードレビュー、コメント、追加コミットが行き交います。git pullコマンドと名前は似ていますが別物で、PRはGit自体ではなくGitHubのようなホスティングサービスの機能です。
Q26. draft Pull Requestの特徴はどれですか。
解説
draft PRは作業方針の共有やCIの事前確認のために早めに開いておく、未完成状態のPRです。draftの間はマージボタンが無効化され、準備ができたらReady for reviewに切り替えて正式なレビューを依頼します。
Q27. Pull Requestのレビューを提出するときに選べる状態でないものはどれですか。
解説
レビュー提出の状態は、意見だけを残すComment、承認するApprove、修正を求めるRequest changesの3つです。Force mergeというレビュー状態は存在しません。Request changesがあると、保護ルールによってはマージがブロックされることがあります。
Q28. CODEOWNERSファイルがすることはどれですか。
解説
CODEOWNERSはパスパターンと担当者（ユーザーまたはチーム）をマッピングするファイルで、該当パスに触れるPRが開かれると担当者が自動的にレビュアーに割り当てられます。branch protectionと組み合わせれば、code ownerの承認なしにはマージできないようにもできます。
Q29. マージ方式のうちSquash and mergeの動作はどれですか。
解説
Squash and mergeはPRの複数のコミットを1つにまとめて対象ブランチに追加するため、デフォルトブランチの履歴がPR単位できれいになります。AはMerge commit、BはRebase and mergeの動作です。どの方式でもコンフリクトは人が解決しなければなりません。
Q30. Issuesの代わりにDiscussionsを使うのに適しているのはどんな場合ですか。
解説
Discussionsは、結論が作業として決まらない対話（質問と回答、アイデア、告知）のための場です。バグと作業の追跡はIssues、行単位のレビューはPR、脆弱性の報告はsecurity advisoryと、それぞれ専用の窓口があります。
Q31. GitHub Pagesを正しく説明しているのはどれですか。
解説
GitHub PagesはリポジトリのHTML、CSS、Markdownコンテンツを静的サイトとしてビルドし、github.ioドメイン（またはカスタムドメイン）で提供する機能です。プロジェクトのドキュメントサイトや個人ページに広く使われています。動的なサーバーコードは実行できません。
Domain 4: モダン開発（Q32〜Q38） #
Q32. GitHub Actionsの用語の階層関係として正しいのはどれですか。
解説
workflowはイベントでトリガーされる自動化プロセスの全体で、その中のjobはrunner1台で実行されるまとまりであり、jobは順次実行されるstepで構成されます。job同士は基本的に並列実行され、needsで順序を付けられます。
Q33. GitHub Actionsのworkflowファイルはどこに、どんな形式で置きますか。
解説
workflowはリポジトリの.github/workflowsディレクトリ（複数形）の下にYAMLファイルとして定義します。ファイルとして管理されるため、コードと一緒にバージョン管理されレビューもできます。Webのエディタはこのファイルを編集するインターフェースにすぎません。
Q34. workflowがいつ実行されるかを定義する方法はどれですか。
解説
onキーがトリガーの定義部です。push、pull_request、schedule（cron）、workflow_dispatch（手動実行）といったイベントを指定できます。runs-onはjobが実行されるrunnerの種類を決めるキーなので、役割が異なります。
Q35. GitHub Actionsのrunnerとは何ですか。
解説
runnerはjobが載って実行される実行環境です。GitHubが提供するホスト型runner（Ubuntu、Windows、macOS）を使うか、自前のサーバーをself-hosted runnerとして登録できます。成果物の保管はartifacts機能の役割です。
Q36. Codespacesとgithub.devエディタの違いはどれですか。
解説
github.devはリポジトリでピリオドキーを押して開く無料のWebエディタで、コードを直してコミットすることはできますが、コードを実行するコンピューティングがありません。CodespacesはクラウドVM上の完全な開発環境なので、ターミナル、ビルド、デバッグ、ポートフォワーディングまで可能です。
Q37. GitHub Copilotを正しく説明しているのはどれですか。
解説
Copilotはエディタの中で文脈に合ったコードを提案し、チャットで質問に答えるAIペアプログラミングツールです。CIはActions、スケジュール管理はProjectsが担当する領域なので、役割を区別しておくと試験問題での混同を避けられます。
Q38. GitHub Packagesを正しく説明しているのはどれですか。
解説
Packagesはnpm、Maven、NuGet、RubyGems、コンテナイメージ（GHCR）などをリポジトリの権限体系のままホスティングするレジストリです。MarketplaceはActionsとアプリを探すマーケットなので性格が異なります。releaseはタグベースの配布ページで、パッケージレジストリではありません。
Domain 5: プロジェクト管理（Q39〜Q41） #
Q39. GitHub Projectsが提供するビューの組み合わせとして正しいのはどれですか。
解説
Projectsは同じデータをスプレッドシート型のtable、カンバン型のboard、スケジュール型のroadmapビューに切り替えて見られます。IssueとPRをitemとして追加し、カスタムフィールドで優先度やサイズといった属性を付けて管理します。
Q40. GitHub Projectsのbuilt-in自動化でできることの例はどれですか。
解説
Projectsのbuilt-in workflowsは、itemの状態変化に反応する自動化です。IssueやPRが閉じられたらStatusをDoneに変えたり、新しく追加されたitemにデフォルトのStatusを指定したりします。コミット作成やレビュー承認といったコード領域の自動化は範囲外です。
Q41. リポジトリのInsightsタブで確認できるものはどれですか。
解説
InsightsはPulseの要約、コミット頻度、コントリビューター統計、トラフィックといったリポジトリの活動データを見せてくれるタブです。セキュリティアラートはSecurityタブ、請求はアカウント設定の領域です。プロジェクトの活動状態を把握する用途だと覚えておけばよいでしょう。
Domain 6: プライバシー・セキュリティ・管理（Q42〜Q47） #
Q42. コードのpush権限なしに、IssueとPRへのラベル付けや担当者の指定といった整理作業ができるリポジトリroleはどれですか。
解説
organizationリポジトリのroleはRead、Triage、Write、Maintain、Adminの5段階です。Triageはコードを修正せずにIssue・PRの整理を担当するコミュニティマネージャーに適した段階です。Writeからpushが可能になり、Adminは設定全体を管理します。
Q43. 二要素認証（2FA）が保護するものはどれですか。
解説
2FAはログイン時にパスワードに加えて、認証アプリのコードやセキュリティキーといった第二の要素を要求するアカウント保護の仕組みです。コードの暗号化や脆弱性スキャンとは無関係です。organizationはメンバーに2FAを必須として強制できます。
Q44. fine-grained personal access tokenがclassicトークンと違う点はどれですか。
解説
fine-grained PATは特定のリポジトリだけを指定し、権限も項目別の読み取り・書き込みレベルまで絞れるため、最小権限の原則に合います。classicトークンはscopeの単位が広く、過剰権限になりがちです。有効期限の設定もorganizationでの利用も、fine-grainedの方がより細かく統制できます。
Q45. branch protectionルールで強制できるものはどれですか。
解説
branch protectionは保護対象のブランチに対して、承認レビューの数、必須status check、直接pushの禁止、force pushのブロックといったルールを強制します。人の習慣の代わりにサーバー設定がルールを守らせる仕組みです。
Q46. Dependabotの機能でないものはどれですか。
解説
Dependabotは依存関係の脆弱性通知（alerts）、セキュリティパッチのPR（security updates）、定期的なバージョン更新のPR（version updates）の3つを担当します。コードスタイルの整理はリンターとフォーマッターの領域で、Dependabotとは無関係です。
Q47. secret scanningのpush protection機能は何をしますか。
解説
push protectionは、APIキーやトークンのような既知パターンのsecretがコミットに入っていると、push自体をサーバーが拒否する機能です。流出後の検知ではなく流出前のブロックだという点が核心です。force pushのブロックはbranch protectionの役割です。
Domain 7: GitHubコミュニティ（Q48〜Q50） #
Q48. InnerSourceを正しく説明しているのはどれですか。
解説
InnerSourceは組織の中でチーム間のリポジトリを開いておき、オープンソースのように貢献をやり取りする文化です。internalの可視性、CONTRIBUTINGドキュメント、PRレビューといったオープンソースの道具がそのまま使われます。コードの公開範囲が組織内部だという点だけが違います。
Q49. CONTRIBUTING.mdファイルの役割はどれですか。
解説
CONTRIBUTING.mdはブランチのルール、コミットの規約、レビューの手順のように、プロジェクトへ貢献する方法を案内するドキュメントです。新しいIssueやPRを開くとき、GitHubがこのドキュメントへのリンクを表示します。ライセンスと行動規範はそれぞれLICENSE、CODE_OF_CONDUCT.mdという別ファイルを使います。
Q50. GitHub Sponsorsを正しく説明しているのはどれですか。
解説
Sponsorsはオープンソースのエコシステムを支える開発者と組織に金銭的な支援を送る機能です。プロフィールとリポジトリにSponsorボタンが表示され、月単位の支援ティアを設定できます。広告や採用とは無関係です。
採点と次のステップ #
- 43問以上 — 十分に準備できた状態です。実際の試験を予約してよいでしょう。
- 38〜42問 — 合格圏です。間違えた問題のドメインを該当の回でもう一度整理してから予約してください。
- 37問以下 — 間違いが集中したドメイン（#2〜#9）に戻って概念を立て直し、数日後にこの模擬試験をもう一度解いてみてください。
実際の試験は本模擬試験より問題数が多く表現も多様ですが、問われる概念の範囲は同じです。機能の名前と役割を正確に対応付ける訓練ができていれば、時間は十分にあります。
以上でGitHub Foundationsシリーズを終わります。