最新MCPA-Level-1日本語テスト材料には有効なMCPA-Level-1日本語テストエンジン [Q29-Q54]

最新MCPA-Level-1日本語テスト材料には有効なMCPA-Level-1日本語テストエンジン

MCPA-Level-1日本語更新された試験問題集で[2025年最新] 練習には有効な試験問題集

質問 # 29
API 主導の接続のどのレイヤーが、主要なシステム、レガシーシステム、データソースなどのロックを解除し、機能を公開することに重点を置いていますか?

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

正解：A

解説：
システムレイヤー

接続に対する API 主導のアプローチで使用される API は、次の 3 つのカテゴリに分類されます。
システム API - これらは通常、基幹システムオブレコードにアクセスし、基盤となるシステムの複雑さや変更からユーザーを隔離する手段を提供します。構築すると、多くのユーザーが基盤となるシステムを学習する必要なくデータにアクセスでき、これらの API を複数のプロジェクトで再利用できます。
プロセス API - これらの API は、単一システム内またはシステム間でデータとやり取りしてデータを形成し (データサイロを打破)、そのデータが発生するソースシステムや、そのデータが通過するターゲットチャネルに依存することなくここで作成されます。配信されます。
エクスペリエンス API - エクスペリエンス API は、チャネルごとに個別のポイントツーポイント統合を設定するのではなく、すべて共通のデータソースから、対象とする対象者が最も簡単に消費できるようにデータを再構成できる手段です。通常、エクスペリエンス API は、API が特定のユーザーエクスペリエンスを念頭に置いて設計されている API ファーストの設計原則に基づいて作成されます。

質問 # 30
Anypoint Platform Private Cloud Edition または Anypoint Platform for Pivotal Cloud Foundry を使用する必要がある Mule アプリケーションの展開シナリオはどれですか?

A. すべての API を非公開にし、パブリッククラウドに公開しないことが必要な場合
B. 規制要件により、メタデータを含むすべてのデータ項目のオンプレミス処理が義務付けられている場合
C. アプリケーションネットワーク内のすべてのバックエンドシステムが組織のイントラネットに展開されている場合
D. 複数のデータセンターですべてのアプリケーションを高可用性にする必要がある場合

正解：B

解説：
When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data.
*****************************************
We need NOT require to use Anypoint Platform PCE or PCF for the below. So these options are OUT.
>> We can make ALL applications highly available across multiple data centers using CloudHub too.
>> We can use Anypoint VPN and tunneling from CloudHub to connect to ALL backend systems in the application network that are deployed in the organization's intranet.
>> We can use Anypoint VPC and Firewall Rules to make ALL APIs private and NOT exposed to the public cloud.
Only valid reason in the given options that requires to use Anypoint Platform PCE/ PCF is - When regulatory requirements mandate on-premises processing of EVERY data item, including meta-data.

質問 # 31
レート制限 API ポリシーの適用を、API の RAML 定義に正確に反映するにはどうすればよいですか?

A. 説明、タイプ、および例を含む x-ratelimit-* 応答ヘッダーを追加して、応答定義を改良します。
B. すぐに使用できる Anypoint Platform rate-limit-enforcement securityScheme を説明、タイプ、および例とともに追加して、応答定義を改良することによって
C. レート制限ポリシーの動作の説明を追加してリソース定義を改良することによって
D. 説明、タイプ、および例を含む残りの Requests クエリパラメータを追加して、リクエスト定義を改良することによって

正解：A

解説：
正解: 説明、タイプ、および例を含む x-ratelimit-* 応答ヘッダーを追加して、応答定義を改良することによって
********************************************

参考文献:
https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling#response-headers
https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies#response-headers

質問 # 32
消費者の携帯電話またはタブレットアプリケーションで動作することを目的としたエクスペリエンス API を設計する際に、最も使用される可能性が低い API ポリシーはどれですか?

A. OAuth 2.0 アクセストークンの適用
B. JSON 脅威保護
C. クライアント ID の強制
D. IPwhitellst

正解：D

解説：
IP ホワイトリスト
********************************************
>> OAuth 2.0 アクセストークンとクライアント ID の適用ポリシーは、エクスペリエンス API に適用されるのが非常に一般的
>> JSON の脅威保護は、Experience API に適用する非常に一般的なポリシーでもあり、悪質または疑わしいペイロードが API 実装にヒットするのを防ぎます。
>> IP ホワイトリストポリシーは通常、ローカル VPC 内の IP 範囲のみをホワイトリストに登録するプロセス API とシステム API で非常に一般的です。ただし、エンドユーザー/API コンシューマーが固定されている一部のエクスペリエンス API にも時折適用されます。
>> 特定のエクスペリエンス API にアクセスしようとしている API コンシューマーを前もって知っている場合、そのようなコンシューマーに静的 IP を要求し、それらをホワイトリストに登録して、他の誰かが API にアクセスするのを防ぐことができます。
ただし、質問/シナリオで提供されているエクスペリエンス API は、コンシューマの携帯電話またはタブレットアプリケーションで動作することを目的としています。つまり、携帯電話やタブレットの数は非常に多く、都市/州/国/地球上の任意のデバイスであるため、ホワイトリストに登録される可能性のあるすべての IP を知る方法はありません。
そのため、消費者が通常携帯電話やタブレットであるエクスペリエンス API に IP ホワイトリストを適用する可能性はほとんどありません。

質問 # 33
ある企業が API 主導のデジタル変革に乗り出しており、中央 IT チームがシステム API の定義を開始しました。現在、企業内でエンタープライズデータモデルは定義されておらず、明確な境界付きコンテキストデータモデルの定義には多大な労力が必要です。
MuleSoft の推奨ガイドラインによれば、システム API データモデルはどのように定義する必要がありますか?

A. システムAPIのデータモデルは、バックエンドシステムのデータタイプをほぼ反映したデータタイプを使用する必要があります。
B. データモデルは独自の命名規則を定義する必要があり、バックエンドシステムと同じ命名規則に従うべきではない。
C. バックエンドシステムのデータフィールドにスペルミスがある場合、Systerm API はそれを修正せず、そのまま公開してバックエンドシステムをミラーリングする必要があります。
D. システムAPIはすべてのバックエンドシステムフィールドを公開する必要がある

正解：A

解説：
When defining data models for System APIs without an established Enterprise Data Model, MuleSoft recommends mirroring the back-end systems' data types to achieve quick and effective integration without adding complexity. This approach has several benefits:
* Alignment with Backend Systems:
* Mirroring data types ensures consistency with backend data sources, which simplifies integration, reduces mapping requirements, and minimizes potential data transformation issues.
* Flexibility for Future Enhancements:
* By retaining close alignment with backend data structures, System APIs can evolve to support an Enterprise Data Model in the future without immediate restructuring.
* Explanation of Incorrect Options:
* Option A (exposing misspellings) is not recommended as System APIs should still ensure a professional and coherent interface.
* Option C (custom naming) complicates the API structure without adding immediate value in the absence of a clear data model.
* Option D (exposing all fields) is unnecessary and can reduce performance and add complexity.
ReferencesRefer to MuleSoft best practices for data modeling in System APIs for additional information on mirroring backend systems.

質問 # 34
Mule アプリケーションは HTTPS エンドポイントを公開し、静的 IP アドレスを使用しない 3 つの CloudHub ワーカーにデプロイされます。Mule アプリケーションは、短期間に大量のクライアント要求を予期します。大量のクライアントリクエストに対応するために使用する必要がある、最も費用対効果の高いインフラストラクチャコンポーネントはどれですか?

A. CloudHub 共有ロードバランサー
B. お客様がホストするロードバランサー
C. API プロキシ
D. ランタイムマネージャーの自動スケーリング

正解：A

解説：
The CloudHub shared load balancer
*****************************************
The scenario in this question can be split as below:
>> There are 3 CloudHub workers (So, there are already good number of workers to handle high volume of requests)
>> The workers are not using static IP addresses (So, one CANNOT use customer load-balancing solutions without static IPs)
>> Looking for most cost-effective component to load balance the client requests among the workers.
Based on the above details given in the scenario:
>> Runtime autoscaling is NOT at all cost-effective as it incurs extra cost. Most over, there are already 3 workers running which is a good number.
>> We cannot go for a customer-hosted load balancer as it is also NOT most cost-effective (needs custom load balancer to maintain and licensing) and same time the Mule App is not having Static IP Addresses which limits from going with custom load balancing.
>> An API Proxy is irrelevant there as it has no role to play w.r.t handling high volumes or load balancing.
So, the only right option to go with and fits the purpose of scenario being most cost-effective is - using a CloudHub Shared Load Balancer.

質問 # 35
Anypoint Platform REST API、Anypoint CU、Mule Maven プラグインなどのツールを使用した Anypoint Platform との対話の自動化について正しいのはどれですか?

A. デフォルトでは、Anypoint CLI と Mule Maven プラグインは Mule ランタイムに含まれていないため、デプロイされた Mule アプリケーションでは使用できません。
B. Anypoint Platform API と Anypoint CU へのアクセスは、Anypoint Platform のロールと権限によって個別に制御できるため、特定のユーザーは Anypoint CLI にアクセスでき、他のユーザーはプラットフォーム API にアクセスできます。
C. Anypoint Platform API は CloudHub との対話のみを自動化できますが、顧客がホストする Mule ランタイムへのデプロイには Mule Maven プラグインが必要です。
D. API ポリシーを Anypoint Platform API に適用して、特定の LOB のみが特定の機能にアクセスできるようにすることができます。

正解：A

解説：
正解: デフォルトでは、Anypoint CLI と Mule Maven プラグインは Mule ランタイムに含まれていないため、デプロイされた Mule アプリケーションでは使用できません。
********************************************
>> カスタムで記述された API インスタンスに適用できるように、Anypoint Platform API に API ポリシーを適用することはできません。したがって、これを示唆するオプションは FALSE です。
>> Anypoint Platform API を使用して、CloudHub と顧客がホストする Mule ランタイムの両方とのやり取りを自動化できます。CloudHubだけではありません。したがって、これに反対するオプションは FALSE です。
>> Mule Maven プラグインは、顧客がホストする Mule ランタイムへのデプロイには必須ではありません。CI/CD の自動化がスムーズになるだけです。ただし、デプロイの必須要件ではありません。したがって、これに反対するオプションは FALSE です。
>> 一部のユーザーが Anypoint CLI を使用するためのアクセスと他のユーザーが Anypoint Platform API を使用するためのアクセスを個別に制御するための、プラットフォーム上でのそのような特別な役割と権限はありません。適切な一般的な役割/権限 (API 所有者、Cloudhub 管理者など) があれば、任意のオプション (Anypoint CLI またはプラットフォーム API) を使用できます。したがって、これを示唆するオプションは FALSE です。
選択肢で指定された TRUE ステートメントのみが、Anypoint CLI と Mule Maven プラグインは Mule ランタイムに含まれていないため、デプロイされた Mule アプリケーションで使用できません。
Maven は Studio の一部であるか、開発用に他の Maven インストールを使用できます。
CLI は便利なだけです。アプリをランタイムにインストールする多くの方法の 1 つです。
これらは、展開または自動化のプロセス以外の一部ではありません。

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

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

正解：B

解説：
Create reusable assets, Make them discoverable so that LOB teams can self-serve and browse the APIs, Get active feedback and usage metrics.
*****************************************
Diagram, arrow Description automatically generated

質問 # 37
4 実稼働環境は CloudHub 1.0 上の専用の仮想プライベートクラウド (VPC) 上で実行されており、セキュリティチームのガイドラインでは HTTP トラフィックは禁止されていることが明記されています。
これらのセキュリティガイドラインをサポートする 2 つのオプションはどれですか?
2つの回答を選択してください

A. Mule アプリケーションの HTTP リスナーで HTTPS プロトコルを構成する
B. 設定されたAPIエンドポイントへのアクセスを制御するために、送信および受信HTTPリクエストに適用するカスタムポリシーを作成します。
C. VPC ファイアウォールルールにエントリを追加します。
D. VPCファイアウォールルールからエントリを削除します
E. IP ブロックリストポリシーを構成して、単一の IP アドレスまたは IP アドレスの範囲から構成された API エンドポイントへのアクセスを制御します。

正解：A、D

解説：
* Security Guidelines Overview:
* The production environment is hosted on a dedicated Virtual Private Cloud (VPC) on CloudHub
1.0, with a specific requirement from the security team that no traffic should occur over HTTP.
This implies that only secure HTTPS traffic should be permitted, and HTTP access (port 8081, the default HTTP port in Mule applications) should be disabled.
* Evaluating the Options:
* Option A (Correct Answer): Configuring the HTTPS protocol in the HTTP listener in the Mule application ensures that all traffic is encrypted and occurs over HTTPS (port 8092 by default for HTTPS on Mule applications). This directly aligns with the security guideline to prevent unencrypted HTTP traffic.
* Option B: Creating a custom policy for incoming and outgoing HTTP requests could provide some control over access, but it does not enforce the use of HTTPS exclusively. This option does not disable HTTP traffic and, therefore, does not meet the guideline effectively.
* Option C (Correct Answer): Removing the entry for HTTP (port 8081) in the VPC firewall rule ensures that HTTP traffic is completely blocked at the firewall level. This prevents any HTTP requests from reaching the application, adding a layer of security that complies with the guidelines.
* Option D: The IP Blocklist policy controls access based on IP addresses but does not enforce the use of HTTPS. This policy does not address the specific requirement of preventing HTTP traffic.
* Option E: Adding a firewall rule entry for HTTP (port 8081) would enable HTTP traffic, which directly contradicts the security guidelines. Therefore, this option should be avoided.
* Conclusion:
* Option A and Option C are the correct choices. Configuring the HTTPS protocol in the Mule application's HTTP listener ensures that only HTTPS traffic is allowed, and removing the firewall rule for HTTP (port 8081) blocks any HTTP traffic from reaching the application.
Together, these options enforce secure traffic as required by the security guidelines.
Refer to MuleSoft documentation on configuring HTTP listeners and managing VPC firewall rules for further details on implementing these security controls.

質問 # 38
ダウンタイムが繰り返し発生することが知られている Order API を呼び出す必要がある API 実装が設計されています。
このため、Order API が使用できない場合は、フォールバック API が呼び出されます。
フォールバック API の呼び出しを設計するためのどのアプローチが、最高の回復力を提供しますか?

A. HTTP 4xx または 5xx 応答ステータスコードが Order API から返されるたびに、Order API を呼び出す代わりにフォールバック API を呼び出すオプションを HTTP リクエスターコンポーネントに設定します。
B. Order API が使用できない場合は常に、HTTP 307 一時リダイレクトステータスコードを介してクライアントリクエストをフォールバック API にリダイレクトします。
C. API Manager で注文 API 用に別のエントリを作成し、プライマリ注文 API が使用できない場合に、この API をフォールバック API として呼び出します。
D. Anypoint Exchange で適切な既存のフォールバック API を検索し、Order API に加えてこのフォールバック API への呼び出しを実装します。

正解：D

解説：
Search Anypoint exchange for a suitable existing fallback API, and then implement invocations to this fallback API in addition to the order API
*****************************************
>> It is not ideal and good approach, until unless there is a pre-approved agreement with the API clients that they will receive a HTTP 3xx temporary redirect status code and they have to implement fallback logic their side to call another API.
>> Creating separate entry of same Order API in API manager would just create an another instance of it on top of same API implementation. So, it does NO GOOD by using clone od same API as a fallback API.
Fallback API should be ideally a different API implementation that is not same as primary one.
>> There is NO option currently provided by Anypoint HTTP Connector that allows us to invoke a fallback API when we receive certain HTTP status codes in response.
The only statement TRUE in the given options is to Search Anypoint exchange for a suitable existing fallback API, and then implement invocations to this fallback API in addition to the order API.

質問 # 39
組織は、さまざまなクラウドベースの 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 コントロールプレーンによって管理される、クラウドハブでデプロイされ、手動でプロビジョニングされたオンプレミスの Mule ランタイムの組み合わせを使用する

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

正解：B

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

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

A. API ポリシーは、Mule ランタイムへの API デプロイメントの一部として Runtime Manager で定義され、特定の API インスタンスにのみ適用されます。
B. API ポリシーは、特定の API インスタンスに対して API Manager で定義され、特定の API インスタンスにのみ適用されます。
C. API ポリシーは API 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 インスタンスにのみ適用されます」です。

質問 # 41
Order API は、大量の統合ロジックを含み、Product API の呼び出しを伴うように設計する必要があります。
Order API と Product API の間の力関係は、「顧客/サプライヤー」の関係の 1 つです。なぜなら、Product API は組織全体で頻繁に使用され、CTO のオフィスにいる専任の開発チームによって開発されるからです。
Order API 内で Product API の API データモデルを処理するには、どのような戦略を使用する必要がありますか?

A. Order API に、製品 API データモデルを Order API の内部データ型に変換する腐敗防止レイヤーを実装します。
B. 製品 API と注文 API の両方で使用されるエンタープライズデータモデルをもたらす、組織全体のデータモデリングイニシアチブを開始します。
C. 注文 API が製品 API と同じ (変更されていない) データ型を使用するように、注文 API の統合ロジックを実装するときに、製品 API の API データ型を直接操作します。
D. Order API の統合ロジックが 1 つの一貫した内部データモデルで動作できるように、Order API の API データモデルを採用するよう、Product API の開発チームを説得します。

正解：A

解説：
Convince the development team of the product API to adopt the API data model of the Order API such that integration logic of the Order API can work with one consistent internal data model
*****************************************
Key details to note from the given scenario:
>> Power relationship between Order API and Product API is customer/supplier So, as per below rules of "Power Relationships", the caller (in this case Order API) would request for features to the called (Product API team) and the Product API team would need to accomodate those requests.

質問 # 42
顧客は MuleSoft と ELA 契約を結んでいます。CloudHub にデプロイされた API でパフォーマンスの問題が発生し続けています。根本原因分析の結果、自動スケーリングを適用する必要があることが判明しました。
これを実現するにはどうすればよいでしょうか?

A. HTTP リクエストの数が一定のしきい値に達するとワーカー/レプリカの数が増えるようにポリシーを構成する (水平スケーリング)
B. CPU 使用率に基づいてポリシーを設定し、CloudHub がワーカー/レプリカの数を自動調整するようにします (水平スケーリング)
C. 応答時間が特定のしきい値に達するとワーカー/レプリカの種類が増加するようにポリシーを構成する (垂直スケーリング)
D. 2つの別々のポリシーを設定します。CPUとメモリが特定のしきい値に達すると、ワーカーを増やします。
/レプリカタイプ（垂直シール）とワーカー/レプリカの数（水平シール）

正解：B

解説：
In MuleSoft CloudHub, autoscaling is essential to managing application load efficiently. CloudHub supports horizontal scaling based on CPU usage, which is well-suited to applications experiencing variable demand and needing responsive resource allocation.
* Autoscaling on CloudHub:
* Horizontal scaling increases the number of workers in response to CPU usage thresholds, allowing the application to handle higher loads dynamically. This approach improves performance without downtime or manual intervention.
* Why Option C is Correct:
* Setting up autoscaling based on CPU usage aligns with MuleSoft's best practices for scalable and responsive applications on CloudHub, particularly in an environment with fluctuating load patterns.
* Option C correctly leverages CloudHub's autoscaling features based on resource metrics, which are part of CloudHub's managed scaling solutions.
* Explanation of Incorrect Options:
* Option A (based on HTTP request thresholds) and Option B (separate policies for CPU and memory) do not represent CloudHub's recommended scaling practices.
* Option D suggests vertical scaling based on response time, which is not how CloudHub handles autoscaling.
ReferencesFor more on CloudHub's autoscaling configuration, refer to MuleSoft documentation on CloudHub autoscaling policies.

質問 # 43
Anypoint Platform REST API、Anypoint CU、Mule Maven プラグインなどのツールを使用した Anypoint Platform との対話の自動化について正しいのはどれですか?

A. デフォルトでは、Anypoint CLI と Mule Maven プラグインは Mule ランタイムに含まれていないため、デプロイされた Mule アプリケーションでは使用できません。
B. Anypoint Platform API と Anypoint CU へのアクセスは、Anypoint Platform のロールと権限によって個別に制御できるため、特定のユーザーは Anypoint CLI にアクセスでき、他のユーザーはプラットフォーム API にアクセスできます。
C. Anypoint Platform API は CloudHub との対話のみを自動化できますが、顧客がホストする Mule ランタイムへのデプロイには Mule Maven プラグインが必要です。
D. API ポリシーを Anypoint Platform API に適用して、特定の LOB のみが特定の機能にアクセスできるようにすることができます。

正解：A

解説：
By default, the Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications
*****************************************
>> We CANNOT apply API policies to the Anypoint Platform APIs like we can do on our custom written API instances. So, option suggesting this is FALSE.
>> Anypoint Platform APIs can be used for automating interactions with both CloudHub and customer-hosted Mule runtimes. Not JUST the CloudHub. So, option opposing this is FALSE.
>> Mule Maven plugin is NOT mandatory for deployment to customer-hosted Mule runtimes. It just helps your CI/CD to have smoother automation. But not a compulsory requirement to deploy. So, option opposing this is FALSE.
>> We DO NOT have any such special roles and permissions on the platform to separately control access for some users to have Anypoint CLI and others to have Anypoint Platform APIs. With proper general roles
/permissions (API Owner, Cloudhub Admin etc..), one can use any of the options (Anypoint CLI or Platform APIs). So, option suggesting this is FALSE.
Only TRUE statement given in the choices is that - Anypoint CLI and Mule Maven plugin are NOT included in the Mule runtime, so are NOT available to be used by deployed Mule applications.
Maven is part of Studio or you can use other Maven installation for development.
CLI is convenience only. It is one of many ways how to install app to the runtime.
These are definitely NOT part of anything except your process of deployment or automation.

質問 # 44
CloudHub Dedicated Load Balancer を使用する必要があるのはどのような条件ですか?

A. 同じ Mule アプリケーションの個別のデプロイ間でリージョン間の負荷分散が必要な場合
B. 顧客がホストする Mule ランタイムにデプロイされた API 実装にカスタム DNS 名が必要な場合
C. API 実装と API クライアント間でサーバー側の負荷分散 TLS 相互認証が必要な場合
D. 複数の CloudHub ワーカーにまたがる API 呼び出しの負荷を分散する必要がある場合

正解：C

解説：
API実装とAPIクライアント間でサーバー側負荷分散TLS相互認証が必要な場合
********************************************
事実/記憶のヒント: CloudHub Dedicated Load Balancer には多くの利点がありますが、それを検討する際に心に留めておくべき重要な点が 2 つあります。
>> CloudHub でデプロイされたアプリにカスタム DNS 名を持つ URL エンドポイントを持つ
>> HTTPS と双方向 (相互) 認証の両方のカスタム証明書を構成します。
これに提供されるオプションに来る
>>私たちは
DLB を使用して、同じ Mule アプリケーションの個別のデプロイメント間でリージョン間の負荷分散を実行することはできません。
>> 同じ Mule アプリを指す複数の DLB URL を持つマッピングルールを設定できます。ただし、その逆 (同じ DLB URL を持つ複数の Mule アプリ) は不可能です。
>> DLB が Cloudhub でデプロイされた Mule アプリのカスタム DNS 名をセットアップするのに役立つことは事実ですが、顧客がホストする Mule ランタイムにデプロイされたアプリには当てはまりません。
>> DLB を使用して複数の CloudHub ワーカー間で API 呼び出しの負荷を分散できることは事実ですが、必須ではありません。SLB (Shared Load Balancer) を使用しても同じ (負荷分散) を実現できます。それを達成するために必ずしもDLBを必要とするわけではありません。
したがって、シナリオに適合し、DLB を使用する必要がある唯一の適切なオプションは、API 実装と API クライアントの間で TLS 相互認証が必要な場合です。

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

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

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

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

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

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

正解：B

解説：
正解: システム 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 に何度も触れる必要はありません。

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

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

正解：A

解説：
When a pragmatic approach with only limited isolation from the backend system is deemed appropriate.
*****************************************
General guidance w.r.t choosing Data Models:
>> If an Enterprise Data Model is in use then the API data model of System APIs should make use of data types from that Enterprise Data Model and the corresponding API implementation should translate between these data types from the Enterprise Data Model and the native data model of the backend system.
>> If no Enterprise Data Model is in use then each System API should be assigned to a Bounded Context, the API data model of System APIs should make use of data types from the corresponding Bounded Context Data Model and the corresponding API implementation should translate between these data types from the Bounded Context Data Model and the native data model of the backend system. In this scenario, the data types in the Bounded Context Data Model are defined purely in terms of their business characteristics and are typically not related to the native data model of the backend system. In other words, the translation effort may be significant.
>> If no Enterprise Data Model is in use, and the definition of a clean Bounded Context Data Model is considered too much effort, then the API data model of System APIs should make use of data types that approximately mirror those from the backend system, same semantics and naming as backend system, lightly sanitized, expose all fields needed for the given System API's functionality, but not significantly more and making good use of REST conventions.
The latter approach, i.e., exposing in System APIs an API data model that basically mirrors that of the backend system, does not provide satisfactory isolation from backend systems through the System API tier on its own. In particular, it will typically not be possible to "swap out" a backend system without significantly changing all System APIs in front of that backend system and therefore the API implementations of all Process APIs that depend on those System APIs! This is so because it is not desirable to prolong the life of a previous backend system's data model in the form of the API data model of System APIs that now front a new backend system. The API data models of System APIs following this approach must therefore change when the backend system is replaced.
On the other hand:
>> It is a very pragmatic approach that adds comparatively little overhead over accessing the backend system directly
>> Isolates API clients from intricacies of the backend system outside the data model (protocol, authentication, connection pooling, network address, ...)
>> Allows the usual API policies to be applied to System APIs
>> Makes the API data model for interacting with the backend system explicit and visible, by exposing it in the RAML definitions of the System APIs
>> Further isolation from the backend system data model does occur in the API implementations of the Process API tier

質問 # 47
一般的な Enablement Center の成功を測定し、Anypoint Platform API からの応答ですぐに利用できる、すぐに使用できる主要業績評価指標はどれですか。

A. 展開されたAPI実装ごとに、1日あたりに消費される帯域幅の量
B. 公開されたAPIごとに、API仕様のバージョンをダウンロードした開発者の数
C. 公開された API ごとに、API へのアクセスを要求し、本番環境で承認されたコンシューマーの数
D. ビジネスグループごとに、C1を使用して導入された本番APT実装の数の割合
/CDパイプラインから手動でデプロイされた本番API実装の数まで

正解：C

解説：
* Center for Enablement (C4E) KPIs:
* A Center for Enablement (C4E) in MuleSoft focuses on enabling self-service and reuse by providing APIs that can be consumed across the organization. A key metric of success is how many consumers are utilizing the published APIs.
* The number of consumers who have requested and received access to an API indicates the level of adoption and reuse, which aligns with the goals of a C4E.
* Evaluating the Options:
* Option A: This metric could indicate deployment automation, but it is not a direct measure of C4E's success in enabling API reuse and consumption.
* Option B: Bandwidth usage per API implementation provides insight into API traffic but does not measure C4E enablement or consumer engagement.
* Option C: The number of developers downloading an API specification can be an indicator of interest but does not confirm actual usage or enablement.
* Option D (Correct Answer): The number of consumers who have requested and received access to an API in production is a key metric indicating API adoption and reuse, which aligns with C4E's goals.
* Conclusion:
* Option D is the correct answer as it provides a direct measure of consumer engagement and adoption, indicating the success of the C4E in promoting API usage across the organization.
Refer to MuleSoft's documentation on C4E KPIs and API usage metrics for additional insights.

質問 # 48
新しいアップストリーム API は、中央値 500 ミリ秒、最大 800 ミリ秒 (99 パーセンタイル) の応答時間の SLA を提供するように設計されています。対応する API 実装は、非常に類似した複雑さの 3 つのダウンストリーム API を順番に呼び出す必要があります。
これらのダウンストリーム API の最初のものは、応答時間について次の SLA を提供します: 中央値: 100 ミリ秒、80 パーセンタイル: 500 ミリ秒、95 パーセンタイル: 1000 ミリ秒。
可能であれば、新しいアップストリーム API の望ましい SLA を満たすために、最初のダウンストリーム API の呼び出しに対してアップストリーム API でタイムアウトを設定するにはどうすればよいですか?

A. アップストリーム API の望ましい SLA を満たすためのタイムアウトはありません。別の SLA を最初のダウンストリーム API とネゴシエートするか、別の API を呼び出す必要があります
B. タイムアウトを設定しません。この API の呼び出しは必須であるため、応答するまで待つ必要があります
C. タイムアウトを 50 ミリ秒に設定します。これにより、その API のより多くの呼び出しがタイムアウトになりますが、再試行のための追加の余地が与えられます
D. 100 ミリ秒のタイムアウトを設定します。他の 2 つのダウンストリーム API が完了するまでに 400 ミリ秒かかります

正解：D

解説：
Set a timeout of 100ms; that leaves 400ms for other two downstream APIs to complete
*****************************************
Key details to take from the given scenario:
>> Upstream API's designed SLA is 500ms (median). Lets ignore maximum SLA response times.
>> This API calls 3 downstream APIs sequentially and all these are of similar complexity.
>> The first downstream API is offering median SLA of 100ms, 80th percentile: 500ms; 95th percentile:
1000ms.
Based on the above details:
>> We can rule out the option which is suggesting to set 50ms timeout. Because, if the median SLA itself being offered is 100ms then most of the calls are going to timeout and time gets wasted in retried them and eventually gets exhausted with all retries. Even if some retries gets successful, the remaining time wont leave enough room for 2nd and 3rd downstream APIs to respond within time.
>> The option suggesting to NOT set a timeout as the invocation of this API is mandatory and so we must wait until it responds is silly. As not setting time out would go against the good implementation pattern and moreover if the first API is not responding within its offered median SLA 100ms then most probably it would either respond in 500ms (80th percentile) or 1000ms (95th percentile). In BOTH cases, getting a successful response from 1st downstream API does NO GOOD because already by this time the Upstream API SLA of
500 ms is breached. There is no time left to call 2nd and 3rd downstream APIs.
>> It is NOT true that no timeout is possible to meet the upstream APIs desired SLA.
As 1st downstream API is offering its median SLA of 100ms, it means MOST of the time we would get the responses within that time. So, setting a timeout of 100ms would be ideal for MOST calls as it leaves enough room of 400ms for remaining 2 downstream API calls.

質問 # 49
次の順序のうち、正しいものはどれですか?

A. API クライアントは API を呼び出すロジックを実装します >> API コンシューマは API へのアクセスを要求します >> API 実装は要求を >> API にルーティングします
B. API クライアントは API を呼び出すロジックを実装します >> API コンシューマは API へのアクセスを要求します >> API は要求をルーティングします >> API 実装
C. API コンシューマが API へのアクセスをリクエスト >> API クライアントが API を呼び出すロジックを実装 >> API がリクエストをルーティング >> API 実装
D. API コンシューマが API を呼び出すロジックを実装 >> API クライアントが API へのアクセスをリクエスト >> API 実装がリクエストを >> API にルーティング

正解：C

解説：
正解: API コンシューマーが API へのアクセスを要求する >> API クライアントが API を呼び出すロジックを実装する >> API が要求をルーティングする >> API 実装
********************************************
>> API コンシューマは、API を呼び出すロジックを実装していません。それはただの役割です。したがって、「API コンシューマーは API を呼び出すロジックを実装する」というオプションは無効です。
>> API 実装はリクエストをルーティングしません。これは、ターゲットシステムの機能が公開される最後のロジックです。そのため、リクエストは他のエンティティによって API 実装にルーティングされる必要があります。したがって、「API 実装が要求を >> API にルーティングする」というオプションは無効です
>> 選択肢の 1 つのステートメントは正しいですが、順序が間違っています。シーケンスは、「API クライアントが API を呼び出すロジックを実装する >> API コンシューマが API へのアクセスを要求する >> API が要求をルーティングする >> API 実装」として与えられます。ここでは、オプションのステートメントは有効ですが、順序が間違っています。
>> 正しいオプションとシーケンスは、API コンシューマーが最初に Anypoint Exchange 上の API へのアクセスを要求し、クライアント資格情報を取得するものです。次に、API クライアントは、API コンシューマーによって要求されたアクセスクライアント資格情報を使用して API を呼び出すロジックを記述します。要求は、API Manager によって管理される API を介して API 実装にルーティングされます。

質問 # 50
API 実装をステージング環境にデプロイする前に、一連のテストを実行する必要があります。データセキュリティとアクセス制限により、テストされていない API にバックエンドシステムへのアクセスを許可することはできないため、これらのテストにはモックデータを使用する必要があります。利用可能なモックデータとそのコンテンツの量は、バックエンドシステムへのアクティブな接続なしで API 実装を完全にテストするのに十分です。この模擬データを組み込むには、どのような種類のテストを使用する必要がありますか?

A. 機能テスト (ブラックボックス)
B. 性能試験
C. 単体テスト (ホワイトボックス)
D. 統合テスト

正解：C

解説：
ユニットテスト（ホワイトボックス）
********************************************
リファレンス：
一般的な IT テストのプラクティスと MuleSoft の推奨プラクティスに従って、統合とパフォーマンスのテストは、適切な評価のために完全なエンドツーエンドのセットアップで実行する必要があります。これは、テストの実行中にすべてのエンドシステムを接続する必要があることを意味します。したがって、これらのオプションは終了し、単体テストと機能テストが残ります。
MuleSoft からの添付の参照ドキュメントによると:
単体テスト - Mule 自体の内部で実行する必要なく、現実的に実行できるコードに限定されます。良い候補は、小さなモジュラーコード、サブフロー、カスタムトランスフォーマー、カスタムコンポーネント、カスタム式エバリュエーターなどです。
機能テスト - アプリケーション構成を最も広範囲にテストします。これらのテストでは、幸せな道と不幸な道をシミュレートするための自由とツールがあります。また、ターゲットサービスのスタブを作成し、それらを成功または失敗させて、それぞれハッピーパスとアンハッピーパスを簡単にシミュレートすることもできます。
質問のシナリオでは、ステージングへの展開前に API 実装をテストする必要があり、バックエンドシステムへのアクティブな接続なしで API 実装のさまざまなコンポーネントをテストするのに十分な/十分な量のモックデータがあることも明確に示しているため、単体テストこのモック化されたデータを組み込むために使用されるものです。

質問 # 51
パブリック Anypoint Exchange ポータルを介して API を共有する前に、何を確認する必要がありますか?

A. 一般公開する必要がある API の API インスタンスの可視性レベルは、公開可視性に設定する必要があります。
B. API は、少なくとも初期実装がデプロイされ、ユーザーが操作できるようにアクセスできるようにする必要があります。
C. API へのアクセスが必要なユーザーは、Anypoint Platform の適切なロールに追加する必要があります。
D. サポートされている認証/承認メカニズムのいずれかを使用して API を保護し、データが侵害されないようにする必要があります。

正解：A

解説：

正解: 一般公開する必要がある API の API インスタンスの可視性レベルは、公開可視性に設定する必要があります。
********************************************
リファレンス：
https://docs.mulesoft.com/exchange/to-share-api-asset-to-portal

質問 # 52
API 実装をステージング環境にデプロイする前に、一連のテストを実行する必要があります。データセキュリティとアクセス制限により、テストされていない API にバックエンドシステムへのアクセスを許可することはできないため、これらのテストにはモックデータを使用する必要があります。利用可能なモックデータとそのコンテンツの量は、バックエンドシステムへのアクティブな接続なしで API 実装を完全にテストするのに十分です。この模擬データを組み込むには、どのような種類のテストを使用する必要がありますか?

A. 機能テスト (ブラックボックス)
B. 性能試験
C. 単体テスト (ホワイトボックス)
D. 統合テスト

正解：C

解説：
Unit tests (Whitebox)
*****************************************

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

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

正解：B

解説：
The API policy is defined in API Manager for a specific API instance, and then ONLY applied to the specific API instance.
*****************************************
>> Once our API specifications are ready and published to Exchange, we need to visit API Manager and register an API instance for each API.
>> API Manager is the place where management of API aspects takes place like addressing NFRs by enforcing policies on them.
>> We can create multiple instances for a same API and manage them differently for different purposes.
>> One instance can have a set of API policies applied and another instance of same API can have different set of policies applied for some other purpose.
>> These APIs and their instances are defined PER environment basis. So, one need to manage them seperately in each environment.
>> We can ensure that same configuration of API instances (SLAs, Policies etc..) gets promoted when promoting to higher environments using platform feature. But this is optional only. Still one can change them per environment basis if they have to.
>> Runtime Manager is the place to manage API Implementations and their Mule Runtimes but NOT APIs itself. Though API policies gets executed in Mule Runtimes, We CANNOT enforce API policies in Runtime Manager. We would need to do that via API Manager only for a cherry picked instance in an environment.
So, based on these facts, right statement in the given choices is - "The API policy is defined in API Manager for a specific API instance, and then ONLY applied to the specific API instance".

質問 # 54
......

MCPA-Level-1日本語サンプルには正確な更新された問題：https://www.goshiken.com/MuleSoft/MCPA-Level-1-JPN-mondaishu.html

関するブログ

もっと

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