収録問題 70問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
共有済みコミットの変更を安全に打ち消したい。適切な操作はどれですか？
答え： git revertで逆変更コミットを作る
revertは公開履歴を書き換えず逆変更を追加するため、共同作業に適します。
機能ブランチへmainの最新変更を取り込み、共同作業者の履歴を壊したくない。適切なのはどれですか？
答え： mainをfeatureへマージする
共有ブランチではマージなら既存コミットIDを保持したまま変更を統合できます。
誤って別ブランチに作成した1コミットだけを現在のブランチへ取り込みたい。使う操作はどれですか？
答え： git cherry-pick <commit>
cherry-pickは指定コミットの変更を現在のブランチへ新しいコミットとして適用します。
コミット前に一部の変更だけをステージングし、残りを後のコミットへ分けたい。適切なのはどれですか？
答え： git add -p
git add -pは差分をハンク単位で選んでステージングできます。
秘密鍵を直前の未公開コミットへ誤って含めた。最初に行うべき対応はどれですか？
答え： 鍵を失効・交換し、履歴から除去して再発防止する
秘密は履歴に残り得るため、漏えい前提で失効・交換し、履歴除去とシークレットスキャン等を行います。
レビューしやすいPull Requestにする方法として最も適切なのはどれですか？
答え： 目的を1つに絞り、小さな差分と検証方法を説明する
小さく目的が明確なPRは影響範囲と検証方法を把握しやすくします。
競合解消後に必ず行うべき確認はどれですか？
答え： 競合マーカーがなく、テストと差分確認が通ること
競合解消は構文上成功しても意味的に壊れるため、差分とテストの確認が必要です。
追跡中ファイルを手元には残し、今後はGit管理から外したい。適切なのはどれですか？
答え： git rm --cached後に.gitignoreへ追加する
.gitignoreは既に追跡中のファイルには効かないためインデックスから外す必要があります。
障害を導入したコミットを多数の候補から効率よく特定したい。適切なのはどれですか？
答え： git bisectで良否を二分探索する
bisectは既知のgood/bad間を二分探索し、テストを組み合わせて原因を絞れます。
一時的に作業中変更を退避して緊急修正ブランチへ移りたい。適切なのはどれですか？
答え： git stash pushで退避し、後で復元する
stashは未完成の変更を一時退避し、作業ツリーを切替可能な状態にします。
リリース時点を後から確実に参照し、署名や説明も残したい。適切なのはどれですか？
答え： annotated tagを作成する
annotated tagはタグ作成者・日時・メッセージを持ち、署名も利用できます。
巨大な生成物やバイナリを通常のGit履歴へ繰り返し追加する問題はどれですか？
答え： 履歴が肥大化しcloneやfetchが遅くなる
Git履歴は過去版を保持するため大きなバイナリは容量と転送コストを増やします。
mainへの直接pushを防ぎ、レビュー済み変更だけを取り込みたい。適切なリポジトリ設定はどれですか？
答え： ブランチ保護ルールでPRレビューと必須チェックを要求する
保護ルールは直接pushを制限し、レビューやチェック成功をマージ条件にできます。
履歴を書き換えるrebaseを安全に使いやすい場面はどれですか？
答え： まだ共有していない自分のローカルブランチを整理するとき
未共有履歴なら他者の参照を壊さずコミット整理ができます。
force pushが必要な自分専用ブランチで、他者の更新を誤って消すリスクを下げる方法はどれですか？
答え： --force-with-leaseを使う
--force-with-leaseは想定したremote先端から変わっていない場合だけ更新します。
CIの主な目的として最も適切なのはどれですか？
答え： 小さな変更を頻繁に統合し、自動検証で問題を早期発見する
CIは変更を早く統合・検証し、競合や欠陥の発見を前倒しします。
同じコミットをステージングで検証後、本番へ昇格したい。適切な方法はどれですか？
答え： 一度ビルドした不変なアーティファクトを環境間で昇格する
同一アーティファクトの昇格は検証物と本番物の差を防ぎます。
不安定なテストが時々失敗する。適切な対応はどれですか？
答え： 原因を特定して修正・隔離し、無条件retryで隠さない
不安定なテストを放置するとCIへの信頼が下がり、本物の障害も見逃します。
DBスキーマ変更を後方互換に展開する基本方針はどれですか？
答え： expandで追加し両版対応後、切替を確認してcontractする
expand/contractは旧新アプリが混在する期間の互換性を保ちます。
本番デプロイ直後の異常を早く検出する方法はどれですか？
答え： 重要SLIとエラー率を自動監視し、閾値超過で停止・ロールバックする
リリース判定には利用者影響を表す複数の指標と自動guardrailが有効です。
ブルーグリーンデプロイの特徴はどれですか？
答え： 旧新2環境を用意し、トラフィック切替でリリースとロールバックを行う
blue-greenは切替前検証と迅速な戻しをしやすい一方、二重環境コストがあります。
カナリアリリースの狙いはどれですか？
答え： 一部利用者へ新バージョンを出し、指標確認後に段階拡大する
カナリアは影響範囲を限定して本番挙動を検証します。
パイプラインシークレットの扱いとして適切なのはどれですか？
答え： secret storeから短期資格情報を取得し、ログをmaskして最小権限にする
短期・最小権限・非表示により漏えい時の影響を抑えます。
依存パッケージの再現性を高める方法はどれですか？
答え： ロックファイルをコミットし、CIで固定バージョンを検証する
ロックファイルは同じ依存解決結果を共有し、予期せぬ更新を減らします。
CIキャッシュ設計で避けるべき問題はどれですか？
答え： 不十分なキーで異なる依存状態のキャッシュを誤共有する
誤ったキャッシュヒットは古い依存物を使い、再現しにくい障害を生みます。
並列ジョブを増やす前に考えるべきことはどれですか？
答え： 依存関係、共有リソース競合、コスト、律速区間を測る
並列化は高速化できますが、競合・コスト・順序違反を招く場合があります。
本番デプロイジョブに適した保護はどれですか？
答え： 保護環境、承認、限定資格情報、監査ログを設定する
本番は権限と実行条件を絞り、誰が何を出したか追跡可能にします。
パイプライン自体の変更を安全に行う方法はどれですか？
答え： コードレビューし、検証環境またはdry-runで確認して段階反映する
パイプラインは本番経路を制御するコードなので、アプリ同様のレビューと検証が必要です。
供給網攻撃を減らすパイプライン対策はどれですか？
答え： 外部アクションや依存を信頼済みversion/SHAへ固定し検証する
固定と検証により上流の予期しない変更をそのまま実行するリスクを下げます。
長時間パイプラインを改善する最初の一手はどれですか？
答え： 各stage/jobの時間を計測し、緊急度Criticalパスを特定する
測定により本当の律速を特定してからキャッシュ・並列化・テスト分割を選べます。
GitHub ActionsでワークフローをPull Request作成時に動かす基本設定はどれですか？
答え： on: pull_request
onはワークフローを開始するイベントを定義します。
ジョブBをジョブA成功後にだけ実行したい。使うキーワードはどれですか？
答え： needs
needsでジョブ間の依存関係を宣言できます。
古いコミットのデプロイをキャンセルし、同一環境への多重デプロイを防ぎたい。使う設定はどれですか？
答え： concurrencyとcancel-in-progress
concurrency groupで同じ対象のrunを制御し、古いrunをキャンセルできます。
GITHUB_TOKENを安全に使う方針はどれですか？
答え： workflow/jobのpermissionsを必要最小限に明示する
permissionsを限定すると侵害されたステップの影響範囲を小さくできます。
複数リポジトリで同じデプロイ手順を保守したい。適切な機能はどれですか？
答え： reusable workflow
reusable workflowはワークフロー全体を共通化し、callerから入力を渡せます。
複数OS・複数バージョンで同じテストを実行したい。使う機能はどれですか？
答え： strategy.matrix
matrixは変数の組合せごとにジョブを展開します。
外部アクション参照の改ざんリスクを最小化する最も厳格な方法はどれですか？
答え： 検証済みの完全コミット SHAへpinする
完全SHAは実行コードを特定コミットへ固定します。更新は監査して明示的に行います。
本番デプロイ前に承認と環境シークレットを適用したい。使うものはどれですか？
答え： GitHub Environmentsの保護ルールとシークレット
環境は対象ジョブへ承認規則や環境別シークレットを適用できます。
フォーク由来PRのワークフローでシークレットを扱うときの安全な考え方はどれですか？
答え： 信頼できないコードへシークレットや書き込みトークンを渡さず、権限昇格イベントを慎重に分離する
フォークのコードは攻撃者が制御可能とみなし、機密処理と分離します。
失敗したワークフローの調査で最初に見るべきものはどれですか？
答え： 失敗job/stepのログ、入力コンテキスト、直前の変更
失敗箇所のログと変更差分から、権限・入力・環境・コマンド失敗を切り分けます。
同じリポジトリの現在の作業を保ったまま、別ディレクトリで緊急ホットフィックス用ブランチを同時にチェックアウトしたい。適切な機能はどれですか？
答え： git worktree add
git worktreeは1つのリポジトリへ複数のworking treeを関連付け、別ブランチを並行して扱えます。不要になったworktreeはGitのコマンドで削除します。
誤ったresetでブランチから見えなくなった直前のコミットを、ガベージコレクション前に探して復元したい。まず確認するものはどれですか？
答え： git reflogでHEADやブランチの移動履歴を確認する
reflogはローカルで参照が指していた過去のオブジェクトIDを記録します。目的のコミットを特定し、新しいブランチ作成やcherry-pickで到達可能に戻せます。
長期ブランチで同じ競合を何度も解消している。過去の解消内容を記録し再利用するGit機能はどれですか？
答え： git rerere
rerereは競合の形と手動解消結果を記録し、同じ競合が再発した際に解消案を再適用します。適用結果は必ずレビューとテストを行います。
サブモジュールを含むリポジトリをclone後、親リポジトリが記録したコミットのサブモジュール内容まで取得したい。代表的な操作はどれですか？
答え： git submodule update --init --recursive
サブモジュールは親リポジトリが特定コミットを記録します。initと更新で設定・チェックアウトし、recursiveで入れ子のサブモジュールも処理します。
リリースタグが承認された担当者によって作成され、内容が改ざんされていないことを利用者が検証できるようにしたい。適切なのはどれですか？
答え： 署名付きannotated tagを作り、信頼する公開鍵やアイデンティティでverifyする
署名はタグオブジェクトと対象コミットへの結び付きを検証可能にします。鍵やアイデンティティの信頼設定、失効、CIでの検証も運用します。
CIからクラウドへデプロイする際、長期アクセスキーをシークレットへ保存せず短期認証情報を取得したい。適切な方式はどれですか？
答え： CIのOIDCのIDをクラウドIAMへ連携し、限定ロールを一時的に引き受ける
OIDCフェデレーションはリポジトリ、ブランチ、環境等のクレームを条件に短期認証情報を発行できます。ロールは最小権限と短いsession durationで設計します。
リリース成果物に含まれる依存コンポーネントとバージョンを、脆弱性対応やライセンス確認のため記録したい。生成するものはどれですか？
答え： SBOM
SBOMはsoftwareを構成するパッケージ、バージョン、識別子等のインベントリです。アーティファクトと対応付け、標準形式で保存し継続的な脆弱性照合に使います。
本番へ届いたアーティファクトが、承認済みリポジトリとパイプラインで生成され途中で差し替えられていないことを確認したい。必要な仕組みはどれですか？
答え： アーティファクトダイジェスト、署名、検証可能なビルド来歴を生成しデプロイ時に検証する
ダイジェストは内容、署名と来歴は作成主体・ビルド情報との結び付きを検証します。デプロイポリシーで期待するアイデンティティやソースリビジョンを強制します。
同じバージョンのデプロイジョブを再実行しても、二重登録や設定破損を起こさず同じ状態へ収束させたい。必要な性質はどれですか？
答え： デプロイ処理をidempotentに設計する
idempotentなデプロイは現在状態を確認し、同じ入力から同じ目標状態へ収束します。retry、resume、部分失敗からの復旧を安全にします。
コードのデプロイと利用者への新機能公開を分離し、問題時に再デプロイなしで無効化したい。使う方法はどれですか？
答え： 管理・監査された機能フラグを使う
機能フラグはデプロイ済みコードの経路を対象ユーザーや割合ごとに制御します。オーナー、期限、既定値、障害時動作を決め、不要flagは削除します。
デプロイ後のエラー率とレイテンシが閾値を超えたとき、影響拡大を防ぐパイプライン設計はどれですか？
答え： 観測windowとhealth基準を定義し、自動停止またはロールバックする
技術的なデプロイ完了とアプリケーションの健全性は別です。SLOに対応するメトリクスを一定時間評価し、カナリア停止やロールバックの条件を事前定義します。
Pull Requestごとに統合済みアプリケーションを確認し、マージ時に自動削除される検証環境が欲しい。適切なのはどれですか？
答え： PR単位のephemeral preview 環境
プレビュー環境はPRリビジョンを独立URLで統合確認できます。データ分離、シークレット最小化、TTLとクリーンアップ、コスト上限を自動化します。
IaCで定義した状態と本番クラウドリソースの手動変更との差を検知・是正したい。基本方針はどれですか？
答え： 定期的にplan/drift detectionを行い、承認済みコード変更からreconcileする
ドリフトを可視化し、意図した変更はコードへ反映してレビュー後に適用します。緊急手動変更にも事後記録とコードへの取り込み手順を持ちます。
リリース成果物の保存期間を決める際、適切な考え方はどれですか？
答え： ロールバック・監査・法令要件に合わせ、不変なアーティファクトとメタデータへ保持ポリシーを設定する
再デプロイやロールバックに必要なバイナリ、ダイジェスト、SBOM、来歴を対応付けて保持します。保存コストと要件から期限を定め、削除も監査可能にします。
破壊的変更を含むリリースのバージョンと変更内容を利用者へ一貫して伝えたい。適切な運用はどれですか？
答え： Semantic Versioning等の規約に従いmajorを更新し、machine-readable changelog/release notesを生成する
versioning規約とrelease notesを自動化すると互換性判断とupgrade計画を支援できます。APIマイグレーション方法とdeprecation期間も明示します。
ビルドジョブで作ったバイナリを別ランナーのデプロイジョブへ渡したい。GitHub Actionsで使う方法はどれですか？
答え： ビルドでアーティファクトをアップロードし、デプロイで同じアーティファクトをダウンロードする
ジョブは通常別ランナーで実行されるため、アーティファクトサービスを介して不変のなビルド出力を渡します。ダイジェスト確認と保持も設定します。
ジョブAで計算した短いバージョン文字列をジョブBのステップで利用したい。適切な受け渡しはどれですか？
答え： ステップ出力をjob outputsへ公開し、ジョブBからneeds.A.outputsで参照する
ジョブの出力は依存ジョブへ小さな値を明示的に渡すcontractです。大きなファイルはアーティファクト、機密値はシークレット機構など用途に応じて分けます。
依存関係キャッシュがロックファイル変更後も古い内容を誤利用しないようにしたい。キャッシュキーの基本設計はどれですか？
答え： OS・ランタイムバージョン・ロックファイルのハッシュ等をキーに含める
依存解決へ影響する入力をキーへ含めると、互換性のあるキャッシュだけを再利用できます。リストアキーは不完全一致のリスクを理解して限定します。
外部サービス停止でジョブが永久待機しランナーを占有するのを防ぎたい。GitHub Actionsで設定するものはどれですか？
答え： 適切なtimeout-minutes
timeout-minutesはジョブまたはステップの最大実行時間を制限します。コマンド自身のnetwork timeoutやクリーンアップも併用し、異常終了を可観測にします。
セルフホストランナーで信頼できないフォーク元PRのコードを実行する際の主なリスクと対策はどれですか？
答え： host・ネットワーク・残存認証情報を侵害され得るため、実行させず必要なら使い捨て隔離ランナーと最小権限を使う
セルフホストランナー上のコードはホストの権限とネットワーク到達性を悪用し、次ジョブへ残存物を置けます。信頼ゾーンを分離し、使い捨て（ephemeral）化、外向き通信の制御、短期認証情報を組み合わせます。
同じファイルの変更Aをgit addした後、変更Bを追加しました。次のコミットに入る変更Aだけを確認するコマンドはどれですか？
答え： git diff --cachedで、HEADとインデックスを比較する
コミット対象は作業ツリー全体ではなくインデックスです。git diff --cachedはHEADからステージ済み状態への差分を表示します。add後の編集Bは、追加でステージしない限り入りません。
app.pyを誤ってステージしました。ファイルの編集内容を残し、ステージだけを解除するにはどうしますか？
答え： git restore --staged app.pyで、インデックスだけを戻す
--stagedだけを指定すると、既定ではHEADを元にインデックスを戻し、作業ツリーは変更しません。--worktreeも指定すると編集内容まで戻るため、対象を区別します。
作業ツリーがクリーンな状態でgit mergeを始め、競合しました。まだコミットしておらず、このマージを取りやめて開始前へ戻したい場合はどうしますか？
答え： git merge --abortで、進行中のマージを中止する
merge --abortは進行中のマージを中止し、開始前の状態への復元を試みます。開始時から未コミット変更がある場合は復元できないケースがあるため、ここではクリーンな開始を前提にしています。
git bisect中、あるコミットだけが対象不具合と無関係なビルドエラーで実行できません。原因の判定を歪めないための扱いはどれですか？
答え： 判定不能としてskipし、確定できる範囲で探索を続ける
判定不能なコミットはgit bisect skipで飛ばします。無関係なビルド不良を対象不具合の有無と混同してはいけません。境界近くを飛ばすと原因候補を一つに絞れないことがあり、その場合は候補を追加調査します。
未追跡の新規ファイルも退避したいのに、通常のgit stash pushでは残りました。無視対象の生成物は退避せず、未追跡ファイルを含める方法はどれですか？
答え： git stash push -uで、未追跡ファイルも含めて退避する
-uは未追跡ファイルを含めます。-aは無視対象も含むため、大きな生成物などを巻き込む可能性があります。退避前後のステータスとstashの内容を確認してから作業を切り替えます。
CIが深さ1の浅いcloneを使い、以前のリリースタグを基準に変更履歴を生成できません。元リポジトリには必要な履歴があります。適切な対応はどれですか？
答え： 必要な履歴とタグを取得してから、リリース間の差分を計算する
浅いcloneには過去のコミットが不足しています。必要な深さまで取得するか完全な履歴にし、タグも取得してから比較します。タグ参照だけあっても、必要な履歴が不足する場合があります。
新規のreport.txtがgit statusへ表示されません。無視規則が原因か、どのファイルの何行目で指定されたかを調べるにはどれを使いますか？
答え： git check-ignore -v report.txtで、適用された無視規則を確認する
check-ignore -vは無視規則の定義元、行番号、パターンなどを表示します。追跡済みファイルは通常の確認対象とは異なるため、今回の設問は新規の未追跡ファイルを前提にしています。
設定キーlegacy_modeがいつ追加・削除されたかを調べたい。差分の中でこの文字列の出現数が変わったコミットを手掛かりに履歴を探す場合、使うのはどれですか？
答え： git log -Slegacy_mode -pで、出現数が変化した履歴を探す
git log -Sは指定文字列の出現数が変わる変更を探し、-pで差分も表示します。行を移動しただけなど出現数が変わらない編集は対象外になるため、行の正規表現マッチを調べる-Gとは使い分けます。
Bashのpipefailが無効なCIスクリプトで、失敗するテストコマンドを「test-command | tee result.log」と実行すると成功扱いになりました。適切な修正はどれですか？
答え： pipefailを有効にし、パイプ途中の失敗も終了状態へ反映する
通常のBashパイプラインは最後のコマンドの終了状態を返します。pipefailを有効にすると途中の失敗を検出できます。さらにスクリプト全体が失敗を返すよう、終了状態の確認や終了方針も設定します。
GitHub ActionsのOS別テストで一つが失敗すると、他のマトリクスジョブがキャンセルされます。全OSの結果を集め、失敗は失敗として残す設定はどれですか？
答え： strategy.fail-fastをfalseにし、他のマトリクスジョブを続行する
fail-fast: falseは一つの失敗を理由に他のマトリクスジョブを打ち切らない設定です。continue-on-errorとは異なり、失敗の扱いを成功相当に緩める必要はありません。