ホーム ›
対応資格一覧 ›
AZ-400 Designing and Implementing Microsoft DevOps Solutions 出題範囲 Design and implement source control Configure processes and communications Design and implement build and release pipelines Develop a security and compliance plan Implement an instrumentation strategy 例題に挑戦 スキルサートのAIが生成した演習問題のサンプルです。アプリでは毎週新しい問題が追加されます。
例題1 あなたのチームはAzure DevOpsを使用して、複数のマイクロサービスからなるアプリケーションを開発しています。各サービスは独立したライフサイクルを持ち、個別にデプロイ可能である必要があります。ソース管理の設計として、管理の複雑さを抑えつつ独立性を確保するために最も適切なアプローチはどれか。
単一のAzure DevOpsプロジェクト内で、各サービスに対して個別のGitリポジトリを作成する。 Team Foundation Version Control (TFVC) を使用して、フォルダレベルでアクセス権を細分化する。 サービスごとに個別のAzure DevOpsプロジェクトを作成し、それぞれにリポジトリを配置する。 すべてのサービスを単一のプロジェクト内の単一のGitリポジトリ（モノリポジトリ）で管理する。 単一のリポジトリ内でサービスごとに異なるブランチを作成し、マージを行わずに運用する。 解答と解説を見る 正解: 単一のAzure DevOpsプロジェクト内で、各サービスに対して個別のGitリポジトリを作成する。
正解は「単一のAzure DevOpsプロジェクト内で、各サービスに対して個別のGitリポジトリを作成する。」です。Azure DevOpsでは、一つのプロジェクト内に複数のGitリポジトリを作成することが可能です。マイクロサービスアーキテクチャにおいて、各サービスが独立したデプロイサイクルを持つ場合、リポジトリを分離することでビルド定義やリリースパイプライン、アクセス制御をサービス単位で最適化できます。一方でプロジェクトを分ける必要性は、組織の境界や完全に異なる管理体制がない限り低く、単一プロジェクト内でのリポジトリ分離が推奨されます。
例題2 Azure ReposのGitリポジトリにおいて、メインブランチ（main）のコード品質を維持するためにブランチポリシーを構成しています。開発者がプルリクエスト（PR）を作成した際、コードがコンパイル可能であることを自動的に確認し、最低2人のレビュー担当者の承認を必須としたいと考えています。設定すべき項目として適切な組み合わせはどれか。
ステータスチェックと変更セットの追跡 ロックブランチと必須の承認者グループ チェックインの制限と自動補完の有効化 パスのフィルターとマージ戦略の固定 ビルド検証と最小限のレビュー担当者数 解答と解説を見る 正解: ビルド検証と最小限のレビュー担当者数
正解は「ビルド検証と最小限のレビュー担当者数」です。Azure Reposのブランチポリシーにおいて、「ビルド検証」を設定することで、PRが作成または更新された際に自動的にビルドパイプラインを実行し、成功を確認できます。「最小限のレビュー担当者数」を設定することで、指定した人数（この場合は2人）の承認が得られるまでマージをブロックできます。これにより、手動レビューと自動テストの両面からコードの品質を担保することができます。他の選択肢は、要件を直接満たすポリシー設定ではありません。
重要用語
Agileプロセス Azure Boardsで提供される標準的なプロセスの一つです。ユーザーの要望を「ユーザーストーリー」として管理し、タスクの進捗を追跡します。アジャイル開発手法をベースにしており、作業項目のステータス遷移が一般的なアジャイルのベストプラクティスに従って構成されています。小規模から中規模のチームで、柔軟なプロジェクト管理を行う際に適しています。
Scrumプロセス スクラムガイドに基づいた作業項目管理を行うプロセスです。プロダクトバックログアイテム（PBI）やスプリントを使用し、反復的な開発をサポートします。試験では、Agileプロセスとの違いや、作業項目のライフサイクル（New, Committed, Doneなど）の理解が問われます。スプリント単位で進捗を厳密に管理したいチームに最適です。
継承プロセス Azure DevOpsのシステム規定プロセス（AgileやScrumなど）をカスタマイズするために作成するプロセスです。標準プロセスを直接編集することはできないため、既存のプロセスを「継承」した新しいプロセスを作成し、独自のフィールド、作業項目の種類、ステートを追加します。組織固有の業務フローをツール上に反映させるために必須の機能です。
サービスフック Azure DevOpsで発生したイベント（ビルド完了やコードのプッシュなど）をトリガーに、外部サービス（TeamsやSlack、Trelloなど）でアクションを実行させる仕組みです。サードパーティ製ツールとの統合を容易にし、開発サイクルにおける通知や自動化を促進します。JSON形式のペイロードを使用して、高度なワークフロー連携を実現できます。
Webhook HTTP POSTリクエストを通じて、Azure DevOpsの特定のイベント情報を外部のウェブサービスに送信する通知メカニズムです。サービスフックの一種として機能し、独自のAPIやカスタムアプリケーションとの連携に適しています。イベント駆動型のアーキテクチャを構築する際に、軽量かつリアルタイムにデータをやり取りするための標準的な手段として利用されます。
通知 (Notifications) 作業項目の変更、プルリクエストの作成、ビルドの失敗などのイベントをメール等でユーザーに知らせる機能です。プロジェクト全体の設定だけでなく、個人レベルでもフィルタ条件を設定して通知をカスタマイズできます。重要な変更をチーム全員が即座に把握し、アクションの遅延を防ぐことで、円滑なコミュニケーションと開発速度の維持を支援します。
エリアパス (Area Paths) プロジェクト内の作業項目を、機能別、チーム別、または論理的な構造（例：バックエンド、モバイルUI）に基づいて論理的にグループ化するための設定です。これにより、大規模なプロジェクトでも担当範囲ごとにタスクを整理し、特定の範囲に限定したクエリやダッシュボードの表示が可能になります。権限設定の単位としても機能し、アクセス制御に利用されます。
反復パス (Iteration Paths) 作業項目を特定の期間（スプリントやマイルストーン）に関連付けるための設定です。チームがいつどの作業を行うかをスケジュールし、ベロシティやバーンダウンチャートによる進捗管理を可能にします。プロジェクト全体のタイムラインの中で、特定の期間内に完了すべきタスクを明確化し、リリースの計画性と予測可能性を高めるために不可欠な要素です。 AZ-400 Designing and Implementing Microsoft DevOps Solutionsの対策はアプリで AIが毎週生成する新作問題・ランクマッチ・週次ランキング・AI診断で「続けられる」資格学習を。無料で始められます。
