AZ-900 サンプル問題

正解：B

A　IaaSではゲストOSより上の層は利用者の責任。自動更新を有効にするかどうかを決めるのも利用者側の判断になる

B（正解）　正解。IaaSではMicrosoftが物理データセンター・物理ネットワーク・ホストまでを担い、ゲストOS・ミドルウェア・アプリ・データは利用者の責任範囲になる

C　サイズやSKUで責任分界点が動くことはない。分界点はIaaS/PaaS/SaaSというサービスモデルで決まる

D　責任共有モデルはリージョンによって変わらない。データの所在地はリージョンで決まるが、責任分界点とは別の話

正解：D

A　アプリそのものはどのモデルでも利用者の資産であり、責任は移らない

B　データとアクセス権はIaaS・PaaS・SaaSのいずれでも常に利用者の責任として残る

C　IDとアカウントの管理は全モデル共通で利用者の責任。PaaSにしても消えない

D（正解）　正解。PaaSではプラットフォーム(OS・ミドルウェア・ランタイム)の保守をMicrosoftが担うため、利用者はアプリとデータに集中できる

正解：C

A　仮想マシンやストレージといった基盤だけを借りるモデル。その上のアプリは自分で構築・運用する必要がある

B　アプリを開発・実行するための土台を借りるモデル。動かすアプリは利用者が用意するため「完成品をすぐ使う」形ではない

C（正解）　正解。完成したアプリケーションをサブスクリプションで利用する形態で、利用者はデータと利用者アカウントの管理に責任を持つ

D　オンプレミスとパブリッククラウドを組み合わせた配置モデルの名前であり、サービスモデル(IaaS/PaaS/SaaS)の分類ではない

正解：A

A（正解）　正解。OSを含む環境を利用者が自由に構成できるため、既存構成をそのまま持ち込むリフト&シフトに向く

B　OSやランタイムのバージョンはプラットフォーム側が管理するため、特定の古い構成を維持したい要件とは相性が悪い

C　提供元が用意したアプリを使う形態であり、自社の既存パッケージを動かす場所ではない

D　イベントに応じて短時間のコードを実行する形態。OS構成を維持したまま既存パッケージを動かす用途には合わない

正解：B

A　専有ハードウェアはプライベートクラウドや専用ホストなどの特別な形態の話。パブリッククラウドは基盤を多数の利用者で共有するのが前提

B（正解）　正解。共有基盤を前提とすることで規模の経済が働き、初期投資なしに必要な分だけ調達できる

C　専用線接続は選択肢の一つに過ぎない。パブリッククラウドは公衆ネットワーク越しに利用できるのが基本

D　設備を自ら保有するのはオンプレミスやプライベートクラウドの考え方で、パブリッククラウドの説明ではない

正解：C

A　共有基盤を利用する形態であり、自社設備内でのみ処理するという要件を満たせない

B　複数のクラウド事業者を併用する考え方。事業者が増えるだけで、自社設備で処理する要件の答えにはならない

C（正解）　正解。自社専用の環境をクラウド的に運用する形態で、統制を保ちながらセルフサービスや弾力性の一部を得られる。ただし設備投資と運用負担は自社に残る

D　コードの実行形態を指す言葉であり、リソースをどこに配置するかという配置モデルの分類ではない

正解：D

A　1台のマシンのCPUやメモリを増強する手法を指す語。リソースをどこに置くかという話ではない

B　災害でシステムが失われたときに復旧する備え。平常時の能力不足を補う仕組みとは目的が異なる

C　アプリの実行単位をパッケージ化する技術。繁忙期に外部の資源を借りるという構成の名前ではない

D（正解）　正解。オンプレミスとパブリッククラウドを併用するハイブリッド構成の代表例で、ピーク分だけクラウドに逃がすことで設備を増やさずに済む

正解：A

A（正解）　正解。単一障害点をなくして冗長化することで、部分的な障害があっても利用者から見た稼働が続く状態を指す

B　これはスケーラビリティの説明。能力を増やせることと、壊れても止まらないことは別の性質

C　バックアップと復旧の話。障害中もサービスを継続できるかどうかとは目的が異なる

D　レイテンシーや到達性の話であり、可用性の定義ではない

正解：C

A　負荷に応じて能力を増減できる性質。災害後に別の場所で再開する備えの話ではない

B　需要の変動に自動的に追従する性質。災害対策を指す用語ではない

C（正解）　正解。広域災害を想定し、離れた場所にデータや実行環境を用意して業務を再開できるようにする備えを指す

D　必要なリソースを素早く用意できる速さのこと。災害時の復旧計画そのものを意味する語ではない

正解：B

A　1台あたりのCPUやメモリを増やす手法。台数を増やすのは水平方向の拡張であり別物

B（正解）　正解。同じ役割のインスタンスを並べて増やす手法で、上限に当たりにくく、負荷が下がれば台数を減らす縮退も容易

C　データを地理的に離れた場所へ複製する仕組み。処理能力を増やす手法ではない

D　障害時に待機系へ切り替える動作のこと。平常時に能力を増やす手段ではない

正解：D

A　障害が起きても止まらない性質。増減が自動で行われること自体を指す語ではない

B　環境を移し替えやすい性質。負荷への追従とは無関係

C　同じ役割の予備を持つことで障害に耐える考え方。需要に合わせて増減する動きの説明ではない

D（正解）　正解。需要の増減に合わせてリソースが自動的に伸縮する性質で、使った分だけ支払う従量課金と組み合わさって無駄をなくす

正解：A

A（正解）　正解。調達待ちがなくなることで試行回数を増やせ、市場投入までの時間が短くなる

B　大量調達により単価が下がる仕組みの話。速さの説明ではない

C　データが所在国の法律に従うという考え方。環境構築の速さとは関係がない

D　障害が起きても機能し続ける性質。素早く作って捨てられることとは別の性質

正解：C

A　方向が逆。機器購入がCapEx、利用料がOpExであり、クラウド移行はその逆方向の変化になる

B　従量課金では使った分だけ払うため変動費の性格が強まる。説明が逆になっている

C（正解）　正解。前払いの資産購入がなくなり、利用実績に応じた経費として計上される形に変わる

D　資産の購入と役務の利用では会計上の扱いが異なる。クラウド移行の代表的な効果として費用構造の転換が挙げられる

正解：B

A　定額制の説明であり、従量課金の説明ではない。従量課金は使用量に比例する

B（正解）　正解。過剰なキャパシティを事前購入する必要がなくなり、需要に合わせた支出ができる

C　事前申告は不要。長期利用を前提に割引を得る予約は、あくまで任意の別の仕組み

D　リージョンごとに料金は異なる。リージョン選択はコストに影響する判断材料の一つ

正解：C

A　リソースをまとめる論理的な入れ物。メタデータの保存場所は持つが、各リソース自体の配置場所はリソース側のリージョン指定で決まる

B　課金とリソース所有の単位。1つのサブスクリプションから複数のリージョンにリソースを作成できるため、保存場所を決めるものではない

C（正解）　正解。リージョンはデータセンター群が置かれた地理的な単位で、リソースをどのリージョンに作成するかがデータの所在地を決める

D　複数のサブスクリプションをまとめてガバナンスを適用する階層。物理的な配置先を決めるものではない

正解：B

A　同一ゾーン内で台数を並べても、そのゾーン全体に影響する電源障害では同時に停止する

B（正解）　正解。可用性ゾーンは電源・冷却・ネットワークが独立した物理的に分離された拠点で、低遅延の高速回線で結ばれている。ゾーン障害の影響を切り離す基本策

C　復旧手段としては有効だが、障害の発生中もサービスを止めずに動かし続ける仕組みにはならない

D　1台あたりの性能が上がるだけで、そのデータセンターが停電すれば停止する。可用性の向上にはつながらない

正解：A

A（正解）　正解。広域災害の影響を同時に受けにくい距離を保ちつつ、更新が両方に同時適用されないよう配慮されている。地理冗長レプリケーションの複製先にもなる

B　可用性ゾーンはリージョン内の分離された拠点。リージョンペアはリージョン同士の組み合わせであり階層が異なる

C　ペアはAzure側であらかじめ定義されている。任意に組み替えるものではない

D　料金の一致とは無関係。ペアの目的は災害時の復旧とメンテナンスの分散にある

正解：D

A　実現はできるが、サブスクリプションは課金と管理境界の単位であり、プロジェクト単位で作り捨てる粒度としては大きすぎる

B　タグはメタデータのラベルであり、外してもリソース自体は消えない。分類やコスト配分には役立つが削除操作の単位ではない

C　管理グループにはサブスクリプションを配置するもので、個々のリソースを直接入れることはできない

D（正解）　正解。リソースグループはライフサイクルを共にするリソースをまとめる論理コンテナーで、削除すると中のリソースがまとめて削除される

正解：A

A（正解）　正解。OSレベルの完全な制御ができるIaaSであり、既存構成をそのまま持ち込むリフト&シフトの標準的な移行先になる

B　イベントに応じて短時間のコードを実行するサーバーレスサービス。常駐する業務サーバーをそのまま動かす用途には向かない

C　WebアプリやAPIを動かすPaaS。OSやミドルウェアはプラットフォーム側の管理となるため、既存構成をそのまま維持する要件には合わない

D　単一のコンテナーを手軽に実行するサービス。サーバーをそのまま移すのではなく、アプリをコンテナー化する前提が必要になる

正解：C

A　常時稼働するサーバーを自分で管理する形態。イベント時だけの短い処理のために台数を維持するのは無駄が大きい

B　利用者にWindowsデスクトップ環境を配信するサービス。バックエンドの自動処理を動かす仕組みではない

C（正解）　正解。イベント駆動で実行されるサーバーレスのコンピューティングで、インフラの管理が不要かつ実行時間に応じた課金になる

D　多数のコンテナーを継続的に運用・調整するためのオーケストレーション基盤。単発の短い処理には過剰で運用負担も大きい

正解：B

A　コンテナーを1つ手早く実行する用途に向くサービス。多数のコンテナーの配置調整や自動復旧を担うオーケストレーション機能は持たない

B（正解）　正解。Kubernetesのマネージドサービスで、コンテナーの配置・自動復旧・スケーリングといったオーケストレーションを行える

C　同一構成の仮想マシン群を増減させる仕組み。コンテナー単位の管理は自分で作り込む必要がある

D架空　実在しないサービス名。コンテナー関連の語感でもっともらしく見えるが存在しない

正解：D

A　クラスターの構成と運用が前提になる。コンテナー1つを動かすだけなら準備の手間が見合わない

B　OSの用意やコンテナーランタイムの導入が必要で、手軽さの点で劣る

C　Webアプリを継続的に公開するのに向くPaaS。単発のバッチコンテナー実行が主目的のサービスではない

D（正解）　正解。仮想マシンやクラスターを用意せずコンテナーを直接起動でき、実行した秒数に応じた課金となるため単発処理に適する

正解：C

A　WebアプリやAPIをホストするPaaS。デスクトップ環境の配信を目的としたサービスではない

B　Azure外のサーバーやKubernetesをAzureの管理下に置く仕組み。デスクトップ配信の機能ではない

C（正解）　正解。仮想デスクトップとアプリをクラウドから配信するサービスで、データを端末に置かない運用や既存Windowsライセンスの活用ができる

D　同一構成の仮想マシン群を自動で増減させる仕組み。利用者向けデスクトップの配信・接続管理を担うものではない

正解：A

A（正解）　正解。Azure上のプライベートネットワーク空間で、サブネットに分割してリソースを配置し、プライベートIPで相互通信させられる

B　ドメイン名を管理・名前解決するサービス。ネットワーク空間そのものを提供するわけではない

C　Webトラフィックをグローバルに配信・高速化するサービス。仮想マシン同士をプライベートIPで通信させるネットワーク空間を提供するものではない

D　オンプレミスとAzureを専用線で接続するサービス。Azure内部のネットワーク空間を作るものではない

正解：B

A　オンプレミスとの接続や、暗号化トンネルが必要なケースで使う手段。Azure内の仮想ネットワーク同士なら、より単純で高速な方法がある

B（正解）　正解。ピアリングで接続された仮想ネットワークはAzureのバックボーン経由で低遅延に通信でき、ゲートウェイの構築も不要

C　インターネット経由となり、要件である「インターネットを経由しない」に反する

D　オンプレミス拠点とAzureを専用線で結ぶサービス。Azure内の仮想ネットワーク同士の接続には不要で過剰

正解：C

A　レイヤー4(TCP/UDP)で分散する仕組みで高速だが、URLパスなどHTTPの中身を見た振り分けはできない

B　名前解決を担うサービス。リクエストの中身を見て転送先を決める役割は持たない

C（正解）　正解。レイヤー7(HTTP/HTTPS)のロードバランサーで、URLパスやホスト名に基づくルーティングができ、WAFを組み合わせて保護できる

D架空　実在しないサービス名。保護という語感でもっともらしく見えるが存在しない

正解：D

A　Azure内の仮想ネットワーク同士を接続する機能。オンプレミス拠点との接続には使えない

B　インターネット利用者へのWeb配信を高速化するサービスであり、自社拠点とAzureを結ぶ専用の接続を提供するものではない

C　暗号化トンネルでオンプレミスと接続できるが、経路はインターネットであり帯域と遅延は保証されない

D（正解）　正解。接続事業者を介した専用線でAzureと接続し、インターネットを経由しないため帯域と遅延が安定する

正解：B

A　SMB/NFSでマウントして共有フォルダーとして使うサービス。既存アプリのファイル共有の置き換えには向くが、大量の非構造化データを安価に貯める用途では割高になりやすい

B（正解）　正解。画像・動画・バックアップなどの非構造化オブジェクトを大量に格納するためのサービスで、アクセス層を使い分けてコストを抑えられる

C　リレーショナルデータを扱うマネージドデータベース。大容量のバイナリファイル置き場としては適さない

D　仮想マシンに接続して使うブロックストレージ。基本的に1台の仮想マシンから使うもので、共有の大容量オブジェクト置き場ではない

正解：C

A　単一のデータセンター内で3つのコピーを保持する方式。機器故障には耐えるが、その拠点やリージョン全体の障害には対応できない

B　同一リージョン内の複数の可用性ゾーンに複製する方式。ゾーン障害には耐えるが、リージョン全体の災害までは守れない

C（正解）　正解。プライマリリージョンに加えて数百km離れたセカンダリリージョンにも複製するため、リージョン規模の災害からデータを保護できる

D架空　実在しない機能名。冗長化らしい語を並べただけの選択肢

正解：D

A　頻繁に読み書きするデータ向けで、保存単価が最も高い。年に数回しか触れないデータには割高

B　アクセス頻度の低いデータ向けでホットより安いが、数年参照しないデータにはさらに安い層がある

C　低遅延・高トランザクション向けの最も高価な構成。長期保管の要件とは正反対

D（正解）　正解。ほとんど参照しない長期保管データ向けで保存単価が最も安い。読み出しにはリハイドレートという時間のかかる処理が必要になる点が許容できる場合に選ぶ

正解：A

A（正解）　正解。SMBやNFSでマウントできるフルマネージドのファイル共有で、既存アプリのドライブレターをそのまま置き換えやすい

B　HTTPベースのAPIでアクセスするオブジェクトストレージ。共有ドライブとして直接マウントする前提のアプリには改修が必要になる

C　1台の仮想マシンに接続するブロックストレージ。複数サーバーからの一般的なファイル共有用途とは異なる

D　キーと属性を持つ構造化データを格納するNoSQLストア。ファイル共有の代替にはならない

正解：B

A　移行はできるが、OSとSQL Serverのパッチ適用やバックアップ設計が引き続き利用者の責任として残るため、運用負担軽減の要件に対して弱い

B（正解）　正解。SQL Server互換のPaaSデータベースで、パッチ適用・バックアップ・高可用性がプラットフォーム側で管理される

C　グローバル分散のNoSQLデータベース。リレーショナルな既存資産をそのまま移す先としては設計の作り直しが必要になる

D　オブジェクトストレージであり、データベースエンジンを提供するものではない

正解：C

A　リレーショナルモデルが前提で固定スキーマに向く。スキーマが頻繁に変わるJSONデータや複数リージョンでの書き込みという要件には合いにくい

B　マネージドのリレーショナルデータベース。要件のグローバル分散NoSQLとは性格が異なる

C（正解）　正解。グローバル分散に対応したNoSQLデータベースで、複数リージョンへの複製と低遅延アクセス、柔軟なスキーマを前提としている

D　簡易なキー値ストアとしては使えるが、複数リージョンへの分散書き込みや応答時間の保証といった要件には設計上応えられない

正解：B

A　これから構築する構成の見積もりを作るためのツール。すでに発生している実績コストの分析や通知は行わない

B（正解）　正解。実際の使用状況とコストを分析でき、予算を設定してしきい値超過時にアラートを送る運用ができる

C　コスト最適化を含む推奨事項を提示するが、予算のしきい値を設定して通知する機能そのものは持たない

D　リソースのメトリックやログを監視する基盤。請求額の予算管理を主目的とするツールではない

正解：A

A（正解）　正解。サービス・リージョン・サイズ・数量を選んで構成の見積もりを作成でき、保存や共有もできる

B　オンプレミス環境を検出し、移行した場合のコストを現状と比較する機能。既存環境の実態が入力の前提であり、まだ存在しない構成をゼロから積み上げる見積もりには使えない

C　実際に発生したコストを分析・管理するツール。リソースがまだ存在しない段階の見積もりには使えない

D　既存リソースに対する推奨事項を提示するサービス。未作成の構成の見積もりは行わない

正解：C

A　リージョンごとに単価は異なる。どのリージョンに配置するかはコストを左右する判断材料の一つ

B　Azureへの受信データ転送は原則として無料。課金の中心になるのは外へ出ていく送信側

C（正解）　正解。データ転送はリージョンやインターネットの境界を越える方向によって扱いが異なり、配信量の多い設計では総額に大きく影響する

D　コンピューティングは実行時間に応じた従量課金が基本。停止(割り当て解除)すれば実行時間への課金は止まる

正解：D

A　余剰容量を安く使える代わりにAzure側の都合で立ち退きが発生する。中断が許されない本番環境には適さない

B　誤った削除や変更を防ぐガバナンス機能であり、料金には一切影響しない

C　費用を部門別に把握するための分類には役立つが、支払額そのものを下げる仕組みではない

D（正解）　正解。長期利用を前提に前もってコミットすることで従量課金より大幅な割引を受けられる。稼働が読める安定したワークロードに向く

正解：B

A　一定期間・一定額まで無償で試せる仕組み。既存ライセンスの持ち込みとは別の話

B（正解）　正解。保有する対象ライセンスをAzureに適用することで、仮想マシン料金に含まれるライセンス相当分を抑えられる

C　余剰容量を安価に使う仕組みで、中断される可能性がある。ライセンス持ち込みの制度ではない

D架空　実在しないサービス名。ライセンス最適化らしい名前に寄せた偽の選択肢

正解：C

A　既存リソースの削除や変更を防ぐ仕組み。どのリージョンに作成できるかを制限する用途では使えない

B　誰がどの操作を行えるかを制御する仕組み。作成権限のある利用者が「どんな内容で」作成するかまでは制約できない

C（正解）　正解。許可されたリージョンなどの規則を定義し、条件に反する作成・変更を拒否したり、既存リソースの準拠状況を評価したりできる

D　リソースを分類するためのラベル。付けるだけでは何も強制されない(タグの付与自体をPolicyで必須化することはできる)

正解：A

A（正解）　正解。RBACでは必要な範囲(スコープ)に必要最小限のロールを割り当てるのが基本で、閲覧者ロールは読み取りのみを許可する

B　範囲が広すぎるうえ、共同作成者はリソースの作成・変更・削除ができてしまう。最小権限の原則に反する

C　削除は防げるが、そもそもその担当者にアクセス権を与える手段ではなく、他の利用者の運用まで制限してしまう

D　タグは分類用のラベルであり、アクセス権を一切制御しない

正解：B

A　削除は防げるが更新も一切できなくなるため、日常的な構成変更を続けたいという要件を満たさない

B（正解）　正解。読み取りと変更は許可したまま削除だけを禁止できる。所有者権限を持つ利用者でもロックを外さない限り削除できない

C　準拠状況の記録には役立つが、監査は行為を止める仕組みではないため誤削除そのものは防げない

D　削除は防げても通常の運用作業まで止まってしまう。要件に対して影響が大きすぎる

正解：D

A　リージョンは配置場所を決めるものであり、部門と一致する保証がない。分類の手段としては不適切

B　運用上の工夫としては使われるが、名前は後から変更できず、コスト分析でも集計軸として扱いにくい

C　管理グループはサブスクリプションを束ねる階層であり、1つのサブスクリプション内のリソースを部門別に分けるものではない

D（正解）　正解。タグは名前と値のペアでリソースを分類でき、Cost Managementでタグを軸にコストを集計して部門別に把握できる

正解：C

A　1つのサブスクリプションの中でリソースをまとめる論理コンテナー。サブスクリプションをまたいだ一括適用はできない

B　分類用のラベルであり、規則を適用する階層としては機能しない

C（正解）　正解。複数のサブスクリプションを階層的にまとめる器で、上位に割り当てたポリシーやロールが配下のサブスクリプションへ継承される

D架空　実在しないサービス名。ガバナンスという語感でもっともらしく見えるが存在しない

正解：A

A（正解）　正解。Azure外のサーバーやKubernetesクラスターをAzureのリソースとして登録し、ポリシー適用や監視を共通の仕組みで行えるようにする

B　利用者にデスクトップ環境を配信するサービス。他環境のサーバーを管理下に置くものではない

C　オンプレミスとAzureを専用線で接続するネットワークサービス。管理面の統合を担う機能ではない

D　オンプレミス環境をAzureへ移行するための評価・移行ツール群。移行せずに現地のまま管理下へ置く用途とは目的が異なる

正解：B

A　Azureリソースの構成が規則に準拠しているかを扱う仕組み。データの中身を走査して分類する機能ではない

B（正解）　正解。データ資産のスキャンとカタログ化、分類、系統(リネージ)の把握を通じてデータガバナンスを支援する

C　リソースの稼働状況を収集・分析する監視基盤であり、データ資産の棚卸しを行うものではない

D　キーやシークレットを保管する金庫。保存されたデータ全体の把握や分類は担当範囲外

正解：C

A　収集済みの情報をもとに改善推奨を提示するサービス。データ収集とアラートの基盤そのものではない

B　Azure側の障害や計画メンテナンスの状況を知らせるサービス。利用者のリソースのメトリック監視は範囲外

C（正解）　正解。メトリックとログを収集・可視化し、アラートやオートスケールの起点となるAzureの監視基盤

D　コストの分析と予算管理を行うツールであり、稼働状況の監視は行わない

正解：D

A　Azure側のサービス障害情報を確認する画面であり、利用者のログを検索する仕組みではない

B　推奨事項を一覧するサービス。任意のクエリでログを分析する用途には使えない

C架空　実在しないサービス名。ログ分析らしい語を組み合わせた偽の選択肢

D（正解）　正解。Azure Monitorが収集したログの保存先であり、KQL(Kusto照会言語)で検索・集計・可視化を行える

正解：A

A（正解）　正解。アプリのパフォーマンス、依存関係、例外、利用状況を計測するアプリケーション性能監視(APM)機能

B　リソース構成の準拠を評価・強制する仕組みであり、アプリの性能計測は行わない

C　セキュリティ体制の評価と脅威検出が目的。応答時間や例外の傾向を分析する機能ではない

D　Azureプラットフォーム側の稼働状況を扱うサービス。自社アプリ内部の性能は対象外

正解：B

A　自分のリソースの数値がしきい値を超えたときに発報する仕組み。Azure側の障害情報や計画メンテナンスの告知は扱わない

B（正解）　正解。利用中のサービスとリージョンに絞ってサービス障害・計画メンテナンス・正常性の勧告を通知でき、影響範囲の確認に使える

C　信頼性やコストなどの改善推奨を提示するサービス。進行中の障害を知らせるものではない

D　コストの分析と予算管理のツールであり、稼働状況の通知は行わない

正解：C

A　Azure側の障害やメンテナンスの状況を伝えるサービス。構成の改善提案は行わない

B　定めた規則への準拠を評価・強制する仕組み。使用実績に基づく提案を生成するものではない

C（正解）　正解。信頼性・セキュリティ・パフォーマンス・コスト・オペレーショナルエクセレンスの観点で、実際の構成と利用状況に基づく個別の推奨事項を提示する

D　これから作る構成の見積もりを作るツールであり、既存環境の改善提案は行わない