第1回 問題集（全般）
全120問 ／ すべての問題の解答・解説を無料で閲覧できます
AZ-400 問題集 おすすめの使い方
目次
Azure DevOpsで新しいプロジェクトを作成する際、チームがスクラム（Scrum）のプラクティスに従って作業項目を管理したい。適切なプロセステンプレートはどれですか？
解答・解説を見る
正解: C. C. Scrum
正解の根拠・詳細解説
Scrumプロセステンプレートは、プロダクトバックログ項目（PBI）・スプリント・タスクなど、スクラムの用語に対応した作業項目タイプを提供します。Agileテンプレートはユーザーストーリー、CMMIは要件管理に重点を置いた厳格なプロセス向けです。
チームのカンバンボードで、開発中のタスク数を制限し、ボトルネックを可視化したい場合に設定すべき機能は？
解答・解説を見る
正解: A. A. 列のWIP制限（Work In Progress limit）
正解の根拠・詳細解説
カンバンボードの各列にWIP制限を設定することで、同時進行中のタスク数を制限し、ボトルネックの発生箇所を可視化できます。これによりチームはフローの改善に集中できます。
複数のチームが同じプロジェクト内で異なる機能領域を担当している場合、作業項目をチームごとに分類するために使用する仕組みは？
解答・解説を見る
正解: A. A. エリアパス（Area Path）
正解の根拠・詳細解説
エリアパスは作業項目を機能領域やチームごとに分類するための階層構造です。各チームに特定のエリアパスを割り当てることで、ボードやバックログをチーム単位でフィルタリングできます。
スプリントの期間や開始・終了日を管理するために使用するAzure DevOpsの機能は？
解答・解説を見る
正解: B. B. イテレーションパス（Iteration Path）
正解の根拠・詳細解説
イテレーションパスはスプリント（イテレーション）の期間を定義し、作業項目をどのスプリントに割り当てるかを管理するための機能です。
開発チームのベロシティ（1スプリントあたりに完了できる作業量）を可視化し、今後のスプリント計画に活用したい。適切なAzure Boardsのレポートは？
解答・解説を見る
正解: B. B. ベロシティチャート
正解の根拠・詳細解説
ベロシティチャートは過去のスプリントで完了した作業量（ストーリーポイントなど）を時系列で表示し、今後のスプリント計画における作業量の見積もりに利用されます。
プルリクエストを作業項目（Work Item）にリンクし、コードの変更とビジネス要件のトレーサビリティを確保したい。Azure DevOpsで推奨される方法は？
解答・解説を見る
正解: A. A. プルリクエストの説明欄に作業項目IDを「AB#番号」形式で記載する
正解の根拠・詳細解説
Azure DevOpsでは、プルリクエストやコミットのメッセージに「AB#123」のように記述することで、自動的に該当する作業項目にリンクされ、トレーサビリティが確保されます。
チームの累積フロー図（Cumulative Flow Diagram）が、特定の列で帯が広がり続けている場合、何を示していますか？
解答・解説を見る
正解: A. A. その列での処理が滞留（ボトルネック）している
正解の根拠・詳細解説
累積フロー図である列の帯が時間とともに広がり続けている場合、その工程への流入が処理速度を上回っており、ボトルネックが発生していることを示します。
ステークホルダーに進捗状況を定期的に共有するために、Azure DevOpsで作成・共有できる機能は？
解答・解説を見る
正解: A. A. ダッシュボード（Dashboard）とウィジェット
正解の根拠・詳細解説
Azure DevOpsのダッシュボードは、バーンダウンチャートやスプリント概要などのウィジェットを組み合わせて、チームやステークホルダー向けに進捗状況を可視化・共有できます。
GitHub上のIssueとAzure Boardsの作業項目を連携させ、両方のツールで進捗を同期したい場合に利用する機能は？
解答・解説を見る
正解: A. A. Azure Boards GitHub連携（GitHub Connection）
正解の根拠・詳細解説
Azure Boardsには、GitHub.comリポジトリと連携してIssueとAzure Boardsの作業項目を同期する「GitHub連携」機能があり、両方のツールでステータスを一致させることができます。
チームの作業項目に対するアクセス権限を、特定のエリアパス単位で制御したい場合の方法は？
解答・解説を見る
正解: A. A. エリアパスごとにセキュリティグループの権限を設定する
正解の根拠・詳細解説
Azure DevOpsでは、エリアパスごとに「このノードとその子のみ」といった権限スコープを設定し、特定のチームやグループに限定したアクセス制御を行うことができます。
スプリントレビューやレトロスペクティブの結果を記録し、チーム全体でナレッジを共有するために最適なAzure DevOpsの機能は？
解答・解説を見る
正解: A. A. Wiki
正解の根拠・詳細解説
Azure DevOpsのWiki機能を使うことで、レトロスペクティブの議事録やチームのプロセスドキュメントをMarkdown形式で記録・共有でき、ナレッジの蓄積に役立ちます。
バックログの作業項目に「ビジネス価値（Business Value）」フィールドを設定する主な目的は？
解答・解説を見る
正解: A. A. 優先順位付けの判断材料として、ビジネスへの影響度を数値化するため
正解の根拠・詳細解説
ビジネス価値フィールドは、各バックログ項目がビジネスにもたらす価値を数値で表現し、開発コストと比較しながら優先順位を決定するための指標として活用されます。
チームがOKR（Objectives and Key Results）を活用して四半期ごとの目標を管理したい場合、Azure DevOpsで一般的に採用されるアプローチは？
解答・解説を見る
正解: A. A. 「目標」と「主要な結果」をエピックやフィーチャーとして作業項目に登録し、関連するバックログ項目をリンクする
正解の根拠・詳細解説
Azure DevOpsには専用のOKR機能はありませんが、エピック・フィーチャーといった上位の作業項目をOKRの「目標」「主要な結果」として扱い、関連バックログ項目をリンクすることで進捗を追跡できます。
新しいチームメンバーがプロジェクトに参加した際、過去のスプリントの振り返り内容や設計判断の経緯を確認できるようにするには？
解答・解説を見る
正解: A. A. Wikiやプルリクエストのコメント履歴、作業項目の履歴を活用する
正解の根拠・詳細解説
作業項目の履歴、プルリクエストの議論、Wikiに記録された設計判断などは、オンボーディング時に過去の経緯を理解するための重要な情報源となります。
プロジェクトの透明性を高めるため、ステークホルダーにはAzure DevOpsのコードやパイプライン詳細は見せず、バックログとボードのみ閲覧させたい。適切なアクセスレベルは？
解答・解説を見る
正解: A. A. ステークホルダーアクセス（Stakeholder access）
正解の根拠・詳細解説
ステークホルダーアクセスは無料で付与でき、バックログ・ボード・ダッシュボードの閲覧や作業項目の追加・編集はできますが、リポジトリのコードやビルド/リリースの詳細にはアクセスできません。
チームがスケーリングされたアジャイル（例: SAFe）を採用し、複数チームのバックログを統合的に管理したい場合、Azure DevOpsで活用すべき機能は？
解答・解説を見る
正解: A. A. 複数チームバックログとポートフォリオバックログ（エピック/フィーチャー）の階層管理
正解の根拠・詳細解説
ポートフォリオバックログ（エピック・フィーチャー）を使うことで、複数チームのバックログ項目を上位レベルで集約・管理し、スケーリングされたアジャイル開発を支援できます。
チームのコミュニケーションを効率化するため、Azure DevOpsのビルド失敗やプルリクエスト作成時にMicrosoft Teamsへ自動通知を送りたい場合、設定する機能は？
解答・解説を見る
正解: A. A. サービスフック（Service Hooks）
正解の根拠・詳細解説
サービスフックを使うことで、ビルドの完了・失敗、プルリクエストの作成など特定のイベントが発生した際に、Microsoft TeamsやSlackなど外部サービスへ自動的に通知を送信できます。
プロジェクトのバックログ項目に「受け入れ基準（Acceptance Criteria）」を記載する主な目的は？
解答・解説を見る
正解: A. A. 開発完了の判断基準を明確にし、テストやレビューで確認できるようにするため
正解の根拠・詳細解説
受け入れ基準は、その作業項目が「完了」と見なされるための具体的な条件を記述するもので、開発者・テスター・プロダクトオーナー間で完了の定義を共有するために重要です。
組織内の複数のAzure DevOpsプロジェクトで、共通のプロセステンプレートをカスタマイズして使い回したい場合に使用する機能は？
解答・解説を見る
正解: A. A. 継承プロセス（Inherited Process）
正解の根拠・詳細解説
継承プロセス（Inherited Process）を使うと、既存のプロセステンプレート（Agile/Scrum/CMMIなど）を基にカスタムプロセスを作成し、複数プロジェクトで共通利用できます。
プロジェクト管理者が、各スプリントの「未完了作業の持ち越し」を分析したい場合、確認すべき指標は？
解答・解説を見る
正解: A. A. スプリントごとの完了率とキャリーオーバー（持ち越し）された作業項目数
正解の根拠・詳細解説
スプリントの完了率や持ち越された作業項目数を継続的に追跡することで、見積もりの精度向上やキャパシティ計画の改善に役立てることができます。
チームがDevOpsの導入効果を測定するために重視する「フローメトリクス」に含まれる指標として適切なものは？
解答・解説を見る
正解: A. A. サイクルタイム、リードタイム、スループット
正解の根拠・詳細解説
フローメトリクスは作業の流れの効率性を測る指標で、サイクルタイム（作業開始から完了までの時間）、リードタイム（要求から完了までの時間）、スループット（単位時間あたりの完了数）などが含まれます。
リモートチームと現地チームが混在するプロジェクトで、コミュニケーション戦略として最も適切なものは？
解答・解説を見る
正解: A. A. 非同期コミュニケーション（Wiki、コメント、通知）と定期的な同期ミーティングを組み合わせる
正解の根拠・詳細解説
タイムゾーンが異なるチームでは、Wikiやコメントなどの非同期コミュニケーションを基本としつつ、重要な意思決定には定期的な同期ミーティングを組み合わせることで、情報の透明性と意思決定の速度を両立できます。
Azure DevOpsで、作業項目のカスタムフィールドを追加し、特定の業務要件（例: 顧客名、優先度ランク）を管理したい場合に必要な操作は？
解答・解説を見る
正解: A. A. 継承プロセスでプロセスをカスタマイズし、カスタムフィールドを作業項目タイプに追加する
正解の根拠・詳細解説
継承プロセスを使用している場合、組織設定からプロセスをカスタマイズし、作業項目タイプに新しいカスタムフィールドを追加できます。これにより業務固有の情報を作業項目に記録できます。
チームがカンバンボードで「進行中」列のカードに、ブロッカー（作業を妨げる要因）があることを示したい場合の機能は？
解答・解説を見る
正解: A. A. ブロックタグ（Blocked tag）/ ブロックフラグを設定する
正解の根拠・詳細解説
Azure Boardsのカンバンボードでは、作業項目のカードに対してブロックされている状態を明示できます。代表的な方法はカードにBlockedタグを付け、ボードのスタイル規則でそのタグが付いたカードの色を変えるという構成で、ボードを開いた瞬間に停滞している作業を視覚的に識別できます。組織のプロセステンプレートによっては作業項目にBlockedフィールドが用意されており、その値をカード上に表示させる運用も使われます。いずれの場合も狙いは同じで、デイリースタンドアップやフローの分析時に、どのカードが外部要因で進んでいないかをチーム全員が即座に共有し、滞留時間の短縮につなげることにあります。タスクを削除したりイテレーションを移動したりすると、ブロックが発生したという事実そのものが記録から失われ、後からサイクルタイムを分析してボトルネックを振り返ることができなくなります。またすべてのカードを一律に赤くする運用は情報量を持たず、特定のカードだけを目立たせるという本来の目的を損ないます。
チーム開発において、常にmainブランチをデプロイ可能な状態に保ちながら、短命なフィーチャーブランチで開発を行う手法を何と呼びますか？
解答・解説を見る
正解: A. A. トランクベース開発（Trunk-based Development）
正解の根拠・詳細解説
トランクベース開発は、開発者が頻繁に小さな変更をmain（トランク）にマージし、長命なブランチを避けることで統合の手間を減らし、継続的インテグレーションを促進する手法です。
プルリクエストがmainブランチにマージされる前に、最低1名以上のレビュー承認を必須にしたい場合に設定する機能は？
解答・解説を見る
正解: A. A. ブランチポリシー（Branch Policy）の「最小要求者数」
正解の根拠・詳細解説
ブランチポリシーで「レビュー担当者の最小要求数」を設定することで、指定した人数以上の承認がない限りプルリクエストをマージできないように強制できます。
大きなバイナリファイル（画像、動画、データセットなど）をGitリポジトリで効率的に管理するために使用する技術は？
解答・解説を見る
正解: A. A. Git LFS（Large File Storage）
正解の根拠・詳細解説
Git LFSは、大きなバイナリファイルをリポジトリ本体ではなく別のストレージに格納し、ポインタファイルのみをGit履歴に記録することで、リポジトリのサイズ肥大化を防ぎます。
複数の関連プロジェクトのソースコードを単一のリポジトリで管理するアプローチを何と呼びますか？
解答・解説を見る
正解: A. A. モノレポ（Monorepo）
正解の根拠・詳細解説
モノレポは複数のプロジェクトやサービスのコードを1つのリポジトリにまとめて管理する手法で、コード共有や一括変更が容易になる一方、リポジトリサイズやビルド時間の管理が課題となります。
チームがTFVC（Team Foundation Version Control）からGitへの移行を計画している。移行時に考慮すべき重要な点は？
解答・解説を見る
正解: A. A. 履歴の移行方法（git-tfsなどのツール利用）とチームのワークフロー変更への教育
正解の根拠・詳細解説
TFVCからGitへの移行では、git-tfsなどのツールを使って履歴を移行する方法を検討し、また集中型から分散型バージョン管理への移行に伴うチームのワークフローやマインドセットの変化に対する教育が重要になります。
プルリクエストをマージする際、複数のコミットを1つのコミットにまとめてmainブランチの履歴をクリーンに保ちたい場合に使用するマージ方法は？
解答・解説を見る
正解: A. A. スカッシュマージ（Squash merge）
正解の根拠・詳細解説
スカッシュマージは、フィーチャーブランチの複数のコミットを1つのコミットに圧縮してターゲットブランチに統合する方法で、mainブランチの履歴を簡潔に保つことができます。
別のブランチで行われた特定の1つのコミットだけを、現在のブランチに取り込みたい場合に使用するGitコマンドは？
解答・解説を見る
正解: A. A. git cherry-pick
正解の根拠・詳細解説
git cherry-pickは、指定したコミットの変更内容のみを現在のブランチに適用するコマンドで、ホットフィックスを複数のブランチに反映させる際などに利用されます。
誤ってGitの履歴にAPIキーなどの機密情報をコミットしてしまった場合、最も適切な対応は？
解答・解説を見る
正解: A. A. 該当の機密情報を無効化（ローテーション）し、履歴から完全に削除する（git filter-repo等）
正解の根拠・詳細解説
機密情報が履歴に含まれてしまった場合、まず該当の認証情報を無効化・ローテーションすることが最優先です。さらにgit filter-repoなどのツールで履歴から完全に削除する必要があります。単に新しいコミットで削除しても履歴には残り続けます。
特定のファイルやディレクトリへの変更があった場合に、自動的に特定のレビュアーをプルリクエストに追加したい場合に使用する仕組みは？
解答・解説を見る
正解: A. A. CODEOWNERSファイル
正解の根拠・詳細解説
CODEOWNERSファイルをリポジトリのルートに配置することで、指定したパスへの変更を含むプルリクエストに対し、該当するオーナー（レビュアー）を自動的に必須レビュアーとして追加できます。
GitHubやAzure ReposでのプルリクエストにおいてCI（継続的インテグレーション）ビルドが成功するまでマージボタンを無効化したい場合の設定は？
解答・解説を見る
正解: A. A. ブランチポリシーで「ビルド検証」を必須に設定する
正解の根拠・詳細解説
ブランチポリシーの「ビルド検証」を設定することで、指定したパイプラインが成功しない限りプルリクエストのマージを禁止し、品質の低いコードがmainブランチに統合されることを防げます。
リリース前の安定版コードを管理しつつ、ホットフィックスを適用できるようにするための一般的なブランチ戦略は？
解答・解説を見る
正解: A. A. リリースブランチを作成し、必要に応じてmainへcherry-pickでホットフィックスを反映する
正解の根拠・詳細解説
リリースブランチを作成することで、リリース後も安定版のコードベースを保持しつつ、緊急のバグ修正（ホットフィックス）を適用し、必要に応じてmainブランチへも反映（cherry-pick）できます。
チームメンバーがリポジトリへの直接プッシュ権限を持たないようにし、すべての変更をプルリクエスト経由にしたい場合の設定は？
解答・解説を見る
正解: A. A. ブランチポリシーで対象ブランチへの直接プッシュを禁止する
正解の根拠・詳細解説
対象ブランチ（例: main）に対してブランチポリシーを設定し、「最小数のレビュアーを要求する」などのポリシーを有効にすると、直接プッシュが禁止され、プルリクエスト経由でのみ変更が可能になります。
コードレビューの効率を高めるため、プルリクエストの差分（diff）が大きくなりすぎないように推奨されるプラクティスは？
解答・解説を見る
正解: A. A. 小さく頻繁にコミット・プルリクエストを作成する
正解の根拠・詳細解説
小さく頻繁な変更単位でプルリクエストを作成することで、レビュアーが変更内容を把握しやすくなり、レビューの質とスピードが向上し、マージコンフリクトのリスクも減少します。
Azure ReposのGitリポジトリで、フォークではなく同一リポジトリ内でブランチを作成して開発する「共有リポジトリモデル」の利点は？
解答・解説を見る
正解: A. A. ブランチの可視性が高く、CI/CDパイプラインとの連携が容易
正解の根拠・詳細解説
共有リポジトリモデルでは、すべての開発者が同じリポジトリ内にブランチを作成するため、CI/CDパイプラインの設定がシンプルになり、ブランチの状況がチーム全体で可視化されやすくなります。
コミットメッセージの一貫性を保ち、自動的にリリースノートを生成できるようにするために推奨される手法は？
解答・解説を見る
正解: A. A. Conventional Commits（規約に基づくコミットメッセージ）を採用する
正解の根拠・詳細解説
Conventional Commitsのような規約に従ってコミットメッセージを記述することで、feat/fix/choreなどの種別を機械的に解析でき、自動的なリリースノート生成やセマンティックバージョニングが可能になります。
プルリクエストのコメントで議論された内容が、すべて解決（Resolve）されるまでマージを禁止したい場合に設定するポリシーは？
解答・解説を見る
正解: A. A. 「コメント解決の必須化」ポリシー
正解の根拠・詳細解説
ブランチポリシーで「コメント解決の必須化」を有効にすると、プルリクエスト内のすべてのコメントスレッドが解決済みになるまでマージができなくなり、フィードバックの見落としを防ぎます。
リポジトリ内の特定のブランチ（例: release/\*）に一致するすべてのブランチに同じポリシーを適用したい場合の設定方法は？
解答・解説を見る
正解: A. A. ブランチ命名パターン（ワイルドカード）を使ったブランチポリシー
正解の根拠・詳細解説
Azure Reposでは、`release/\*`のようなワイルドカードパターンを使ってブランチポリシーを設定でき、パターンに一致するすべてのブランチに自動的に同じポリシーが適用されます。
開発者がローカルで作業中の変更を一時的に退避し、別の緊急タスクに切り替えたい場合に使用するGitコマンドは？
解答・解説を見る
正解: A. A. git stash
正解の根拠・詳細解説
git stashは、作業ディレクトリの未コミットの変更を一時的に保存し、作業ツリーをクリーンな状態に戻すコマンドです。後で git stash pop により変更を復元できます。
Azure DevOpsでGitHubリポジトリのコードに対してAzure Pipelinesを実行したい場合、最初に必要な設定は？
解答・解説を見る
正解: A. A. GitHubサービス接続（Service Connection）を作成し、リポジトリへのアクセスを許可する
正解の根拠・詳細解説
Azure PipelinesでGitHub上のリポジトリを使用する場合、GitHubサービス接続（OAuthまたはPAT）を設定してAzure DevOpsにリポジトリへのアクセス権限を付与する必要があります。
コードベースの品質を保つため、プルリクエスト作成時に静的コード解析（リンター）を自動実行し、エラーがあればマージをブロックしたい。実現方法は？
解答・解説を見る
正解: A. A. プルリクエストトリガーのパイプラインに静的解析タスクを含め、ビルド検証ポリシーで必須化する
正解の根拠・詳細解説
プルリクエストトリガーのパイプラインに静的解析（リンター）ステップを含め、ビルド検証ポリシーでそのパイプラインの成功を必須化することで、品質基準を満たさないコードのマージを未然に防げます。
長期間更新されていないフィーチャーブランチが多数存在し、リポジトリが整理しにくくなっている。推奨される対応は？
解答・解説を見る
正解: A. A. マージ済み・未使用のブランチを定期的に削除するポリシーを導入する
正解の根拠・詳細解説
マージ済みのブランチや一定期間更新のないブランチを定期的に削除（クリーンアップ）することで、リポジトリの可読性と管理性が向上します。Azure Reposには自動クリーンアップのポリシー設定もあります。
チームが複数のリポジトリで共通利用するライブラリコードを管理する際、各リポジトリから特定バージョンの共通コードを参照する方法として適切なものは？
解答・解説を見る
正解: A. A. Gitサブモジュール（Submodule）またはパッケージフィード経由での参照
正解の根拠・詳細解説
Gitサブモジュールを使えば別リポジトリの特定コミットを参照できますが、より一般的にはAzure Artifactsなどのパッケージフィードに共通ライブラリを公開し、バージョン管理されたパッケージとして各リポジトリから参照する方法が推奨されます。
プルリクエストの自動マージを設定したが、ターゲットブランチに新しいコミットが追加されてコンフリクトが発生した。Azure DevOpsの挙動として正しいものは？
解答・解説を見る
正解: A. A. 自動マージは一時停止され、手動でのコンフリクト解決が必要になる
正解の根拠・詳細解説
自動補完（auto-complete）を設定していても、マージコンフリクトが発生した場合は自動マージが一時停止し、開発者が手動でコンフリクトを解決してから再度マージを完了させる必要があります。
セキュリティ強化のため、特定のユーザーグループのみがリポジトリの「強制プッシュ（force push）」を実行できるようにしたい。設定すべき項目は？
解答・解説を見る
正解: A. A. ブランチセキュリティ設定で「強制プッシュ（書き換え履歴と削除）」の権限を限定したグループにのみ許可する
正解の根拠・詳細解説
Azure Reposではリポジトリ単位およびブランチ単位でGitの権限を細かく設定できます。強制プッシュに相当するのが「履歴の書き換えと削除を強制的にプッシュする」権限で、これを許可されたIDだけがブランチの履歴を上書きしたり、既存のコミットを消したりできます。既定では一般の共同作成者には与えられておらず、意図しない履歴の消失やレビュー済みコミットの改変を防ぐ設計になっています。特定のグループにだけ必要な場合は、そのグループに対してのみこの権限を許可に設定し、対象を必要なブランチに絞ることで影響範囲を最小化できます。権限はリポジトリからブランチへ継承されるため、リポジトリ全体ではなく個々のブランチのセキュリティ設定で調整すると、mainのような重要ブランチを保護しつつ作業ブランチでは柔軟に運用できます。すべてのユーザーに管理者権限を付与する案は最小権限の原則に真っ向から反します。リポジトリをパブリックにするのは可視性の設定であって書き込み権限とは無関係で、強制プッシュを設定できないという選択肢も誤りです。
複数のステージ（ビルド→テスト→ステージング→本番）を1つのYAMLファイルで定義し、各ステージの依存関係を管理したい場合に使用する構造は？
解答・解説を見る
正解: A. A. マルチステージパイプライン（stages）
正解の根拠・詳細解説
Azure PipelinesのYAMLでは`stages`キーを使って複数のステージを定義し、`dependsOn`で各ステージ間の依存関係や実行順序を制御できます。これにより一連のCI/CDフローをコードとして管理できます。
新バージョンを少数の利用者にのみ公開し、問題がなければ徐々に対象を広げていくデプロイ戦略は？
解答・解説を見る
正解: A. A. カナリアデプロイ（Canary Deployment）
正解の根拠・詳細解説
カナリアデプロイは、新バージョンを最初は一部のユーザーやサーバーにのみ展開し、メトリクスを監視しながら問題がなければ段階的に展開範囲を拡大していく手法です。
本番環境と同一構成のステージング環境に新バージョンをデプロイし、検証後にトラフィックを瞬時に切り替えるデプロイ戦略は？
解答・解説を見る
正解: A. A. ブルーグリーンデプロイ（Blue-Green Deployment）
正解の根拠・詳細解説
ブルーグリーンデプロイは、本番（Blue）と同一のステージング環境（Green）を用意し、Green環境で新バージョンを検証後、ルーティングを切り替えることでダウンタイムを最小化する手法です。
Azure App Serviceで、本番トラフィックに影響を与えずに新バージョンをテストし、問題がなければ即座に切り替えたい場合に使用する機能は？
解答・解説を見る
正解: A. A. デプロイスロット（Deployment Slots）
正解の根拠・詳細解説
App Serviceのデプロイスロットを使うと、本番スロットとは別のスロット（例: staging）に新バージョンをデプロイして検証し、準備ができたら「スロットの交換（swap）」で本番に反映できます。
コンテナイメージをビルドし、Azure Container Registry（ACR）にプッシュするパイプラインタスクとして適切なものは？
解答・解説を見る
正解: A. A. Docker タスク（build と push）
正解の根拠・詳細解説
AzureパイプラインのDockerタスクを使うことで、Dockerfileからイメージをビルドし、ACRへのログイン後にイメージをプッシュする一連の処理をパイプライン内で実行できます。
Azureリソースをコードで定義し、宣言的にデプロイするためにMicrosoftが提供するドメイン固有言語（DSL）は？
解答・解説を見る
正解: A. A. Bicep
正解の根拠・詳細解説
BicepはAzureリソースを宣言的に記述するためのMicrosoft製DSLで、ARMテンプレート（JSON）よりも簡潔な構文でInfrastructure as Code（IaC）を実現できます。
マルチクラウドやオンプレミスを含む環境のインフラをコードで管理したい場合、HashiCorp製のオープンソースIaCツールとしてAzure DevOpsと統合できるものは？
解答・解説を見る
正解: A. A. Terraform
正解の根拠・詳細解説
TerraformはAzureだけでなく複数のクラウドプロバイダーに対応したIaCツールで、Azure Pipelinesには公式拡張機能（Terraformタスク）が提供されており、init/plan/applyの各コマンドをパイプラインに組み込めます。
複数のパイプラインで共有するシークレットや設定値（接続文字列など）を一元管理し、パイプライン内で変数として利用したい場合に使用する機能は？
解答・解説を見る
正解: A. A. 変数グループ（Variable Groups）
正解の根拠・詳細解説
変数グループは、複数のパイプライン間で共有する変数（環境設定値やシークレット）をライブラリに一元管理する機能で、Azure Key Vaultとリンクすることも可能です。
Microsoft提供のホストエージェントではOS要件を満たせない、または社内ネットワークのリソースにアクセスする必要があるパイプラインを実行する場合に使用するのは？
解答・解説を見る
正解: A. A. セルフホストエージェント（Self-hosted agent）
正解の根拠・詳細解説
セルフホストエージェントは、自社で管理するマシン（オンプレミスやVM）にエージェントをインストールして使用するもので、特殊なソフトウェア要件や社内リソースへのアクセスが必要な場合に利用されます。
AKS（Azure Kubernetes Service）クラスターにアプリケーションをデプロイするために、Kubernetesのマニフェストファイル（YAML）を適用するパイプラインタスクは？
解答・解説を見る
正解: A. A. Kubernetesマニフェストタスク（KubernetesManifest@0）
正解の根拠・詳細解説
KubernetesManifestタスクを使用すると、デプロイメントやサービスなどのKubernetesマニフェストファイルをAKSクラスターに適用し、イメージのタグ置換などの機能も提供されます。
データベースのスキーマ変更を、SQL Serverデータベースプロジェクトからビルドした成果物としてデプロイするために使用するファイル形式は？
解答・解説を見る
正解: A. A. DACPAC（データ層アプリケーションパッケージ）
正解の根拠・詳細解説
DACPACは、SQL Serverデータベースのスキーマ定義をパッケージ化したファイルで、SqlPackageユーティリティやAzure SQL Databaseデプロイタスクを使ってターゲットデータベースに適用（差分デプロイ）できます。
新機能を本番環境にデプロイした後も、特定のユーザーグループのみに機能を有効化し、問題があれば即座に無効化できるようにする手法は？
解答・解説を見る
正解: A. A. フィーチャーフラグ（Feature Flags）
正解の根拠・詳細解説
フィーチャーフラグを使うことで、コードのデプロイと機能の有効化を分離でき、本番環境にデプロイ済みの新機能を、再デプロイなしで特定ユーザーやグループに段階的に公開・無効化できます。
リリースパイプラインで、ステージへのデプロイ前に外部の承認者（例: 変更管理チーム）の承認を必須にしたい場合に使用する機能は？
解答・解説を見る
正解: A. A. 事前デプロイ承認（Pre-deployment Approvals）
正解の根拠・詳細解説
事前デプロイ承認を設定することで、ステージへのデプロイが開始される前に指定した承認者の承認を必須とし、変更管理プロセスをパイプラインに組み込むことができます。
パイプラインのステージ間でビルド成果物（バイナリ、設定ファイルなど）を受け渡す仕組みは？
解答・解説を見る
正解: A. A. パイプラインアーティファクト（Pipeline Artifacts）
正解の根拠・詳細解説
パイプラインアーティファクトは、ビルドステージで生成された成果物をパブリッシュし、後続のステージ（デプロイなど）でダウンロードして利用できる仕組みです。
本番環境へのデプロイ前に、外部の監視システムのアラート状態を確認し、問題があればデプロイを自動的に中止したい場合に使用する機能は？
解答・解説を見る
正解: A. A. リリースゲート（Release Gates）
正解の根拠・詳細解説
リリースゲートは、Azure Monitorのアラートや外部のWeb APIなどと連携し、事前に定義した条件を満たさない場合にデプロイを自動的にブロックする機能です。
コンテナイメージのバージョン管理において、`latest`タグのみを使用することの問題点として正しいものは？
解答・解説を見る
正解: A. A. 特定バージョンへのロールバックが困難になり、デプロイの再現性が損なわれる
正解の根拠・詳細解説
`latest`タグは常に最新イメージを指すため、どのバージョンが実際にデプロイされているかの追跡が難しく、特定バージョンへのロールバックも困難になります。セマンティックバージョニングやGitコミットSHAをタグに使うことが推奨されます。
Azure Pipelinesで、同じYAML定義を複数の環境（dev/staging/prod）に対して使い回しつつ、環境ごとに異なる設定値を適用したい場合の適切な方法は？
解答・解説を見る
正解: A. A. テンプレートとパラメータ、環境ごとの変数グループを組み合わせる
正解の根拠・詳細解説
YAMLテンプレートとパラメータを使って共通のパイプライン定義を再利用しつつ、環境（Environment）ごとの変数グループやリソースに紐づくスコープ変数を使うことで、環境差分を管理しやすくなります。
パイプラインの実行時間を短縮するため、依存パッケージ（npmパッケージなど）のダウンロード結果を再利用したい場合に使用する機能は？
解答・解説を見る
正解: A. A. パイプラインキャッシュ（Cache タスク）
正解の根拠・詳細解説
Cacheタスクを使うことで、npm/NuGet/Mavenなどの依存パッケージをキャッシュし、次回以降のパイプライン実行時にダウンロード時間を短縮できます。
本番環境にデプロイされたアプリケーションで重大な不具合が発見された場合、最も迅速に以前の安定バージョンに戻す方法として適切なものは？
解答・解説を見る
正解: A. A. 直前の成功したリリースを再デプロイする（ロールバック）
正解の根拠・詳細解説
リリースパイプラインで以前の成功したデプロイを再実行（再デプロイ）することで、迅速にロールバックできます。デプロイスロットのスワップを利用している場合はスロットの再交換でも対応可能です。
YAMLパイプラインにおいて、特定のブランチへのプッシュ時のみパイプラインを実行したい場合に使用する設定は？
解答・解説を見る
正解: A. A. trigger（branches include/exclude）
正解の根拠・詳細解説
YAMLパイプラインの`trigger`セクションで`branches`の`include`/`exclude`を指定することで、特定のブランチへのプッシュ時のみパイプラインを実行するように制御できます。
Helmチャートを使ってAKSにアプリケーションをデプロイする利点として正しいものは？
解答・解説を見る
正解: A. A. Kubernetesリソースをパッケージ化し、バージョン管理・パラメータ化された再利用可能なデプロイが可能になる
正解の根拠・詳細解説
Helmは複数のKubernetesマニフェストをまとめた「チャート」としてアプリケーションをパッケージ化し、values.yamlによるパラメータ化やバージョン管理されたリリース・ロールバックを容易にします。
パイプラインの本番デプロイステージで、複数のリージョンに段階的にデプロイしながら、各リージョンでの展開後に一定時間モニタリングしてから次のリージョンへ進める手法を何と呼びますか？
解答・解説を見る
正解: A. A. リングベースデプロイ（Ring-based Deployment）
正解の根拠・詳細解説
リングベースデプロイは、内部ユーザー→早期アダプター→一般ユーザーのように、リスクの低いグループから順に段階的（リング単位）に展開していく手法で、各段階でのモニタリングにより問題の早期検出が可能になります。
パイプライン内でAzureリソースに対して操作を行う際、サービスプリンシパルの認証情報をパイプラインに安全に渡すために使用する仕組みは？
解答・解説を見る
正解: A. A. サービス接続（Service Connection）
正解の根拠・詳細解説
サービス接続は、Azureサブスクリプションなどの外部リソースへの認証情報を安全に保管し、パイプラインタスクから参照できるようにする仕組みで、認証情報をコードや変数に直接書く必要がなくなります。
複数のマイクロサービスをそれぞれ独立したパイプラインでビルド・デプロイする構成において、サービス間の依存関係（例: サービスAのデプロイ完了後にサービスBをデプロイ）を管理する方法は？
解答・解説を見る
正解: A. A. パイプラインのリソーストリガー（pipeline resources）を使って他パイプラインの完了をトリガーにする
正解の根拠・詳細解説
YAMLパイプラインのresources.pipelinesでは、別のパイプラインを参照として宣言し、そのパイプラインの実行が完了したことを自身の実行トリガーにできます。これによって、サービスAのパイプラインが成功した後にサービスBのパイプラインが自動的に開始されるという依存関係を、パイプライン定義の中に宣言的に記述できます。参照元のブランチやタグでトリガー条件を絞り込めるほか、上流のパイプラインが生成した成果物を下流でダウンロードして利用できるため、ビルド成果物の受け渡しとデプロイ順序の制御を同じ仕組みで実現できます。各サービスのパイプラインは独立したままなので、マイクロサービスごとに個別にビルド・テスト・デプロイでき、変更のあったサービスだけを再デプロイできるという利点も維持されます。すべてを1つの巨大なパイプラインに統合すると独立してデプロイできる利点が失われ、1サービスの小さな変更でも全体の再実行が必要になります。チャットでの手動連絡は再現性と監査性がなく、担当者の見落としが直接リリース事故につながります。
ソースコードを実行せずに、コード自体を解析して脆弱性（SQLインジェクションなど）を検出する手法を何と呼びますか？
解答・解説を見る
正解: A. A. SAST（静的アプリケーションセキュリティテスト）
正解の根拠・詳細解説
SAST（Static Application Security Testing）は、ソースコードやバイナリを実行せずに解析し、脆弱性のパターンを検出する手法で、開発の早い段階（シフトレフト）でセキュリティ問題を発見できます。
実行中のアプリケーションに対して外部から攻撃をシミュレートし、実際の脆弱性を検出する手法は？
解答・解説を見る
正解: A. A. DAST（動的アプリケーションセキュリティテスト）
正解の根拠・詳細解説
DAST（Dynamic Application Security Testing）は、デプロイされ実行中のアプリケーションに対して実際にリクエストを送信し、実行時の脆弱性（認証バイパスや設定ミスなど）を検出する手法です。
プロジェクトが利用しているオープンソースライブラリの既知の脆弱性やライセンス問題を検出する手法は？
解答・解説を見る
正解: A. A. SCA（ソフトウェア構成分析 / Software Composition Analysis）
正解の根拠・詳細解説
SCA（Software Composition Analysis）は、プロジェクトが依存するオープンソースコンポーネントを分析し、既知の脆弱性（CVE）やライセンスコンプライアンス上の問題を特定するツール・手法です。
コンテナイメージをACRにプッシュする前に、OSパッケージやライブラリの脆弱性をスキャンしたい場合に活用できるAzureサービスは？
解答・解説を見る
正解: A. A. Microsoft Defender for Cloud（コンテナレジストリの脆弱性スキャン）
正解の根拠・詳細解説
Microsoft Defender for Cloud（旧Azure Security Center）は、ACRにプッシュされたコンテナイメージを自動的にスキャンし、OSやアプリケーション層の既知の脆弱性を検出してレポートします。
組織内のすべてのAzureリソースが、特定のタグ付けルールやSKU制限などのガバナンスポリシーに準拠していることを継続的に強制したい場合に使用するサービスは？
解答・解説を見る
正解: A. A. Azure Policy
正解の根拠・詳細解説
Azure Policyを使うと、リソースの作成・更新時にポリシー定義（タグの必須化、許可されたリージョンの制限など）への準拠を評価し、非準拠リソースを拒否またはフラグ付けできます。
ソフトウェアサプライチェーンのセキュリティを向上させるため、ビルドに使用したすべてのコンポーネントとその依存関係を記録した文書を何と呼びますか？
解答・解説を見る
正解: A. A. SBOM（Software Bill of Materials）
正解の根拠・詳細解説
SBOM（ソフトウェア部品表）は、ソフトウェアを構成するすべてのコンポーネント・ライブラリ・依存関係をリスト化した文書で、脆弱性が発見された際の影響範囲の特定やサプライチェーン管理に役立ちます。
パイプラインが使用するサービス接続（Service Connection）に付与する権限についての最も適切な原則は？
解答・解説を見る
正解: A. A. 必要最小限の権限のみを付与する（最小権限の原則）
正解の根拠・詳細解説
最小権限の原則に従い、サービス接続にはパイプラインが実際に必要とするリソーススコープ・操作のみを許可する権限を付与すべきです。過剰な権限は、認証情報が漏洩した際の被害を拡大させます。
組織がGDPRやISO27001などの規制・標準への準拠状況を評価し、改善のためのアクション項目を管理したい場合に利用できるMicrosoft 365 / Azureのツールは？
解答・解説を見る
正解: A. A. Microsoft Purview コンプライアンスマネージャー
正解の根拠・詳細解説
Microsoft Purviewのコンプライアンスマネージャーは、組織のコンプライアンススコアを評価し、各種規制・標準（GDPR、ISO27001など）に対する管理策の実施状況と改善アクションを追跡できます。
GitHubリポジトリにAPIキーなどのシークレットが誤ってコミットされた場合に、自動的に検出して警告する機能は？
解答・解説を見る
正解: A. A. GitHub Advanced Securityのシークレットスキャン（Secret Scanning）
正解の根拠・詳細解説
GitHub Advanced Securityのシークレットスキャン機能は、コミットされたコード内にAPIキーやトークンなどの既知のシークレットパターンを検出し、リポジトリ管理者に警告します。
Azure VM上で動作するアプリケーションが、コード内にパスワードを記述せずにAzure Key Vaultへ安全にアクセスするための推奨される認証方法は？
解答・解説を見る
正解: A. A. マネージドID（Managed Identity）
正解の根拠・詳細解説
マネージドIDを使用すると、Azureリソース（VMなど）はAzure ADによって自動的に管理される識別情報を使って他のAzureサービス（Key Vaultなど）に認証でき、資格情報をコードに記述する必要がなくなります。
開発の初期段階でアプリケーションのセキュリティリスクを洗い出し、攻撃者の視点から潜在的な脅威を特定・分類するプロセスは？
解答・解説を見る
正解: A. A. 脅威モデリング（Threat Modeling）
正解の根拠・詳細解説
脅威モデリングは、システムの設計段階で攻撃者の視点から潜在的な脅威（STRIDEモデルなど）を体系的に洗い出し、対策を設計に組み込むためのプロセスです。
Azureリソースに対する操作（作成・変更・削除）の履歴を追跡し、セキュリティ監査やコンプライアンス調査に利用できるログは？
解答・解説を見る
正解: A. A. Azureアクティビティログ（Activity Log）
正解の根拠・詳細解説
Azureアクティビティログは、サブスクリプション内のリソースに対する管理操作（書き込み、削除など）を記録し、誰が・いつ・何を変更したかを追跡するための監査証跡として利用されます。
本番環境で実行中のコンテナに対して、ランタイム時の異常な動作（不審なプロセス起動など）を検知する仕組みを何と呼びますか？
解答・解説を見る
正解: A. A. ランタイム保護（Runtime Protection）
正解の根拠・詳細解説
ランタイム保護は、実行中のワークロード（コンテナやVM）を監視し、既知の攻撃パターンや異常な振る舞いをリアルタイムで検知・ブロックする仕組みで、Defender for Cloudなどで提供されます。
パイプラインに脆弱性スキャンを統合した結果、深刻度「高」の脆弱性が検出された場合、本番デプロイを自動的に停止させたい。実現方法として適切なものは？
解答・解説を見る
正解: A. A. スキャン結果に基づく品質ゲート（Quality Gate）をパイプラインに設定する
正解の根拠・詳細解説
パイプライン内に脆弱性スキャンの結果を評価する品質ゲートを設定し、定義した深刻度の脆弱性が検出された場合にパイプラインを失敗させることで、リスクのあるコードの本番デプロイを未然に防げます。
コンテナイメージの脆弱性スキャンに加えて、イメージが信頼された発行元によって署名されていることを確認し、未署名イメージのデプロイを禁止したい場合に活用できる仕組みは？
解答・解説を見る
正解: A. A. コンテンツトラスト / イメージ署名の検証（Notaryなど）とAzure Policyの組み合わせ
正解の根拠・詳細解説
イメージ署名（コンテンツトラスト）により発行元の真正性を検証し、Azure PolicyやAdmission Controllerと組み合わせることで、署名されていない、または信頼できないイメージのデプロイをクラスターレベルで禁止できます。
チームがDevSecOpsを推進する上で、「セキュリティをパイプラインの後工程（リリース直前）だけでなく開発の早い段階から組み込む」という考え方を表す用語は？
解答・解説を見る
正解: A. A. シフトレフト（Shift Left）
正解の根拠・詳細解説
シフトレフトとは、セキュリティテストやレビューを開発プロセスの早い段階（コーディング・コミット時点）に移動させることで、問題を早期に発見・修正し、修正コストを削減する考え方です。
Azure DevOpsのパイプラインで使用するパーソナルアクセストークン（PAT）について、セキュリティ上推奨されるプラクティスは？
解答・解説を見る
正解: A. A. 有効期限を設定し、必要最小限のスコープを付与し、定期的にローテーションする
正解の根拠・詳細解説
PATは漏洩した場合に大きなリスクとなるため、有効期限の設定、必要なスコープのみへの限定、定期的なローテーションが推奨されます。可能であればマネージドIDやサービス接続の使用を優先すべきです。
クラウド環境全体（複数のサブスクリプションやハイブリッド環境）のセキュリティ態勢を可視化し、推奨事項に基づいてセキュアスコアを改善したい場合に使用するサービスは？
解答・解説を見る
正解: A. A. Microsoft Defender for Cloud
正解の根拠・詳細解説
Microsoft Defender for Cloudは、クラウドセキュリティ態勢管理（CSPM）の機能を提供し、セキュアスコアによって組織全体のセキュリティ状況を可視化し、改善のための推奨事項を提示します。
パイプラインの実行ログに、データベースの接続文字列やAPIキーなどの機密情報が平文で出力されてしまうことを防ぐためにAzure Pipelinesが提供する機能は？
解答・解説を見る
正解: A. A. シークレット変数の自動マスキング（Secret variables）
正解の根拠・詳細解説
変数を「シークレット」として設定すると、その値はパイプラインのログ出力時に自動的に`\*\*\*`でマスキングされ、誤って機密情報がログに露出するリスクを低減します。
コンプライアンス要件として、本番環境への変更はすべて承認とログが残る形で実施される必要がある。これを実現するためにAzure DevOpsで設定すべき組み合わせは？
解答・解説を見る
正解: A. A. 環境（Environment）への承認チェックと、デプロイ履行のログ記録
正解の根拠・詳細解説
Azure Pipelinesの環境（Environment）リソースに承認・チェックを設定することで、本番環境へのデプロイには事前承認が必須となり、すべてのデプロイ履行はログとして記録され、コンプライアンス要件を満たすトレーサビリティを確保できます。
Infrastructure as Code（IaC）のテンプレート（Bicep/Terraformなど）自体に、セキュリティ設定の不備（例: パブリックアクセス許可のストレージ）がないかをデプロイ前に検査する手法は？
解答・解説を見る
正解: A. A. IaCスキャン（静的解析、例: Checkov、tfsecなど）
正解の根拠・詳細解説
IaCスキャンツールは、Bicep/TerraformなどのIaCテンプレートをデプロイ前に静的解析し、セキュリティのベストプラクティスに違反する設定（パブリックアクセス、暗号化なしのストレージなど）を検出します。
組織のAzure ADにおいて、特権アカウント（管理者権限を持つアカウント）の使用を必要な時だけ一時的に許可し、常時持続的な権限付与を避けるための仕組みは？
解答・解説を見る
正解: A. A. Azure AD Privileged Identity Management（PIM）
正解の根拠・詳細解説
Azure AD PIM（Privileged Identity Management）は、特権ロールへのアクセスをJust-In-Time（必要な時のみ）かつ時間制限付きで付与する仕組みで、常時特権を持つアカウントのリスクを低減します。
パイプラインで使用するサードパーティ拡張機能（Marketplace拡張）を組織に導入する前に検討すべきセキュリティ上の観点は？
解答・解説を見る
正解: A. A. 発行元の信頼性、必要な権限の範囲、組織のセキュリティポリシーへの準拠
正解の根拠・詳細解説
サードパーティ拡張機能はパイプライン内で広範な権限で実行される可能性があるため、発行元の信頼性、要求される権限のスコープ、組織のセキュリティ・コンプライアンスポリシーへの適合を事前に評価する必要があります。
コンテナベースのアプリケーションにおいて、ベースイメージに含まれるOSの脆弱性を最小化するための一般的なプラクティスは？
解答・解説を見る
正解: A. A. 最小構成のベースイメージ（distroless / Alpineなど）を使用し、定期的に最新化する
正解の根拠・詳細解説
コンテナイメージで検出される脆弱性の多くは、アプリケーションコードそのものではなく、ベースイメージに含まれるOSパッケージやライブラリに由来します。distrolessやAlpineのような最小構成のイメージは、シェルやパッケージマネージャー、不要なユーティリティを含まないため、そもそも存在するパッケージ数が少なく、報告されるCVEの数と攻撃対象領域の双方を小さく抑えられます。加えて、ベースイメージには時間の経過とともに新しい脆弱性が公表されるため、一度ビルドしたイメージを固定し続けるのではなく、定期的に最新のベースイメージで再ビルドして再デプロイするサイクルを回す必要があります。CI/CDではビルド時にコンテナイメージのスキャンを実行し、深刻度がしきい値を超えた場合にパイプラインを失敗させる仕組みを組み込むと、脆弱なイメージが本番環境へ到達する前に検出できます。多くのツールを詰め込む、イメージを更新しない、rootユーザーで実行するといった運用はいずれも攻撃対象領域と侵害時の被害範囲を広げる方向に働きます。
Webアプリケーションのパフォーマンス（応答時間、例外、依存関係呼び出しなど）を監視するためにApplication Insightsを導入する際、最初に必要な設定は？
解答・解説を見る
正解: A. A. アプリケーションにインストルメンテーションキー（接続文字列）を設定したSDKを組み込む
正解の根拠・詳細解説
Application Insightsを使用するには、アプリケーションにApplication Insights SDKを組み込み、インストルメンテーションキー（または接続文字列）を設定することで、テレメトリデータがAzureに送信されるようになります。
Application Insightsで収集したテレメトリデータに対して、柔軟なクエリを実行し独自のダッシュボードを作成するために使用するクエリ言語は？
解答・解説を見る
正解: A. A. KQL（Kusto Query Language）
正解の根拠・詳細解説
KQL（Kusto Query Language）はAzure Monitor LogsやApplication Insightsで使用されるクエリ言語で、ログデータの集計・フィルタリング・可視化を柔軟に行うことができます。
CPU使用率が一定のしきい値を超えた場合に、運用チームに自動的にメールやSMSで通知したい場合に設定する機能は？
解答・解説を見る
正解: A. A. Azure Monitorアラートルール（アクショングループ含む）
正解の根拠・詳細解説
Azure Monitorでアラートルール（条件・評価頻度）とアクショングループ（通知先: メール、SMS、Webhookなど）を設定することで、指定した条件を満たした際に自動的に通知やアクションを実行できます。
新しいリリースをデプロイした後、パフォーマンス指標の変化がそのリリースに起因するものかを判断しやすくするために、Application Insightsのタイムラインに記録する情報は？
解答・解説を見る
正解: A. A. リリースアノテーション（Release Annotations）
正解の根拠・詳細解説
リリースアノテーションは、デプロイのタイミングをApplication Insightsのメトリクスグラフ上にマーカーとして表示する機能で、リリース前後のパフォーマンス変化を視覚的に比較しやすくします。
Webアプリケーションが世界中の複数の地点から正常にアクセス可能かを定期的にチェックし、ダウンタイムを検出したい場合に使用するApplication Insightsの機能は？
解答・解説を見る
正解: A. A. 可用性テスト（Availability Tests）
正解の根拠・詳細解説
可用性テストは、世界各地のMicrosoftのテストエージェントから定期的に指定したURLにリクエストを送信し、応答時間や可用性を監視・アラートする機能です。
アプリケーション内でユーザーが特定のボタンをクリックした回数など、ビジネス上重要な独自のイベントを記録したい場合に使用するApplication Insightsの機能は？
解答・解説を見る
正解: A. A. カスタムイベント（Custom Events）の送信（TrackEvent）
正解の根拠・詳細解説
TrackEventメソッドを使ってカスタムイベントを送信することで、標準のテレメトリでは捉えられないビジネス固有のユーザー行動（特定機能の利用回数など）を記録・分析できます。
複数のマイクロサービスをまたがる1つのリクエストの処理経路を可視化し、どのサービスで遅延が発生しているかを特定する手法は？
解答・解説を見る
正解: A. A. 分散トレーシング（Distributed Tracing）と Application Map
正解の根拠・詳細解説
分散トレーシングは、サービス間をまたがるリクエストに一意の操作IDを付与して追跡する仕組みで、Application Insightsの「アプリケーションマップ」を使うことで、サービス間の依存関係と各ステップのレイテンシを可視化できます。
サービスの信頼性目標を定義する際、「99.9%の可用性を維持する」といった具体的な目標値を何と呼びますか？
解答・解説を見る
正解: A. A. SLO（Service Level Objective）
正解の根拠・詳細解説
SLO（サービスレベル目標）は、SLI（サービスレベル指標、例: 可用性・レイテンシ）に対する具体的な数値目標を定めたもので、信頼性とリリース速度のバランスを取るための基準となります。
SLOに対して許容される「失敗の余地」を数値化し、新機能のリリースペースを調整する際の判断材料とする概念は？
解答・解説を見る
正解: A. A. エラーバジェット（Error Budget）
正解の根拠・詳細解説
エラーバジェットは「1 – SLO」で計算される、許容可能な障害の量を表す指標です。エラーバジェットが残っている場合は新機能のリリースを積極的に行い、消費し尽くした場合は信頼性向上を優先するという判断に使われます。
新機能の効果を検証するため、ユーザーを2つのグループに分け、異なるバージョンのUIを提示して反応を比較する手法は？
解答・解説を見る
正解: A. A. A/Bテスト
正解の根拠・詳細解説
A/Bテストは、ユーザーをランダムに2つ（またはそれ以上）のグループに分け、異なるバージョンの機能やUIを提示して、コンバージョン率やエンゲージメントなどの指標を比較する手法で、データに基づいた意思決定に役立ちます。
複数のAzureサービス（VM、App Service、AKSなど）から出力されるログデータを一元的に集約し、横断的に分析したい場合に使用するサービスは？
解答・解説を見る
正解: A. A. Log Analytics ワークスペース
正解の根拠・詳細解説
Log Analyticsワークスペースは、複数のリソースからログやメトリクスデータを収集・格納する中央リポジトリで、KQLを使って横断的な分析やダッシュボード作成、アラート設定が可能です。
AKSクラスター上で動作するコンテナのCPU・メモリ使用率やログを監視するために使用するAzure Monitorの機能は？
解答・解説を見る
正解: A. A. Container Insights
正解の根拠・詳細解説
Container InsightsはAzure Monitorの一部で、AKSなどのKubernetesクラスターのノード・ポッド・コンテナレベルのパフォーマンスメトリクスとログを収集し、健全性を監視できます。
デプロイ後にApplication Insightsで異常な例外率の急増を検知した場合、人手を介さずに自動的に直前のバージョンへ戻す仕組みを何と呼びますか？
解答・解説を見る
正解: A. A. 自動ロールバック（Automated Rollback）
正解の根拠・詳細解説
自動ロールバックは、リリースゲートやモニタリングアラートと連携し、デプロイ後にエラー率やレスポンスタイムの異常を検知した場合、自動的に直前の安定バージョンへのロールバックをトリガーする仕組みです。
ECサイトにおいて、ユーザーが「商品ページ閲覧→カート追加→購入完了」のどの段階で離脱しているかを分析したい場合に使用するApplication Insightsの機能は？
解答・解説を見る
正解: A. A. ユーザーフロー / ファネル分析（User Flows / Funnels）
正解の根拠・詳細解説
ファネル分析（コンバージョンファネル）は、定義したステップ（イベントやページビュー）ごとにユーザーがどの段階で離脱しているかを可視化し、UI/UX改善のためのインサイトを提供します。
高トラフィックなアプリケーションでApplication Insightsのデータ量が膨大になり、コストが増大している場合の対策として適切なものは？
解答・解説を見る
正解: A. A. サンプリング（Sampling）を設定してテレメトリ量を削減する
正解の根拠・詳細解説
サンプリングを設定することで、収集するテレメトリの一部のみを送信・保存しつつ、統計的に妥当な分析結果を維持しながらデータ量とコストを削減できます。
コンプライアンス要件により、収集したログデータを特定の期間保持する必要がある場合、Log Analyticsワークスペースで設定する項目は？
解答・解説を見る
正解: A. A. データ保持期間（Retention）
正解の根拠・詳細解説
Log Analyticsワークスペースでは、テーブルごと、またはワークスペース全体でデータ保持期間を設定でき、コンプライアンス要件（例: 1年間保持）に応じて調整できます。
多数のアラートが頻繁に発生し、運用チームが本当に重要なアラートを見逃してしまう状態を何と呼び、その対策として適切なものは？
解答・解説を見る
正解: A. A. アラートファティーグ（Alert Fatigue）。しきい値の見直しや動的なアラート（異常検知）の活用で対策する
正解の根拠・詳細解説
アラートファティーグは、過剰な数のアラートにより重要な通知が見逃される状態を指します。対策として、しきい値の適正化、アラートのグルーピング、動的しきい値（異常検知ベース）の活用などが有効です。
アプリケーションの内部状態（メモリ使用量、内部メトリクスなど）を計測する「ホワイトボックスモニタリング」に対し、外部から見たユーザー視点での可用性・応答性を計測する手法を何と呼びますか？
解答・解説を見る
正解: A. A. ブラックボックスモニタリング（例: 可用性テスト）
正解の根拠・詳細解説
ブラックボックスモニタリングは、外部からシステムを利用するユーザーの視点で可用性や応答時間を計測する手法（例: 可用性テスト）であり、内部の実装状態を計測するホワイトボックスモニタリング（アプリケーションのメトリクスなど）と相互に補完し合います。
ライブのプロダクション環境で発生した例外について、コードを再現環境にデプロイせずに、発生時のスナップショット（変数の状態やコールスタック）を取得したい場合に使用する機能は？
解答・解説を見る
正解: A. A. スナップショットデバッガー（Snapshot Debugger）
正解の根拠・詳細解説
Application Insightsのスナップショットデバッガーは、本番環境で例外が発生した際に、その時点の変数の値やコールスタックを含むスナップショットを自動的にキャプチャし、Visual Studioでデバッグできるようにします。
チームがリリース後のフィードバックを継続的に製品バックログに反映させるプロセスを構築する上で、最も重要なステップは？
解答・解説を見る
正解: A. A. モニタリングデータやユーザーフィードバックを定期的にレビューし、優先順位付けされたバックログ項目として登録する
正解の根拠・詳細解説
継続的フィードバックループでは、本番環境のモニタリングデータやユーザーからのフィードバックを定期的にレビューし、改善点を新しいバックログ項目として優先順位付けして登録することで、製品の継続的改善につなげます。
Application Insightsで、特定のページの読み込みに時間がかかっているユーザーのブラウザやデバイスの傾向を分析したい場合に確認する項目は？
解答・解説を見る
正解: A. A. ページビューのテレメトリに含まれるクライアント情報（ブラウザ・デバイス・地域など）
正解の根拠・詳細解説
Application Insightsのページビューテレメトリには、クライアントのブラウザ・OS・デバイスタイプ・地域などの情報が含まれており、特定の環境でパフォーマンス問題が発生していないかを分析できます。
複数チームが共通のApplication Insightsリソースを使用する大規模組織で、各チームが自分のサービスに関連するデータのみにアクセスできるよう制御したい場合の方法は？
解答・解説を見る
正解: A. A. Azure RBAC（ロールベースアクセス制御）とリソースレベルでの権限スコープ設定
正解の根拠・詳細解説
Azure RBACを使ってApplication Insightsリソースやリソースグループに対する権限スコープを設定することで、各チームが必要なデータのみにアクセスできるよう制御できます。
モバイルアプリケーションのクラッシュレポートを収集し、クラッシュの発生傾向（OS バージョン別など）を分析したい場合に活用できるサービスは？
解答・解説を見る
正解: A. A. Application Insights（または App Center のクラッシュ分析）
正解の根拠・詳細解説
Application InsightsやVisual Studio App Centerは、モバイルアプリのクラッシュレポートを収集し、OSバージョンやデバイスモデル別の発生傾向を分析するダッシュボードを提供します。
DevOpsの「継続的な学習と改善」の文化を組織に根付かせるために、リリース後に実施することが推奨されるプラクティスは？
解答・解説を見る
正解: A. A. ポストモートム（振り返り）を実施し、得られた学びをプロセス改善に反映する
正解の根拠・詳細解説
DevOps における継続的な学習と改善は、障害やリリースの結果を個人の落ち度ではなくシステムとプロセスの問題として扱うことで初めて機能します。非難のない（Blameless）ポストモーテムでは、何がいつ起きたかを時系列で整理し、その時点でなぜその判断が合理的に見えたのかを事実ベースで掘り下げ、検知の遅れや手順の曖昧さといった根本原因を特定します。そのうえで、監視アラートの追加、パイプラインへの自動テストや承認ゲートの組み込み、ランブックの更新といった具体的な改善策を作業項目として登録し、実際に完了するまで追跡することが重要です。選択肢Bのように担当者を特定して罰則を科すと、以後インシデントの報告や失敗の共有が抑制され、組織が学習に必要な情報そのものを失うため、かえって同種の障害が再発しやすくなります。振り返りを行わない運用や同じ手順を無変更で繰り返す運用も、フィードバックループが存在しないという点で改善にはつながりません。
