模擬問題集一覧

AZ-400 模擬問題集(練習問題)

Azure DevOps Engineer 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

2 練習テスト 160 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

2 テスト · 全 160 問
1
模擬問題集1先頭 15 問 無料
80 問 120 分 合格 70%
2
模擬問題集2 プラン限定
80 問 120 分 合格 70%

説明

AZ-400(Azure DevOps Engineer)の合格に向けた、本番形式の模擬問題集です。全 160 問を2 回の練習テストに分割し、 試験モード/演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 160 問+全解説が受け放題

模試プラン(¥980/月)なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

AZ-400 の操作は、実機のハンズオンラボで身につける

問題集で覚えた知識を、本物の Azure・AWS 環境で手を動かして確かめられます。 Pro プランなら AZ-400 対応のハンズオンラボ 12 本と、この問題集の全 160 問がすべて使えます。 ラボは会員登録だけで 1 本無料で試せます。

AZ-400 の対応ラボを見る(12 本)ラボを 1 本無料で試す

AZ-400 の出題範囲(カバーしている分野)

全 160 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はAZ-400 の学習ガイドにまとめています。

AZ-400 の無料練習問題(15 問・解説つき)

会員登録なしで、全 160 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1セキュリティとコンプライアンス計画の策定セキュリティとコンプライアンス計画の策定
問題
あなたは App1 という名前のアプリのビルドとデプロイに Azure Pipelines のパイプラインを使用しています。 App1 がデプロイされる前に、アプリのすべてのコードがカスタム ツールを使用したセキュリティ検証に合格していることを保証する必要があります。 何をすべきですか?

選択肢と解説

  • 1
    会社の開発部門で使用しているブランチのポリシーに、ステータス チェックを追加する。
  • ✓
    main ブランチのポリシーに、ステータス チェックを追加する。
  • 3
    プロジェクトに Service hook を追加する。
  • 4
    すべてのリリース パイプラインのジョブ承認スコープを現在のプロジェクトに制限する。

解説

正解: main ブランチのポリシーにステータス チェックを追加する。
解説: Azure Repos のブランチ ポリシーには「ステータス チェックを必須にする (Require status checks)」項目があり、外部サービス(カスタム セキュリティ スキャナーなど)が REST API で報告したステータスが成功であることを、main ブランチへの変更がマージされる前に必須にできます。App1 が main ブランチからデプロイされる前提では、main ブランチのポリシーにステータス チェックを設定することで、カスタム ツールによるセキュリティ検証に合格していないコードがデプロイ対象になることを防げます。
各選択肢の検討:
  • 開発部門のブランチに付けても、main ブランチへ取り込まれる際に検証されないため、デプロイ前の保証になりません。
  • main ブランチのポリシーへのステータス チェック追加が、デプロイ対象コードへの検証を強制でき、要件を満たします。
  • Service hook は外部システムへのイベント通知の仕組みであり、デプロイをブロックする手段ではありません。
  • ジョブ承認スコープの制限はパイプラインがアクセスできるリソース範囲を狭めるための機能で、セキュリティ検証の実行や強制とは無関係です。
参考: Microsoft Learn: ブランチ ポリシーと設定
この問題のページを開く →
問題 2[アクション一覧] - サイトをスパイダーする (Spider the site) - 結果をレポートする (Repor…セキュリティとコンプライアンス計画の策定
問題
あなたは Pipeline1 という名前の Azure Pipelines のアプリケーション CI/CD パイプラインを持っています。 Pipeline1 に OWASP ZAP テストを追加する必要があります。 Pipeline1 にどの 4 つのアクションを順番に追加すべきですか? 回答するには、アクション一覧から適切なアクションを回答エリアに移動し、正しい順序に並べてください。 [アクション一覧] - サイトをスパイダーする (Spider the site) - 結果をレポートする (Report the results) - ベースラインを実行する (Run the baseline) - コンテナーを起動する (Start a container) - OWASP ZAP を毎週プルする (Pull OWASP ZAP weekly) - アクティブ スキャンを実行する (Run an active scan) 4 つのアクションを正しい順序で選択する組み合わせとして最も適切なものはどれですか?

選択肢と解説

  • ✓
    コンテナーを起動する → サイトをスパイダーする → アクティブ スキャンを実行する → 結果をレポートする
  • 2
    コンテナーを起動する → ベースラインを実行する → アクティブ スキャンを実行する → 結果をレポートする
  • 3
    OWASP ZAP を毎週プルする → コンテナーを起動する → サイトをスパイダーする → 結果をレポートする
  • 4
    ベースラインを実行する → サイトをスパイダーする → アクティブ スキャンを実行する → 結果をレポートする
  • 5
    コンテナーを起動する → サイトをスパイダーする → ベースラインを実行する → 結果をレポートする
  • 6
    OWASP ZAP を毎週プルする → サイトをスパイダーする → アクティブ スキャンを実行する → 結果をレポートする

解説

正解: コンテナーを起動する → サイトをスパイダーする → アクティブ スキャンを実行する → 結果をレポートする。
解説: OWASP ZAP を Azure Pipelines に統合する場合、ZAP は通常 Docker コンテナーとして実行します。まず ZAP コンテナーを起動して攻撃プロキシを準備し、対象 Web アプリをスパイダー(クロール)して URL の一覧を構築します。続いてアクティブ スキャンを実行して既知の脆弱性パターンに対する動的テストを行い、最後に結果(HTML/XML レポート)を生成・公開してパイプラインのアーティファクトとして取り込みます。この 4 つのステップが ZAP を使った典型的な動的セキュリティ テスト (DAST) のフローです。
各選択肢の検討:
  • コンテナー起動 → スパイダー → アクティブ スキャン → レポートが、ZAP の DAST 実施手順として正しい順序です。
  • ベースライン スキャンはパッシブな簡易チェックであり、スパイダー+アクティブ スキャンと併用する設計ではありません。両者を順に実行するこの流れは ZAP の標準手順と一致しません。
  • 「毎週プル」はスケジュールド トリガーの設定であってパイプライン内のステップではないため、4 ステップの中に含めるのは不適切です。
  • コンテナーを起動せずにベースラインから開始しているため、ZAP が動作する環境が用意されておらず誤りです。
  • アクティブ スキャンより後にベースラインを置くのは順序が誤っており、結果出力も適切に行われません。
  • 「毎週プル」はトリガー設定であり、4 ステップの中に含めるべきではありません。
参考: Microsoft Learn: Azure Pipelines で Docker コンテナーを使用する
この問題のページを開く →
問題 3どのシークレット権限を使用すべきですか?セキュリティとコンプライアンス計画の策定
問題
あなたは Microsoft ASP.NET Core アプリケーションを作成します。 このアプリケーションに対し、構成データとしてシークレットを提供するために Azure Key Vault を使用する予定です。 最小権限の原則 (principle of least privilege) に基づき、アプリケーションにシークレット権限を割り当てる Key Vault のアクセス ポリシーを作成する必要があります。 どのシークレット権限を使用すべきですか?

選択肢と解説

  • 1
    List のみ
  • 2
    Get のみ
  • ✓
    Get と List

解説

正解: Get と List。
解説: ASP.NET Core の Azure Key Vault 構成プロバイダー (Azure.Extensions.AspNetCore.Configuration.Secrets) は、Key Vault 上のシークレットを列挙し、それぞれの値を取得して構成のキー/値ペアにマッピングします。シークレットの一覧取得には List 権限が、各シークレットの値の取得には Get 権限が必要です。Microsoft のドキュメントでも、本プロバイダーを利用する際は Key Vault のアクセス ポリシーで Get と List の両方をアプリケーションに付与するよう明示されています。これが構成プロバイダー利用時の最小権限となります。
各選択肢の検討:
  • List のみではシークレットの値が読めず、構成として利用できません。
  • Get のみでは構成プロバイダーがシークレット一覧を列挙できず、初期ロードに失敗します。
  • Get と List の組み合わせが、構成プロバイダーの動作に必要な最小限の権限であり、最小権限の原則を満たします。
参考: Microsoft Learn: ASP.NET Core における Azure Key Vault 構成プロバイダー
この問題のページを開く →
問題 4この要件を満たすために、Azure ポータルで実行する手順として最も適切な組み合わせはどれですか?セキュリティとコンプライアンス計画の策定
問題
シミュレーション - あなたの会社は、すべての Azure Web アプリを 5 時間ごとにバックアップすることを要件とする新しいコンプライアンス戦略を導入する予定です。 あなたは、リソース グループ内にある az400-123456789-main という名前の Azure Web アプリを、同じリソース グループの Azure ストレージ アカウントに 5 時間ごとにバックアップする必要があります。 このタスクを完了するには、Microsoft Azure ポータルにサインインしてください。 この要件を満たすために、Azure ポータルで実行する手順として最も適切な組み合わせはどれですか?

選択肢と解説

  • ✓
    App Service の「バックアップ」ブレードを開き、対象ストレージ アカウントとコンテナーを設定し、「スケジュールド バックアップ」を有効化して頻度を 5 時間に設定し、保持期間と保存方法を構成して保存する。
  • 2
    App Service の「Application Insights」を有効化し、Log Analytics ワークスペースに 5 時間ごとに出力するように構成する。
  • 3
    対象ストレージ アカウントのライフサイクル管理ポリシーを作成し、5 時間ごとに Web アプリのデータをコピーするルールを定義する。
  • 4
    Azure Backup コンテナーを作成し、Web アプリをそのコンテナーに登録して 5 時間間隔のバックアップ ポリシーを割り当てる。

解説

正解: App Service の「バックアップ」ブレードからスケジュールド バックアップを構成する。
解説: Azure App Service (Web アプリ) は組み込みの「Backup」機能を持ち、Azure portal の対象 Web アプリのメニューから [バックアップ] ブレードを開き、保存先となる Azure ストレージ アカウントと BLOB コンテナーを選択して構成します。スケジュールド バックアップを有効化すると、バックアップ頻度(時間/日単位)と開始時刻、保持期間を指定でき、たとえば「5 時間ごと」のような時間単位の繰り返しを設定可能です。これにより本問の要件(az400-123456789-main を 5 時間ごとにストレージ アカウントへバックアップ)を満たせます。
各選択肢の検討:
  • App Service の組み込みバックアップでストレージ アカウントへのスケジュールド バックアップを構成するのが正規の手順です。
  • Application Insights はテレメトリ収集のための機能であり、Web アプリのバックアップは取得できません。
  • ライフサイクル管理ポリシーはストレージ アカウント上の BLOB の階層移動/削除を制御するもので、App Service のバックアップを取る仕組みではありません。
  • Azure Backup (Recovery Services コンテナー) は VM やファイル共有等のバックアップで使用し、App Service Web アプリは対象ではありません。
参考: Microsoft Learn: App Service でアプリをバックアップする
この問題のページを開く →
問題 5ビルドとリリースのパイプラインの設計・実装ビルドとリリースのパイプラインの設計・実装
問題
あなたは Contoso という名前の Azure DevOps 組織の無料 (Free) レベルを使用しています。Contoso には 10 個のプライベート プロジェクトが含まれます。各プロジェクトには依存関係のない複数のジョブがあります。ビルド プロセスでは、オンプレミスのファイル システム上にあるリソース ファイルへのアクセスが必要です。 あなたは 5 台のセルフホステッド エージェントで頻繁にジョブを実行していますが、ビルド時間が長く、ビルドが頻繁にキューに積まれます。 キューに積まれるビルドの数と、ビルドの実行に要する時間を最小化する必要があります。 何をすべきですか?

選択肢と解説

  • 1
    パイプラインが Microsoft ホステッド エージェントを使用するように構成する。
  • 2
    追加のセルフホステッド エージェントを登録する。
  • ✓
    セルフホステッドの並列ジョブを購入する。
  • 4
    Microsoft ホステッドの並列ジョブを購入する。

解説

正解: セルフホステッドの並列ジョブを購入する。
解説: Azure DevOps の Free レベルではセルフホステッド エージェントを使用する場合、1 つの並列ジョブだけが無償で提供されます。エージェントを 5 台登録しても、並列ジョブの上限が 1 のままなら同時実行はエージェント数ではなく並列ジョブ数で制限されるため、ビルドはキューに溜まります。ビルドはオンプレミスのファイル システムにアクセスする必要があるため Microsoft ホステッド エージェントには移行できません。したがって、追加のセルフホステッド並列ジョブを購入することで同時に走行できるビルド数を増やし、キュー長と総ビルド時間を短縮するのが正しい解決策です。
各選択肢の検討:
  • Microsoft ホステッド エージェントはオンプレミス ネットワーク上のファイルにアクセスできないため、要件に合いません。
  • エージェントをさらに登録しても、Free 階層では同時実行可能な並列ジョブが 1 のままで、キューは解消されません。
  • セルフホステッドの並列ジョブを購入することで、既存のセルフホステッド エージェント上で同時に実行できるジョブ数が増え、キュー長とビルド完了までの時間を最小化できます。
  • Microsoft ホステッドの並列ジョブを購入してもオンプレミス資産にアクセスできないため、本ビルド プロセスでは使用できません。
参考: Microsoft Learn: Azure Pipelines の並列ジョブを構成して支払う
この問題のページを開く →
問題 6実行すべきコマンドはどれですか?セキュリティとコンプライアンス計画の策定
問題
あなたは Node.js アプリケーションを WhiteSource Bolt でスキャンします。 スキャンの結果、無効なライセンスを持つ多数のライブラリが検出されましたが、それらは開発時にのみ使用されているものです。 WhiteSource Bolt によって本番 (production) 依存関係のみがスキャンされるようにする必要があります。 実行すべきコマンドはどれですか?

選択肢と解説

  • 1
    npm edit
  • 2
    npm publish
  • ✓
    npm install
  • 4
    npm update

解説

正解: npm install。
解説: WhiteSource Bolt (現 Mend Bolt) は node_modules フォルダー内に実際にインストールされているパッケージをスキャン対象とします。本番依存関係のみに絞るには、スキャンの前に npm install --production(または環境変数 NODE_ENV=production と npm install) を実行して devDependencies を除外したクリーンな node_modules を用意します。これによって開発時にのみ使用するライブラリはインストールされず、Bolt のスキャン対象から外れます。
各選択肢の検討:
  • npm edit はインストール済みパッケージのソースを直接編集するためのコマンドで、依存関係のスコープ制御には使えません。
  • npm publish は自身のパッケージをレジストリに公開するコマンドであり、依存関係スキャンとは無関係です。
  • npm install --production によって devDependencies を除外した node_modules を生成でき、WhiteSource Bolt が本番依存だけをスキャンするようになります。
  • npm update は既存依存関係のバージョン更新で、開発用依存を取り除く動作はしません。
参考: Microsoft Learn: Azure Pipelines での JavaScript と Node.js アプリのビルド
この問題のページを開く →
問題 7このポリシーの効果は何ですか?セキュリティとコンプライアンス計画の策定
問題
あなたは次の Azure Policy を持っています。 if: { allOf: [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly", "notEquals": "true" } ] }, then: { effect: "deny" } このポリシーをテナント ルート グループに割り当てます。 このポリシーの効果は何ですか?

選択肢と解説

  • 1
    既存の Azure ストレージ アカウントへのすべての HTTP トラフィックを禁止する。
  • ✓
    新規の Azure ストレージ アカウントへのすべてのトラフィックが暗号化されることを保証する。
  • 3
    新規の Azure ストレージ アカウントにインターネット経由でアクセスする際の HTTPS トラフィックを禁止する。
  • 4
    新規の Azure ストレージ アカウントのすべてのデータが保存時に暗号化されることを保証する。

解説

正解: 新規の Azure ストレージ アカウントへのすべてのトラフィックが暗号化されることを保証する。
解説: このポリシーは「リソース種別が Microsoft.Storage/storageAccounts であり、かつ supportsHttpsTrafficOnly が true でない」ストレージ アカウントの作成や更新を deny します。supportsHttpsTrafficOnly を true に設定することは「Secure transfer required(安全な転送が必要)」を有効にすることと同じで、HTTPS 以外の接続(HTTP)を拒否する設定です。Azure Policy の deny 効果は新しくデプロイされる/更新されるリソースの作成時に評価されるため、結果として「新規ストレージ アカウントは暗号化された (HTTPS) トラフィックでのみアクセス可能」になります。
各選択肢の検討:
  • Policy の deny 効果は既存リソースを直接ブロックしませんし、既存トラフィックを動的に止める仕組みでもないため、既存ストレージへの HTTP 遮断は本ポリシーの直接効果ではありません。
  • 新規ストレージ アカウントの supportsHttpsTrafficOnly を実質的に true 強制するため、すべてのトラフィックが HTTPS (暗号化) となります。
  • HTTPS は許可される側であり禁止対象ではありません。
  • このポリシーは転送時 (HTTPS) の暗号化を強制するもので、保存時暗号化 (encryption at rest) を制御するものではありません。
参考: Microsoft Learn: Azure Storage で安全な転送を必須にする
この問題のページを開く →
問題 8使用すべきバージョン管理システムはどれですか?ソース コントロール戦略の設計・実装
問題
あなたは Azure DevOps を使用して、PROJ-01 という名前のプロジェクトの Azure Pipelines を構成しています。 ソース コードを社内ネットワーク上のマネージド Windows サーバーに保存できるバージョン管理システムを使用する準備をしています。 使用すべきバージョン管理システムはどれですか?

選択肢と解説

  • ✓
    GitHub Enterprise
  • 2
    Bitbucket Cloud
  • 3
    GitHub Professional
  • 4
    Azure Repos の Git

解説

正解: GitHub Enterprise。
解説: 要件は「社内ネットワーク上のマネージド Windows サーバーにソース コードを保存する」、つまりオンプレミスでホストできるバージョン管理システムです。GitHub Enterprise Server は組織のオンプレミス インフラ(Windows を含むホスト環境)にデプロイ・運用できる自己ホスト型製品で、Azure Pipelines のサービス接続から接続元として利用できます。Azure Pipelines は GitHub Enterprise Server リポジトリをトリガー対象として扱えるため、本シナリオの要件に最も適合します。
各選択肢の検討:
  • GitHub Enterprise (Server) はオンプレミスにデプロイ可能なため、社内のマネージド Windows サーバーに置きたいという条件に合致します。
  • Bitbucket Cloud は SaaS であり、オンプレミス ホスティングはできません (オンプレ版は Bitbucket Data Center)。
  • GitHub Professional は個人向けのプランで、自社ネットワークでホストするオンプレ版ではありません。
  • Azure Repos の Git は Azure DevOps Services 上のクラウド ホスト型で、社内サーバーには配置できません (オンプレミスは Azure DevOps Server)。
参考: Microsoft Learn: Azure Pipelines で GitHub Enterprise Server リポジトリをビルドする
この問題のページを開く →
問題 9この解決策は目的を満たしますか?計測戦略の実装
問題
あなたの会社は、監視目的で Azure SQL Database Intelligent Insights と Azure Application Insights を使用しています。 あなたは、アドホック クエリを使ってこのモニタリング データを分析する作業を任されました。正しいクエリ言語を使用する必要があります。 解決策: Transact-SQL を使用する。 この解決策は目的を満たしますか?

選択肢と解説

  • 1
    はい
  • ✓
    いいえ

解説

正解: いいえ。
解説: Azure SQL Database Intelligent Insights は診断ログとして Azure Monitor (Log Analytics) や Event Hubs に出力され、Application Insights もテレメトリは Azure Monitor / Log Analytics ストアに保存されます。これらに対するアドホック クエリには Kusto Query Language (KQL) を使用します。Transact-SQL は Azure SQL Database のデータベース エンジンに対するクエリ言語であり、Intelligent Insights の診断ログや Application Insights のテレメトリを直接照会する言語ではありません。したがってこの解決策は目的を満たしません。
各選択肢の検討:
  • はい: Transact-SQL は SQL Database の業務データへの問い合わせ用で、Application Insights の分析には使えないため誤りです。
  • いいえ: 両モニタリング データのアドホック分析には Kusto (KQL) が必要であり、Transact-SQL では要件を満たしません。
参考: Microsoft Learn: Azure Monitor のログ クエリの概要
この問題のページを開く →
問題 10[スコープ一覧] - stage - job - pipeline settings UI - pipeline roo…ビルドとリリースのパイプラインの設計・実装
問題
あなたは Azure Pipeline を持っています。 構成値を変数として保存する必要があります。 変数を定義できるスコープは 4 つあり、優先順位 (precedence) の高いものから低いものへ並べる必要があります。 回答するには、スコープ一覧から適切なスコープを回答エリアに移動し、正しい順序に並べてください。 [スコープ一覧] - stage - job - pipeline settings UI - pipeline root - task 優先順位を高い方から低い方の順に並べた組み合わせとして最も適切なものはどれですか?

選択肢と解説

  • ✓
    job → stage → pipeline root → pipeline settings UI
  • 2
    pipeline settings UI → pipeline root → stage → job
  • 3
    task → job → stage → pipeline root
  • 4
    stage → job → pipeline root → pipeline settings UI
  • 5
    pipeline root → pipeline settings UI → stage → job

解説

正解: job → stage → pipeline root → pipeline settings UI。
解説: Azure Pipelines における変数のスコープと優先順位は、ローカルに定義されたものほど優先されます。Microsoft Learn のドキュメントには、同名の変数を複数のスコープで設定した場合、高い方からの優先順位は (1) YAML の Job レベル、(2) YAML の Stage レベル、(3) Pipeline root レベル、(4) Pipeline settings UI で設定された変数、と明示されています。Task は変数のスコープではないため、回答対象に含まれません。
各選択肢の検討:
  • job → stage → pipeline root → pipeline settings UI が Microsoft Learn の優先順位定義と一致します。
  • pipeline settings UI → pipeline root → stage → job は順序が逆です。
  • task は変数スコープではないため、回答に含めるのは誤りです。
  • stage → job では Job が Stage より優先されるという仕様に反します。
  • pipeline root が pipeline settings UI より下位とする並びは、Microsoft Learn の定義に反します。
参考: Microsoft Learn: Azure Pipelines の変数を定義する
この問題のページを開く →
問題 11[アクション一覧] - 証明書をアップロードする (Upload a certificate) - クライアント シーク…セキュリティとコンプライアンス計画の策定
問題
あなたは Exabeam Fusion SIEM と Azure クラウド プラットフォームを使用しています。 Exabeam と Azure を統合する必要があります。ソリューションでは OAuth 認証を使用する必要があります。 順番に実行すべき 3 つのアクションはどれですか? 回答するには、アクション一覧から適切なアクションを回答エリアに移動し、正しい順序に並べてください。 [アクション一覧] - 証明書をアップロードする (Upload a certificate) - クライアント シークレットを作成する (Create a client secret) - Microsoft Entra (旧 Microsoft Azure Active Directory) に Exabeam アプリケーションを登録する (Register an Exabeam application in Microsoft Entra) - Exabeam Azure クラウド コネクタを構成する (Configure the Exabeam Azure cloud connector) - API アクセス許可を構成する (Configure API permissions) 3 つのアクションを正しい順序で選択する組み合わせとして最も適切なものはどれですか?

選択肢と解説

  • ✓
    Microsoft Entra に Exabeam アプリケーションを登録する → クライアント シークレットを作成する → API アクセス許可を構成する
  • 2
    Microsoft Entra に Exabeam アプリケーションを登録する → API アクセス許可を構成する → クライアント シークレットを作成する
  • 3
    クライアント シークレットを作成する → Microsoft Entra に Exabeam アプリケーションを登録する → API アクセス許可を構成する
  • 4
    Microsoft Entra に Exabeam アプリケーションを登録する → 証明書をアップロードする → Exabeam Azure クラウド コネクタを構成する
  • 5
    API アクセス許可を構成する → クライアント シークレットを作成する → Microsoft Entra に Exabeam アプリケーションを登録する

解説

正解: Microsoft Entra に Exabeam アプリケーションを登録する → クライアント シークレットを作成する → API アクセス許可を構成する。
解説: OAuth (クライアント資格情報フロー) で Exabeam を Azure と連携させる場合、まず Microsoft Entra ID にアプリ登録を作成して clientId と tenantId を確保し、続けてクライアント シークレットを発行します。最後に、収集対象のリソースに合わせて API アクセス許可(Microsoft Graph や Azure Monitor などへのアクセス)を構成し、テナント管理者の同意を与えます。証明書アップロードは OAuth 認証では不要、Exabeam Azure クラウド コネクタの構成は Exabeam 側設定で Azure 側の OAuth セットアップには含まれません。
各選択肢の検討:
  • Entra にアプリ登録 → クライアント シークレット作成 → API アクセス許可の構成、が OAuth 連携の正しい順序です。
  • アクセス許可を先に構成しても、まだシークレットがないため Exabeam 側からの認証が成立しません。
  • アプリ登録がまだ存在しない段階でクライアント シークレットは作成できないため誤りです。
  • OAuth 認証では証明書ではなくクライアント シークレットを利用します。コネクタ構成は Exabeam 側手順であり、Azure 側 3 ステップに含めるものではありません。
  • アプリ登録が最後では他の手順を実行できないため誤りです。
参考: Microsoft Learn: クイック スタート: Microsoft ID プラットフォームにアプリケーションを登録する
この問題のページを開く →
問題 12ビルドとリリースのパイプラインの設計・実装ビルドとリリースのパイプラインの設計・実装
問題
あなたは、自分が作成した NuGet パッケージをホストするために Azure Artifacts を使用しています。 そのパッケージの 1 つを、組織外の匿名 (anonymous) ユーザーが利用できるようにする必要があります。ソリューションでは公開ポイントの数を最小化する必要があります。 何をすべきですか?

選択肢と解説

  • 1
    そのパッケージのフィード URL を変更する。
  • ✓
    そのパッケージ用に新しいフィードを作成する。
  • 3
    そのパッケージをリリース ビューに昇格 (Promote) する。
  • 4
    そのパッケージをパブリック NuGet リポジトリに公開する。

解説

正解: そのパッケージ用に新しいフィードを作成する。
解説: Azure Artifacts では、フィードの可視性 (visibility) はフィード単位で構成します。匿名ユーザーが利用できるようにするには、そのフィードを「Public」(パブリック プロジェクト配下のフィード)として公開する必要があります。既存フィードを丸ごとパブリックに切り替えると他のすべてのパッケージも公開されてしまうため、対象パッケージ用に専用の新しい (パブリックな) フィードを作成し、そこにパッケージを発行するのが、公開ポイントの最小化と要件を両立する正しい方法です。
各選択肢の検討:
  • フィード URL は識別子であり、変更しても匿名アクセスは付与されません。
  • パッケージ用に新しい (パブリック プロジェクト配下の) フィードを作成するのが、匿名アクセスを実現しつつ他パッケージへの影響を抑える正しい手段です。
  • リリース ビューへの昇格はパッケージのライフサイクル管理機能で、外部の匿名ユーザーへの公開設定ではありません。
  • NuGet.org への公開は要件としての「公開ポイントの最小化」に反し、Azure Artifacts 外への二重公開となるため不適切です。
参考: Microsoft Learn: Azure Artifacts フィードのアクセス許可
この問題のページを開く →
問題 13ビルドとリリースのパイプラインの設計・実装ビルドとリリースのパイプラインの設計・実装
問題
あなたは、App1 という名前のアプリのビルドとデプロイに使用する Azure Pipeline を持っています。ビルド ジョブは Microsoft ホステッドの Windows エージェントを使用しています。 App1 のビルド ジョブは断続的にタイムアウト エラーを返します。 ビルド ジョブが正常に完了するようにする必要があります。ソリューションでは管理作業を最小化する必要があります。 何をすべきですか?

選択肢と解説

  • 1
    ビルド エージェントの構成を変更する。
  • 2
    セルフホステッド エージェントをデプロイする。
  • 3
    Microsoft ホステッドの Linux エージェントに変更する。
  • ✓
    並列ジョブを追加で購入する。

解説

正解: 並列ジョブを追加で購入する。
解説: Microsoft ホステッド エージェントには 1 ジョブあたりの実行時間上限があり、特に無料割り当ての並列ジョブを使う場合は、Public プロジェクトでない限り 1 ジョブあたり 60 分の制限が課されます。並列ジョブを追加購入 (Microsoft-hosted parallel jobs) するとビルド ジョブのタイムアウトが 360 分まで引き上げられ、断続的なタイムアウトを根本的に解消できます。エージェント自体の構成変更やセルフホステッドへの切替えはより多くの管理作業を伴うため、管理作業最小化の要件を満たしません。
各選択肢の検討:
  • Microsoft ホステッド エージェントの構成 (CPU/メモリなど) はユーザーがカスタマイズできないため不適切です。
  • セルフホステッド エージェントの構築・運用は管理コストが大きく、要件と一致しません。
  • Linux エージェントに変えてもジョブ時間制限の原因 (無料並列ジョブの 60 分制限) は解消されません。
  • 並列ジョブを購入すると 1 ジョブの最大実行時間が 360 分に拡張され、タイムアウト問題が解消します。これが管理作業を最も抑えた解決策です。
参考: Microsoft Learn: Azure Pipelines の並列ジョブを構成して支払う
この問題のページを開く →
問題 14- Git からの認証をサポートする - 認証時に資格情報を入力する手間を最小化する 何を推奨すべきですか?セキュリティとコンプライアンス計画の策定
問題
あなたは Contoso という名前の Azure DevOps 組織を持っています。 次の要件を満たす認証メカニズムを推奨する必要があります。 - Git からの認証をサポートする - 認証時に資格情報を入力する手間を最小化する 何を推奨すべきですか?

選択肢と解説

  • ✓
    Azure DevOps の個人用アクセス トークン (PAT)
  • 2
    Azure DevOps の代替資格情報 (Alternate credentials)
  • 3
    Azure Active Directory (Azure AD) のユーザー アカウント
  • 4
    Azure Active Directory (Azure AD) のマネージド ID

解説

正解: Azure DevOps の個人用アクセス トークン (PAT)。
解説: Azure DevOps から Git で操作 (clone/push/pull) する際の標準的な認証手段は PAT です。Git は Basic 認証として PAT を渡すことができ、Git Credential Manager 等と組み合わせると初回入力以降はキャッシュされ、操作のたびに資格情報を入力する必要がなくなります。これにより「Git からの認証サポート」と「資格情報入力の手間の最小化」の両方を満たせます。
各選択肢の検討:
  • PAT は Git クライアントから直接利用でき、資格情報マネージャーと組み合わせて入力を最小化できる正しい選択です。
  • 代替資格情報 (Basic 認証用のユーザー名/パスワード) は既に非推奨かつ既定で無効化されており、推奨されません。
  • Azure AD のユーザー アカウントを直接 Git で利用する場合、対話的サインインやデバイス コード フローが必要となり、資格情報入力の最小化要件と一致しません。
  • マネージド ID は Azure リソース (VM、App Service など) のためのアイデンティティであり、Git クライアントからの認証用途ではありません。
参考: Microsoft Learn: 個人用アクセス トークンを使用する
この問題のページを開く →
問題 15選択肢: itemType / resultCode / source / success計測戦略の実装
問題
ホットスポット - あなたは、ホーム ページのページ読み込みパフォーマンスに基づいてトリガーされるアラートを作成する予定です。 次の Application Insights ログ クエリ (概要) を確認してください。 requests | where timestamp >= ago(7d) | where operation_Name endswith 'Home/Index' | where operation_Name startswith 'GET' | summarize percentiles(duration, 50, 90, 95) by bin(timestamp, 1h) | extend threshold = 675 | render timechart このクエリでは、duration の 50/90/95 パーセンタイル (percentile_duration_50, percentile_duration_90, percentile_duration_95) と固定しきい値 threshold=675 が時系列でレンダリングされています。 次の 2 つの文を完成させる選択肢として、最も適切な組み合わせはどれですか? 文 1: ほとんどのユーザーのページ読み込み体験に基づいてアラートを作成するには、アラート レベルを [回答] に基づかせる必要がある。 選択肢: percentile_duration_50 / percentile_duration_90 / percentile_duration_95 / threshold 文 2: 認証エラーがサーバーで発生したときにのみアラートを作成するには、クエリを [回答] でフィルタリングする必要がある。 選択肢: itemType / resultCode / source / success

選択肢と解説

  • 1
    文 1: percentile_duration_95、文 2: resultCode
  • 2
    文 1: percentile_duration_50、文 2: success
  • 3
    文 1: percentile_duration_95、文 2: success
  • ✓
    文 1: percentile_duration_90、文 2: resultCode
  • 5
    文 1: threshold、文 2: source

解説

正解: 文 1: percentile_duration_90、文 2: resultCode。
解説: 「ほとんどのユーザーのページ読み込み体験」を捉える指標としては、外れ値を排除しつつ広範なユーザーをカバーする 90 パーセンタイル (P90) が一般的に推奨されます。50 パーセンタイル (中央値) は半数のユーザー、95 パーセンタイルはより極端な遅いケースを表すため、「ほとんどのユーザー」というニュアンスにはやや過剰です。また、Application Insights の requests テーブルでサーバー側の認証エラー (HTTP 401 など) を絞り込むには resultCode (HTTP ステータス コード) でフィルターするのが正しい方法です。success は成功/失敗の真偽値で、認証エラーかどうかを区別できません。
各選択肢の検討:
  • P95 と resultCode は P95 が「ほとんどのユーザー」の代表値としては保守的すぎ、不正確です。
  • P50 と success は中央値では多数派の体感をカバーできず、success ではエラーの種別 (認証など) を識別できません。
  • P95 と success も同様の理由で不適切です。
  • P90 と resultCode は Application Insights における Web パフォーマンス監視と認証エラー検出の双方で実務的に妥当な組み合わせです。
  • threshold は集計済みの定数値で、アラート レベルの「基準」として直接用いる対象ではありません。source は requests テーブルの認証エラー識別に用いるフィールドではありません。
参考: Microsoft Learn: Application Insights のログ クエリ
この問題のページを開く →

AZ-400 対策のハンズオンラボ

実際の Azure・AWS 環境を払い出して手を動かせます。問題演習と組み合わせると理解が定着します。

Azure Functions CLI でタイマー関数を作成する
beginner・約 45 分
Azure Functions を C# で作成・ローカル実行・デプロイ
intermediate・約 60 分
Terraform で Azure ネットワーク基盤を構築
advanced・約 60 分
Terraform で AKS クラスタをデプロイ
advanced・約 60 分
AKS にコンテナ アプリを ACR Build でデプロイ
intermediate・約 60 分
SQL Database から ARM テンプレートをエクスポートし Template Specs に保存
beginner・約 45 分
既存 Azure リソースを Terraform にインポート
advanced・約 30 分
Azure Arc でハイブリッド環境を Ansible + Bicep で大規模管理
advanced・約 75 分
AZ-400 のラボを全て見る(12 件)→

AZ-400 模擬問題集についてよくある質問

AZ-400 の練習問題は無料で試せますか?

はい。AZ-400 は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン(月額 ¥980)または Pro プラン(月額 ¥4,980)でご利用ください。

問題は何問ありますか?

AZ-400 は本番形式の練習テスト 2 回・全 160 問を収録しています。全問に解説が付いています。

解説は付いていますか?

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン(出題分野)別の正答率も受験後に確認できます。

AZ-400 のハンズオン学習もできますか?

はい。AZ-400 に対応するハンズオンラボを 12 件ご用意しています。実際の Azure・AWS 環境を払い出して手を動かしながら学習できます。