[2024年10月15日]MCPA-Level-1日本語究極な学習ガイド [Q19-Q36]

[2024年10月15日]MCPA-Level-1日本語究極な学習ガイド

究極なガイドで準備MCPA-Level-1日本語認定試験MuleSoft Certified Platform Architectは2024年更新

質問 # 19
Anypoint VPC の技術アーキテクチャについて正しいのはどれですか?

• A. VPC ピアリングを使用して、基盤となる AWS VPC をオンプレミス (AWS 以外) のプライベート ネットワークにリンクできます。
• B. Anypoint VPC にデプロイされた Mule アプリケーションとオンプレミス システム間のトラフィックは、プライベート ネットワーク内に留まることができます。
• C. 各 CloudHub 環境には個別の Anypoint VPC が必要です
• D. Anypoint VPC のプライベート IP アドレス範囲は、CloudHub によって自動的に選択されます

正解：B

解説：
正解: Anypoint VPC にデプロイされた Mule アプリケーションとオンプレミス システム間のトラフィックは、プライベート ネットワーク内にとどまることができます。
********************************************
>> Anypoint VPC のプライベート IP アドレス範囲は、CloudHub によって自動的に選択されません。これは、CIDR ブロックを使用して VPC を作成するときに選択されます。
CIDR ブロック: Classless Inter-Domain Routing (CIDR) 表記での Anypoint VPC のサイズ。
たとえば、10.111.0.0/24 に設定すると、Anypoint VPC には 10.111.0.0 から 10.111.0.255 までの 256 個の IP アドレスが付与されます。
理想的には、Anypoint VPC 用に選択する CIDR ブロックは、プライベート IP スペースからのものであり、他の Anypoint VPC の CIDR ブロック、または企業ネットワークで使用されている CIDR ブロックと重複しないようにする必要があります。

各 CloudHub 環境には個別の Anypoint VPC が必要です。Anypoint VPC が作成されると、複数の環境で同じ VPC を選択できます。ただし、通常は、Non-Prod 環境と Prod 環境で常に個別の Anypoint VPC を使用することがベストで推奨される方法です。
>> Anypoint VPN を使用して、基盤となる AWS VPC をオンプレミス (非 AWS) プライベート ネットワークにリンクします。VPC ピアリングではありません。
リファレンス：
与えられた選択肢の唯一の真実は、Anypoint VPC にデプロイされた Mule アプリケーションとオンプレミス システム間のトラフィックがプライベート ネットワーク内にとどまることができるということです。
https://docs.mulesoft.com/runtime-manager/vpc-connectivity-methods-concept

質問 # 20
たとえば、以下の機能を提供する CRM-Z と呼ばれる従来の CRM システムがあるとします。
1. 顧客の創造
2.既存の顧客の詳細を修正する
3. 顧客の詳細を取得する
4. 顧客を一時停止する

• A. すべての機能がさまざまな操作/リソースとしてラップされている customerManagement という名前のシステム API を実装します。
• B. createCustomer、amendCustomer、retrieveCustomer、suspendCustomer という名前の異なるシステム API を実装します。それらはモジュール化されており、懸念事項が分離されているためです。
• C. createCustomerInCRMZ、amendCustomerInCRMZ、retrieveCustomerFromCRMZ、suspendCustomerInCRMZ という名前の異なるシステム API を実装します。それらはモジュール化されており、懸念事項が分離されているためです。

正解：B

解説：
Implement different system APIs named createCustomer, amendCustomer, retrieveCustomer
and suspendCustomer as they are modular and has seperation of concerns
*****************************************
>> It is quite normal to have a single API and different Verb + Resource combinations. However, this fits well for an Experience API or a Process API but not a best architecture style for System APIs. So, option with just one customerManagement API is not the best choice here.
>> The option with APIs in createCustomerInCRMZ format is next close choice w.r.t modularization and less maintenance but the naming of APIs is directly coupled with the legacy system. A better foreseen approach would be to name your APIs by abstracting the backend system names as it allows seamless replacement/migration of any backend system anytime. So, this is not the correct choice too.
>> createCustomer, amendCustomer, retrieveCustomer and suspendCustomer is the right approach and is the best fit compared to other options as they are both modular and same time got the names decoupled from backend system and it has covered all requirements a System API needs.

質問 # 21
バックエンド システムの制限により、システム API は 1 秒あたり最大 500 リクエストしか処理できません。バックエンド システムの過負荷を避けるために、システム API に適用するのに最適な API ポリシーのタイプはどれですか?

• A. スパイク制御
• B. HTTP キャッシング
• C. レート制限 - SLA ベース
• D. レート制限

正解：A

解説：
スパイクコントロール
********************************************
>> まず最初に、HTTP キャッシング ポリシーは、バックエンド システムの過負荷を回避することとは別の目的のためのものです。これはアウトです。
>> レート制限およびスロットリング/スパイク制御ポリシーは、API アクセスを制限するように設計されていますが、意図は異なります。
>> レート制限は、アクセスにハード制限を適用することで API を保護します。
>> スロットリング/スパイク制御は、トラフィックのスパイクを平滑化することで API アクセスを形作ります。
そのため、Spike Control は適切なオプションです。

質問 # 22
ビジネス ロジック オーケストレーションは、API 主導の接続のどのレイヤーに存在しますか?

• A. システム層
• B. 経験層
• C. プロセス層

正解：C

解説：
プロセスレイヤー
********************************************
>> エクスペリエンス レイヤーは、エンド ユーザー エクスペリエンスの強化専用です。このレイヤーは、さまざまな API クライアント/コンシューマーのニーズを満たすためのものです。
>> システム層は、本質的にモジュラーであり、バックエンド システムのさまざまな個々の機能を実装/公開する API 専用です。
>> プロセス レイヤーは、1 つまたは複数のシステム レイヤーのモジュラー API を呼び出すことによって、単純または複雑なビジネス オーケストレーション ロジックが記述される場所です。つまり、プロセス レイヤーが正解です。

質問 # 23
展示を参照してください。

API 主導の接続とアプリケーション ネットワークという意味で有効な API とは何ですか?
A) Java RMI over TCP

B) Java RMI over TCP

C) CORBA over HOP

D) XML over UDP

• A. オプション A
• B. オプション B
• C. オプション D
• D. オプション C

正解：C

解説：
XML over HTTP
*****************************************
>> API-led connectivity and Application Networks urge to have the APIs on HTTP based protocols for building most effective APIs and networks on top of them.
>> The HTTP based APIs allow the platform to apply various varities of policies to address many NFRs
>> The HTTP based APIs also allow to implement many standard and effective implementation patterns that adhere to HTTP based w3c rules.

Bottom of Form
Top of Form

質問 # 24
API ポリシーを適用できる Mule アプリケーション
その Mule アプリケーションによって公開されたエンドポイントへの Anypoint Platform?
A) HTTP/1.x 経由でリクエストを受け入れる Mule アプリケーション

B) TCP 経由で JSON 要求を受け入れるが、応答を提供する必要がない Mule アプリケーション

C) WebSocket 経由で JSON リクエストを受け入れる Mute アプリケーション

D) HTTP/2 経由で gRPC リクエストを受け入れる Mule アプリケーション

• A. オプション A
• B. オプション B
• C. オプション C
• D. オプション D

正解：A

解説：
選択肢A
********************************************
>> Anypoint API Manager と API ポリシーは、すべてのタイプの HTTP/1.x API に適用されます。
>> WebSocket API、HTTP/2 API、gRPC API には適用されません

質問 # 25
バックエンド システムの制限により、システム API は 1 秒あたり最大 500 リクエストしか処理できません。バックエンド システムの過負荷を避けるために、システム API に適用するのに最適な API ポリシーのタイプはどれですか?

• A. スパイク制御
• B. HTTP キャッシング
• C. レート制限 - SLA ベース
• D. レート制限

正解：A

解説：
Spike control
*****************************************
>> First things first, HTTP Caching policy is for purposes different than avoiding the backend system from overloading. So this is OUT.
>> Rate Limiting and Throttling/ Spike Control policies are designed to limit API access, but have different intentions.
>> Rate limiting protects an API by applying a hard limit on its access.
>> Throttling/ Spike Control shapes API access by smoothing spikes in traffic.
That is why, Spike Control is the right option.

質問 # 26
API では、クライアント リクエスト (TPS) vth 小さなメッセージ ペイトアドの割合が高くなります。クライアント アプリケーションの種類に基づいて、API に使用制限を課すにはどうすればよいですか?

• A. クライアント アプリケーションの種類ごとに要求数を制限するスパイク制御ポリシーを使用する
• B. レート制限ポリシーとクライアント ID 強制ポリシーを使用します。それぞれクライアント アプリケーション タイプによって構成されます。
• C. クロスオリジン リソース共有 (CORS) ポリシーを使用して、クライアント アプリケーションの種類によって構成された、クライアント アプリケーション間のリソース共有を制限します。
• D. SLA ベースのレート制限ポリシーを使用し、クライアント アプリケーションをそのタイプに基づいて一致する SLA 層に割り当てます。

正解：D

解説：
Use an SLA-based rate limiting policy and assign a client application to a matching SLA tier based on its type.
*****************************************
>> SLA tiers will come into play whenever any limits to be imposed on APIs based on client type

質問 # 27
API 実装を Anypoint VPC にデプロイする必要があるのはいつですか?

• A. API 実装が永続オブジェクト ストアに書き込む必要がある場合
• B. パブリック アクセスを許可しない制限された顧客ホスト型ネットワークのサブネット内で API 実装にアクセスできる必要がある場合
• C. API 実装が、お客様が管理する AWS インスタンスで CloudHub の外部にデプロイされた公開サービスを呼び出す必要がある場合
• D. Mule Maven プラグインを使用して API 実装を本番 AWS VPC にデプロイする必要がある場合

正解：C

質問 # 28
ある企業は、EU コントロール プレーンと顧客がホストする Mule ランタイムを組み合わせたハイブリッド Anypoint Platform デプロイ モデルを使用しています。ステージング環境で Mule API 実装を正常にテストした後、Mule API 実装は環境固有のプロパティで設定され、本番環境に昇格する必要があります。MuleSoft が Mule API 実装を設定し、本番環境への昇格を自動化するために推奨する方法は何ですか?

• A. API ポリシーを使用してステージング環境にデプロイされた Mule API 実装のプロパティを変更し、別の API ポリシーを使用して Mule API 実装を本番環境にデプロイします。
• B. API Manager の [プロパティ] タブで Mule API 実装のプロパティを変更し、API Manager を使用して Mule API 実装を本番環境にプロモートします。
• C. 各環境のプロパティ ファイルを Mule API 実装の展開可能なアーカイブにバンドルし、Anypoint CLI または Anypoint Platform REST APIsB を使用して Mule API 実装を本番環境に昇格させます。
• D. Anypoint Exchange で Mule API 実装のプロパティを変更し、Runtime Manager を使用して Mule API 実装を本番環境にプロモートします。

正解：C

解説：
正解: 各環境のプロパティ ファイルを Mule API 実装の展開可能なアーカイブにバンドルし、Anypoint CLI または Anypoint Platform REST API を使用して Mule API 実装を本番環境に昇格させます。
********************************************
>> Anypoint Exchange は、資産の発見と文書化に使用されます。Mule API 実装のプロパティを変更するための準備はまったくありません。
>> API Manager は、API インスタンス、そのコントラクト、ポリシー、および SLA を管理するためのものです。また、API 実装のプロパティを変更するための規定もありません。
>> API ポリシーは、API の非機能要件に対処するためのものであり、API 実装のプロパティを変更する規定はありません。
そのため、開発プラクティスの一環としてこれを行う正しい方法と推奨される方法は、各環境のプロパティ ファイルを Mule API 実装にバンドルし、環境ごとにそれぞれのファイルをポイントして参照することです。

質問 # 29
ある企業は、成功を収めたエンタープライズ データ モデル (EDM) を作成しました。同社は、同社の IT 運用モデルのコア イネーブラーとして最新の API を採用することにより、アプリケーション ネットワークの構築に取り組んでいます。最新の API データ モデルを設計する際に、企業はどの API 層 (経験、プロセス、システム) で EDM を再利用する必要がありますか?

• A. エクスペリエンス層とシステム層
• B. プロセス層とシステム層
• C. エクスペリエンス、プロセス、およびシステム層
• D. エクスペリエンス層とプロセス層

正解：B

解説：
At the process and system tiers
*****************************************
>> Experience Layer APIs are modeled and designed exclusively for the end user's experience. So, the data models of experience layer vary based on the nature and type of such API consumer. For example, Mobile consumers will need light-weight data models to transfer with ease on the wire, where as web-based consumers will need detailed data models to render most of the info on web pages, so on. So, enterprise data models fit for the purpose of canonical models but not of good use for experience APIs.
>> That is why, EDMs should be used extensively in process and system tiers but NOT in experience tier.

質問 # 30
システム API の API データ モデルが、対応するバックエンド システムによって公開されたデータ モデルを合理的に模倣し、バックエンド システムのデータ モデルを最小限に改善できるのはいつですか?

• A. システム API を、対応するデータ モデルを使用して境界付けられたコンテキストに割り当てることができる場合
• B. バックエンド システムからの限定的な分離のみを伴う実用的なアプローチが適切と見なされる場合
• C. 近い将来、対応するバックエンド システムのリプレースが予想される場合
• D. 組織全体で広く使用されている既存のエンタープライズ データ モデルがある場合

正解：B

質問 # 31
コード中心の API ドキュメント環境では、API コンシューマーが、代表的なシナリオの一部として 1 つ以上の API を呼び出す方法を示す API クライアント ソース コードを調査および実行できるようにする必要があります。
Anypoint Platform を使用して、この種のコード中心の API ドキュメント環境を提供する最も効果的な方法は何ですか?

• A. API ノートブックを作成し、関連する Anypoint Exchange エントリに含めます。
• B. 関連する API を Anypoint Exchange エントリを介して検出できるようにする
• C. 関連する API ごとにモック サービスを有効にし、Anypoint Exchange エントリを介してそれらを公開します。
• D. Anypoint Exchange エントリと API コンソールを通じて API が十分に文書化されていることを確認し、これらのページをすべての API コンシューマーと共有します。

正解：A

解説：
Create API Notebooks and Include them in the relevant Anypoint exchange entries
*****************************************
>> API Notebooks are the one on Anypoint Platform that enable us to provide code-centric API documentation

質問 # 32
Mule アプリケーションが CloudHub 共有ワーカー クラウドにデプロイされたときに作成される完全修飾ドメイン名 (FQDN) (別名 DNS エントリ) を最もよく表しているのはどれですか?

• A. FQDN はアプリケーション名によって決定されますが、展開後に管理者が変更できます
• B. FQDN は、選択したアプリケーション名によって決まります。地域に関係なく、
• C. 固定数の FQDN が作成され、環境と VPC の設計に関係なく作成されます
• D. FQDN は、アプリケーション名と Anypoint Platform 組織の両方によって決定されます。

正解：B

解説：
The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region
*****************************************
>> When deploying applications to Shared Worker Cloud, the FQDN are always determined by application name chosen.
>> It does NOT matter what region the app is being deployed to.
>> Although it is fact and true that the generated FQDN will have the region included in it (Ex:
exp-salesorder-api.au-s1.cloudhub.io), it does NOT mean that the same name can be used when deploying to another CloudHub region.
>> Application name should be universally unique irrespective of Region and Organization and solely determines the FQDN for Shared Load Balancers.

質問 # 33
API ポリシーが Anypoint Platform で定義されている場所と、それが API インスタンスにどのように適用されるかについて正しいのはどれですか?

• A. API ポリシーは API Manager で定義され、すべての API インスタンスに自動的に適用されます。
• B. API ポリシーは、特定の API インスタンスに対して API Manager で定義され、特定の API インスタンスにのみ適用されます。
• C. API ポリシーは、Mule ランタイムへの API デプロイメントの一部として Runtime Manager で定義され、特定の API インスタンスにのみ適用されます。
• D. API ポリシーは API Manager で定義され、指定された環境のすべての API インスタンスに適用されます。

正解：B

解説：
正解: API ポリシーは、特定の API インスタンスに対して API Manager で定義され、特定の API インスタンスにのみ適用されます。
********************************************
>> API 仕様の準備が整い、Exchange に公開されたら、API Manager にアクセスして、各 API の API インスタンスを登録する必要があります。
>> API Manager は、NFR にポリシーを適用して NFR に対処するなど、API の側面の管理が行われる場所です。
>> 同じ API に対して複数のインスタンスを作成し、目的ごとに異なる方法で管理できます。
>> 1 つのインスタンスに API ポリシーのセットを適用し、同じ API の別のインスタンスに別の目的で別のポリシーのセットを適用できます。
>> これらの API とそのインスタンスは、環境ごとに定義されています。そのため、環境ごとに個別に管理する必要があります。
>> プラットフォーム機能を使用してより高い環境に昇格するときに、API インスタンス (SLA、ポリシーなど) の同じ構成が昇格されるようにすることができます。ただし、これはオプションのみです。必要に応じて、環境ごとに変更することもできます。
>> Runtime Manager は、API 実装とその Mule ランタイムを管理する場所ですが、API 自体は管理しません。API ポリシーは Mule Runtimes で実行されますが、Runtime Manager で API ポリシーを強制することはできません。環境内の厳選されたインスタンスに対してのみ、API Manager を介してこれを行う必要があります。
したがって、これらの事実に基づいて、指定された選択肢の正しいステートメントは、「API ポリシーは、特定の API インスタンスに対して API Manager で定義され、特定の API インスタンスにのみ適用されます」です。

質問 # 34
API 実装が CloudHub にデプロイされます。
アラート条件が API 実装のエンドツーエンドのリクエスト処理に依存する場合、デフォルトの Anypoint Platform 機能を使用してアラートを出すことができる条件は何ですか?

• A. API 呼び出しの応答時間がしきい値を超えた場合
• B. 認識されていない API クライアントから API が呼び出された場合
• C. 特定の API クライアントが一定期間内に API を頻繁に呼び出す場合
• D. API が非常に多くの API 呼び出しを受け取る場合

正解：A

解説：
When the response time of API invocations exceeds a threshold
*****************************************
>> Alerts can be setup for all the given options using the default Anypoint Platform functionality
>> However, the question insists on an alert whose conditions depend on the end-to-end request processing of the API implementation.
>> Alert w.r.t "Response Times" is the only one which requires end-to-end request processing of API implementation in order to determine if the threshold is exceeded or not.

質問 # 35
正しいか間違っているか。より多くの工数とリソースが必要な場合でも、設計および開発されている API がセルフサービス可能であることを常に確認する必要があります。

• A. FALSE
• B. TRUE

正解：B

解説：
TRUE
********************************************
>> MuleSoft が提案した IT 運用モデルによると、API を設計し、それらが検出可能でセルフサービス可能であることを確認することは非常に重要であり、API とそのアプリケーション ネットワークの成功を決定します。

質問 # 36
......

MuleSoft Certified Platform Architect基礎問題MCPA-Level-1日本語試験練習問題集：https://jp.fast2test.com/MCPA-Level-1-JPN-premium-file.html