収録問題 60問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
共有済みコミットの変更を安全に打ち消したい。適切な操作は？
答え： git revertで逆変更コミットを作る
revertは公開履歴を書き換えず逆変更を追加するため、共同作業に適します。
機能ブランチへmainの最新変更を取り込み、共同作業者の履歴を壊したくない。適切なのは？
答え： mainをfeatureへmergeする
共有ブランチではmergeなら既存コミットIDを保持したまま変更を統合できます。
誤って別ブランチに作成した1コミットだけを現在のブランチへ取り込みたい。使う操作は？
答え： git cherry-pick <commit>
cherry-pickは指定コミットの変更を現在のブランチへ新しいコミットとして適用します。
コミット前に一部の変更だけをstagingし、残りを後のコミットへ分けたい。適切なのは？
答え： git add -p
git add -pは差分をhunk単位で選んでstagingできます。
秘密鍵を直前の未公開コミットへ誤って含めた。最初に行うべき対応は？
答え： 鍵を失効・交換し、履歴から除去して再発防止する
秘密は履歴に残り得るため、漏えい前提で失効・交換し、履歴除去とsecret scan等を行います。
レビューしやすいPull Requestにする方法として最も適切なのは？
答え： 目的を1つに絞り、小さな差分と検証方法を説明する
小さく目的が明確なPRは影響範囲と検証方法を把握しやすくします。
競合解消後に必ず行うべき確認は？
答え： 競合マーカーがなく、テストと差分確認が通ること
競合解消は構文上成功しても意味的に壊れるため、差分とテストの確認が必要です。
追跡中ファイルを手元には残し、今後はGit管理から外したい。適切なのは？
答え： git rm --cached後に.gitignoreへ追加する
.gitignoreは既に追跡中のファイルには効かないためindexから外す必要があります。
障害を導入したコミットを多数の候補から効率よく特定したい。適切なのは？
答え： git bisectで良否を二分探索する
bisectは既知のgood/bad間を二分探索し、テストを組み合わせて原因を絞れます。
一時的に作業中変更を退避して緊急修正ブランチへ移りたい。適切なのは？
答え： git stash pushで退避し、後で復元する
stashは未完成の変更を一時退避し、作業ツリーを切替可能な状態にします。
リリース時点を後から確実に参照し、署名や説明も残したい。適切なのは？
答え： annotated tagを作成する
annotated tagはタグ作成者・日時・メッセージを持ち、署名も利用できます。
巨大な生成物やバイナリを通常のGit履歴へ繰り返し追加する問題は？
答え： 履歴が肥大化しcloneやfetchが遅くなる
Git履歴は過去版を保持するため大きなバイナリは容量と転送コストを増やします。
mainへの直接pushを防ぎ、レビュー済み変更だけを取り込みたい。適切なリポジトリ設定は？
答え： branch protection rulesでPRレビューと必須checkを要求する
保護ルールは直接pushを制限し、レビューやcheck成功をmerge条件にできます。
履歴を書き換えるrebaseを安全に使いやすい場面は？
答え： まだ共有していない自分のlocal branchを整理するとき
未共有履歴なら他者の参照を壊さずコミット整理ができます。
force pushが必要な自分専用branchで、他者の更新を誤って消すリスクを下げる方法は？
答え： --force-with-leaseを使う
--force-with-leaseは想定したremote先端から変わっていない場合だけ更新します。
CIの主な目的として最も適切なのは？
答え： 小さな変更を頻繁に統合し、自動検証で問題を早期発見する
CIは変更を早く統合・検証し、競合や欠陥の発見を前倒しします。
同じcommitをstagingで検証後、本番へ昇格したい。適切な方法は？
答え： 一度buildしたimmutable artifactを環境間で昇格する
同一artifactの昇格は検証物と本番物の差を防ぎます。
flaky testが時々失敗する。適切な対応は？
答え： 原因を特定して修正・隔離し、無条件retryで隠さない
flaky testを放置するとCIへの信頼が下がり、本物の障害も見逃します。
DB schema変更を後方互換に展開する基本方針は？
答え： expandで追加し両版対応後、切替を確認してcontractする
expand/contractは旧新アプリが混在する期間の互換性を保ちます。
本番デプロイ直後の異常を早く検出する方法は？
答え： 重要SLIとエラー率を自動監視し、閾値超過で停止・rollbackする
リリース判定には利用者影響を表す複数の指標と自動guardrailが有効です。
blue-green deploymentの特徴は？
答え： 旧新2環境を用意し、トラフィック切替でreleaseとrollbackを行う
blue-greenは切替前検証と迅速な戻しをしやすい一方、二重環境コストがあります。
canary releaseの狙いは？
答え： 一部利用者へ新versionを出し、指標確認後に段階拡大する
canaryは影響範囲を限定して本番挙動を検証します。
pipeline secretの扱いとして適切なのは？
答え： secret storeから短期資格情報を取得し、ログをmaskして最小権限にする
短期・最小権限・非表示により漏えい時の影響を抑えます。
依存packageの再現性を高める方法は？
答え： lock fileをcommitし、CIで固定versionを検証する
lock fileは同じ依存解決結果を共有し、予期せぬ更新を減らします。
CI cache設計で避けるべき問題は？
答え： 不十分なkeyで異なる依存状態のcacheを誤共有する
誤ったcache hitは古い依存物を使い、再現しにくい障害を生みます。
並列jobを増やす前に考えるべきことは？
答え： 依存関係、共有resource競合、コスト、律速区間を測る
並列化は高速化できますが、競合・コスト・順序違反を招く場合があります。
本番deploy jobに適した保護は？
答え： 保護環境、承認、限定資格情報、監査ログを設定する
本番は権限と実行条件を絞り、誰が何を出したか追跡可能にします。
pipeline自体の変更を安全に行う方法は？
答え： code reviewし、検証環境またはdry-runで確認して段階反映する
pipelineはproduction経路を制御するcodeなので、アプリ同様のreviewと検証が必要です。
供給網攻撃を減らすpipeline対策は？
答え： 外部actionや依存を信頼済みversion/SHAへ固定し検証する
固定と検証により上流の予期しない変更をそのまま実行するリスクを下げます。
長時間pipelineを改善する最初の一手は？
答え： 各stage/jobの時間を計測し、critical pathを特定する
測定により本当の律速を特定してからcache・並列化・test分割を選べます。
GitHub ActionsでworkflowをPull Request作成時に動かす基本設定は？
答え： on: pull_request
onはworkflowを開始するeventを定義します。
job Bをjob A成功後にだけ実行したい。使うkeywordは？
答え： needs
needsでjob間の依存関係を宣言できます。
古いcommitのdeployをcancelし、同一環境への多重deployを防ぎたい。使う設定は？
答え： concurrencyとcancel-in-progress
concurrency groupで同じ対象のrunを制御し、古いrunをcancelできます。
GITHUB_TOKENを安全に使う方針は？
答え： workflow/jobのpermissionsを必要最小限に明示する
permissionsを限定すると侵害されたstepの影響範囲を小さくできます。
複数repositoryで同じdeploy手順を保守したい。適切な機能は？
答え： reusable workflow
reusable workflowはworkflow全体を共通化し、callerから入力を渡せます。
複数OS・複数versionで同じtestを実行したい。使う機能は？
答え： strategy.matrix
matrixは変数の組合せごとにjobを展開します。
外部action参照の改ざんリスクを最小化する最も厳格な方法は？
答え： 検証済みの完全commit SHAへpinする
完全SHAは実行codeを特定commitへ固定します。更新は監査して明示的に行います。
本番deploy前に承認と環境secretを適用したい。使うものは？
答え： GitHub environmentのprotection rulesとsecrets
environmentは対象jobへ承認規則や環境別secretを適用できます。
fork由来PRのworkflowでsecretを扱うときの安全な考え方は？
答え： 信頼できないcodeへsecretやwrite tokenを渡さず、権限昇格eventを慎重に分離する
forkのcodeは攻撃者が制御可能とみなし、機密処理と分離します。
失敗したworkflowの調査で最初に見るべきものは？
答え： 失敗job/stepのlog、入力context、直前の変更
失敗箇所のlogと変更差分から、権限・入力・環境・command失敗を切り分けます。
同じrepositoryの現在の作業を保ったまま、別directoryで緊急hotfix branchを同時にcheckoutしたい。適切な機能は？
答え： git worktree add
git worktreeは1つのrepositoryへ複数のworking treeを関連付け、別branchを並行して扱えます。不要になったworktreeはGitのcommandで削除します。
誤ったresetでbranchから見えなくなった直前のcommitを、garbage collection前に探して復元したい。まず確認するものは？
答え： git reflogでHEADやbranchの移動履歴を確認する
reflogはlocalで参照が指していた過去のobject IDを記録します。目的のcommitを特定し、新しいbranch作成やcherry-pickで到達可能に戻せます。
長期branchで同じconflictを何度も解消している。過去の解消内容を記録し再利用するGit機能は？
答え： git rerere
rerereはconflictの形と手動解消結果を記録し、同じconflictが再発した際に解消案を再適用します。適用結果は必ずreviewとtestを行います。
submoduleを含むrepositoryをclone後、親repositoryが記録したcommitのsubmodule内容まで取得したい。代表的な操作は？
答え： git submodule update --init --recursive
submoduleは親repositoryが特定commitを記録します。initとupdateで設定・checkoutし、recursiveで入れ子のsubmoduleも処理します。
release tagが承認された担当者によって作成され、内容が改ざんされていないことを利用者が検証できるようにしたい。適切なのは？
答え： 署名付きannotated tagを作り、信頼する公開鍵やidentityでverifyする
署名はtag objectと対象commitへの結び付きを検証可能にします。鍵やidentityの信頼設定、失効、CIでのverificationも運用します。
CIからcloudへdeployする際、長期access keyをsecretへ保存せず短期credentialを取得したい。適切な方式は？
答え： CIのOIDC identityをcloud IAMへ連携し、限定roleを一時assumeする
OIDC federationはrepository、branch、environment等のclaimを条件に短期credentialを発行できます。roleは最小権限と短いsession durationで設計します。
release artifactに含まれる依存componentとversionを、脆弱性対応やlicense確認のため記録したい。生成するものは？
答え： SBOM
SBOMはsoftwareを構成するpackage、version、識別子等のinventoryです。artifactと対応付け、標準formatで保存し継続的な脆弱性照合に使います。
本番へ届いたartifactが、承認済みrepositoryとpipelineで生成され途中で差し替えられていないことを確認したい。必要な仕組みは？
答え： artifact digest、署名、検証可能なbuild provenanceを生成しdeploy時に検証する
digestは内容、署名とprovenanceは作成主体・build情報との結び付きを検証します。deploy policyで期待するidentityやsource revisionを強制します。
同じversionのdeploy jobを再実行しても、二重登録や設定破損を起こさず同じ状態へ収束させたい。必要な性質は？
答え： deploy処理をidempotentに設計する
idempotentなdeployは現在状態を確認し、同じ入力から同じ目標状態へ収束します。retry、resume、部分失敗からの復旧を安全にします。
codeのdeployと利用者への新機能公開を分離し、問題時に再deployなしで無効化したい。使う方法は？
答え： 管理・監査されたfeature flagを使う
feature flagはdeploy済みcodeの経路を対象userや割合ごとに制御します。owner、期限、既定値、障害時動作を決め、不要flagは削除します。
deploy後のerror率とlatencyが閾値を超えたとき、影響拡大を防ぐpipeline設計は？
答え： 観測windowとhealth基準を定義し、自動停止またはrollbackする
技術的なdeploy完了とapplicationの健全性は別です。SLOに対応するmetricを一定時間評価し、canary停止やrollbackの条件を事前定義します。
Pull Requestごとに統合済みapplicationを確認し、merge時に自動削除される検証環境が欲しい。適切なのは？
答え： PR単位のephemeral preview environment
preview環境はPR revisionを独立URLで統合確認できます。data分離、secret最小化、TTLとcleanup、cost上限を自動化します。
IaCで定義した状態と本番cloud resourceの手動変更との差を検知・是正したい。基本方針は？
答え： 定期的にplan/drift detectionを行い、承認済みcode変更からreconcileする
driftを可視化し、意図した変更はcodeへ反映してreview後に適用します。緊急手動変更にも事後記録とcodeへの取り込み手順を持ちます。
release artifactの保存期間を決める際、適切な考え方は？
答え： rollback・監査・法令要件に合わせ、immutable artifactとmetadataへretention policyを設定する
再deployやrollbackに必要なbinary、digest、SBOM、provenanceを対応付けて保持します。保存costと要件から期限を定め、削除も監査可能にします。
breaking changeを含むreleaseのversionと変更内容を利用者へ一貫して伝えたい。適切な運用は？
答え： Semantic Versioning等の規約に従いmajorを更新し、machine-readable changelog/release notesを生成する
versioning規約とrelease notesを自動化すると互換性判断とupgrade計画を支援できます。API migration方法とdeprecation期間も明示します。
build jobで作ったbinaryを別runnerのdeploy jobへ渡したい。GitHub Actionsで使う方法は？
答え： buildでartifactをuploadし、deployで同じartifactをdownloadする
jobは通常別runnerで実行されるため、artifact serviceを介してimmutableなbuild出力を渡します。digest確認とretentionも設定します。
job Aで計算した短いversion文字列をjob Bのstepで利用したい。適切な受け渡しは？
答え： step outputをjob outputsへ公開し、job Bからneeds.A.outputsで参照する
job outputは依存jobへ小さな値を明示的に渡すcontractです。大きなfileはartifact、機密値はsecret機構など用途に応じて分けます。
dependency cacheがlock file変更後も古い内容を誤利用しないようにしたい。cache keyの基本設計は？
答え： OS・runtime version・lock file hash等をkeyに含める
依存解決へ影響する入力をkeyへ含めると、互換性のあるcacheだけを再利用できます。restore keyは不完全一致のriskを理解して限定します。
外部service停止でjobが永久待機しrunnerを占有するのを防ぎたい。GitHub Actionsで設定するものは？
答え： 適切なtimeout-minutes
timeout-minutesはjobまたはstepの最大実行時間を制限します。command自身のnetwork timeoutやcleanupも併用し、異常終了を可観測にします。
self-hosted runnerで信頼できないfork PR codeを実行する際の主なriskと対策は？
答え： host・network・残存credentialを侵害され得るため、実行させず必要なら使い捨て隔離runnerと最小権限を使う
self-hosted runner上のcodeはhost権限とnetwork到達性を悪用し、次jobへ残存物を置けます。信頼zoneを分離し、ephemeral化、egress制御、短期credentialを組み合わせます。