GoShiken MCPA-Level-1日本語問題集154問でMuleSoft Certified Platform Architectを確実実践 [Q55-Q79]

GoShiken MCPA-Level-1日本語問題集154問でMuleSoft Certified Platform Architectを確実実践

リアル最新MCPA-Level-1日本語試験問題MCPA-Level-1日本語問題集

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

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

正解：C

解説：
正解: createCustomer、amendCustomer、retrieveCustomer、suspendCustomer という名前の異なるシステム API を実装します。それらはモジュール化されており、懸念事項が分離されているためです。
********************************************
>> 単一の API と異なる Verb + Resource の組み合わせを使用するのはごく普通のことです。ただし、これはエクスペリエンス API やプロセス API には適していますが、システム API には最適なアーキテクチャスタイルではありません。したがって、customerManagement API を 1 つだけ使用するオプションは、ここでは最良の選択ではありません。
>> createCustomerInCRMZ 形式の API を使用するオプションは、モジュール化とメンテナンスの軽減という点で次に近い選択肢ですが、API の命名はレガシーシステムと直接結び付いています。より適切な方法として、バックエンドシステムの名前を抽象化して API に名前を付けることをお勧めします。これにより、バックエンドシステムをいつでもシームレスに交換/移行できるようになります。したがって、これも正しい選択ではありません。
>> createCustomer、amendCustomer、retrieveCustomer、suspendCustomer は適切なアプローチであり、他のオプションと比較して最適です。これらは両方ともモジュラーであり、同時に名前がバックエンドシステムから切り離されており、システム API が必要とするすべての要件をカバーしているためです。

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

開発者は、クライアント ID 強制ポリシーによって管理される STAGING 環境にデプロイされた API を呼び出すクライアントアプリケーションを構築しています。
API を正常に呼び出すには何が必要ですか?

A. Anypoint Platform から取得した有効な OAuth トークンと、それに関連付けられたクライアント ID とシークレット
B. STAGING 環境の API インスタンス用に Anypoint Exchange から取得したクライアント ID とシークレット
C. Anypoint Platform アカウントの STAGING 環境のクライアント ID とシークレット
D. STAGING 環境で API を所有する Anypoint Platform アカウントのクライアント ID とシークレット

正解：B

解説：
Anypoint Exchange から取得した STAGING 環境の API インスタンスのクライアント ID とシークレット
********************************************
>> Anypoint Platform アカウントのクライアント ID とシークレット、または API にアクセスするための個々の環境を使用することはできません
>> 問題の API に適用されるポリシーのタイプが「クライアント ID 適用ポリシー」であるため、OAuth トークンベースのアクセスは機能しません。
API にアクセスする正しい方法は、Anypoint Exchange から取得したクライアント ID とシークレットを使用して、作業する特定の環境の API インスタンスに使用することです。
参考文献:
API Manager での API インスタンスコントラクトの管理
https://docs.mulesoft.com/api-manager/1.x/request-access-to-api-task
https://docs.mulesoft.com/exchange/to-request-access
https://docs.mulesoft.com/api-manager/2.x/policy-mule3-client-id-based-policies

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

A. FALSE
B. TRUE

正解：B

解説：
TRUE
*****************************************
>> As per MuleSoft proposed IT Operating Model, designing APIs and making sure that they are discoverable and self-servable is VERY VERY IMPORTANT and decides the success of an API and its application network.

質問 # 58
組織では、さまざまなクラウドベースの SaaS システムと複数のオンプレミスシステムを使用しています。オンプレミスシステムは組織のアプリケーションネットワークの重要な部分であり、組織のイントラネット内からのみアクセスできます。
クラウドベースの SaaS システムとオンプレミスシステムの両方との統合をサポートするために Anypoint Platform を構成して使用する最適な方法は何ですか?
A) Anypoint Platform Private Cloud Edition コントロールプレーンによって管理される Anypoint VPC で CloudHub でデプロイされた Mule ランタイムを使用する B) MuleSoft がホストする Anypoint Platform コントロールプレーンによって管理される共有ワーカークラウドで CloudHub でデプロイされた Mule ランタイムを使用する C) Anypoint Platform Private Cloud Edition コントロールプレーンによって管理され、外部ネットワークアクセスのない完全に分離されたオンプレミスの Mule ランタイムインストールを使用する D) MuleSoft がホストする Anypoint Platform コントロールプレーンによって管理される、Cloud Hub でデプロイされたオンプレミスの Mule ランタイムと手動でプロビジョニングされたオンプレミスの Mule ランタイムの組み合わせを使用する

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

正解：D

解説：
Use a combination of CloudHub-deployed and manually provisioned on-premises Mule runtimes managed by the MuleSoft-hosted Platform control plane.
*****************************************
Key details to be taken from the given scenario:
>> Organization uses BOTH cloud-based and on-premises systems
>> On-premises systems can only be accessed from within the organization's intranet Let us evaluate the given choices based on above key details:
>> CloudHub-deployed Mule runtimes can ONLY be controlled using MuleSoft-hosted control plane. We CANNOT use Private Cloud Edition's control plane to control CloudHub Mule Runtimes. So, option suggesting this is INVALID
>> Using CloudHub-deployed Mule runtimes in the shared worker cloud managed by the MuleSoft-hosted Anypoint Platform is completely IRRELEVANT to given scenario and silly choice. So, option suggesting this is INVALID
>> Using an on-premises installation of Mule runtimes that are completely isolated with NO external network access, managed by the Anypoint Platform Private Cloud Edition control plane would work for On-premises integrations. However, with NO external access, integrations cannot be done to SaaS-based apps. Moreover CloudHub-hosted apps are best-fit for integrating with SaaS-based applications. So, option suggesting this is BEST WAY.
The best way to configure and use Anypoint Platform to support these mixed/hybrid integrations is to use a combination of CloudHub-deployed and manually provisioned on-premises Mule runtimes managed by the MuleSoft-hosted Platform control plane.

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

1 つのエンドツーエンドのビジネスプロセスをエクスペリエンス、プロセス、およびシステム API のコラボレーションに分解する最良の方法は何ですか?
A) エクスペリエンス API レベルではなく、プロセス API レベルでエンドユーザーアプリケーションのカスタマイズを処理する

B) システム API が、特定されたプロセスまたはエクスペリエンス API で現在必要とされていないデータを返すことを許可する

C) 3 つのレイヤー (エクスペリエンス、プロセス、およびシステム API) ごとに正確に 1 つの API を作成することにより、常に階層型アプローチを使用します。

D) プロセス API を使用して、複数のシステム API への呼び出しを調整しますが、他のプロセス API への呼び出しは調整しません

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

正解：A

解説：
正解: システム API が、特定されたプロセス API またはエクスペリエンス API で現在必要とされていないデータを返すことを許可します。
********************************************
>> エンドユーザーアプリケーションのすべてのカスタマイズは、「エクスペリエンス API」でのみ処理する必要があります。未処理 API
>> 階層化されたアプローチを使用する必要がありますが、常に 3 つのレイヤーのそれぞれに正確に 1 つの API を作成する必要はありません。エクスペリエンス API は 1 つかもしれませんが、プロセス API とシステム API は複数あることがよくあります。システム API は、エンドシステムの前に構築される最小のモジュラー API であるため、常に複数になることは間違いありません。
>> プロセス API は、システム API と他のプロセス API を呼び出すことができます。プロセス API が他のプロセス API を呼び出すべきではないという API 主導の接続には、そのようなアンチデザインパターンはありません。
そのため、API 主導の接続の原則に従って理にかなっている、指定された一連のオプションの正しい答えは、システム API が、特定されたプロセスまたはエクスペリエンス API によって現在必要とされていないデータを返すことを許可することです。このようにして、将来の一部のプロセス API はシステム API からのそのデータを利用でき、システム層 API に何度も触れる必要はありません。

質問 # 60
アプリケーションネットワークは再構成可能です。「曲がっても壊れない」ため、変更のために構築されています。

A. TRUE
B. 偽

正解：A

解説：
*****************************************
>> Application Network is a disposable architecture.
>> Which means, it can be altered without disturbing entire architecture and its components.
>> It bends as per requirements or design changes but does not break

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

組織は、すべての CloudHub デプロイメントに対して 1 つの特定の CloudHub (AWS) リージョンを使用します。
組織の Mule アプリケーションがアベイラビリティーゾーン (AZ) の CloudHub にデプロイされている場合、CloudHub ワーカーはどのようにアベイラビリティーゾーン (AZ) に割り当てられますか?

A. 特定の環境に属するワーカーは、そのリージョン内の同じ AZ に割り当てられます。
B. Mule アプリケーション用に AZ がランダムに選択され、Mule アプリケーションのすべての CloudHub ワーカーがその 1 つの AZ に割り当てられます。
C. ワーカーは、そのリージョン内の利用可能な AZ にランダムに分散されます
D. AZ は、Mule アプリケーションのデプロイ構成の一部として選択されます

正解：B

解説：
正解: ワーカーは、そのリージョン内の利用可能な AZ にランダムに分散されます。
********************************************
>> 現在、選択する AWS リージョンを選択することしか制御できませんが、どのアベイラビリティーゾーン (AZ) をどのワーカーに割り当てるかを決定するための構成やデプロイオプションを使用して制御することはまったくできません。
>> プラットフォームには、環境またはアプリケーションに基づくワーカーへの AZ の割り当てに関して、固定または暗黙のルールはありません。
>>完全にランダムに割り当てられます。ただし、cloudhub は、すべてのワーカーが同じアプリケーションの同じ AZ に割り当てられないように、複数の AZ にワーカーを割り当てることによって HA が確実に達成されるようにします。
リファレンス：

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

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

正解：C

解説：
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.

質問 # 63
Anypoint Platform で API ポリシーを使用して効果的に適用できないものは何ですか?

A. DoS 攻撃に対する防御
B. API 間で改ざん防止された資格情報を維持する
C. バックエンドシステムの過負荷
D. HTTP リクエストとレスポンスのロギング

正解：A

解説：
正解: DoS 攻撃に対する防御
********************************************
>> バックエンドシステムの過負荷は、「Spike Control Policy」を適用することで処理できます
>> HTTP リクエストとレスポンスのロギングは、「メッセージロギングポリシー」を適用することで実行できます
>> クレデンシャルは「セキュリティ」および「コンプライアンス」ポリシーを使用して改ざん防止できます。ただし、残念ながら、現在 Anypoint Platform には DOS 攻撃を防ぐ適切な方法がありません。

質問 # 64
MuleSoft がイノベーションとクロック速度を改善するために組織に推奨する IT 運用モデルの主な変更点は何ですか?

A. 再利用可能な API に SOA を実装して、消費よりも生産に集中する。これにより、XML および WSDL 形式で標準化され、意思決定が高速化されます。
B. 資産の生産と同じくらい消費を促進します。これにより、開発者は他のプロジェクトのアセットを発見して再利用できるようになり、標準化が促進されます
C. 毎日多くの小さな決定を下す、無駄のない機敏な組織を作成します。これにより、意思決定が迅速化され、各事業部門がプロジェクトの所有権を取得できるようになります
D. マスターデータ管理 (MDM) システムを使用して資産を公開します。これにより、プロジェクトが標準化され、開発者は他のプロジェクトのアセットをすばやく見つけて再利用できます

正解：B

解説：
Drive consumption as much as production of assets; this enables developers to discover and reuse assets from other projects and encourages standardization
*****************************************
>> The main motto of the new IT Operating Model that MuleSoft recommends and made popular is to change the way that they are delivered from a production model to a production + consumption model, which is done through an API strategy called API-led connectivity.
>> The assets built should also be discoverable and self-serveable for reusablity across LOBs and organization.
>> MuleSoft's IT operating model does not talk about SDLC model (Agile/ Lean etc) or MDM at all. So, options suggesting these are not valid.
References:
https://blogs.mulesoft.com/biz/connectivity/what-is-a-center-for-enablement-c4e/
https://www.mulesoft.com/resources/api/secret-to-managing-it-projects

質問 # 65
ある組織は、MuleSoft が推奨する API 主導の接続アプローチに従ってアプリケーションネットワークを構築しました。悪意のある外部 API クライアントからの攻撃からアプリケーションネットワークを保護するために、組織は JSON 脅威保護ポリシーを適用する予定です。
JSON 脅威保護ポリシーは、どの API 主導の接続レイヤーに最も一般的に適用されますか?

A. プロセス層
B. すべてのレイヤー
C. システム層
D. エクスペリエンスレイヤー

正解：D

解説：
* Understanding JSON Threat Protection Policies:
* JSON Threat Protection policies are used to protect APIs from attacks that exploit JSON payloads, such as oversized payloads, deeply nested objects, and excessive array elements. This helps prevent Denial of Service (DoS) attacks and other malicious payload-related threats.
* These policies are typically applied to safeguard APIs that are directly exposed to external clients, where the risk of receiving malicious payloads is highest.
* API-led Connectivity Layers:
* Experience Layer: This layer is designed to expose APIs to end-users or external API clients, often acting as the interface that interacts with users or applications.
* Process Layer: This layer is used for orchestration and aggregation of data from various System APIs, typically operating within a trusted environment and not directly exposed to external clients.
* System Layer: This layer provides access to backend systems and databases, often within the organization's secure environment and not directly accessible to external clients.
* Evaluating the Options:
* Option A (All layers): While JSON Threat Protection can technically be applied to all layers, it is most commonly applied at the Experience layer, where APIs are exposed to external traffic and are more vulnerable to attacks.
* Option B (System layer): The System layer is generally not exposed to external clients directly, so JSON Threat Protection is less critical here.
* Option C (Process layer): Similar to the System layer, the Process layer is typically internal and not exposed directly to external clients, so JSON Threat Protection is less commonly applied.
* Option D (Correct Answer): The Experience layer is the correct answer because it is the layer that directly interacts with external clients, making it the primary target for malicious payloads.
Applying JSON Threat Protection here effectively protects the application network from external threats.
* Conclusion:
* Option D is the correct answer, as the Experience layer is the most common layer for applying JSON Threat Protection policies to protect against external attacks.
For further reference, consult MuleSoft's documentation on API security policies and best practices for securing APIs at the Experience layer.

質問 # 66
REST API 実装のバージョン 3.0.1 は、ISO 8601 hh:mm:ss 形式を使用して PST 時間で時間値を表します。代わりに、ISO 8601 hh:mm:ss 形式を使用して CEST 時間の時間値を表すように API 実装を変更する必要があります。semver.org のセマンティックバージョニング仕様に従う場合、更新された API 実装にはどのバージョンを割り当てる必要がありますか?

A. 4.0.0
B. 3.0.2
C. 3.0.1
D. 3.1.0

正解：A

解説：
4.0.0
********************************************
semver.org のセマンティックバージョニング仕様によると:
バージョン番号 MAJOR.MINOR.PATCH を指定すると、次の値がインクリメントされます。
- 互換性のない API の変更を行った場合のメジャーバージョン。
- 下位互換性のある方法で機能を追加する場合のマイナーバージョン。
- 下位互換性のあるバグ修正を行う場合の PATCH バージョン。
質問に示されているシナリオに従って、API 実装はその動作を完全に変更しています。時刻の形式は引き続き hh:mm:ss として維持されており、スキーマ wrt 形式に変更はありませんが、時刻が完全に異なるため、API はこの変更後に異なる機能を開始します。
例: 変更前、たとえば、時刻は PST を表す 09:00:00 として進んでいます。変更後、中央ヨーロッパの夏時間は太平洋時間より 9 時間進んでいるため、同じ時刻が 18:00:00 になります。
>> これにより、API 応答の時間の処理方法によっては、API クライアントで不確実な動作が発生する可能性があります。すべての API クライアントは、API 機能が変更され、CEST 形式で返されることを通知する必要があります。したがって、これは主要な変更と見なされ、この新しい変更の API のバージョンは 4.0.0 になります。

質問 # 67
ある会社は、アプリケーションネットワークの作成を開始し、現在、Center for Enablement (C4E) 組織モデルの実装を計画しています。会社が中央集権型の C4E ではなく連合型の C4E を決定する主な要因は何ですか?

A. 開発がすでに複数の独立したイニシアチブまたはグループに編成されている場合
B. アプリケーションネットワーク内のアプリケーションの大部分がクラウドベースの場合
C. 開発チームが共有する既存の共通アセットが多数ある場合
D. API の作成を担当するさまざまなチームが統合に慣れていないため、広範なトレーニングが必要な場合

正解：A

解説：
When development is already organized into several independent initiatives or groups
*****************************************
>> It would require lot of process effort in an organization to have a single C4E team coordinating with multiple already organized development teams which are into several independent initiatives. A single C4E works well with different teams having at least a common initiative. So, in this scenario, federated C4E works well instead of centralized C4E.

質問 # 68
展示を参照してください。組織は Mule スタンドアロンランタイムを実行しており、Active Directory を Anypoint Platform 外部 ID プロバイダーとして構成しています。組織には他のシステムコンポーネントのための予算がありません。
特定の内部ユーザーグループへのアクセスを最も効果的に制限するには、組織内のすべての API インスタンスにどのようなポリシーを適用する必要がありますか?

A. IPホワイトリストポリシーを適用します。特定のユーザーのワークステーションのみがホワイトリストに追加されます。
B. OAuth 2.0アクセストークン強制ポリシーを適用します。内部Active DirectoryがOAuthサーバーとして構成されます。
C. クライアントID強制ポリシーを適用します。特定のユーザーグループは、特定のクライアント資格情報を使用するようにクライアントアプリケーションを構成します。
D. 基本認証 - LDAP ポリシーを適用します。内部 Active Directory がユーザー認証用の LDAP ソースとして構成されます。

正解：D

解説：
Apply a basic authentication - LDAP policy; the internal Active Directory will be configured as the LDAP source for authenticating users.
*****************************************
>> IP Whitelisting does NOT fit for this purpose. Moreover, the users workstations may not necessarily have static IPs in the network.
>> OAuth 2.0 enforcement requires a client provider which isn't in the organizations system components.
>> It is not an effective approach to let every user create separate client credentials and configure those for their usage.
The effective way it to apply a basic authentication - LDAP policy and the internal Active Directory will be configured as the LDAP source for authenticating users.

質問 # 69
一緒に使用すると、IT 運用モデルを効果的にするのは次のうちどれですか?

A. 再利用可能なアセットを作成する、作成したアセットを組織全体でマーケティングする、アセットが消費されているかどうかを確認するための LOB レビューを随時調整する
B. 再利用可能なアセットを作成し、LOB チームがセルフサービスで API を閲覧できるようにそれらを検出可能にし、アクティブなフィードバックと使用状況の指標を取得します
C. 再利用可能なアセットを作成し、それらを検出可能にして、LOB チームがセルフサービスで API を参照できるようにします。

正解：C

解説：
正解: 再利用可能なアセットを作成し、LOB チームがセルフサービスで API を参照できるようにそれらを検出可能にし、アクティブなフィードバックと使用状況の指標を取得します。
********************************************

質問 # 70
MuleSoft が提案する IT 運用モデルの主な利点は何ですか?

A. 1. IT デリバリーギャップを減らす
2. IT キャパシティを増やすことなく、さまざまなビジネスニーズに対応
3.資産の消費を生産速度で行う
B. 1. IT デリバリーギャップを減らす
2. IT キャパシティを増やすことなく、さまざまなビジネスニーズに対応
3. まず、再利用可能なアセットの作成に集中します。考えられるすべてのアセットの作成が完了したら、組織内の LOB にそれらの使用を開始するよう通知します。
C. 1. IT デリバリーギャップを減らす
2. IT能力の増強と多様なIT部門の形成により、多様なビジネス需要に対応
3.資産の消費を生産速度で行う

正解：A

解説：
1. IT デリバリーギャップを減らす
2. IT キャパシティを増やすことなく、さまざまなビジネスニーズに対応
3. 資産の消費を生産速度に合わせます。
********************************************
リファレンス：

質問 # 71
展示を参照してください。組織は Mule スタンドアロンランタイムを実行しており、Active Directory を Anypoint Platform 外部 ID プロバイダとして設定しています。組織には、他のシステムコンポーネントの予算がありません。

内部ユーザーの特定のグループへのアクセスを最も効果的に制限するために、組織内の API のすべてのインスタンスにどのポリシーを適用する必要がありますか?

A. 基本認証 - LDAP ポリシーを適用します。内部 Active Directory は、ユーザーを認証するための LDAP ソースとして構成されます。
B. IP ホワイトリストポリシーを適用します。特定のユーザーのワークステーションのみがホワイトリストに含まれます
C. OAuth 2.0 アクセストークンの適用ポリシーを適用します。内部 Active Directory は OAuth サーバーとして構成されます
D. クライアント ID 強制ポリシーを適用します。特定のユーザーグループが、特定のクライアント資格情報を使用するようにクライアントアプリケーションを構成します。

正解：A

質問 # 72
あるヨーロッパの企業はヨーロッパ全土に顧客を抱えており、IT 部門は古いプラットフォームから MuleSoft に移行しています。主な要件は、新しいプラットフォームではダウンタイムなしでの再展開と複数のランタイムバージョンへのアプリケーションの展開が可能であること、セキュリティと速度が提供されること、メッセージサービスとして Anypoint MQ が利用できることです。
追加のネットワーク構成なしで、要件に基づいてどのランタイムプレーンを選択する必要がありますか?

A. ランタイムプレーン用のセルフマネージドKubernetes上のAnypoint Runtime Fabric
B. 顧客ホストのランタイムプレーン
C. MuleSoft がホストするランタイムプレーン (CloudHub)
D. ランタイムプレーン用の VM / ベアメタル上のランタイムファブリック

正解：C

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

新しいプロモーションプロセス API 用に RAML 定義が提案され、Anypoint Exchange に公開されました。
プロモーション API の重要な利用者となるマーケティング部門には、満たさなければならない重要な要件と期待があります。
Anypoint Platform の機能を使用して、この初期の API 設計フェーズにマーケティング部門を関与させる最も効果的な方法は何ですか?
A) マーケティング部門に、自動生成された API コンソールを使用して API のモック実装と対話するように依頼します。

B) マーケティング IT システムのデータベーススキーマを RAML に変換する、マーケティング部門の DBA との設計ワークショップを開催する

C) Anypoint Studio を使用して API を Mule アプリケーションとして実装し、その API 実装を CloudHub にデプロイして、マーケティング部門に操作を依頼します。

D) API デザイナーから統合テストスイートをエクスポートし、マーケティング部門にテストを実行してもらい、そのスイートで合格することを確認します。

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

正解：D

解説：
正解: マーケティング部門に依頼して、自動生成された API コンソールを使用して API のモック実装を操作してもらいます。
********************************************
MuleSoft の IT 運用モデルによると:
>> API コンシューマーは、完全な API 実装の準備が整うまで待つ必要はありません。
>> API を操作するために技術的なテストスイートをエンドユーザーと共有する必要はありません。
>> Anypoint Platform は、公開されているすべての API 仕様のモック機能を Anypoint Exchange に提供します。Anypoint Exchange には、API 機能と動作の性質のすべての詳細をカバーする豊富なドキュメントも含まれます。
>> フィードバックのためにエンドユーザーとワークショップの日を設定する必要はありません。
API コンシューマーは、プラットフォームで Anypoint Exchange 機能を使用し、モック機能を使用して API と対話できます。フィードバックをすばやく共有して、変更を組み込むことができます。

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

組織は、すべての CloudHub デプロイメントに対して 1 つの特定の CloudHub (AWS) リージョンを使用します。
組織の Mule アプリケーションがアベイラビリティーゾーン (AZ) の CloudHub にデプロイされている場合、CloudHub ワーカーはどのようにアベイラビリティーゾーン (AZ) に割り当てられますか?

A. 特定の環境に属するワーカーは、そのリージョン内の同じ AZ に割り当てられます。
B. Mule アプリケーション用に AZ がランダムに選択され、Mule アプリケーションのすべての CloudHub ワーカーがその 1 つの AZ に割り当てられます。
C. ワーカーは、そのリージョン内の利用可能な AZ にランダムに分散されます
D. AZ は、Mule アプリケーションのデプロイ構成の一部として選択されます

正解：B

解説：
Workers are randomly distributed across available AZs within that region.
*****************************************
>> Currently, we only have control to choose which AWS Region to choose but there is no control at all using any configurations or deployment options to decide what Availability Zone (AZ) to assign to what worker.
>> There are NO fixed or implicit rules on platform too w.r.t assignment of AZ to workers based on environment or application.
>> They are completely assigned in random. However, cloudhub definitely ensures that HA is achieved by assigning the workers to more than on AZ so that all workers are not assigned to same AZ for same application.

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

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

正解：A

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

質問 # 76
API はクライアント ID 強制ポリシーで保護されており、デフォルトの構成を使用しています。クライアントアプリケーションから API へのアクセスが要求され、クライアントアプリケーションと API の間に承認された契約が存在します。この API の消費者は、401 エラー「クライアントアプリケーションの資格情報が不正または無効です」をどのようにして回避できますか?

A. 取得した clent_id と clent_secret をすべての呼び出しで URI パラメータとして送信します。
B. 取得したclent_idとclient_secretをすべてのAPIリクエスト呼び出しのヘッダーで送信します。
C. 取得したトークンをすべての呼び出しのヘッダーとして送信します
D. 取得したclient_idとclient_secretをリクエスト本文で送信します。

正解：A

解説：
When using the Client ID Enforcement policy with default settings, MuleSoft expects the client_id and client_secret to be provided in the URI parameters of each request. This policy is typically used to control and monitor access by validating that each request has valid credentials. Here's how to avoid a 401 Unauthorized error:
* URI Parameters Requirement:
* The default configuration for the Client ID Enforcement policy requires the client_id and client_secret to be included in each request's URI parameters. This is a straightforward way to authenticate API requests without additional configurations.
* Why Option C is Correct:
* Providing client_id and client_secret in the URI parameters meets the policy's requirements for each request, ensuring authorized access and avoiding the 401 error.
* Explanation of Incorrect Options:
* Option A (sending a token in the header) would be applicable for token-based authentication (like OAuth 2.0), not Client ID Enforcement.
* Option B (request body) and Option D (header) are not valid locations for client_id and client_secret under the default configuration of Client ID Enforcement, which expects them in the URI.
ReferencesFor more details, consult MuleSoft's documentation on Client ID Enforcement policies and expected request configurations

質問 # 77
展示品を参照してください。
3 つのビジネスプロセスを実装する必要があり、実装では複数の異なる SaaS アプリケーションと通信する必要があります。
これらのプロセスは、個別の (サイロ化された) LOB によって所有され、主に互いに独立していますが、いくつかのビジネスエンティティを共有しています。各 LOB には 1 つの開発チームと独自の予算があります。この組織のコンテキストでは、データモデルの冗長性を最小限に抑えてこれらのビジネスプロセスを実装する API の API データモデルを選択する最も効果的な方法は何ですか。
A) ビジネスプロセスの一貫した部分と関連するビジネスエンティティの定義に一致する複数の境界付きコンテキストデータモデルを構築する

B) 確立されたマイクロサービスとアジャイル API 中心のプラクティスに従うために、各 API に個別のデータモデルを構築する C) 組織全体で一貫性と再利用を促進するために、XML スキーマを使用してすべての API データモデルを構築する D) 3 つのビジネスプロセスのすべてのデータタイプを統合し、データモデルの一貫性と冗長性を確保する 1 つの集中型標準データモデル (エンタープライズデータモデル) を構築する

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

正解：A

解説：
Build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.
*****************************************
>> The options w.r.t building API data models using XML schema/ Agile API-centric practices are irrelevant to the scenario given in the question. So these two are INVALID.
>> Building EDM (Enterprise Data Model) is not feasible or right fit for this scenario as the teams and LOBs work in silo and they all have different initiatives, budget etc.. Building EDM needs intensive coordination among all the team which evidently seems not possible in this scenario.
So, the right fit for this scenario is to build several Bounded Context Data Models that align with coherent parts of the business processes and the definitions of associated business entities.

質問 # 78
大手融資会社が、データベースサーバーと Web サーバーからデータをロック解除する API を開発しました。この API は、CloudHub 1.0 上の Anypoint Virtual Private Cloud (VPC) にデプロイされています。
データベースサーバーと Web サーバーは顧客の安全なネットワーク内にあり、パブリックインターネットからはアクセスできません。データベースサーバーは顧客の AWS VPC 内にあり、Web サーバーは顧客のオンプレミスの企業データセンター内にあります。
API がデータベースサーバーおよび Web サーバーに接続できるようにアクセスを有効にするにはどうすればよいでしょうか?

A. AWS VPC との VPC ピアリングと、顧客のオンプレミス企業データセンターへの VPN トンネルを設定します。
B. AWS VPCと顧客のオンプレミス企業データセンターとのVPCピアリングを設定する
C. AWS VPC を介して顧客のオンプレミス企業データセンターへのトランジットゲートウェイをセットアップする
D. 顧客のオンプレミス企業データセンターとの VPC ピアリングと AWS VPC への VPN トンネルを設定します。

正解：A

解説：
* Scenario Overview:
* The API resides in Anypoint Virtual Private Cloud (VPC) on CloudHub 1.0, where it requires connectivity to both an AWS-hosted database server and an on-premises web server.
* Both servers are isolated from the public internet: the database server is within the customer's AWS VPC, and the web server is within the customer's on-premises corporate data center.
* Connectivity Requirements:
* To connect to the AWS database server from the API in Anypoint VPC, VPC peering is ideal.
This would allow a private network connection between the MuleSoft Anypoint VPC and the customer's AWS VPC, enabling secure, direct access to the database.
* To connect to the on-premises web server, a VPN tunnel is suitable. This would establish a secure, encrypted connection from the Anypoint VPC to the customer's corporate data center, allowing secure data flow between the API and the on-premises web server.
* Analysis of Options:
* Option A (Correct Answer): Setting up VPC peering with AWS VPC enables private network connectivity with the database server, while a VPN tunnel to the on-premises data center allows secure access to the web server. This combination meets the requirements for secure, controlled access to both resources.
* Option B: VPC peering alone would not suffice because it does not support a connection from the Anypoint VPC directly to an on-premises network. A VPN is necessary for on-premises access.
* Option C: Setting up a transit gateway would provide connectivity within AWS but would not enable direct connectivity from CloudHub to the on-premises network.
* Option D: VPC peering with the on-premises network is not possible because VPC peering is typically used to connect two VPCs, not a VPC with an on-premises network.
* Conclusion:
* Option A is the correct choice, as it provides a complete solution by using VPC peering for AWS VPC connectivity and a VPN tunnel for secure on-premises connectivity. This setup aligns with Anypoint Platform best practices for connecting Anypoint VPCs to both AWS-hosted and on- premises systems, ensuring secure, controlled access to both the database and web server.
For more detailed reference, MuleSoft documentation on Anypoint VPC peering and VPN connectivity provides additional context on best practices for setting up these connections within a hybrid network infrastructure.

質問 # 79
......

MCPA-Level-1日本語別格な問題集で最上級の成績にさせるMCPA-Level-1日本語問題：https://www.goshiken.com/MuleSoft/MCPA-Level-1-JPN-mondaishu.html

関するブログ

もっと

MCPA-Level-1-JPN無料問題集