MENU
会員登録（無料）
  1. ホーム
  2. Microsoft Azure 向けソリューションの開発(AZ-204)WEB問題集

Microsoft Azure 向けソリューションの開発(AZ-204)WEB問題集

WEB問題集

Question#1(AZ-204)

複数のAzure API Management (APIM) ホスト型APIを開発しています。

あるAPIに対して、軽微で非互換性のない（non-breaking）変更をいくつか行う必要があります。APIの変更には以下の要件が含まれます：

  • APIの呼び出し元（クライアント）を中断させてはならない。

  • 問題が発見された場合にロールバック（元の状態に戻すこと）が可能であること。

  • 開発者が新機能の内容を理解できるようにドキュメント化されていること。

  • 公開前にテストされていること。

APIを更新する必要があります。

あなたは何をすべきですか？

ディスカッション 0

正解：D

Azure API Managementにおける変更管理には、「リビジョン」と「バージョン」の2つの概念があります。この問題の鍵は「非互換性のない変更（non-breaking changes）」という点です。

なぜ「リビジョン」が正解なのか？

  • リビジョン (Revision):

    • APIの実装に対する安全でインクリメンタル（段階的）な変更に使用します。

    • 呼び出し元に影響を与えず、変更をオフライン（特定のURL）でテストできます。

    • 準備ができたら、そのリビジョンを「最新（Current）」に設定するだけで公開でき、問題があればすぐに以前のリビジョンに戻せます。

    • 変更履歴が記録されるため、開発者は何が変わったのかを確認できます。

Question#2(AZ-204)

ある企業のAzure Container Apps上で動作する複数のマイクロサービスを開発しています。これらのマイクロサービスに対して、インターネットからの外部TCPイングレス（受信）トラフィックが有効になっています。

マイクロサービスは、Azure Event Hubのトリガーに基づいてスケーリングする必要があります。

カスタムスケーリングルールを使用して、マイクロサービスをスケーリングする必要があります。

使用すべき2つのKubernetes Event-driven Autoscaling (KEDA) トリガーフィールドはどれですか？ それぞれの正解はソリューションの一部を構成します。

（2つ選択）

ディスカッション 0

正解：A, B

Azure Container Appsで「カスタムスケーリングルール」を定義する際、内部的にはKEDAが使用されます。YAML構成やAzure CLI、ポータルでスケーラーを定義する際、特定のイベントソース（この場合はEvent Hub）を識別するために必須となる主要なフィールドが type と metadata です。

1. type (選択肢 B)

スケーリングをトリガーするイベントソースの種類を指定します。

  • Azure Event Hubを使用する場合、このフィールドには azure-eventhub と記述する必要があります。

  • これにより、KEDAはどのスケーラー（RabbitMQ、Kafka、Event Hubなど）を使用すべきかを判断します。

2. metadata (選択肢 A)

スケーリングの判断基準となる詳細なパラメータを定義します。

  • Event Hubの場合、ここには consumerGroup、connectionFromEnv（接続文字列を参照する環境変数名）、またはスケーリングの閾値となる lagThreshold などを記述します。

  • これがないと、KEDAは「どのEvent Hubの、どのコンシューマーグループを監視すればよいか」を把握できません。

Question#3(AZ-204)

Azure Event Grid を使用して、顧客にほぼリアルタイムの情報をプッシュするアプリケーションを実装しています。

以下の要件があります：

  • 数百種類のイベントタイプを含むイベントを、数千の顧客に送信する必要がある。

  • イベントは、処理前にイベントタイプによってフィルタリングされる必要がある。

  • 認証と認可は Microsoft Entra ID（旧 Azure AD）を使用して処理する必要がある。

  • イベントは単一のエンドポイントに公開される必要がある。

Azure Event Grid を実装する必要があります。

解決策： イベントを「イベントドメイン (Event Domain)」に公開します。顧客ごとに「カスタムトピック (Custom Topic)」を作成します。

この解決策は目標を満たしていますか？

ディスカッション 0

正解：B

このソリューションが「いいえ」である理由は、「顧客ごとにカスタムトピックを作成する」という部分が誤りだからです。

なぜ「イベントドメイン」を使うのか？

イベントドメインは、数千ものトピックを持つ大規模なアプリケーションを管理するために設計されたツールです。要件にある「数千の顧客」や「単一のエンドポイントへの公開」を処理するのに最適です。

どこが間違っているのか？

  • イベントドメインの構造: イベントドメイン内では、個別のトピックは「カスタムトピック」ではなく、**「ドメイントピック (Domain Topic)」**と呼ばれます。

  • 管理の複雑さ: 顧客ごとに独立した「カスタムトピック」を作成してしまうと、それぞれに異なるエンドポイントや管理コストが発生し、「単一のエンドポイントに公開する」という要件や、大規模なマルチテナント管理が非常に困難になります。

  • 正しい構成: 正解は「イベントドメインを作成し、そのドメイン内にドメイントピックを作成する」ことです。これにより、パブリッシャー（公開側）はドメインの単一エンドポイントにイベントを送信するだけで、Event Grid が適切なドメイントピック（顧客）へ振り分けてくれます。

要件との照らし合わせ

  • 数千の顧客: イベントドメインは最大 100,000 個のドメイントピックをサポートします。

  • 単一エンドポイント: イベントドメインには 1 つの公開用エンドポイントがあります。

  • フィルタリング: ドメイントピック内のイベントサブスクリプションでフィルタ設定が可能です。

  • Entra ID: イベントドメインは Entra ID による RBAC をサポートしています。

Question#4(AZ-204)

Azure Event Grid を使用して、顧客にほぼリアルタイムの情報をプッシュするアプリケーションを実装しています。

以下の要件があります：

  • 数百種類のイベントタイプを含むイベントを、数千の顧客に送信する必要がある。

  • イベントは、処理前にイベントタイプによってフィルタリングされる必要がある。

  • 認証と認可は Microsoft Entra ID を使用して処理する必要がある。

  • イベントは単一のエンドポイントに公開される必要がある。

Azure Event Grid を実装する必要があります。

解決策： イベントを「カスタムトピック (Custom Topic)」に公開します。顧客ごとに「イベントサブスクリプション (Event Subscription)」を作成します。

この解決策は目標を満たしていますか？

ディスカッション 0

正解：B

この解決策が「いいえ」である理由は、主に Azure Event Grid の制限（クォータ） にあります。

1. 数千の顧客へのスケーラビリティ不足

  • 要件： 数千の顧客に送信する。

  • 制限： 1つのトピック（カスタムトピックを含む）に対して作成できるイベントサブスクリプションの数は、デフォルトで 500個 までです。

  • 結論： 「数千の顧客」に対して一人ずつサブスクリプションを作成しようとすると、上限に達してしまい、要件を満たすことができません。

2. 認証と認可の粒度

  • 要件： Entra ID による認証・認可。

  • 詳細： 1つのカスタムトピックにすべての顧客のサブスクリプションを紐付けてしまうと、顧客ごとのアクセス制御（認可）を細かく管理することが困難になります。イベントドメインであれば、トピックレベルでの認可が可能です。

3. イベントドメインとの比較

先ほどの問題でも触れましたが、このような「大規模・マルチテナント（多数の顧客）」のケースでは、イベントドメイン (Event Domain) を使用するのが正解です。

  • カスタムトピック案（今回）： サブスクリプション上限（500）により、数千の顧客に対応不可。

  • イベントドメイン案： 最大 100,000 個のドメイントピックをサポートしており、数千〜数万の顧客にも余裕を持って対応可能。

Question#5(AZ-204)

Azure Event Grid を使用して、顧客にほぼリアルタイムの情報をプッシュするアプリケーションを実装しています。

以下の要件があります：

  • 数百種類のイベントタイプを含むイベントを、数千の顧客に送信する必要がある。

  • イベントは、処理前にイベントタイプによってフィルタリングされる必要がある。

  • 認証と認可は Microsoft Entra ID を使用して処理する必要がある。

  • イベントは単一のエンドポイントに公開される必要がある。

Azure Event Grid を実装する必要があります。

解決策： イングレス（Ingress）を有効にし、TCPスケールルールを作成して、コンテナアプリ（Container App）に適用します。

この解決策は目標を満たしていますか？

ディスカッション 0

正解：B

この解決策が「いいえ」である理由は、提示された技術が Azure Event Grid ではなく、Azure Container Apps のスケーリングに関するものだからです。

1. サービスの不一致

  • 要件： Azure Event Grid を実装して、イベントを顧客にプッシュ（配信）する。

  • 解決策： コンテナアプリのイングレス設定やTCPスケールルールを操作する。

  • 結論： コンテナアプリのスケーリング設定を変更しても、Event Grid の構成（トピックやドメインの作成）には一切寄与しません。

2. スケールルールとイベント配信の違い

  • TCPスケールルール： これは Azure Container Apps において、同時に発生している TCP 接続数に基づいて、コンテナのインスタンス数を増減させるための設定です。

  • イベント配信： 要件にある「数千の顧客へのイベント送信」や「イベントタイプによるフィルタリング」は、Event Grid のリソース（イベントドメインやドメイントピック）で管理されるべき機能です。

次のページ