WEB問題集
AZ700-APP#9
Application Gateway の HTTPS リスナーで「複数の異なるドメイン (例: app1.contoso.com / app2.contoso.com) を 1 つの Public IP で受け付ける」場合に活用される機能はどれですか?
解説
【正解: A】の理由
Multi-site Listener は 1 つの Application Gateway フロントエンドに複数のホスト名 (例: app1.contoso.com / app2.contoso.com) を関連付け、Host ヘッダーまたは SNI に基づいて異なるバックエンド プールへ振り分ける機能です。これにより、Public IP を 1 つに集約しつつ多サイト ホスティングを実現できます。
【他選択肢が違う理由】
- B: Basic Listener は単一サイト用で、複数ホスト名の振り分けには対応しません。
- C: Path-based routing は URL パスでの振り分け機能で、ホスト名ベースの分岐には Multi-site Listener が適切です。
- D: URL Rewrite は応答ヘッダや URL の書き換え機能で、ホスト名ベース振り分けの主機能ではありません。
【参考】
AZ700-APP#10
Azure Load Balancer の各ルールについて、用途を選んでください。
| ステートメント | 選択 |
|---|---|
単一の Public IP / Port を特定 VM へ 1:1 で転送 Inbound NAT Rule は Frontend Port と単一 Backend Instance Port を 1:1 で紐付ける構成で、特定 VM への直接 RDP / SSH アクセスなどに利用されます。そのため、複数 VM への分散は不要な「単一インスタンス転送」用途に該当します。 | |
複数 Backend Pool 間で 5-tuple ハッシュにより負荷分散 Load Balancing Rule は Backend Pool 内の複数インスタンスに 5-tuple ハッシュベースで負荷分散します。これにより、複数 VM 構成での Web フロントエンド分散などのスケール アウト シナリオが実現できます。 | |
Backend Pool からの Outbound SNAT ポート割り当て制御 Outbound Rule は Backend インスタンスからの Outbound SNAT 通信について、Public IP と SNAT ポートの明示割り当てを制御します。これにより、SNAT ポート枯渇による接続エラーの予防設計が可能となります。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| 単一の Public IP / Port を特定 VM へ 1:1 で転送 | Inbound NAT Rule |
| 複数 Backend Pool 間で 5-tuple ハッシュにより負荷分散 | Load Balancing Rule |
| Backend Pool からの Outbound SNAT ポート割り当て制御 | Outbound Rule |
【各判定の詳細】
- 「単一の Public IP / Port を特定 VM へ 1:1 で転送」→ Inbound NAT Rule: Inbound NAT Rule は Frontend Port と単一 Backend Instance Port を 1:1 で紐付ける構成で、特定 VM への直接 RDP / SSH アクセスなどに利用されます。そのため、複数 VM への分散は不要な「単一インスタンス転送」用途に該当します。
- 「複数 Backend Pool 間で 5-tuple ハッシュにより負荷分散」→ Load Balancing Rule: Load Balancing Rule は Backend Pool 内の複数インスタンスに 5-tuple ハッシュベースで負荷分散します。これにより、複数 VM 構成での Web フロントエンド分散などのスケール アウト シナリオが実現できます。
- 「Backend Pool からの Outbound SNAT ポート割り当て制御」→ Outbound Rule: Outbound Rule は Backend インスタンスからの Outbound SNAT 通信について、Public IP と SNAT ポートの明示割り当てを制御します。これにより、SNAT ポート枯渇による接続エラーの予防設計が可能となります。
【参考】
AZ700-APP#11
Azure Front Door Standard をゼロから構築し、グローバル Web アプリを WAF 保護付きで配信する手順を正しい順序に並べてください。
- Front Door Profile を作成 (Standard SKU)
- Endpoint を作成 (xxx.azurefd.net の Front Door エンドポイント)
- Origin Group + Origin (バックエンド) を構成 (Health Probe 含む)
- Route を作成 (Endpoint → Origin Group マッピング + Rule Set + WAF)
解説
【正しい順序】
- ステップ 1: Profile 作成
- ステップ 2: Endpoint 作成
- ステップ 3: Origin Group + Origin
- ステップ 4: Route 作成
【各ステップの理由】
- ステップ 1 Profile 作成: Front Door Standard / Premium を選び、Profile リソースを作成します。これがすべての Endpoint / Origin / Route の集約コンテナとなります。
- ステップ 2 Endpoint 作成: xxx.azurefd.net のグローバル エンドポイントを作成します。後で カスタム ドメインを関連付けることも可能です。
- ステップ 3 Origin Group + Origin: バックエンド (Web App / Storage / Public Endpoint) を Origin として登録し、Health Probe を構成して Origin Group に集約します。
- ステップ 4 Route 作成: Endpoint → Origin Group の紐付けを Route で定義し、WAF Policy と Rule Set を関連付けることでセキュリティと書き換えルールを適用します。
【誤った順序の問題点】
- Origin Group なしで Route 作成: Route のターゲットとなる Origin Group が存在しないため、Route 作成は失敗します。
- Profile を最後に作成: Profile はすべてのリソースの親であり、最初に作成しないと他のリソースを配置する場所がありません。
【参考】
AZ700-APP#12
Application Gateway の動作について、各記述が正しいか判定してください。
| ステートメント | はい | いいえ |
|---|---|---|
Application Gateway は HTTP / HTTPS 以外 (TCP / UDP) のロード バランシングにも対応する Application Gateway は L7 (HTTP / HTTPS) 専用のロード バランサーであり、TCP / UDP の L4 トラフィック処理は行いません。そのため、L4 ロード バランシングが必要な場合は Azure Load Balancer (Standard) を選定します。 | ||
Application Gateway は WAF v2 SKU で Web Application Firewall を統合できる Application Gateway の WAF v2 SKU では OWASP Core Rule Set とカスタム ルールを組み合わせて WAF を統合できます。これにより、リージョン内 Web アプリケーションのレイヤ 7 攻撃から防御する設計が可能となります。 | ||
Application Gateway は AKS Ingress Controller として Application Gateway Ingress Controller (AGIC) 経由で利用できる Azure Application Gateway は AGIC (Application Gateway Ingress Controller) 経由で Kubernetes Service の Ingress として利用可能です。そのため、AKS Pod の HTTP / HTTPS エントリ ポイントとして AGIC + App Gateway 構成が標準パターンとなります。 |
解説
【正解一覧】
| ステートメント | 正解 |
|---|---|
| Application Gateway は HTTP / HTTPS 以外 | いいえ |
| Application Gateway は WAF v2 SKU で Web Application Firewal… | はい |
| Application Gateway は AKS Ingress Controller として Applicati… | はい |
【各判定の詳細】
- 「Application Gateway は HTTP / HTTPS 以外」→ いいえ: Application Gateway は L7 (HTTP / HTTPS) 専用のロード バランサーであり、TCP / UDP の L4 トラフィック処理は行いません。そのため、L4 ロード バランシングが必要な場合は Azure Load Balancer (Standard) を選定します。
- 「Application Gateway は WAF v2 SKU で Web Applicati…」→ はい: Application Gateway の WAF v2 SKU では OWASP Core Rule Set とカスタム ルールを組み合わせて WAF を統合できます。これにより、リージョン内 Web アプリケーションのレイヤ 7 攻撃から防御する設計が可能となります。
- 「Application Gateway は AKS Ingress Controller として…」→ はい: Azure Application Gateway は AGIC (Application Gateway Ingress Controller) 経由で Kubernetes Service の Ingress として利用可能です。そのため、AKS Pod の HTTP / HTTPS エントリ ポイントとして AGIC + App Gateway 構成が標準パターンとなります。
【参考】
AZ700-APP#13
Azure Front Door でクライアントから最も近い (低レイテンシ) Origin へ誘導するルーティング動作に該当するのはどれですか?
解説
【正解: A】の理由
Azure Front Door の既定ルーティング動作は「Latency-based」で、Microsoft グローバル ネットワークの遅延計測結果に基づき、クライアントから最も近い (低レイテンシ) Origin へトラフィックを誘導します。これにより、ユーザは追加設定なしで世界中で最速のエンドポイントに到達できます。
【他選択肢が違う理由】
- B: Priority は明示的な順位付けで、Latency 評価とは独立した制御方式です。
- C: Weighted は事前に重みを指定する方式で、自動的なレイテンシ評価ではありません。
- D: Geographic は地理ベースで明示的に振り分ける方式で、レイテンシ最適化は別動作です。
【参考】
AZ700-APP#14
各ルーティング要件と Traffic Manager のルーティング方式をマッチさせてください。
項目（ドラッグしてください）
- プライマリ + バックアップの順序付きフェイルオーバ
- A/B テストでトラフィックを 90% / 10% で配分
- EU ユーザは EU region、US ユーザは US region に固定誘導
- クライアントから低レイテンシな region を自動選択
Priority (優先順位)
Weighted (重み付け)
Geographic (地理)
Performance (パフォーマンス)
解説
【正しいマッチング完全版】
※ Priority = 順位フェイルオーバ、Weighted = A/B 配分、Geographic = 地域固定、Performance = レイテンシ自動選択の対応関係を覚えると要件マッピングが正確になります。
- プライマリ + バックアップの順序付きフェイルオーバ → Priority (優先順位)
- A/B テストでトラフィックを 90% / 10% で配分 → Weighted (重み付け)
- EU ユーザは EU region、US ユーザは US region に固定誘導 → Geographic (地理)
- クライアントから低レイテンシな region を自動選択 → Performance (パフォーマンス)
【正解マッチング】
| 機能 | 対応 |
|---|---|
| プライマリ + バックアップの順序付きフェイルオーバ | Priority (優先順位) |
| A/B テストでトラフィックを 90% / 10% で配分 | Weighted (重み付け) |
| EU ユーザは EU region、US ユーザは US region に固… | Geographic (地理) |
| クライアントから低レイテンシな region を自動選択 | Performance (パフォーマンス) |
【参考】
AZ700-APP#15
Traffic Manager プロファイルで「DNS TTL」を設定する目的として最も適切なものはどれですか?
解説
【正解: A】の理由
Traffic Manager の DNS TTL は応答 DNS レコードのキャッシュ保持時間を制御する設定で、エンドポイント切替時にクライアント側 DNS リゾルバが新しい応答を取得するまでの待機時間に直接影響します。そのため、低い TTL (例: 30〜60 秒) を設定すると障害時のフェイルオーバ反映が高速になりますが、DNS クエリ頻度は増加します。
【他選択肢が違う理由】
- B: Health Probe 間隔は別の設定項目で、TTL とは独立して構成します。
- C: スループット制限は Traffic Manager の機能範囲外です。
- D: TLS 証明書の有効期間は別の概念で、DNS TTL とは無関係です。
【参考】
AZ700-APP#16
API Management インスタンスを Developer SKU で構築して、既存の Backend API を公開する手順を正しい順序に並べてください。
- API Management インスタンスを作成 (Developer SKU)
- Backend API をインポート (OpenAPI / SOAP / Function 等)
- Product を作成して API をアサイン
- Policy (認証 / レート リミット / 変換) を Operation 単位で構成
解説
【正しい順序】
- ステップ 1: APIM インスタンス作成
- ステップ 2: API インポート
- ステップ 3: Product 作成 + API アサイン
- ステップ 4: Policy 構成
【各ステップの理由】
- ステップ 1 APIM インスタンス作成: Developer SKU は本番非対応 (SLA なし) ですが、開発・検証用途に最適なコスト効率の良い SKU として選定します。
- ステップ 2 API インポート: OpenAPI / Swagger / SOAP / Function App / Logic App から API メタデータを取り込み、Operation を自動構成します。
- ステップ 3 Product 作成 + API アサイン: Product は API のグルーピング単位で、Subscription Key の発行と利用者管理を Product 単位で行います。
- ステップ 4 Policy 構成: Inbound / Outbound / Backend / On-Error の各 Section で認証・レート リミット・変換などの Policy を Operation 単位で適用します。
【誤った順序の問題点】
- Policy を先に構成: Policy の対象となる API / Operation が存在しないため、Policy 作成は意味を持ちません。
- API なしで Product 作成: Product は API のコンテナのため、対象 API が存在しないと意味のない Product になります。
【参考】
AZ700-APP#17
Application Gateway の Backend Pool で利用可能な「Backend Target」種別として、サポートされていないものはどれですか?
解説
【正解: D】の理由
Azure Storage Blob Container は Application Gateway の Backend Pool として直接指定することはできません。Application Gateway は HTTP / HTTPS バックエンドを対象とするため、VM / VMSS / App Service / Public IP / IP アドレス / FQDN を Backend Target として利用します。Storage Blob 配信が必要な場合は Front Door や Azure CDN を採用するのが一般的です。
【他選択肢が違う理由】
- A: VM は Backend Pool に NIC 経由または IP アドレスで登録可能です。
- B: VMSS (Scale Set) は Application Gateway Ingress Controller (AGIC) や手動構成で Backend Pool に登録可能です。
- C: App Service (Web App) は Backend Pool に FQDN で登録可能で、Application Gateway 経由配信は標準パターンです。
【参考】
AZ700-APP#18
Azure Front Door の SKU 機能差について、各機能をどちらが対応しているか選んでください。
| ステートメント | 選択 |
|---|---|
Microsoft マネージド WAF Rule Set + Bot Manager Premium SKU では Microsoft マネージドの WAF Rule Set と Bot Manager Rule Set を組み合わせて利用できます。これにより、OWASP CRS に加えて Microsoft 独自の脅威インテリジェンス ベースの保護が実現します。 | |
Private Link 経由の Origin 接続 Private Link 経由 Origin 接続は Premium SKU 限定の機能で、Storage Account や Web App などの Origin にプライベート アクセスする際に活用します。これにより、Front Door 経由のトラフィックを含めて Origin の Public Endpoint を完全に閉じる設計が可能となります。 | |
カスタム ドメイン + TLS 証明書 (Managed Cert) のサポート Managed Certificate (Microsoft マネージド TLS 証明書) は Standard と Premium の両方で利用可能です。そのため、低コストで TLS 配信を実現したい場合は Standard SKU でも要件を満たせます。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| Microsoft マネージド WAF Rule Set + Bot Manager | Premium |
| Private Link 経由の Origin 接続 | Premium |
| カスタム ドメイン + TLS 証明書 | どちらでも |
【各判定の詳細】
- 「Microsoft マネージド WAF Rule Set + Bot Manager」→ Premium: Premium SKU では Microsoft マネージドの WAF Rule Set と Bot Manager Rule Set を組み合わせて利用できます。これにより、OWASP CRS に加えて Microsoft 独自の脅威インテリジェンス ベースの保護が実現します。
- 「Private Link 経由の Origin 接続」→ Premium: Private Link 経由 Origin 接続は Premium SKU 限定の機能で、Storage Account や Web App などの Origin にプライベート アクセスする際に活用します。これにより、Front Door 経由のトラフィックを含めて Origin の Public Endpoint を完全に閉じる設計が可能となります。
- 「カスタム ドメイン + TLS 証明書」→ どちらでも: Managed Certificate (Microsoft マネージド TLS 証明書) は Standard と Premium の両方で利用可能です。そのため、低コストで TLS 配信を実現したい場合は Standard SKU でも要件を満たせます。