AZ-104 サンプル問題

正解：C

A　250名を手作業で登録するのは非効率で、入力ミスの温床にもなる

B　組織アカウントの一括登録手段ではなく、管理者側で属性やライセンスを統制できない

C（正解）　正解。Entra管理センターの一括操作でCSVテンプレートに記入した複数ユーザーを一度に作成できる

D　Azure PolicyはAzureリソースのガバナンス機能であり、Entra IDユーザーの作成はできない

正解：D

A　メンバーの追加・削除がすべて手動になり、異動のたびに更新が必要で要件を満たさない

B　管理単位は管理権限を委任するスコープであり、リソースへのアクセス付与に使うグループの代替にはならない

C　所有者管理でも手動更新は残る。グループ種別の問題ではなくメンバーシップ方式の問題

D（正解）　正解。user.department -eq "Sales" のようなルールで属性に基づきメンバーが自動更新される。Microsoft Entra ID P1ライセンスが必要

正解：D

A　デバイスの参加はユーザーのサインイン手段を提供するものではなく、外部コラボの解決策にならない

B　アカウントが二重管理になり、退職・異動の追随やパスワード管理の負担とリスクが生じる

C　資格情報の共有は監査証跡を失わせる重大なセキュリティ違反

D（正解）　正解。招待メールを通じて外部ユーザーが自組織の資格情報のままゲストとしてアクセスできる

正解：C

A　個人所有デバイス(BYOD)向けの方式で、個人アカウントでのサインインを前提とし組織の完全管理には向かない

B　オンプレミスのAD DSドメイン参加が前提の方式で、ADを使っていない環境では構成できない

C（正解）　正解。会社所有デバイスを組織アカウントでサインインさせ、クラウドのみで管理する方式

D　組織の管理下に置くという要件をまったく満たさない

正解：B

A　サブスクリプション全体のあらゆるリソースを変更できてしまい、最小権限に反する

B（正解）　正解。対象リソースグループに限定し、仮想マシンの管理に必要な権限のみを付与できる

C　リソース管理に加えて他者への権限付与まで可能になり過剰

D　閲覧のみで仮想マシンの作成・管理ができない

正解：D

A　権限付与は可能だがリソースの完全な管理権限も付いてくるため過剰

B　リソースの変更は可能だがRBACのロール割り当てはできず、要件と正反対

C　閲覧のみでロール割り当てはできない

D（正解）　正解。ユーザーアクセスの管理(ロール割り当て)に特化し、リソースの変更権限を含まない

正解：A

A（正解）　正解。カスタムロールのActionsに広い権限を書き、NotActionsでMicrosoft.Network/* を除外できる

B　拒否割り当てはデプロイスタック等のAzure側機能が作成するもので、ユーザーが直接作成することはできない

C　RBACは許可の加算モデルであり、複数ロールを重ねても権限は狭まらない

D　Policyはリソースの構成状態を統制する機能で、特定ユーザーの権限を狭めるRBACの代替ではない

正解：C

A　ロール割り当てが複製されているわけではなく、上位スコープの割り当てがそのまま効いている

B　ロールは割り当てたスコープでのみ有効で、他のサブスクリプションには及ばない

C（正解）　正解。管理グループ→サブスクリプション→リソースグループ→リソースの順に割り当てが継承される

D　リソースグループスコープにも個別にロールを割り当てられる

正解：D

A　アクセスキー取得経由のアクセスは可能になるが過剰権限であり、Entra ID認証によるデータアクセスの解決策でもない

B　インターネット上の誰でも読めるようになり、特定ユーザーへの権限付与とはまったく異なる

C　Entra ID認証の要件に反し、キーの配布は監査・失効管理の面でもリスクが大きい

D（正解）　正解。ReaderはコントロールプレーンのロールでBlobデータは読めない。データプレーン用のロールが別途必要

正解：D

A　20回の割り当てと以後の個別メンテナンスが必要になり、設定漏れのリスクも高い

B　課金分離や上限の観点で現実的でなく、大規模な移行作業も発生する

C　初回は自動化できても、割り当てが20か所に分散する構造は変わらない

D（正解）　正解。管理グループへの割り当ては配下の全サブスクリプションに継承され、一元管理できる

正解：B・D

A　基本的なディレクトリ管理はFreeで利用できる

B（正解）　正解。条件付きアクセスはP1以上のライセンスが必要

C　ゲスト招待自体はFreeでも利用できる

D（正解）　正解。属性ベースの動的グループはP1以上のライセンスが必要

E　セキュリティの既定値群は無料で利用できる機能

正解：A・C・E

A（正解）　正解。Denyは条件に一致するリソースの作成・更新要求を拒否する効果

B　リソースを再起動する効果は存在しない

C（正解）　正解。Auditは非準拠リソースを拒否せず、コンプライアンス結果として記録する効果

D　リソースのサイズを変更する効果は存在しない

E（正解）　正解。DeployIfNotExistsは関連リソースが存在しない場合にテンプレートをデプロイする効果

F　承認フローを行う効果は存在しない

正解：B

A　低遅延のBlob専用アカウントで、テーブルやキューは扱えずアクセス層もない

B（正解）　正解。汎用v2は全ストレージサービスとホット/クール等のアクセス層をサポートする標準的な選択肢

C　ファイル共有専用のアカウントで、Blobやテーブルは扱えない

D　ページBLOB専用のアカウントで、汎用用途には使えない

正解：C

A　19文字であり3〜24文字の範囲内。長さは原因ではない

B　数字は使用できる

C（正解）　正解。ストレージアカウント名は英小文字と数字のみ・3〜24文字で、さらにAzure全体で一意である必要がある

D　名前はリージョン単位ではなくAzure全体で一意という制約

正解：A

A（正解）　正解。ZRSはリージョン内の3つの可用性ゾーンへ同期的に複製し、ゾーン障害に耐えつつデータをリージョン内に保つ

B　単一データセンター内の3コピーのため、ゾーン(データセンター)障害には耐えられない

C　リージョン障害には備えられるが、ペアリージョンへ複製するため「リージョン外に出さない」要件に反する

D　GRSと同様にセカンダリリージョンへ複製されるため要件に反する

正解：D

A　セカンダリへ複製はされるが、平常時にセカンダリを読み取ることはできない

B　リージョン内の冗長化であり、セカンダリリージョンという概念自体がない

C　単一データセンター内の複製で、他リージョンからの読み取りはできない

D（正解）　正解。読み取りアクセスgeo冗長ではセカンダリリージョンのエンドポイント(-secondary)から常時読み取りできる

正解：B

A　多くの組み合わせで既存アカウントの冗長性は変更(変換)できる

B（正解）　正解。LRSからGRS等への変更はポータルの設定変更や変換要求で行え、データが自動的にセカンダリへ複製され始める

C　ストレージアカウント名はAzure全体で一意のため同名では作成できず、複製の仕組みにもならない

D　バックアップは復旧手段であり、冗長性(レプリケーション)の変更ではない

正解：C

A　アーカイブ層はオフライン層であり、そのままでは読み取れない

B　標準優先度で最大15時間程度、高優先度なら1時間未満で完了する場合もあり、24時間が最短ではない

C（正解）　正解。アーカイブはオフライン層のため、オンライン層への層変更(リハイドレート)を待ってから読み取る

D　層の変更でデータ内容が変化することはない

正解：B

A　オンライン層だが、より低頻度アクセス向けに安価なコールド層がある

B（正解）　正解。コールド層はオンライン層の中で最も保存単価が低く、90日以上保持する低頻度データに適する(90日未満の削除には早期削除料金)

C　保存単価は最安だがオフライン層のため、即時読み取りの要件を満たさない

D　アクセス頻度が高いデータ向けで、保存単価が最も高い

正解：A

A（正解）　正解。ライフサイクル管理は経過日数などの条件で層の移動と削除をルールベースで自動実行する

B　自作スクリプトでも可能だが、標準機能があるのに自前実装・運用するのは負荷が高い

C　AzCopyはコピーのツールであり、同一Blobの層を日数条件で自動変更する仕組みではない

D　イミュータブルポリシーは削除・上書きを禁止する保持機能で、層の自動移動はできない

正解：C

A　層の移動や削除を自動化する機能で、削除からの復元機能ではない

B　変更履歴の記録機能であり、それ自体に復元機能はない

C（正解）　正解。論理削除を有効にすると、削除されたBlobが指定期間保持され、期間内なら復元できる

D　ロックは管理プレーンの操作制限で、Blobデータの削除防止・復元の機能ではない

正解：D

A　スナップショットは取得時点の状態を保持できるが、明示的に取得操作が必要で自動では作られない

B　層はコスト・性能の選択であり、過去の状態の保持とは無関係

C　GRSは障害対策の複製であり、上書き前の状態を保持する機能ではない(上書きは複製先にも反映される)

D（正解）　正解。バージョン管理を有効にすると、上書き・削除のたびに以前のバージョンが自動保持される

正解：B

A　実行中VMのサイズ変更にはVMの再起動が伴う

B（正解）　正解。リサイズは再起動を伴う操作であり、現在のハードウェアクラスタで提供されないサイズへは割り当て解除が必要な場合もある

C　VMのサイズは作成後でも変更できる

D　リサイズでディスクの内容が消えることはない

正解：C

A　再起動では同じホスト上で起動し直すことがあり、ホスト起因の問題が解消しない場合がある

B　サイズ変更は性能の変更が目的で、トラブルシューティングの手段としては副作用が大きい

C（正解）　正解。再デプロイはVMをAzure内の新しいホストへ移動して起動し直す操作で、接続問題のトラブルシューティングに使われる

D　再作成は最終手段であり、構成やローカルデータを失うリスクを伴う

正解：A

A（正解）　正解。ブート診断を有効にすると起動画面のスクリーンショットやシリアルログを取得でき、起動失敗の切り分けに役立つ

B　CPUなどの数値データでは起動画面の状態は分からない

C　管理操作の履歴であり、ゲストOSの起動状態は記録されない

D　ネットワークの通過可否の情報であり、OS起動画面の確認はできない

正解：D

A　Policyはリソース構成のガバナンスであり、ゲストOS内で任意のスクリプトを実行する機能ではない

B　タグはメタデータであり、OS内の処理は行えない

C　起動状態の確認機能であり、スクリプト実行はできない

D（正解）　正解。VM拡張機能としてスクリプトをダウンロード・実行でき、デプロイ後の構成作業を自動化できる

正解：D

A　スナップショットはディスクの時点コピーで、バージョン管理やリージョン展開を担うイメージ配布の仕組みではない

B　停止しただけのVMは固有情報が残っており、汎用イメージとして展開できない

C　手動配布は管理不能になりやすく、リージョン展開・バージョン管理の要件を満たさない

D（正解）　正解。一般化したイメージをCompute Galleryのイメージ定義・バージョンとして登録し、対象リージョンへレプリカを配置して展開できる

正解：A

A（正解）　正解。スポットVMは余剰キャパシティを大幅割引で利用でき、立ち退き(eviction)を許容できる中断可能なワークロードに適する

B　予約は常時稼働する定常的なワークロードのコミット割引で、夜間のみの中断可能ワークロードには不向き

C　利用自体は可能だが、中断を許容できるのに割引を活かさないためコスト面で最適でない

D　物理ホスト占有のためのオプションで、むしろ高コストになる

正解：C

A　いつでも立ち退きが起こり得るため、常時稼働の本番ワークロードには使えない

B　24時間稼働の要件に反する

C（正解）　正解。1年または3年のコミットで従量課金より大幅な割引が受けられ、定常稼働のワークロードに最適

D　単価差はあっても限定的で、移行コストとリスクに見合う定石ではない

正解：B

A　リソースの移動機能はリソースグループ・サブスクリプション間のもので、リージョンは選択できない

B（正解）　正解。Resource MoverはVMと関連リソースのリージョン間移動を計画的に実行でき、内部的にSite Recoveryの複製を利用する

C架空　そのような名称のサービスは存在しない

D　サイズ変更は同一リージョン内の性能変更であり、リージョンは変わらない

正解：D

A　サブスクリプション追加でも回避はできるが、管理が分散する過剰な対応

B　クォータはリージョン×サブスクリプション単位であり、リソースグループの分割では解決しない

C　クォータはキャパシティの一時的な不足ではなく上限設定のため、再試行では解決しない

D（正解）　正解。「クォータ」画面やサポートリクエストからvCPUクォータの引き上げを申請できる

正解：A

A（正解）　正解。Standard SKUのパブリックIPは常に静的割り当てで、リソースが存続する限り割り当て解除中も同じアドレスが維持される

B　これは2025年9月に廃止されたBasic SKUの動的割り当ての動作。現行のStandard SKUは動的割り当てを選択できない

C　静的割り当てのため割り当て解除しても維持される。OS内停止のみではコンピューティング課金も続いてしまう

D　DNS名ラベルは名前解決用の設定であり、IPアドレスが維持されるかどうかとは無関係

正解：B

A　UDは最大20まで増やせるが既定は5

B（正解）　正解。既定はUD 5(最大20)で、FDはリージョンにより2または3。FDは電源・ネットワークを共有する単位、UDは計画メンテナンスの単位

C　FDとUDの数が逆になっている

D　1つずつでは分散にならず、可用性セットの意味がない

正解：C

A　可用性セットはデータセンター内のラック障害対策(SLA 99.95%)で、データセンター全体の障害には耐えられない

B　近接配置グループは低遅延のために同一データセンターへ寄せる構成で、可用性はむしろ下がる方向

C（正解）　正解。複数の可用性ゾーンへVMを分散するとデータセンター(ゾーン)障害に耐えられ、99.99%のSLAが適用される

D　単一VMのSLAはディスク構成依存で低く、ゾーン障害にも耐えられない

正解：C

A　/24の総アドレス数だが、Azureでは予約分を除く必要がある

B　一般的なネットワークの計算(ネットワーク・ブロードキャストのみ除外)で、Azureの予約数を考慮していない

C（正解）　正解。Azureは各サブネットで先頭4つ(ネットワークアドレス・既定ゲートウェイ・DNS用×2)と末尾1つ(ブロードキャスト)の計5個を予約する

D　予約は5個であり6個ではない

正解：A

A（正解）　正解。接続予定のネットワークとアドレス空間が重複するとルーティングが成立しないため、事前の重複回避が必須

B　アドレス空間が重複すると接続時に通信できなくなる

C　VNetにはRFC1918等のプライベート空間を使うのが原則で、他組織のパブリック空間の流用は問題を起こす

D　変更は可能だが接続済み環境での重複解消は影響が大きく、設計時の回避が定石

正解：B

A　/30では予約5個を引くと利用可能アドレスがなくなるため作成できない

B（正解）　正解。Azureのサブネットは/29が最小(8アドレス中、予約5個を除く3個が利用可能)

C　作成可能だが最小ではない

D　単一アドレスのサブネットは作成できない

正解：C

A　許可・拒否の種別ではなく優先度の数値で評価順が決まる

B　作成順は評価に関係しない

C（正解）　正解。NSGは優先度100(小さいほど優先)の拒否ルールに一致した時点で評価を終了するため、200の許可ルールには到達しない

D　矛盾するルールがあっても無効化はされず、優先度順に評価される

正解：B

A　既定ルールによりインターネットからのインバウンドは拒否される

B（正解）　正解。既定ルールはAllowVnetInBound・AllowAzureLoadBalancerInBound・DenyAllInboundの3つで構成される

C　既定ルールでVNet内の通信は許可されている

D　カスタムルールがなくても既定ルールは常に機能する

正解：A

A（正解）　正解。ASGをNICに割り当て、NSGルールの送信元・宛先にASGを指定すれば役割ベースのルールを記述できる

B　分割でも実現できるが、IPアドレス体系の再設計と移行が必要で「同一サブネットのまま」の意図に合わない

C　IP列挙は台数追加のたびにルール修正が必要で、避けたい方式そのもの

D　サービスタグはAzureサービスのIP範囲を表すもので、自前のVMの役割分類には使えない

正解：D

A　インバウンドではサブネット側も評価される

B　NIC側も評価される

C　NSG同士に優先関係はなく、両方が順に評価される

D（正解）　正解。インバウンドはサブネット→NICの順で評価され、どちらかで拒否されると通信は到達しない

正解：B

A　ピアリングは推移的に働かないため、Bを経由した自動的な到達はできない

B（正解）　正解。非推移性はピアリングの重要な特性で、直接ピアリングまたはハブのNVA/ゲートウェイ経由のルーティングが必要

C　リージョンにかかわらず推移的な通信はできない

D　NSGはフィルターでありルーティングの欠如は解決しない

正解：A

A（正解）　正解。リージョンが異なるVNet間はグローバルピアリングで接続でき、トラフィックはパブリックインターネットを経由しない

B　グローバルピアリングにより異なるリージョン間でも接続できる

C　ピアリングのトラフィックはMicrosoftバックボーン内を流れる

D　ExpressRouteはオンプレミス接続のサービスで、VNet間のピアリングには不要

正解：C

A　VNet間通信は可能になるが、ゲートウェイの共用には追加設定が必要

B　ゲートウェイ転送の許可はゲートウェイを持つハブ側で有効にする設定で、逆になっている

C（正解）　正解。ゲートウェイを持つ側がgateway transitを許可し、利用する側がuse remote gatewaysを有効にする組み合わせ

D　追加のゲートウェイはコストが増える上、「リモートゲートウェイを使用」との併用もできない

正解：B

A　説明が逆になっている

B（正解）　正解。メトリックは軽量でほぼリアルタイムの数値、ログはKQLで分析する構造化された記録という役割分担

C　格納先も分析方法も異なる別のデータ種別

D　プラットフォームメトリックの収集は基本無償だが、保持や取り込みには制約・課金があり、無制限ではない

正解：A

A（正解）　正解。診断設定はログ・メトリックの送信先としてLog Analytics・ストレージアカウント・イベントハブ等を指定できる

B　アラートは通知の仕組みで、データの転送設定ではない

C　ワークスペースが自動でリソースのログを取りに行く仕組みはない

D　タグはメタデータであり、ログ送信の構成にはならない

正解：C

A　アクティビティログの既定の保持期間は90日で、それ以上は自動保持されない

B　アクティビティログ自体の保持期間を延長する設定はない

C（正解）　正解。長期保持にはエクスポートが必要で、送信先側の保持設定で3年保持を構成する

D　手動運用は漏れが発生しやすく、監査要件の担保として不適切

正解：B

A　保持期間は24時間ではない

B（正解）　正解。メトリックの保持は93日。長期保存が必要な場合は診断設定等でLog Analyticsやストレージへ転送しておく

C　再起動でメトリック履歴は消えない

D　メトリックエクスプローラーでの参照にライセンスは不要

正解：D

A　ホストメトリックにはゲストOS内のメモリ使用率等は含まれない

B　ブート診断は起動画面の確認機能で、性能データの継続収集はできない

C　目視の確認は継続的な収集・分析にならない

D（正解）　正解。ゲストOS内のデータ収集にはAzure Monitorエージェントとデータ収集ルールが必要で、VM insightsを有効化すると主要な性能データとマップが揃う

正解：A

A（正解）　正解。アラートルールで条件(シグナル・しきい値・集計期間)を定義し、通知先はアクショングループとして設定する

B　アクティビティログアラートは管理操作やサービス正常性のイベント向けで、CPUなどのメトリック条件には使わない

C　自動スケールはインスタンス数の調整機能で、通知の仕組みではない

D　可視化だけでは通知されない