合格させるMuleSoft MCPA-Level-1日本語にはFast2test提供の試験問題集で2025年07月更新
完全版最新のMCPA-Level-1日本語問題集、100%カバー率問題と解答があなたをリアル試験で合格させる
質問 # 69
API は、承認されたセマンティック バージョニングの慣行に従い、その API プロデューサーによって Anypoint exchange でバージョン 3.1.1 から 3.2.0 に更新され、変更は API パブリック ポータルを介して通知されました。API エンドポイントは、新しいバージョンでは変更されません。API クライアントの開発者は、この変更にどのように対応する必要がありますか?
- A. API プロデューサーは、新しいバージョンと並行して古いバージョンを実行するように要求する必要があります。
- B. API クライアント コードは、新しい機能を利用する必要がある場合にのみ変更する必要があります。
- C. API クライアント側でコードを更新し、完全な回帰を行う必要があります。
- D. API プロデューサーに連絡して、既存の機能への変更を理解する必要があります。
正解：B
質問 # 70
一部の HTTP 要求への応答は、要求で使用される HTTP 動詞に応じてキャッシュできます。HTTP 仕様によると、どの HTTP 動詞に対してこれを安全に行うことができますか?
- A. GET、OPTIONS、HEAD
- B. GET、PUT、オプション
- C. GET、HEAD、POST
- D. PUT、POST、DELETE
正解：A
解説：
GET,OPTIONS,HEAD
http://restcookbook.com/HTTP%20Methods/べき等性/
質問 # 71
Mule アプリケーションは API を実装します。Mule アプリケーションには、コネクタ構成で HTTPS プロトコルを設定し、ポート値をハードコードする HTTP リスナーがあります。Mule アプリケーションは Anypoint VPC にデプロイされ、すべての受信トラフィックに CloudHub 1.0 共有ロードバランサ (SLB) を使用します。
Mule アプリケーションが SLB 経由でルーティングされた HTTPS API 呼び出しを適切に受信できるように、HTTP リスナーのコネクタ構成に割り当てる必要があるポート番号はどれですか?
- A. 0
- B. 1
- C. 2
- D. 3
正解：B
解説：
When using CloudHub 1.0's Shared Load Balancer (SLB) for a Mule application configured with HTTPS in an Anypoint VPC, specific ports must be configured for the application to correctly route incoming traffic:
* Port Requirement for SLB:
* The CloudHub Shared Load Balancer for HTTPS traffic requires that applications listen on port 8092 for secure (HTTPS) communication. This port is reserved specifically for SSL traffic when using SLB with Anypoint VPCs.
* Why Option B is Correct:
* Setting the HTTP Listener's connector configuration to 8092 aligns with CloudHub requirements for HTTPS via the Shared Load Balancer.
* Explanation of Incorrect Options:
* Option A (8082) is used for non-HTTPS (HTTP) traffic.
* Option C (80) and Option D (443) are standard web ports but are not applicable within CloudHub SLB's internal configuration for VPC routing.
ReferencesFor more information on the Shared Load Balancer port configurations, refer to MuleSoft's documentation on CloudHub and VPC load balancer requirements.
質問 # 72
Anypoint Platform が提供する 4 つの重要なプラットフォーム機能は何ですか?
- A. API の設計と開発、API ランタイムの実行とホスティング、API の運用と管理、API コンシューマー エンゲージメント
- B. API の設計と開発、API ランタイムの実行とホスティング、API のバージョニング、API の廃止
- C. API の設計と開発、API の廃止、API のバージョニング、API コンシューマ エンゲージメント
- D. API バージョニング、API ランタイムの実行とホスティング、API 呼び出し、API コンシューマー エンゲージメント
正解：A
解説：
正解: API の設計と開発、API ランタイムの実行とホスティング、API の運用と管理、API コンシューマー エンゲージメント
********************************************
>> API の設計と開発 - Anypoint Studio、Anypoint Design Center、Anypoint Connectors
>> API ランタイムの実行とホスティング - Mule ランタイム、CloudHub、ランタイム サービス
>> API の運用と管理 - Anypoint API Manager、Anypoint Exchange
>> API コンシューマー管理 - API コントラクト、パブリック ポータル、Anypoint Exchange、API ノートブック
質問 # 73
統合テストではなく MUnit テストに適したシナリオはどれですか?
- A. テストに実装の詳細に関する知識が必要ない場合
- B. モックが許可されていない場合
- C. 依存関係（他のWeb APIなど）への読み取り専用インタラクション用
- D. SoapUIを使用して実装されたテストの場合
正解：C
解説：
MUnit is MuleSoft's testing framework for creating and running automated tests within Anypoint Studio. It is specifically designed for unit testing Mule applications and is best suited when testing doesn't require understanding the inner workings or implementation details of the components being tested.
* Ideal Use Cases for MUnit:
* MUnit is optimal when testing individual flows, functions, or components in isolation. This type of testing focuses on verifying the behavior of each unit without needing to understand the complete system.
* Since unit tests do not require external integrations or dependencies to be live, mocking is commonly used in MUnit to simulate the behavior of external services and APIs.
* Why Option B is Correct:
* Option B aligns with the concept of unit testing, where the emphasis is on testing functionality rather than system integration. Integration tests, on the other hand, would require implementation knowledge and live endpoints, making them unsuitable for MUnit's scope.
* Explanation of Incorrect Options:
* Option A (read-only interactions) and Option C (no mocking) do not suit MUnit's typical testing environment as MUnit is designed with mocking capabilities to simulate dependencies.
* Option D (SoapUI-based tests) suggests an external testing tool, while MUnit is specific to MuleSoft.
ReferencesFor more on MUnit best practices, refer to MuleSoft's MUnit documentation.
質問 # 74
API 実装は、CloudHub 上の単一のワーカーにデプロイされ、外部 API クライアント (CloudHub の外部) によって呼び出されます。API 実装が API 呼び出しに応答しなくなるとすぐにトリガーされることが保証されているアラートを設定するにはどうすればよいですか?
- A. API 内にハートビート/ヘルス チェックを実装し、Anypoint Platform の外部から呼び出して、ハートビートが応答しない場合にアラートを出す
- B. 呼び出し元の API クライアント内で API 呼び出しの例外を処理し、API が使用できない場合にその API クライアントからアラートを生成します。
- C. API が指定された期間内にリクエストを受信しなかった場合のアラートを作成します
- D. Anypoint Runtime Manager で「ワーカーが応答していません」アラートを構成する
正解：D
解説：
Configure a "Worker not responding" alert in Anypoint Runtime Manager.
*****************************************
>> All the options eventually helps to generate the alert required when the application stops responding.
>> However, handling exceptions within calling API and then raising alert from API client is inappropriate and silly. There could be many API clients invoking the API implementation and it is not ideal to have this setup consistently in all of them. Not a realistic way to do.
>> Implementing a health check/ heartbeat with in the API and calling from outside to detmine the health sounds OK but needs extra setup for it and same time there are very good chances of generating false alarms when there are any intermittent network issues between external tool calling the health check API on API implementation. The API implementation itself may not have any issues but due to some other factors some false alarms may go out.
>> Creating an alert in API Manager when the API receives no requests within a specified time period would actually generate realistic alerts but even here some false alarms may go out when there are genuinely no requests from API clients.
The best and right way to achieve this requirement is to setup an alert on Runtime Manager with a condition
"Worker not responding". This would generate an alert AS SOON AS the workers become unresponsive.
Bottom of Form
Top of Form
質問 # 75
ある企業は、Runtime Manager を通じて、デフォルト設定の Mule アプリケーションを顧客がホストする Mule ランタイムにデプロイします。各 Mule アプリケーションは、API クライアントに RESTful インターフェイスを公開する API 実装です。Mule ランタイムは、MuleSoft がホストするコントロール プレーンによって管理されます。ペイロードは、どの Logger コンポーネントでも使用されません。
API クライアントが顧客がホストする Mule アプリケーションに HTTP リクエストを送信すると、どのメタデータまたはデータ (ペイロード) が MuleSoft がホストするコントロール プレーンにプッシュされますか?
- A. データのみ
- B. データとメタデータ
- C. データなし
- D. メタデータのみ
正解：D
解説：
* Understanding the Data Flow Between Mule Runtimes and Control Plane:
* When Mule applications are deployed on customer-hosted Mule runtimes, the MuleSoft-hosted control plane (Anypoint Platform) can monitor and manage these applications. However, due to data privacy and security, the control plane only collects specific types of information.
* Typically, only metadata about the request and response (such as headers, status codes, and timestamps) is sent to the MuleSoft-hosted control plane. The actual payload data is not transmitted unless explicitly configured, ensuring that sensitive data remains within the customer's network.
* Evaluating the Options:
* Option A (Only the data): This is incorrect because the payload data itself is not automatically sent to the control plane in default configurations.
* Option B (No data): This is incorrect as well; while the payload is not sent, metadata is still collected and sent to the control plane.
* Option C (The data and metadata): This option is incorrect because data (payload) is not transmitted to the control plane by default.
* Option D (Correct Answer): Only the metadata is sent to the MuleSoft-hosted control plane by default, aligning with MuleSoft's design to prioritize security and data privacy for customer- hosted runtimes.
* Conclusion:
* Option D is the correct answer, as by default, only metadata is sent to the MuleSoft-hosted control plane, and not the payload. This configuration is designed to protect sensitive data from being exposed outside the customer's hosted environment.
For more details, refer to MuleSoft's documentation on telemetry data collected in customer-hosted Mule runtimes and the MuleSoft control plane.
質問 # 76
API ポリシーを適用できる Mule アプリケーション
その Mule アプリケーションによって公開されたエンドポイントへの Anypoint Platform?
A) HTTP/1.x 経由でリクエストを受け入れる Mule アプリケーション
B) TCP 経由で JSON 要求を受け入れるが、応答を提供する必要がない Mule アプリケーション
C) WebSocket 経由で JSON リクエストを受け入れる Mute アプリケーション
D) HTTP/2 経由で gRPC リクエストを受け入れる Mule アプリケーション
- A. オプション C
- B. オプション D
- C. オプション A
- D. オプション B
正解：C
解説：
Option A
*****************************************
>> Anypoint API Manager and API policies are applicable to all types of HTTP/1.x APIs.
>> They are not applicable to WebSocket APIs, HTTP/2 APIs and gRPC APIs
質問 # 77
Anypoint Platform が提供する API 呼び出しメトリクスは何を提供しますか?
- A. 特定の脅威のしきい値を超える可能性がある将来のポリシー違反のプロアクティブな識別
- B. 過去の API 呼び出しに関するデータで、さまざまな API の異常や使用パターンを特定するのに役立ちます
- C. 再利用のレベルに基づくアプリケーション ネットワークの有効性の測定
- D. ビジネス ユーザーと直接共有できる API からの ROI 指標
正解：B
解説：
正解: 過去の API 呼び出しに関するデータは、さまざまな API の異常と使用パターンを特定するのに役立ちます
********************************************
Anypoint Platform によって提供される API 呼び出しメトリクス:
>> 投資収益率 (ROI) 関連の情報は一切提供しません。したがって、それを示唆するオプションはアウトです。
>> API がどのように再利用されているか、API が効果的に使用されているかどうかなどについての情報は提供しません。
>> 将来のポリシー違反を積極的に特定するのに役立つ予測情報を提供しません。
そのため、このようなメトリクスから取得できるデータ/情報の種類は、過去の API 呼び出しに関するものであり、さまざまな API の異常や使用パターンを特定するのに役立ちます。
質問 # 78
システム API は、プライマリ環境とディザスター リカバリー (DR) 環境にデプロイされ、環境ごとに異なる DNS 名が使用されます。プロセス API はシステム API のクライアントであり、システム API によってレート制限されており、環境ごとに異なる制限があります。システム API の DR 環境は、プライマリ環境によって提供されるレート制限の 20% しか提供しません。これらの条件と制約を考慮して、プロセス API の全体的なエラーを減らすための最良の API フォールト トレラント呼び出し戦略は何ですか?
- A. プライマリ環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。それでも失敗する場合は、DR 環境にデプロイされたプロセス API のコピーを呼び出します
- B. プライマリ環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。それでも失敗する場合は、DR 環境にデプロイされたシステム API を呼び出します
- C. プライマリ環境にデプロイされたシステム API を呼び出します。再試行ロジックをプロセス API に追加して、DR 環境にデプロイされたシステム API を呼び出して断続的な障害を処理する
- D. 並行して、プライマリ環境にデプロイされたシステム API と DR 環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。プロセス API にロジックを追加して結果を組み合わせる
正解：B
解説：
Invoke the system API deployed to the primary environment; add timeout and retry logic to the process API to avoid intermittent failures; if it still fails, invoke the system API deployed to the DR environment
*****************************************
There is one important consideration to be noted in the question which is - System API in DR environment provides only 20% of the rate limiting offered by the primary environment. So,comparitively, very less calls will be allowed into the DR environment API opposed to its primary environment. With this in mind, lets analyse what is the right and best fault-tolerant invocation strategy.
1. Invoking both the system APIs in parallel is definitely NOT a feasible approach because of the 20% limitation we have on DR environment. Calling in parallel every time would easily and quickly exhaust the rate limits on DR environment and may not give chance to genuine intermittent error scenarios to let in during the time of need.
2. Another option given is suggesting to add timeout and retry logic to process API while invoking primary environment's system API. This is good so far. However, when all retries failed, the option is suggesting to invoke the copy of process API on DR environment which is not right or recommended. Only system API is the one to be considered for fallback and not the whole process API. Process APIs usually have lot of heavy orchestration calling many other APIs which we do not want to repeat again by calling DR's process API. So this option is NOT right.
3. One more option given is suggesting to add the retry (no timeout) logic to process API to directly retry on DR environment's system API instead of retrying the primary environment system API first. This is not at all a proper fallback. A proper fallback should occur only after all retries are performed and exhausted on Primary environment first. But here, the option is suggesting to directly retry fallback API on first failure itself without trying main API. So, this option is NOT right too.
This leaves us one option which is right and best fit.
- Invoke the system API deployed to the primary environment
- Add Timeout and Retry logic on it in process API
- If it fails even after all retries, then invoke the system API deployed to the DR environment.
質問 # 79
展示を参照してください。
組織は、すべての CloudHub デプロイメントに対して 1 つの特定の CloudHub (AWS) リージョンを使用します。
組織の Mule アプリケーションがアベイラビリティーゾーン (AZ) の CloudHub にデプロイされている場合、CloudHub ワーカーはどのようにアベイラビリティーゾーン (AZ) に割り当てられますか?
- A. AZ は、Mule アプリケーションのデプロイ構成の一部として選択されます
- B. Mule アプリケーション用に AZ がランダムに選択され、Mule アプリケーションのすべての CloudHub ワーカーがその 1 つの AZ に割り当てられます。
- C. ワーカーは、そのリージョン内の利用可能な AZ にランダムに分散されます
- D. 特定の環境に属するワーカーは、そのリージョン内の同じ AZ に割り当てられます。
正解：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.
質問 # 80
Anypoint Platform Private Cloud Edition または Anypoint Platform for Pivotal Cloud Foundry を使用する必要がある Mule アプリケーションの展開シナリオはどれですか?
- A. 複数のデータセンターですべてのアプリケーションを高可用性にする必要がある場合
- B. すべての API を非公開にし、パブリック クラウドに公開しないことが必要な場合
- C. 規制要件により、メタデータを含むすべてのデータ項目のオンプレミス処理が義務付けられている場合
- D. アプリケーション ネットワーク内のすべてのバックエンド システムが組織のイントラネットに展開されている場合
正解：C
解説：
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.
質問 # 81
複数の CloudHub ワーカーにデプロイされた Mule アプリケーションとして実装された非同期実行の長時間実行プロセスでトランザクション状態を追跡するための、Anypoint Platform で最もパフォーマンスの高いすぐに使えるソリューションは何ですか?
- A. Redis 分散キャッシュ
- B. java.util.WeakHashMap
- C. ファイルベースのストレージ
- D. 永続オブジェクト ストア
正解：D
解説：
Persistent Object Store
*****************************************
>> Redis distributed cache is performant but NOT out-of-the-box solution in Anypoint Platform
>> File-storage is neither performant nor out-of-the-box solution in Anypoint Platform
>> java.util.WeakHashMap needs a completely custom implementation of cache from scratch using Java code and is limited to the JVM where it is running. Which means the state in the cache is not worker aware when running on multiple workers. This type of cache is local to the worker. So, this is neither out-of-the-box nor worker-aware among multiple workers on cloudhub. https://www.baeldung.com/java-weakhashmap
>> Persistent Object Store is an out-of-the-box solution provided by Anypoint Platform which is performant as well as worker aware among multiple workers running on CloudHub. https://docs.mulesoft.com/object-store/ So, Persistent Object Store is the right answer.
質問 # 82
REST API 実装のバージョン 3.0.1 は、ISO 8601 hh:mm:ss 形式を使用して PST 時間で時間値を表します。代わりに、ISO 8601 hh:mm:ss 形式を使用して CEST 時間の時間値を表すように API 実装を変更する必要があります。semver.org のセマンティック バージョニング仕様に従う場合、更新された API 実装にはどのバージョンを割り当てる必要がありますか?
- A. 3.0.1
- B. 3.1.0
- C. 3.0.2
- D. 4.0.0
正解：D
解説：
4.0.0
*****************************************
As per semver.org semantic versioning specification:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes.
- MINOR version when you add functionality in a backwards compatible manner.
- PATCH version when you make backwards compatible bug fixes.
As per the scenario given in the question, the API implementation is completely changing its behavior.
Although the format of the time is still being maintained as hh:mm:ss and there is nochange in schema w.r.t format, the API will start functioning different after this change as the times are going to come completely different.
Example: Before the change, say, time is going as 09:00:00 representing the PST. Now on, after the change, the same time will go as 18:00:00 as Central European Summer Time is 9 hours ahead of Pacific Time.
>> This may lead to some uncertain behavior on API clients depending on how they are handling the times in the API response. All the API clients need to be informed that the API functionality is going to change and will return in CEST format. So, this considered as a MAJOR change and the version of API for this new change would be 4.0.0
質問 # 83
顧客は、特定の期間に受信するリクエストの数を監視して洞察を得るとともに、主要なパフォーマンス指標 (応答時間、CPU 使用率、アクティブな API の数) を測定したいと考えています。
これらのデータの洞察を提供するツールはどれですか?
- A. 機能監視
- B. ランタイムアラート
- C. APT マネージャー
- D. あらゆるポイントのモニタリング
正解：D
解説：
* Understanding Anypoint Monitoring and Its Capabilities:
* Anypoint Monitoring provides comprehensive visibility into Mule applications, offering metrics and analytics such as request counts, response times, CPU utilization, memory usage, and other key performance indicators (KPIs). This tool is designed to help teams monitor API usage, troubleshoot issues, and optimize application performance.
* Evaluating the Options:
* Option A (Correct Answer): Anypoint Monitoring is the ideal tool for this requirement. It provides real-time insights into metrics such as the number of requests, response times, CPU utilization, and active API usage.
* Option B (API Manager): API Manager focuses on API lifecycle management, including applying policies, managing contracts, and setting access controls. It does not provide performance monitoring or KPI tracking.
* Option C (Runtime Alerts): Runtime Alerts can notify users of specific conditions, like high CPU usage, but they do not provide a full suite of metrics or insights over a given time period.
* Option D (Functional Monitoring): Functional Monitoring focuses on functional testing of APIs rather than performance and usage metrics. It does not provide continuous KPI tracking.
* Conclusion:
* Option A is the correct answer. Anypoint Monitoring is the most suitable tool to track the specified metrics, providing detailed insights into API requests, response times, CPU usage, and active API counts.
For further details, refer to MuleSoft's Anypoint Monitoring documentation on configuring dashboards and tracking performance metrics.
質問 # 84
以下にリストされている Anypoint Platform の機能のうち、API および API 呼び出し/コンシューマーのカテゴリに該当するものはどれですか? 2 つを選択します。
- A. API の運用と管理
- B. API ランタイムの実行とホスティング
- C. API 消費者エンゲージメント
- D. API の設計と開発
正解：D
解説：
正解: API の設計と開発および API ランタイムの実行とホスティング
********************************************
>> API の設計と開発 - Anypoint Studio、Anypoint Design Center、Anypoint Connectors
>> API ランタイムの実行とホスティング - Mule ランタイム、CloudHub、ランタイム サービス
>> API の運用と管理 - Anypoint API Manager、Anypoint Exchange
正解: API の運用と管理および API コンシューマー エンゲージメント
********************************************
>> API の設計と開発 - Anypoint Studio、Anypoint Design Center、Anypoint Connectors
>> API ランタイムの実行とホスティング - Mule ランタイム、CloudHub、ランタイム サービス
>> API の運用と管理 - Anypoint API Manager、Anypoint Exchange
>> API コンシューマー管理 - API コントラクト、パブリック ポータル、Anypoint Exchange、API ノートブック
質問 # 85
Anypoint Platform Private Cloud Edition または Anypoint Platform for Pivotal Cloud Foundry を使用する必要がある Mule アプリケーションの展開シナリオはどれですか?
- A. 複数のデータセンターですべてのアプリケーションを高可用性にする必要がある場合
- B. すべての API を非公開にし、パブリック クラウドに公開しないことが必要な場合
- C. 規制要件により、メタデータを含むすべてのデータ項目のオンプレミス処理が義務付けられている場合
- D. アプリケーション ネットワーク内のすべてのバックエンド システムが組織のイントラネットに展開されている場合
正解：C
解説：
正解: 規制要件により、メタデータを含むすべてのデータ項目のオンプレミス処理が義務付けられている場合。
********************************************
以下では、Anypoint Platform PCE または PCF を使用する必要はありません。したがって、これらのオプションはアウトです。
>> CloudHub も使用して、複数のデータセンターですべてのアプリケーションを高可用性にすることができます。
>> Anypoint VPN と CloudHub からのトンネリングを使用して、組織のイントラネットに展開されているアプリケーション ネットワーク内のすべてのバックエンド システムに接続できます。
>> Anypoint VPC とファイアウォール ルールを使用して、すべての API をプライベートにし、パブリック クラウドに公開しないようにすることができます。
指定されたオプションで Anypoint Platform PCE/PCF を使用する必要がある唯一の正当な理由は、規制要件により、メタデータを含むすべてのデータ項目のオンプレミス処理が義務付けられている場合です。
質問 # 86
経験豊富な中央 IT 部門を持つ大規模な組織が、MuleSoft の使用を開始しています。サイロ化されたバックエンド システムを新しい顧客関係管理 (CRM) システムに接続するプロジェクトがあります。Enablement センターは、API 主導の接続を使用するように指導しています。
API 主導の接続性を使用したアプリケーション ネットワークの作成をサポートするアクションは何ですか?
- A. ビジネスアナリストに、2つのシステム間の標準データモデルを指定するためのビジネスプロセスモデルの作成を依頼します。
- B. 新しい CRM システムがカスタム REST API の作成をサポートし、CloudHub で 4 つのプライベート ネットワークを確立し、GAuth 2.0 認証をサポートしているかどうかを判断します。
- C. このプロジェクトを迅速に進めるために、中央IT部門はCRMシステムとバックエンドシステムを拡張し、組み込みの統合インターフェースを使用して相互に接続する必要があります。
- D. REST APIを使用してバックエンドシステムのデータをロック解除するためのシステムAPIを作成します。
正解：D
解説：
For an organization starting with API-led connectivity to integrate a siloed back-end system with a new CRM, the following approach aligns with best practices and MuleSoft's Center for Enablement (C4E) guidance:
* API-led Connectivity: This model organizes APIs into distinct layers (System, Process, and Experience) to improve reusability, modularity, and manageability.
* System APIs are used to expose and unlock data from core systems (such as back-end applications or databases).
* Process APIs orchestrate data across multiple systems and transform it as needed.
* Experience APIs format the data specifically for consumption by applications or devices, such as the CRM in this case.
* Step to Support Application Network:
* Create a System API for the back-end system. This API should expose the necessary data to support integration with the CRM.
* By creating a System API with a RESTful interface, data can be accessed in a standardized way, making it easier to integrate with other systems and supporting future scalability.
* Why Option D is Correct:
* Creating a System API aligns with the principle of API-led connectivity, ensuring that data is exposed in a reusable manner. This API can then be orchestrated by Process APIs as needed to meet CRM requirements and can easily be extended to other applications.
* Explanation of Incorrect Options:
* Option A (creating a business process model) does not directly enable connectivity or expose back-end data through APIs.
* Option B is unnecessary at this stage; assessing CRM capabilities like OAuth 2.0 support is not directly related to creating the application network via System APIs.
* Option C contradicts API-led best practices by suggesting a point-to-point integration, which API-led connectivity seeks to avoid due to its lack of flexibility and scalability.
ReferencesRefer to MuleSoft's API-led Connectivity resources for a detailed framework on building scalable integration layers using System, Process, and Experience APIs.
質問 # 87
展示を参照してください。
顧客がホストする Mule ランタイムを MuleSoft がホストする Anypoint Platform コントロール プレーン (ハイブリッド展開) とともに使用する場合、正しいのはどれですか?
- A. API 実装は、コントロール プレーンと通信できない場合でも、顧客がホストする Mule ランタイムで正常に実行できます。
- B. Anypoint Runtime Manager は、ノードに障害が発生した場合に新しい Mule ランタイム インスタンスを作成することで、コントロール プレーンの HA を自動的に確保します。
- C. Anypoint Runtime Manager は、Mule アプリケーションをデプロイするために Mule ランタイムへのネットワーク接続を開始します。
- D. MuleSoft がホストする共有ロード バランサを使用して、Mule ランタイムへの API 呼び出しの負荷を分散できます。
正解：A
解説：
API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane.
*****************************************
>> We CANNOT use Shared Load balancer to load balance APIs on customer hosted runtimes
>> For Hybrid deployment models, the on-premises are first connected to Runtime Manager using Runtime Manager agent. So, the connection is initiated first from On-premises to Runtime Manager. Then all control can be done from Runtime Manager.
>> Anypoint Runtime Manager CANNOT ensure automatic HA. Clusters/Server Groups etc should be configured before hand.
Only TRUE statement in the given choices is, API implementations can run successfully in customer-hosted Mule runtimes, even when they are unable to communicate with the control plane. There are several references below to justify this statement.
References:
https://docs.mulesoft.com/runtime-manager/deployment-strategies#hybrid-deployments
https://help.mulesoft.com/s/article/On-Premise-Runtimes-Disconnected-From-US-Control-Plane-June-18th-2018
https://help.mulesoft.com/s/article/Runtime-Manager-cannot-manage-On-Prem-Applications-and-Servers-from-U
https://help.mulesoft.com/s/article/On-premise-Runtimes-Appear-Disconnected-in-Runtime-Manager-May-29th-
質問 # 88
Anypoint Platform で API ポリシーを使用して効果的に適用できないものは何ですか?
- A. HTTP リクエストとレスポンスのロギング
- B. DoS 攻撃に対する防御
- C. バックエンド システムの過負荷
- D. API 間で改ざん防止された資格情報を維持する
正解：B
解説：
正解: DoS 攻撃に対する防御
********************************************
>> バックエンド システムの過負荷は、「Spike Control Policy」を適用することで処理できます
>> HTTP リクエストとレスポンスのロギングは、「メッセージ ロギング ポリシー」を適用することで実行できます
>> クレデンシャルは「セキュリティ」および「コンプライアンス」ポリシーを使用して改ざん防止できます。ただし、残念ながら、現在 Anypoint Platform には DOS 攻撃を防ぐ適切な方法がありません。
質問 # 89
......
最新MCPA-Level-1日本語試験問題集有効で最新の問題集：https://jp.fast2test.com/MCPA-Level-1-JPN-premium-file.html