MCPA-Level-1日本語無料試験問題と解答PDF最新問題2025年05月
最新MCPA-Level-1日本語試験問題集で最近更新された154問題
質問 # 37
トラフィックは API プロキシを介して API 実装にルーティングされます。API プロキシは API Manager によって管理され、API 実装は Runtime Manager を使用して CloudHub VPC にデプロイされます。この API には API ポリシーが適用されています。このデプロイ シナリオでは、どの時点で API ポリシーが着信 API クライアント リクエストに適用されますか?
- A. API実装時
- B. MuleSoft がホストするロードバランサー
- C. APIプロキシで
- D. APIプロキシとAPI実装の両方で
正解：C
質問 # 38
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.
質問 # 39
プロセス API に適用される可能性が最も低い API ポリシーはどれですか?
- A. JSON 脅威保護
- B. レート制限
- C. カスタム サーキット ブレーカー
- D. クライアント ID の強制
正解：A
解説：
JSON threat protection
*****************************************
Fact: Technically, there are no restrictions on what policy can be applied in what layer. Any policy can be applied on any layer API. However, context should also be considered properly before blindly applying the policies on APIs.
That is why, this question asked for a policy that would LEAST likely be applied to a Process API.
From the given options:
>> All policies except "JSON threat protection" can be applied without hesitation to the APIs in Process tier.
>> JSON threat protection policy ideally fits for experience APIs to prevent suspicious JSON payload coming from external API clients. This covers more of a security aspect by trying toavoid possibly malicious and harmful JSON payloads from external clients calling experience APIs.
As external API clients are NEVER allowed to call Process APIs directly and also these kind of malicious and harmful JSON payloads are always stopped at experience API layer only using this policy, it is LEAST LIKELY that this same policy is again applied on Process Layer API.
質問 # 40
展示を参照してください。
開発者は、クライアント ID 強制ポリシーによって管理される STAGING 環境にデプロイされた API を呼び出すクライアント アプリケーションを構築しています。
API を正常に呼び出すには何が必要ですか?
- A. STAGING 環境の API インスタンス用に Anypoint Exchange から取得したクライアント ID とシークレット
- B. Anypoint Platform から取得した有効な OAuth トークンと、それに関連付けられたクライアント ID とシークレット
- C. Anypoint Platform アカウントの STAGING 環境のクライアント ID とシークレット
- D. STAGING 環境で API を所有する Anypoint Platform アカウントのクライアント ID とシークレット
正解：A
解説：
The client ID and secret obtained from Anypoint Exchange for the API instance in the STAGING environment
*****************************************
>> We CANNOT use the client ID and secret of Anypoint Platform account or any individual environments for accessing the APIs
>> As the type of policy that is enforced on the API in question is "Client ID Enforcment Policy", OAuth token based access won't work.
Right way to access the API is to use the client ID and secret obtained from Anypoint Exchange for the API instance in a particular environment we want to work on.
References:
Managing API instance Contracts on API Manager
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
質問 # 41
一緒に使用すると、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
質問 # 42
共有ロード バランサで CloudHub を使用する場合、Anypoint Platform ではなく、API 実装 (Mule アプリケーション) によって排他的に管理されるものは何ですか?
- A. API 実装に割り当てられた DNS エントリの数
- B. HTTPS エンドポイントを公開するために API 実装によって使用される SSL 証明書
- C. 特定の CloudHub ワーカーへの各 HTTP リクエストの割り当て
- D. ログ エントリを Runtime Manager で表示できるようにするロギング構成
正解：B
解説：
正解: HTTPS エンドポイントを公開するために API 実装で使用される SSL 証明書
********************************************
>> 特定の CloudHub ワーカーへの各 HTTP リクエストの割り当ては、Anypoint Platform 自体によって処理されます。API 実装で明示的に管理する必要はなく、実際、API 実装で管理することはできません。
>> ログ エントリを Runtime Manager で表示できるようにするロギング構成は、SLB だけでなく、常に API 実装で管理されます。したがって、これは SLB を使用する場合にのみ行うことではありません。
>> コード内の API 実装に割り当てられた DNS エントリの数を管理しません。Anypoint Platform がこれを処理します。
これは、API 実装によって排他的に管理される HTTPS エンドポイントを公開するために API 実装によって使用される SSL 証明書です。SLB を使用する場合、Anypoint Platform はこれを行いません。
質問 # 43
正しいか間違っているか。より多くの工数とリソースが必要な場合でも、設計および開発されている API がセルフサービス可能であることを常に確認する必要があります。
- A. TRUE
- B. FALSE
正解：A
解説：
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.
質問 # 44
ある小売会社は、Order API を使用して新しい注文を受け付けています。Order API は、JMS キューを使用してバックエンドの注文管理サービスに注文を送信します。注文の通常の負荷は、それぞれが 0.2 仮想コアで構成された 2 つの CloudHub ワーカーを使用して処理されています。各 CloudHub ワーカーの CPU 負荷は通常、70% をはるかに下回ります。ただし、年に数回、Order API は平均注文数の 4 倍 (4x) を取得します。これにより、CloudHub ワーカーの CPU 負荷が 90% を超え、注文の送信時間が 30 秒を超えます。ただし、原因はバックエンド注文管理サービスではなく、注文 API の応答 SLA を満たすのに十分な速さで応答します。Mule アプリケーションの CloudHub デプロイメントを構成して、このパフォーマンスの課題に会社が対処できるようにする最もリソース効率の高い方法は何ですか?
- A. CPU 使用率が 70% を超えるとトリガーされる垂直方向の CloudHub 自動スケーリング ポリシーを使用する
- B. CPU 使用率が 70% を超えるとトリガーされる水平 CloudHub 自動スケーリング ポリシーを使用します。
- C. 2 つの CloudHub ワーカーのそれぞれのサイズを、少なくとも 4 倍 (4x) ずつ 1 つの仮想コアに永続的に増やします。
- D. CloudHub ワーカーの数を 4 倍 (4x) から 8 つの CloudHub ワーカーに永続的に増やします。
正解：B
解説：
Use a horizontal CloudHub autoscaling policy that triggers on CPU utilization greater than
70%
*****************************************
The scenario in the question is very clearly stating that the usual traffic in the year is pretty well handled by the existing worker configuration with CPU running well below 70%. The problem occurs only "sometimes" occasionally when there is spike in the number of orders coming in.
So, based on above, We neither need to permanently increase the size of each worker nor need to permanently increase the number of workers. This is unnecessary as other than those "occasional" times the resources are idle and wasted.
We have two options left now. Either to use horizontal Cloudhub autoscaling policy to automatically increase the number of workers or to use vertical Cloudhub autoscaling policy to automatically increase the vCore size of each worker.
Here, we need to take two things into consideration:
1. CPU
2. Order Submission Rate to JMS Queue
>> From CPU perspective, both the options (horizontal and vertical scaling) solves the issue. Both helps to bring down the usage below 90%.
>> However, If we go with Vertical Scaling, then from Order Submission Rate perspective, as the application is still being load balanced with two workers only, there may not be much improvement in the incoming request processing rate and order submission rate to JMS queue. The throughput would be same as before.
Only CPU utilization comes down.
>> But, if we go with Horizontal Scaling, it will spawn new workers and adds extra hand to increase the throughput as more workers are being load balanced now. This way we can address both CPU and Order Submission rate.
Hence, Horizontal CloudHub Autoscaling policy is the right and best answer.
質問 # 45
Anypoint Platform が提供する API 呼び出しメトリクスは何を提供しますか?
- A. 特定の脅威のしきい値を超える可能性がある将来のポリシー違反のプロアクティブな識別
- B. 再利用のレベルに基づくアプリケーション ネットワークの有効性の測定
- C. 過去の API 呼び出しに関するデータで、さまざまな API の異常や使用パターンを特定するのに役立ちます
- D. ビジネス ユーザーと直接共有できる API からの ROI 指標
正解：C
解説：
Data on past API invocations to help identify anomalies and usage patterns across various APIs
*****************************************
API Invocation metrics provided by Anypoint Platform:
>> Does NOT provide any Return Of Investment (ROI) related information. So the option suggesting it is OUT.
>> Does NOT provide any information w.r.t how APIs are reused, whether there is effective usage of APIs or not etc...
>> Does NOT prodive any prediction information as such to help us proactively identify any future policy violations.
So, the kind of data/information we can get from such metrics is on past API invocations to help identify anomalies and usage patterns across various APIs.
質問 # 46
顧客は、特定の期間に受信するリクエストの数を監視して洞察を得るとともに、主要なパフォーマンス指標 (応答時間、CPU 使用率、アクティブな API の数) を測定したいと考えています。
これらのデータの洞察を提供するツールはどれですか?
- A. あらゆるポイントのモニタリング
- B. 機能監視
- C. ランタイムアラート
- D. APT マネージャー
正解：A
解説：
* 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.
質問 # 47
展示を参照してください。
3 つのビジネス プロセスを実装する必要があり、実装は複数の異なる SaaS アプリケーションと通信する必要があります。
これらのプロセスは、別々の (サイロ化された) LOB によって所有され、主に互いに独立していますが、いくつかのビジネス エンティティを共有しています。各 LOB には 1 つの開発チームと独自の予算があります。この組織のコンテキストでは、データ モデルの冗長性を最小限に抑えてこれらのビジネス プロセスを実装する API の API データ モデルを選択する最も効果的なアプローチは何ですか?
A) ビジネス プロセスの一貫した部分と関連するビジネス エンティティの定義に合わせて、境界付けられたコンテキスト データ モデルをいくつか構築する
B) 確立されたマイクロサービスとアジャイル API 中心のプラクティスに従うために、API ごとに個別のデータモデルを構築する
C) XML スキーマを使用してすべての API データ モデルを構築し、組織全体で一貫性と再利用を推進する
D) 3 つのすべてのビジネス プロセスからのすべてのデータ タイプを統合する 1 つの集中管理された正規データ モデル (エンタープライズ データ モデル) を構築し、データ モデルが一貫性があり、冗長でないことを保証します。
- A. オプション A
- B. オプション C
- C. オプション B
- D. オプション D
正解：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 EDMneeds 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.
質問 # 48
以下のオプションから正しいオーナー層の組み合わせを選択してください
- A. 1. アプリ開発者は、エクスペリエンス レイヤー API を所有し、それに注力しています。
2. 中央 IT が所有し、プロセス レイヤー API に集中する
3. LOB IT が所有し、システム層 API に集中 - B. 1. アプリ開発者は、エクスペリエンス レイヤー API を所有し、それに注力しています。
2. LOB IT が所有し、プロセス レイヤー API に注力
3. 中央 IT が所有し、システム層 API に集中する - C. 1. 中央 IT は、エクスペリエンス レイヤー API を所有し、それに重点を置いています。
2. LOB IT が所有し、プロセス レイヤー API に注力
3. アプリ開発者は、システム層 API を所有し、それに専念しています
正解：B
解説：
1. App Developers owns and focuses on Experience Layer APIs
2. LOB IT owns and focuses on Process Layer APIs
3. Central IT owns and focuses on System Layer APIs
References:
https://blogs.mulesoft.com/biz/api/experience-api-ownership/
https://blogs.mulesoft.com/biz/api/process-api-ownership/
https://blogs.mulesoft.com/biz/api/system-api-ownership/
質問 # 49
Mule アプリケーションは HTTPS エンドポイントを公開し、静的 IP アドレスを使用しない 3 つの CloudHub ワーカーにデプロイされます。Mule アプリケーションは、短期間に大量のクライアント要求を予期します。大量のクライアント リクエストに対応するために使用する必要がある、最も費用対効果の高いインフラストラクチャ コンポーネントはどれですか?
- A. ランタイム マネージャーの自動スケーリング
- B. CloudHub 共有ロードバランサー
- C. API プロキシ
- D. お客様がホストするロード バランサー
正解：B
解説：
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.
質問 # 50
次の順序のうち、正しいものはどれですか?
- 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 Consumer requests access to API >> API Client implementes logic to call an API >> API routes the request to >> API Implementation
*****************************************
>> API consumer does not implement any logic to invoke APIs. It is just a role. So, the option stating "API Consumer implementes logic to call an API" is INVALID.
>> API Implementation does not route any requests. It is a final piece of logic where functionality of target systems is exposed. So, the requests should be routed to the API implementation by some other entity. So, the options stating "API Implementation routes the request to >> API" is INVALID
>> The statements in one of the options are correct but sequence is wrong. The sequence is given as "API Client implementes logic to call an API >> API Consumer requests access to API >> API routes the request to >> API Implementation". Here, the statements in the options are VALID but sequence is WRONG.
>> Right option and sequence is the one where API consumer first requests access to API on Anypoint Exchange and obtains client credentials. API client then writes logic to call an API by using the access client credentials requested by API consumer and the requests will be routed to API implementation via the API which is managed by API Manager.
質問 # 51
4 運輸組織の開発者は、乗客レコードを処理および保存するために、Reservation Mule アプリケーションに 1 つの処理機能を実装しています。この Reservation アプリケーションは、複数の CloudHub ワーカー/レプリカにデプロイされます。複数の外部システムから重複した乗客レコードが Reservation アプリケーションに送信される可能性があります。
予約アプリケーションが各乗客レコードを可能な限り 1 回だけ処理できるように、適切なストレージ メカニズムを選択する必要があります。選択されたストレージ メカニズムは、デプロイされた予約 Mule アプリケーションによる各乗客レコードの 1 回だけの処理を試行できるように状態情報を同期するために、すべての CloudHub ワーカー/レプリカで共有される必要があります。
Anypoint Platform のどのタイプのシンプルなストレージ メカニズムにより、Reservation Mule アプリケーションは最小限の開発労力で、CloudHub ワーカー/レプリカ間でデータを 1 回だけ更新および共有できるようになりますか?
- A. 非永続オブジェクトストア
- B. ランタイム ファブリック オブジェクト ストア
- C. インメモリ Mule オブジェクト ストア
- D. 永続オブジェクトストア
正解：D
解説：
* Processing Requirements and Storage Mechanism:
* The Reservation Mule application will be deployed to multiple CloudHub workers/replicas, meaning that each worker must share state information to handle records exactly once. This requires a shared storage mechanism where state can be stored and accessed by multiple instances to avoid duplicate processing of the same records.
* A Persistent Object Store in Anypoint Platform can be used to store records in a way that is accessible across multiple workers, providing a reliable mechanism for "exactly once" processing.
* Evaluating the Options:
* Option A (Correct Answer): A Persistent Object Store is designed to retain data across different application instances and can be shared by all workers on CloudHub. It helps achieve idempotency by ensuring that a record is processed exactly once.
* Option B: Runtime Fabric Object Store is used for applications deployed in Anypoint Runtime Fabric, not CloudHub. This option would not be compatible with the CloudHub deployment.
* Option C: A Non-persistent Object Store does not retain data across application restarts or different instances, making it unsuitable for the requirement of synchronized storage for exactly- once processing.
* Option D: An In-memory Mule Object Store is local to each worker and is not shared across instances, so it does not meet the requirement for a shared storage mechanism accessible to all CloudHub workers.
* Conclusion:
* Option A is the correct answer, as a Persistent Object Store allows data sharing across multiple CloudHub workers, enabling them to synchronize and achieve "exactly once" processing of passenger records with minimal development effort.
Refer to MuleSoft's documentation on Object Store configurations and usage for best practices on handling state across distributed instances.
質問 # 52
API 主導の接続のどのレイヤーが、主要なシステム、レガシー システム、データ ソースなどのロックを解除し、機能を公開することに重点を置いていますか?
- A. システム層
- B. プロセス層
- C. 経験層
正解：A
解説：
System Layer
The APIs used in an API-led approach to connectivity fall into three categories:
System APIs - these usually access the core systems of record and provide a means of insulating the user from the complexity or any changes to the underlying systems. Once built, many users, can access data without any need to learn the underlying systems and can reuse these APIs in multiple projects.
Process APIs - These APIs interact with and shape data within a single system or across systems (breaking down data silos) and are created here without a dependence on the source systems from which that data originates, as well as the target channels through which that data is delivered.
Experience APIs - Experience APIs are the means by which data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source, rather than setting up separate point-to- point integrations for each channel. An Experience API is usually created with API-first design principles where the API is designed for the specific user experience in mind.
質問 # 53
ある企業は、成功を収めたエンタープライズ データ モデル (EDM) を作成しました。同社は、同社の IT 運用モデルのコア イネーブラーとして最新の API を採用することにより、アプリケーション ネットワークの構築に取り組んでいます。最新の API データ モデルを設計する際に、企業はどの API 層 (経験、プロセス、システム) で EDM を再利用する必要がありますか?
- A. プロセス層とシステム層
- B. エクスペリエンス層とシステム層
- C. エクスペリエンス層とプロセス層
- D. エクスペリエンス、プロセス、およびシステム層
正解：A
解説：
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.
質問 # 54
たとえば、以下の機能を提供する 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.
質問 # 55
コード中心の 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
解説：
正解: API ノートブックを作成し、関連する Anypoint exchange エントリに含める
********************************************
>> API ノートブックは、コード中心の API ドキュメントを提供できる Anypoint Platform のノートブックです。
質問 # 56
あるヨーロッパの企業はヨーロッパ全土に顧客を抱えており、IT 部門は古いプラットフォームから MuleSoft に移行しています。主な要件は、新しいプラットフォームではダウンタイムなしでの再展開と複数のランタイム バージョンへのアプリケーションの展開が可能であること、セキュリティと速度が提供されること、メッセージ サービスとして Anypoint MQ が利用できることです。
追加のネットワーク構成なしで、要件に基づいてどのランタイム プレーンを選択する必要がありますか?
- A. 顧客ホスト型ランタイムプレーン
- B. ランタイムプレーン用のセルフマネージドKubernetes上のAnypoint Runtime Fabric
- C. ランタイムプレーン用の VM / ベアメタル上のランタイムファブリック
- D. MuleSoft がホストするランタイム プレーン (CloudHub)
正解：D
解説：
For a European company with requirements such as zero-downtime redeployment, deployment to multiple runtime versions, secure and fast performance, and the use of Anypoint MQ without additional network configuration, CloudHub is the best choice for the following reasons:
* Zero-Downtime Redeployment: CloudHub supports zero-downtime deployment, which allows seamless redeployment of applications without impacting availability.
* Support for Multiple Runtime Versions: CloudHub allows deploying applications across different Mule runtime versions, giving flexibility to test and migrate applications as needed.
* Integrated Anypoint MQ: Anypoint MQ, which is fully integrated with CloudHub, provides reliable messaging across applications. Choosing CloudHub removes the need for additional network configurations, as Anypoint MQ can be directly accessed in this hosted environment.
* Security and Performance: CloudHub offers secure networking, automatic scaling, and optimized performance without requiring a complex setup. This is managed by MuleSoft's infrastructure, meeting the speed and security requirements with minimal overhead.
* Explanation of Incorrect Options:
* Option A and D (Runtime Fabric on VMs or Self-Managed Kubernetes): While Runtime Fabric offers flexibility, it requires more complex network and infrastructure configurations, which is not ideal if the company seeks simplicity.
* Option B (Customer-hosted): This would require additional network and security configuration, which does not align with the requirement of minimizing setup complexity.
ReferencesFor more information on CloudHub's capabilities regarding zero-downtime deployments and integration with Anypoint MQ, refer to MuleSoft documentation on CloudHub.
質問 # 57
展示を参照してください。
API 主導の接続とアプリケーション ネットワークという意味で有効な API とは何ですか?
A) Java RMI over TCP
B) Java RMI over TCP
C) CORBA over HOP
D) XML over UDP
- A. オプション A
- B. オプション D
- C. オプション C
- D. オプション B
正解：B
解説：
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
質問 # 58
たとえば、以下の機能を提供する 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.
質問 # 59
ある小売会社は、Order API を使用して新しい注文を受け付けています。Order API は、JMS キューを使用してバックエンドの注文管理サービスに注文を送信します。注文の通常の負荷は、それぞれが 0.2 仮想コアで構成された 2 つの CloudHub ワーカーを使用して処理されています。各 CloudHub ワーカーの CPU 負荷は通常、70% をはるかに下回ります。ただし、年に数回、Order API は平均注文数の 4 倍 (4x) を取得します。これにより、CloudHub ワーカーの CPU 負荷が 90% を超え、注文の送信時間が 30 秒を超えます。ただし、原因はバックエンド注文管理サービスではなく、注文 API の応答 SLA を満たすのに十分な速さで応答します。Mule アプリケーションの CloudHub デプロイメントを構成して、このパフォーマンスの課題に会社が対処できるようにする最もリソース効率の高い方法は何ですか?
- A. CPU 使用率が 70% を超えるとトリガーされる垂直方向の CloudHub 自動スケーリング ポリシーを使用する
- B. CPU 使用率が 70% を超えるとトリガーされる水平 CloudHub 自動スケーリング ポリシーを使用します。
- C. 2 つの CloudHub ワーカーのそれぞれのサイズを、少なくとも 4 倍 (4x) ずつ 1 つの仮想コアに永続的に増やします。
- D. CloudHub ワーカーの数を 4 倍 (4x) から 8 つの CloudHub ワーカーに永続的に増やします。
正解：B
解説：
正解: CPU 使用率が 70% を超えるとトリガーされる水平方向の CloudHub 自動スケーリング ポリシーを使用する
********************************************
問題のシナリオは、その年の通常のトラフィックが、CPU が 70% をはるかに下回って実行されている既存のワーカー構成によってかなりうまく処理されていることを非常に明確に示しています。この問題は、注文数が急増したときに「ときどき」発生することがあります。
したがって、上記に基づいて、各ワーカーのサイズを永続的に増やす必要も、ワーカーの数を永続的に増やす必要もありません。これは、リソースがアイドル状態で浪費される「時折」の時間以外は不要です。
現在、2 つのオプションが残っています。水平方向の Cloudhub 自動スケーリング ポリシーを使用してワーカーの数を自動的に増やすか、垂直方向の Cloudhub 自動スケーリング ポリシーを使用して各ワーカーの仮想コア サイズを自動的に増やします。
ここで、次の 2 つのことを考慮する必要があります。
1.CPU
2. JMS キューへの注文発注率
>> CPU の観点からは、両方のオプション (水平スケーリングと垂直スケーリング) が問題を解決します。どちらも使用率を 90% 未満に抑えるのに役立ちます。
>> ただし、垂直スケーリングを使用する場合、注文送信率の観点から見ると、アプリケーションはまだ 2 つのワーカーのみで負荷分散されているため、受信リクエストの処理率と JMS キューへの注文送信率はあまり改善されない可能性があります. スループットは以前と同じになります。CPU 使用率だけが下がります。
>>しかし、水平スケーリングを使用すると、新しいワーカーが生成され、より多くのワーカーが現在負荷分散されているため、スループットを向上させるために追加のハンドが追加されます。このようにして、CPU と注文提出率の両方に対処できます。
したがって、水平 CloudHub 自動スケーリング ポリシーが適切で最良の答えです。
質問 # 60
......
MuleSoft MCPA-Level-1日本語リアル2025年最新のブレーン問題集で模擬試験問題集：https://jp.fast2test.com/MCPA-Level-1-JPN-premium-file.html