AZ-305 サンプル問題

正解：C

A　分析自体は可能だが、保持設定・アクセス制御・コミットメント階層を3か所で維持することになり、手間を最小化するという要件から外れる

B　ストレージにはKQLのクエリエンジンがなく、横断分析の要件を満たさない

C（正解）　正解。ワークスペース設計の公式指針は「要件を満たす最小数」であり、単一ワークスペースなら横断クエリがそのまま書ける。収集対象はDCRで一元的に定義できる

D　ストリーム処理の基盤であり、アドホックなKQL分析の置き換えにはならない

正解：B

A　全機能を使える既定のプランだが取り込み単価が最も高く、平時にまったく参照しないログには過剰

B（正解）　正解。大量で詳細な、めったに参照しないログのために用意された最も低コストのプランで、合計保持期間の全体にわたってクエリできる。APIで新規作成するDCRベースのカスタムテーブルに設定する

C　取り込みは安価だが対話型でクエリできる期間が30日に固定されるため、12か月をさかのぼって検索するという要件に合わない

D　保管コストは最も低いが、KQLによる検索ができず調査の要件を満たさない

正解：A

A（正解）　正解。イベントハブはSIEM連携のために用意された標準の宛先で、ストリームとして数秒から数分の遅延で受け渡せる

B　Blobは追記型でフラッシュ間隔があり、さらにポーリング周期が上乗せされるため数分以内という要件に届かない

C　1時間周期では遅延要件を満たさず、転送処理を自前で保守することにもなる

D　既存SIEMを継続利用するという前提を変えてしまう提案であり、要件への回答になっていない

正解：D

A　非準拠を可視化するだけで診断設定は作成されず、結局は手作業の是正が必要になる

B　新規サブスクリプションや新規リソースのたびに実行が必要で、漏れが発生する

C　実現は可能だが独自スクリプトの保守が残り、Azureが用意した標準手段より運用負荷が高い

D（正解）　正解。今後作成されるリソースには自動でデプロイされ、既存の非準拠リソースは修復タスクで一括是正できる。管理グループスコープなら新規サブスクリプションにも継承される

正解：B

A　クエリ時のアクセス制御の設定であり、保存時の暗号化キーには一切関与しない

B（正解）　正解。専用クラスターはCMKによる暗号化の前提となる構成で、専用の取り込み容量とクラスター単位のコミットメント階層も併せて得られる

C　取り込み単価は下がるが、CMKの要件は満たされず、分析機能も制限される

D　ネットワーク到達性の制御であって、保存時の暗号化キーが顧客管理になるわけではない

正解：C

A　Sentinelを有効にしたワークスペースは、その中のすべてのデータがSentinelの課金対象になる。RBACでは課金は分離できない

B　単価は下がるがSentinel課金の対象から外れるわけではなく、所有権の分離にもならない

C（正解）　正解。課金と所有権の境界がワークスペース単位であるため、セキュリティ用と運用用を分けるのが公式に示された設計パターン

D　課金は避けられるが運用チームがKQLで分析できなくなり、現行の運用が成り立たない

正解：A

A（正解）　正解。リソースコンテキストのアクセスになり、利用者は自分が読み取り権限を持つリソースのログ行だけを参照できる。ワークスペースを分けずに分離できる標準の方法

B　ワークスペースコンテキストの権限となり、ワークスペース内のすべてのデータを参照できてしまう

C　テーブル単位の制御はできるが、同じテーブルに複数チームのリソースのログが混在するため要件を満たせない

D　利用者がクエリを書き換えれば他チームのログも読めるため、アクセス制御にはならない

正解：D

A　ネットワーク経路の到達性と遅延の測定であり、アプリケーション内部の依存関係の内訳は得られない

B　要求単位の応答時間は分かるが、どの依存関係が遅いのか、どの例外が起きたのかまでは分からない

C　VMやArc対応サーバーのゲスト監視の機能で、App Serviceのアプリケーション内トレースは取得できない

D（正解）　正解。APMとして依存関係の呼び出し(SQL・Redis)を自動収集し、アプリケーションマップで遅延の内訳を、エンドツーエンドのトランザクション診断で例外のスタックを追跡できる

正解：B

A　MMAは2024年8月にサポートを終了しており、現行のエージェントはAzure Monitorエージェント

B（正解）　正解。Arcで非Azureサーバーをリソースとして扱えるようになり、VM insightsのマップ機能でプロセスと接続の依存関係を可視化できる

C　指定したエンドポイント間の到達性と遅延の測定であり、プロセス単位の依存関係マップは提供されない

D　移行計画のための一時的な評価機能であり、恒常的な監視基盤として設計されていない

正解：C

A　コンテナーのログとインベントリが中心で、PromQLによるクエリやGrafanaのPrometheusデータソースとしては利用できない

B　実現はできるが、自前運用を避けたいという要件に正面から反する

C（正解）　正解。Azure MonitorワークスペースはPrometheusメトリクスの保存先で、既定で18か月保持される。Managed Grafanaから既存のダッシュボードをそのまま利用できる

D　保持期間は93日で、アプリケーションが公開するカスタムのPrometheusメトリクスも扱えない

正解：A

A（正解）　正解。ITSM連携はアクショングループのITSMアクションで行い、時間帯ベースの抑制はアラート処理ルールで宣言的に構成できる。アラートルール自体を触らずに済む

B　ルール数だけ手作業が発生し、戻し忘れによる監視の穴が生じる

C架空　実在しない機能。Azure MonitorからITSM製品への連携はアクショングループのITSMアクション(ITSMコネクタ)で行う

D　遅延と重複起票の制御を自前で作り込むことになり、抑制の仕組みも別途必要になる

正解：D

A　誤検知は減るが、通常時の異常な上昇を見逃すことになる

B　数百台では作成と調整の運用が破綻する

C　評価が粗くなって検知が遅れるうえ、変動する基準線の学習も行われない

D（正解）　正解。動的しきい値は過去のパターンから基準線を学習するため周期的な変動を誤検知しない。VMのプラットフォームメトリックはサブスクリプションやリソースグループ単位の複数リソーススコープで1つのルールにまとめられる

正解：A・E

A（正解）　正解。パススルー認証はサインインの検証をオンプレミスのドメインコントローラーへ委ねる方式で、エージェントを冗長化することで単一障害点を排除できる

B　AD FSを廃止するという前提に反し、オンプレミス側の障害時に使えない点も変わらない

C　Azure上のマネージドドメインを提供するサービスで、テナントのサインイン方式には関与しない

D　要件(1)のオンプレミスADでの検証が成り立たなくなる

E（正解）　正解。パススルー認証と併用して構成しておくと、オンプレミス側の障害時にクラウド認証へ切り替えてサインインを継続できる。可用性設計として推奨されている構成

正解：B・D

A　最も単価の高い保持形態を全テーブルへ適用することになり、コストはむしろ大幅に増える

B（正解）　正解。単純な検索しか行わず30日で足りるログはBasicプランの想定用途そのもので、取り込み単価を大きく下げられる

C　組み込みのAzureテーブルはAuxiliaryプランに対応しておらず、既存テーブルのプランをAuxiliaryへ変更することもできない

D（正解）　正解。対話型保持を超える期間は単価の低い長期保持として保管され、必要時に検索ジョブや復元で参照できる。7年の参照要件を最小コストで満たせる

E　取り込みの総量は変わらず、コミットメント階層の適用単位が小さくなって割引が効きにくくなるため逆効果

正解：D

A　SQL Server Agentとデータベースをまたぐクエリをサポートしないため、アプリケーション側の作り直しが必要になる

B　データベースエンジンが異なり、スキーマとT-SQLの全面的な書き換えが避けられない

C　互換性は最も高いが、OSとSQL Serverのパッチ適用が自組織の責任として残るため要件に反する

D（正解）　正解。SQL Serverとのインスタンスレベルの互換性が高く、SQL Server Agent・クロスデータベースクエリ・CLRをそのまま利用できる。PaaSのためOSとエンジンのパッチはAzureが担当する

正解：A

A（正解）　正解。拡張機能の利用、ゾーン冗長高可用性、カスタムメンテナンス期間の指定に対応した現行のマネージドPostgreSQLである

B　リタイアメントパスに入っており新規設計では選定しない。もともとCitusによる分散スケールアウト向けで、単一サーバーの移行先という位置づけでもない

C　エンジンがSQL Serverであり、PostgreSQLの拡張機能やSQL方言をそのまま持ち込めない

D　高可用性とパッチ適用を自前で構築・運用することになり、マネージドサービスの利点を失う

正解：D

A　PaaSのためOSへのアクセスやエージェントの導入ができず、エンジンのバージョンも自動的に更新される

B　OSもインスタンスも隠蔽されており、エージェントの導入とバージョン固定のいずれも満たせない

C　サービスティアの選択で解決する問題ではない。PaaS全般がOSへのアクセスを提供しない

D（正解）　正解。IaaSのためOSを完全に制御でき、任意のエージェント導入とバージョン固定が可能。その代わりパッチ適用の責任は自組織に残る

正解：B

A　アプリケーションの大規模な改修が必要になるうえ、テナントごとのデータ分離という前提が崩れる

B（正解）　正解。プールに割り当てたリソースを複数のデータベースで共有するため、ピークがずれる多数のデータベースを集約するとコスト効率が高い

C　ピークに合わせて個別に確保するため、平均使用率が低いほど無駄が大きくなる

D　インスタンス単位の課金となり、200個の構成では大幅なコスト増になる

正解：A

A（正解）　正解。ワークロードに応じて自動的にスケーリングし秒単位で課金される。自動一時停止を構成すると、無活動期間のコンピューティング料金が発生しなくなる

B　確保したコンピューティングに対して継続的に課金されるため、アイドル時の料金はゼロにならない

C　レプリカを減らしてもプライマリのコンピューティング料金は発生し続ける

D　プールのリソースが常時課金されるため、単独の断続利用データベースではむしろ割高になる

正解：B

A　データとログのストレージ上限が4TBであり、30TBという要件を満たせない

B（正解）　正解。ストレージは最大128TBまで自動的に拡張され、スナップショットベースのバックアップによりデータサイズに依存しない高速な復元ができる

C　ローカルSSDによる低遅延が特長だがストレージ上限は4TBで、テラバイト級の拡張要件に対応できない

D　DTUモデルのストレージ上限はvCoreモデルより小さく、そもそもテラバイト級の拡張を想定した購入モデルではない

正解：C

A　コンピューティングとストレージが分離したリモートストレージ構成で遅延は5〜10ミリ秒。インメモリOLTPも利用できない

B　幅広いワークロードに適するが、メモリ最適化テーブル（インメモリOLTP）はサポートされない

C（正解）　正解。ローカルSSDにデータを配置して1〜2ミリ秒の低遅延を実現し、3つのセカンダリレプリカによる高速フェールオーバーとインメモリOLTPをサポートする

D　コンピューティングの課金と自動スケーリングに関する選択であり、ストレージ遅延とインメモリOLTPの制約はGeneral Purposeのまま変わらない

正解：D

A　可用性の要件は提示されておらず、コストがさらに上がるため費用優先という判断と矛盾する

B　3つの追加レプリカを常に確保するためGeneral Purposeのおよそ2.7倍のコストになり、提示された要件に対して過剰

C　コンピューティングレプリカごとの課金となり、この規模と要件ではGeneral Purposeよりコストが高くなる

D（正解）　正解。コンピューティングとストレージのバランスが取れた予算重視のティアで、既定のSLAと5〜10ミリ秒のストレージ遅延で足りる汎用ワークロードに適する

正解：A

A（正解）　正解。vCore購入モデルでのみAzure Hybrid Benefitが適用でき、保有するSQL Serverライセンスをコンピューティング料金の割引に充当できる

B　DTU購入モデルはAzure SQL Managed Instanceには存在しない。仮にAzure SQL Databaseであっても、DTUモデルではAzure Hybrid Benefitや予約割引を適用できない

C　Azure SQL Managed Instanceにサーバーレスコンピューティングティアは提供されていない。仮に使えたとしても保有ライセンスを反映する仕組みではない

D　本番ワークロードには利用できず、保有ライセンスの活用という要件とも異なる

正解：B

A　データベース数の上限が100、インスタンスのストレージ上限が16TBであり、300個・24TBの要件を満たせない

B（正解）　正解。General Purposeと同じ基本コストで最大500データベース・32TBまで対応する。Elastic SANベースのストレージにより遅延とIOPSも改善される

C　ストレージ上限が16TBで24TBに届かず、データベース数の上限も100。加えてコストはおよそ2.7倍になる

D　インスタンス数が増えて運用負荷とコストが悪化し、1つのインスタンスへ集約するという前提にも反する

正解：D

A　ほとんどのワークロードに適した汎用構成で、ソフトウェアベースのVBSエンクレーブなら構成できるが、Intel SGXによるハードウェアエンクレーブは提供しないため要件を満たさない

B　新規作成が終了し2026年10月1日にリタイア予定の旧世代ハードウェアで、General Purposeのみ対応。ハードウェアエンクレーブの要件も満たさない

C　vCoreあたりのメモリ量を増やした構成であり、SGXベースのエンクレーブには対応しない

D（正解）　正解。Intel SGXを搭載しており、Always Encrypted with secure enclavesによるエンクレーブ内での比較・範囲検索を実行できる

正解：A

A（正解）　正解。拡張ポリシーは1日に複数回のバックアップに対応し、時間単位スケジュールでは最短4時間間隔を選べるためRPO 4時間を満たせる

B　1つの保護対象に割り当てられるバックアップポリシーは1つだけで、複数ポリシーを重ねることはできない

C　MARSはファイルとフォルダー単位の保護でVM全体の復旧にならず、要件に反してエージェント運用も増える

D　Site RecoveryはDRの仕組みでバックアップの代替にはならず、長期保持や項目単位の復元ができない

正解：B

A　コンテナーの冗長性は最初のバックアップが保存される前にしか変更できず、運用中のコンテナーでは選べない

B（正解）　正解。運用開始後は冗長性を変えられないため、GRSの新規コンテナーで保護を組み直し、リージョン間復元を有効化するのが唯一の道。旧コンテナーは既存復旧ポイントの保持期間が切れるまで残す

C　コンテナー間でバックアップデータを移動・複製する機能はサポートされていない

D　コンテナーはサブスクリプションやリソースグループ間なら移動できるが、リージョン間の移動はできない

正解：A

A（正解）　正解。MARSエージェントはファイル・フォルダーとシステム状態を1日3回までAzureへ直接バックアップでき、追加のサーバーを必要としない

B　MABSはアプリ整合性や細かい復旧が必要な場合に選ぶ構成で、専用サーバーを建てない要件に反する

C　Site RecoveryはDRの仕組みで、ファイルやシステム状態を世代管理するバックアップではない

D　File Syncは同期とキャッシュの仕組みであり、世代を遡って復元するバックアップにはならない

正解：C

A　暗号化は機密性のための対策であり、復旧ポイントを削除する操作そのものは止められない

B　地理冗長はリージョン障害への備えで、権限を持つ主体による削除は複製先にも及ぶ

C（正解）　正解。不変性を有効にすると保持期間の短縮や復旧ポイントの削除が拒否され、不可逆にロックすれば設定の解除自体ができなくなる

D　論理削除は削除後の一定期間だけ復元できる猶予であり、削除操作そのものを拒否する仕組みではない

正解：D

A　バックアップポリシーはVM単位で割り当てるため、同一VM内のディスクごとに別のポリシーは適用できない

B　運用負荷が増えるうえ、OSディスクと業務データの世代管理や保持ポリシーも失われる

C　非管理ディスクはレガシーな構成で推奨されない。マネージドディスクのまま除外する手段がある

D（正解）　正解。選択的ディスクバックアップはVM内の一部のデータディスクをバックアップ対象から外せるため、保護範囲を保ったままコストを削減できる

正解：B

A　ポイントインタイム復元の保持期間は最長35日で、年単位まで延長する設定は存在しない

B（正解）　正解。LTRポリシーは週次・月次・年次のフルバックアップを最長10年まで保持でき、35日の上限を超える規制要件に対応できる

C　継続的に同期するDRの仕組みで、過去時点のバックアップを長期に保管する用途ではない

D　バックアップの置き場所と耐障害性の設定であり、保持できる期間は変わらない

正解：C

A　VM単位のバックアップはRPOが最短4時間で、15分という要件を満たせない

B　避けたいはずの独自運用を作り込むことになり、復元も手作業が前提になる

C（正解）　正解。Azure BackupのSQL Serverワークロード保護ではログバックアップを最短15分間隔で構成でき、最長35日まで保持できる

D　可用性グループは高可用性のための仕組みで、過去時点へ戻すバックアップの代わりにはならない

正解：A

A（正解）　正解。クロスリージョン読み取りレプリカの昇格は数分で完了し、仮想エンドポイントが接続先を自動的に切り替えるためgeo復元より大幅にRTOが短い

B　ゾーン冗長高可用性は同一リージョン内のゾーン障害への対策で、リージョン全体の障害は救えない

C　保持期間を延ばしても復元にかかる時間は短くならず、RTOの要件には効かない

D　性能階層の変更にすぎず、リージョン障害からの復旧手段にはならない

正解：D

A　定期バックアップは決まった間隔のスナップショットで、任意の時点を指定した復元はできない

B　リージョン障害時に書き込み先を切り替える機能で、誤削除は各リージョンへ複製されるため救えない

C　整合性レベルは読み取り時の保証を決める設定で、削除操作を取り消す手段ではない

D（正解）　正解。継続バックアップは保持期間内の任意の時点を秒単位で指定して新しいアカウントへ復元でき、論理的な削除事故からの復旧に適する

正解：A

A（正解）　正解。大規模並列バッチ向けのマネージドサービスで、プールの自動スケールによりタスク完了後にノードを0台まで縮小でき、タスクのキューイングと再試行も内蔵している

B　クラスターとノードプールを常時運用する必要があり、ジョブのスケジューリングと再試行も自前で設計することになる

C　WebJobsはApp Serviceプランの上で動くため実行していない時間帯もプラン費用が発生し、数千タスクのスケジューリング機能も持たない

D　オーケストレーション機能を持たず、数千タスクのキューイング・再試行・スケジューリングを自前で実装する必要がある

正解：D

A　Kubernetes APIと制御プレーンへの直接アクセスが必要な場合の選択肢で、ノードプールとアップグレードの運用負荷が残る

B　単一コンテナーまたはコンテナーグループを動かす機能で、オーケストレーションと自動スケールを備えていない

C　構築からアップグレードまですべて自社の責任になり、運用したくないという要件に真っ向から反する

D（正解）　正解。Kubernetes上に構築されたマネージドのサーバーレスコンテナー基盤で、KEDAベースのスケールルールによりキュー長に応じたゼロスケールが可能。Kubernetes APIは公開されず運用負荷が低い

正解：C

A　Kubernetes上に構築されているがKubernetes APIを公開しないため、CRDやOperatorを持ち込めない

B　コンテナーイメージは実行できるがKubernetesではなく、CRD・Operator・ノードプールの概念がない

C（正解）　正解。マネージドKubernetesとしてAPIと制御プレーンにフルアクセスでき、CRD・Operator・Helm・GPUを分離した複数ノードプールをそのまま利用できる

D　オーケストレーターを持たないため、CRDやOperatorを前提としたアプリケーションを実行できない

正解：D

A　サンドボックス化された実行環境で、カーネルモードドライバーの導入やレジストリの自由な変更ができない

B　実行環境の制約はApp Serviceと同じで、関数モデルに合わせたコード改修も必要になる

C　サンドボックス化されたコンテナー環境で、ホストOSレベルのドライバー導入はできない

D（正解）　正解。OSへのフルアクセスが必要なリフト&シフト対象では、IaaSのVMがコード改修なしで要件を満たせる唯一の選択肢になる

正解：B

A　仮想ネットワーク統合と常時稼働インスタンスに対応せず、スケール上限も200インスタンスにとどまる

B（正解）　正解。従量課金を維持したまま仮想ネットワーク統合と常時稼働(always ready)インスタンスを構成でき、最大1,000インスタンスまでスケールする

C　インスタンスを常時確保する専用プランのため、リクエストがない時間帯も課金され従量課金の要件を満たさない

D　単一テナントの専用環境で最も高コストになり、従量課金の要件から最も遠い

正解：C

A　ディスク上の保存時データを守る仕組みで、メモリに読み込まれた処理中のデータは平文のまま扱われる

B　物理ホストを他の顧客と共有しなくなるだけで、ホストOSやハイパーバイザーからメモリを保護する仕組みではない

C（正解）　正解。ハードウェアベースの信頼実行環境によりVMのメモリが暗号化され、使用中のデータをホストの管理者やハイパーバイザーからも保護できる

D　鍵の管理主体が変わるだけで、保護される対象は保存時のデータにとどまる

正解：A

A（正解）　正解。未使用容量を大幅な割引価格で利用でき、容量が必要になるとAzureから中断される。中断に耐えられるバッチ処理に最も適する

B　1年または3年の稼働をコミットする代わりに割引を得る仕組みで、夜間だけ動く断続的なジョブでは無駄が大きい

C　既存のWindows ServerやSQL Serverのライセンスを持ち込む仕組みで、対象ライセンスがなければ効果がない

D　物理ホストを専有するため単価は最も高くなり、コスト最優先という要件に反する

正解：B

A　GPUノードの起動には時間がかかり、システムノードプールの常時稼働費用も残る。クラスター運用を避けたい要件にも反する

B（正解）　正解。ゼロスケールに対応し、GPUを使用した分だけ課金される。Kubernetesクラスターの運用も不要

C　Container InstancesのGPUリソースは提供が終了しており、この要件を満たす選択肢にならない

D　スケジュールでは実際のリクエストに追随できず、起動している時間は使わなくても課金される

正解：A

A（正解）　正解。Freeティアはサービスレベル目標(SLO)のみで、金銭的補償を伴うコントロールプレーンのSLAはStandardまたはPremiumティアで提供される

B　ワーカーノード側の構成であり、マネージドなコントロールプレーンのSLAには影響しない

C　ワーカーノードの可用性は高まるが、コントロールプレーンのSLA適用条件ではない

D　ポリシー準拠を評価するアドオンで、可用性のSLAとは無関係

正解：C

A　仮想ネットワーク統合は送信方向の接続を制御する機能で受信の閉域化にはならず、インフラストラクチャもマルチテナントのまま

B　ハイブリッド接続はアプリからオンプレミスのリソースへ到達するための送信側の仕組みで、要件とは方向が逆

C（正解）　正解。ASE v3はシングルテナントの専有インフラストラクチャで、内部ロードバランサー構成にすれば受信は仮想ネットワーク内に限定される

D　アクセス元を制限するだけで、マルチテナントの共有インフラストラクチャという制約は解消されない

正解：D

A　独自のジョブとタスクのモデルを持つため、既存のSlurmのジョブ定義と投入手順を作り直す必要がある

B　コンテナーオーケストレーターであり、HPCスケジューラーの資産をそのまま持ち込む用途には向かない

C架空　実在しないサービス名。既存のHPCスケジューラーをAzure上で運用する役割はAzure CycleCloudが担う

D（正解）　正解。SlurmやPBS Proなど既存のHPCスケジューラーをAzure上でオーケストレーションし、ジョブ需要に応じて計算ノードを自動スケールできる

正解：A

A（正解）　正解。Azure上の専有ハードウェアでvSphere・vSAN・NSXをネイティブに実行するため、既存の管理手順とVM形式を維持したまま短期間で移設できる

B　仮想マシンをAzureのハイパーバイザー形式へ変換するため、vCenterやNSXによる運用手順は維持できない

C　450台の仮想マシンをコンテナー化するには大規模な再設計が必要で、4か月という制約に収まらない

D　PaaSへの移行はアプリケーション単位の改修を伴い、期間と対象規模の両面で現実的でない

正解：C

A　Basic・Standard・Premiumの各ティアは2028年9月30日に廃止が予定されており、新規設計の推奨先はAzure Managed Redisになる

B　低レイテンシの読み取りには使えるがキャッシュ専用に設計されたサービスではなく、単価と機能の両面で見劣りする

C（正解）　正解。Redis Enterpriseをベースにした現行サービスで、Microsoft Entra ID認証に対応し、高可用性を有効にすると既定でゾーン冗長になる

D　パッチ適用・フェールオーバー・スケールをすべて自社で運用することになり、マネージドサービスの利点を失う

正解：B

A　シークレット・キー・証明書の保管に特化しており、機能フラグや環境別ラベルによる一般的な構成管理の機能は持たない

B（正解）　正解。構成値を一元管理してラベルで環境別の値を切り替えられ、機能フラグにより段階的な機能の有効化も実現できる

C　サービスと環境の組み合わせの数だけ設定が分散し、現状の課題をそのまま残す

D　格納はできるが、変更通知・ラベル・機能フラグ・アクセス制御をすべて自前で作り込む必要がある

正解：C

A　L7のロードバランサーでWAFやパスベースルーティングは提供するが、サブスクリプションキーの発行や開発者ポータルは持たない

B　グローバルな配信と負荷分散が主目的で、API単位の利用量制限やポリシーによる変換機能は提供しない

C（正解）　正解。製品とサブスクリプションによる利用量制限、開発者ポータル、ポリシーによる要求・応答の変換をAPIゲートウェイとして標準で提供する

D　認証・レート制限・ドキュメント・変換をすべて自前実装することになり、運用と品質の負担が大きい

正解：C

A　開発・テスト向けのティアで、仮想ネットワークへの注入に対応しない

B　送信の仮想ネットワーク統合と受信のプライベートエンドポイントには対応するが、ゲートウェイ自体を委任サブネットへ注入することはできない

C（正解）　正解。ゲートウェイを委任サブネットへ注入(injection)でき、受信・送信の両方のトラフィックを仮想ネットワーク内に隔離できる

D　サーバーレス課金のティアで、仮想ネットワークへの注入には対応しない