MCPA-Level-1日本語問題一発合格させる問題集はMuleSoft Certified Platform Architect認定で！
MCPA-Level-1日本語練習テストPDF試験材料
質問 # 73
API 実装は、CloudHub 上の単一のワーカーにデプロイされ、外部 API クライアント (CloudHub の外部) によって呼び出されます。API 実装が API 呼び出しに応答しなくなるとすぐにトリガーされることが保証されているアラートを設定するにはどうすればよいですか?
- A. API 内にハートビート/ヘルス チェックを実装し、Anypoint Platform の外部から呼び出して、ハートビートが応答しない場合にアラートを出す
- B. Anypoint Runtime Manager で「ワーカーが応答していません」アラートを構成する
- C. API が指定された期間内にリクエストを受信しなかった場合のアラートを作成します
- D. 呼び出し元の API クライアント内で API 呼び出しの例外を処理し、API が使用できない場合にその API クライアントからアラートを生成します。
正解：B
解説：
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
質問 # 74
API 実装は、要求している API クライアントに 3 つの X-RateLimit-* HTTP 応答ヘッダーを返します。これらの応答ヘッダーは、API クライアントにどのような種類の情報を示していますか?
- A. HTTP レスポンス サイズ
- B. API 実装によって許容される残りの容量
- C. 次のリクエストで送信する相関 ID
- D. スロットリングによるエラー コード
正解：B
解説：
正解: API 実装によって許可される残りの容量。
********************************************
>>参照: https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies#response-headers
質問 # 75
顧客は、MuleSoft アプリケーションを CloudHub 1.0 でホストしたいと考えています。これらのアプリケーションは、ドメイン https://api.acmecorp.com で利用できる必要があります。
acme-dib-prod という専用ロードバランサー (DLB) を作成した後、構成を完了するために顧客がさらに実行する必要があるアクションは何ですか?
- A. api.acmecorp.com の TLS 証明書を使用して DLB を構成し、api から CNAME レコードを作成します。
acmecorp.com から acme-dib-prod.|lb.anypointdns.net へ - B. api.acmecorp.com の TLS 証明書を使用して DLB を構成し、api の A レコードを作成します。
acmecorp.com を DLB に関連付けられたパブリック IP アドレスに接続します。 - C. acme-dib-prod.Jb.anypointdns.net の TLS 証明書を使用して DLB を設定し、api.acmecorp:com から acme-dlb-prod.lb.anypointdns.net への CNAME レコードを作成します。
- D. aplacmecorp.com の TLS 証明書を使用して DLB を構成し、api.aomecorp.com から acme-dib-prod.ei.cloubhub.io への CNAME レコードを作成します。
正解：A
解説：
When setting up a custom domain for MuleSoft applications hosted on CloudHub 1.0 using a Dedicated Load Balancer (DLB), follow these steps:
* Set Up the TLS Certificate: Configure the DLB (acme-dib-prod) with a TLS certificate that covers the custom domain api.acmecorp.com. This certificate will allow HTTPS traffic to be securely directed through the DLB to your Mule applications.
* DNS Configuration with CNAME:
* Create a CNAME record that points api.acmecorp.com to the DLB hostname acme-dib-prod.lb.
anypointdns.net.
* The CNAME record enables the custom domain to resolve to the DLB provided by MuleSoft's Anypoint Platform. This CNAME mapping directs all traffic to the correct DLB for processing and load distribution.
* Why Option B is Correct:
* A CNAME record provides the necessary aliasing to acme-dib-prod.lb.anypointdns.net, which is the endpoint managed by Anypoint Platform for your DLB.
* Option B also correctly identifies the need to configure the DLB with a TLS certificate specifically for api.acmecorp.com rather than for the DLB's internal hostname.
* Explanation of Incorrect Options:
* Options that suggest configuring the DLB with a TLS certificate for the DLB's internal hostname or using an A record are not suitable in this scenario. MuleSoft CloudHub 1.0 DLBs work with CNAME records to provide flexible and scalable domain management, and a direct IP (A record) is not supported for these load balancers.
ReferencesFor more information on configuring custom domains and DLBs on CloudHub 1.0, refer to the MuleSoft documentation on DLB setup and DNS configuration.
質問 # 76
API 実装を Anypoint VPC にデプロイする必要があるのはいつですか?
- A. パブリック アクセスを許可しない制限された顧客ホスト型ネットワークのサブネット内で API 実装にアクセスできる必要がある場合
- B. Mule Maven プラグインを使用して API 実装を本番 AWS VPC にデプロイする必要がある場合
- C. API 実装が、お客様が管理する AWS インスタンスで CloudHub の外部にデプロイされた公開サービスを呼び出す必要がある場合
- D. API 実装が永続オブジェクト ストアに書き込む必要がある場合
正解：C
質問 # 77
特定のビジネス プロセスを実装するために、粗粒度の API デプロイ モデルではなく細粒度の API デプロイ モデルを使用した場合の典型的な結果は何ですか?
- A. 各きめ細かな API が消費するリソースが少ないため、リソースの全体的なタワー使用量
- B. ビジネス プロセスをサポートするアプリケーション ネットワーク内の接続数の減少
- C. アプリケーション ネットワークで検出可能な API 関連アセットの数が多い
- D. API の範囲と複雑さが小さくなった結果、エンド ユーザーの応答時間が短縮されました。
正解：C
解説：
正解: アプリケーション ネットワークで検出可能な API 関連アセットの数が多い。
********************************************
>> 粗粒度のアプローチと比較して、細粒度のアプローチでは応答時間が速くなりません。
>> 実際、粒度の細かい API モデルを持つネットワークよりも、粒度の粗い API を持つネットワークの方が応答時間が速くなります。理由は以下です。
きめの細かいアプローチ:
1. 粗視化に比べて API が多くなる
2. したがって、ビジネス プロセスで機能を実現するには、さらにオーケストレーションを行う必要があります。
3. つまり、多数の API 呼び出しを行う必要があります。したがって、より多くの接続を確立する必要があります。そのため、バルク機能が組み込まれた API が少ない粗粒度アプローチと比較して、明らかにホップ数、ネットワーク I/O 数、統合ポイント数が多くなります。
4. これが、これらすべての余分なホップと追加のレイテンシーのために、粗粒度アプローチに比べて細粒度アプローチの応答時間が少し長くなる理由です。
5. 遅延と接続が追加されるだけでなく、API の数が増えるため、きめの細かいアプローチでより多くのリソースが消費されます。
そのため、細粒度の API は、ネットワーク内でより多くの再利用可能なアセットを公開し、それらを発見できるようにするのに適しています。ただし、ネットワーク ホップと応答時間に関して少し妥協して、統合ポイント、接続、リソースを処理する、より多くのメンテナンスが必要です。
質問 # 78
組織は、今日の見積もりをキャッシュする Quote of the Day API を実装しています。
オブジェクト ストア コネクタ経由で GoudHub オブジェクト ストアを使用して、キャッシュの状態を永続化できるシナリオはどれですか?
- A. キャッシュ状態を共有する必要がある 3 つの CloudHub ワーカーへの API 実装の 1 つの CloudHub デプロイがある場合
- B. CloudHub への API 実装のデプロイと、顧客がホストする Mule ランタイムへの anottV デプロイがあり、キャッシュ状態を共有する必要がある場合
- C. API 実装の 3 つの CloudHub デプロイメントが、キャッシュ状態を共有する必要がある 3 つの個別の CloudHub リージョンにある場合
- D. キャッシュ状態を共有する必要がある同じ CloudHub リージョンに、2 つの Anypoint Platform ビジネス グループによる API 実装の 2 つの CloudHub デプロイがある場合
正解：A
解説：
正解: API 実装の 1 つの CloudHub デプロイメントが、キャッシュ状態を共有する必要がある 3 つの CloudHub ワーカーにある場合。
********************************************
シナリオの主な詳細:
>> Object Store コネクタ経由で CloudHub Object Store を使用する
上記の詳細を考慮すると、次のようになります。
>> CloudHub オブジェクト ストアは、CloudHub Mule アプリケーションと 1 対 1 の関係にあります。
>> オブジェクト ストア コネクタを使用して、アプリケーションの CloudHub オブジェクト ストアを、異なるリージョンまたはビジネス グループで実行されている複数の Mule アプリケーション、またはお客様がホストする Mule ランタイム間で共有することはできません。
>> 本当に必要で、非常に必要な場合、Anypoint Platform は Object Store REST API を使用して別のアプリケーションの CloudHub Object Store へのアクセスを許可する方法をサポートします。ただし、Object Store コネクタは使用しません。
そのため、オブジェクト ストア コネクタ経由で CloudHub オブジェクト ストアを使用してキャッシュの状態を保持できる唯一のシナリオは、キャッシュ状態を共有する必要がある複数の CloudHub ワーカーに API 実装の 1 つの CloudHub デプロイがある場合です。
質問 # 79
大手融資会社が、データベース サーバーと Web サーバーからデータをロック解除する API を開発しました。この API は、CloudHub 1.0 上の Anypoint Virtual Private Cloud (VPC) にデプロイされています。
データベース サーバーと Web サーバーは顧客の安全なネットワーク内にあり、パブリック インターネットからはアクセスできません。データベース サーバーは顧客の AWS VPC 内にあり、Web サーバーは顧客のオンプレミスの企業データ センター内にあります。
API がデータベース サーバーおよび Web サーバーに接続できるようにアクセスを有効にするにはどうすればよいでしょうか?
- A. AWS VPCと顧客のオンプレミス企業データセンターとのVPCピアリングを設定する
- B. AWS VPC を介して顧客のオンプレミス企業データセンターへのトランジットゲートウェイをセットアップする
- C. 顧客のオンプレミス企業データセンターとの VPC ピアリングと AWS VPC への VPN トンネルを設定します。
- D. AWS VPC との VPC ピアリングと、顧客のオンプレミス企業データセンターへの VPN トンネルを設定します。
正解：D
解説：
* 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.
質問 # 80
プロセス API に適用される可能性が最も低い API ポリシーはどれですか?
- A. カスタム サーキット ブレーカー
- B. JSON 脅威保護
- C. レート制限
- D. クライアント ID の強制
正解：B
解説：
正解: JSON 脅威保護
********************************************
事実: 技術的には、どのポリシーをどのレイヤーに適用できるかについて制限はありません。任意のレイヤー API に任意のポリシーを適用できます。ただし、やみくもに API にポリシーを適用する前に、コンテキストも適切に考慮する必要があります。
そのため、この質問では、プロセス API に適用される可能性が最も低いポリシーを求めました。
指定されたオプションから:
>> 「JSON 脅威保護」を除くすべてのポリシーは、プロセス層の API にためらうことなく適用できます。
>> JSON 脅威保護ポリシーはエクスペリエンス API に最適で、外部 API クライアントからの疑わしい JSON ペイロードを防ぎます。これは、エクスペリエンス API を呼び出す外部クライアントからの悪意のある有害な JSON ペイロードを回避しようとすることで、より多くのセキュリティ面をカバーします。
外部 API クライアントがプロセス API を直接呼び出すことは決して許可されておらず、また、この種の悪意のある有害な JSON ペイロードは、このポリシーのみを使用してエクスペリエンス API レイヤーで常に停止されるため、この同じポリシーがプロセス レイヤー API に再び適用される可能性はほとんどありません。
質問 # 81
展示品を参照してください。
3 つのビジネス プロセスを実装する必要があり、実装では複数の異なる SaaS アプリケーションと通信する必要があります。
これらのプロセスは、個別の (サイロ化された) LOB によって所有され、主に互いに独立していますが、いくつかのビジネス エンティティを共有しています。各 LOB には 1 つの開発チームと独自の予算があります。この組織のコンテキストでは、データ モデルの冗長性を最小限に抑えてこれらのビジネス プロセスを実装する API の API データ モデルを選択する最も効果的な方法は何ですか。
A) ビジネスプロセスの一貫した部分と関連するビジネスエンティティの定義に一致する複数の境界付きコンテキストデータモデルを構築する
B) 確立されたマイクロサービスとアジャイル API 中心のプラクティスに従うために、各 API に個別のデータ モデルを構築する C) 組織全体で一貫性と再利用を促進するために、XML スキーマを使用してすべての API データ モデルを構築する D) 3 つのビジネス プロセスのすべてのデータ タイプを統合し、データ モデルの一貫性と冗長性を確保する 1 つの集中型標準データ モデル (エンタープライズ データ モデル) を構築する
- A. オプションB
- B. オプションA
- C. オプションC
- D. オプションD
正解：B
解説：
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.
質問 # 82
Anypoint Platform REST API、Anypoint CU、Mule Maven プラグインなどのツールを使用した Anypoint Platform との対話の自動化について正しいのはどれですか?
- A. デフォルトでは、Anypoint CLI と Mule Maven プラグインは Mule ランタイムに含まれていないため、デプロイされた Mule アプリケーションでは使用できません。
- B. Anypoint Platform API は CloudHub との対話のみを自動化できますが、顧客がホストする Mule ランタイムへのデプロイには Mule Maven プラグインが必要です。
- C. Anypoint Platform API と Anypoint CU へのアクセスは、Anypoint Platform のロールと権限によって個別に制御できるため、特定のユーザーは Anypoint CLI にアクセスでき、他のユーザーはプラットフォーム API にアクセスできます。
- 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.
質問 # 83
あるヨーロッパの企業はヨーロッパ全土に顧客を抱えており、IT 部門は古いプラットフォームから MuleSoft に移行しています。主な要件は、新しいプラットフォームではダウンタイムなしでの再展開と複数のランタイム バージョンへのアプリケーションの展開が可能であること、セキュリティと速度が提供されること、メッセージ サービスとして Anypoint MQ が利用できることです。
追加のネットワーク構成なしで、要件に基づいてどのランタイム プレーンを選択する必要がありますか?
- A. ランタイムプレーン用のセルフマネージドKubernetes上のAnypoint Runtime Fabric
- B. ランタイムプレーン用の VM / ベアメタル上のランタイムファブリック
- C. MuleSoft がホストするランタイム プレーン (CloudHub)
- D. 顧客ホストのランタイムプレーン
正解：C
質問 # 84
組織は、最新の API (MuleSoft によって定義されている) を使用して再利用可能な IT 資産の消費を強調する IT 運用モデルに移行するという戦略的な決定を下します。
この新しい IT 運用モデルに関連する各最新 API を最もよく表しているのはどれですか?
- A. 各最新 API は REST および HTTP ベースである必要があります
- B. 最新の各 API は使いやすくなければならないため、SAML や JWT D などの複雑な認証メカニズムを避ける必要があります。
- C. 最新の API にはそれぞれ独自のソフトウェア開発ライフサイクルがあり、ドキュメント化と自動化の必要性が減ります。
- D. 各モデム API は製品のように扱われ、特定の対象ユーザー (モバイル アプリ開発者など) 向けに設計されている必要があります。
正解：D
解説：
正解:
1. 各最新 API は製品のように扱われ、特定の対象ユーザー (モバイル アプリ開発者など) 向けに設計されている必要があります。
********************************************
質問 # 85
ある小売会社は、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. 2 つの CloudHub ワーカーのそれぞれのサイズを、少なくとも 4 倍 (4x) ずつ 1 つの仮想コアに永続的に増やします。
- C. CloudHub ワーカーの数を 4 倍 (4x) から 8 つの CloudHub ワーカーに永続的に増やします。
- D. CPU 使用率が 70% を超えるとトリガーされる水平 CloudHub 自動スケーリング ポリシーを使用します。
正解：D
解説：
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.
質問 # 86
コード中心の API ドキュメント環境では、API コンシューマーが、代表的なシナリオの一部として 1 つ以上の API を呼び出す方法を示す API クライアント ソース コードを調査および実行できるようにする必要があります。
Anypoint Platform を使用して、この種のコード中心の API ドキュメント環境を提供する最も効果的な方法は何ですか?
- A. API ノートブックを作成し、関連する Anypoint Exchange エントリに含めます。
- B. Anypoint Exchange エントリと API コンソールを通じて API が十分に文書化されていることを確認し、これらのページをすべての API コンシューマーと共有します。
- C. 関連する API ごとにモック サービスを有効にし、Anypoint Exchange エントリを介してそれらを公開します。
- D. 関連する API を Anypoint Exchange エントリを介して検出できるようにする
正解：A
解説：
Create API Notebooks and Include them in the relevant Anypoint exchange entries
*****************************************
>> API Notebooks are the one on Anypoint Platform that enable us to provide code-centric API documentation
質問 # 87
API では、クライアント リクエスト (TPS) vth 小さなメッセージ ペイトアドの割合が高くなります。クライアント アプリケーションの種類に基づいて、API に使用制限を課すにはどうすればよいですか?
- A. SLA ベースのレート制限ポリシーを使用し、クライアント アプリケーションをそのタイプに基づいて一致する SLA 層に割り当てます。
- B. クロスオリジン リソース共有 (CORS) ポリシーを使用して、クライアント アプリケーションの種類によって構成された、クライアント アプリケーション間のリソース共有を制限します。
- C. レート制限ポリシーとクライアント ID 強制ポリシーを使用します。それぞれクライアント アプリケーション タイプによって構成されます。
- D. クライアント アプリケーションの種類ごとに要求数を制限するスパイク制御ポリシーを使用する
正解：A
質問 # 88
運用チームは、アプリケーション ネットワークの監視を設定するために必要な作業を分析しています。カスタム スクリプトを作成したり、追加の分析ソフトウェアやツールをインストールしたりすることなく、どの API 呼び出しメトリックを使用してトラブルを特定および予測できるかを検討しています。
障害を直接特定して予測するという目標を満たすことができるのは、どのタイプのメトリックですか?
- A. 各APT呼び出しからのROI
- B. 1日あたりのAPIポリシー違反の数と種類
- C. 再利用レベルに基づくアプリケーションネットワークの有効性
- D. アプリケーションネットワーク全体での過去のAPI呼び出しの数と種類
正解：B
解説：
To monitor an application network and predict issues without custom scripts, policy violation metrics are critical. They provide insights into potential problems by tracking instances where API usage does not conform to defined policies. Here's why this approach is suitable:
* Predictive Monitoring:
* Tracking API policy violations (such as rate limits or spike controls being hit) can indicate surges in traffic or misuse, which may lead to throttling or service degradation if not addressed.
* By monitoring these violations, teams can proactively adjust limits or optimize API handling to prevent actual failures.
* No Custom Scripting Needed:
* Policy violation metrics are available within MuleSoft's Anypoint Monitoring, meaning there's no need to implement custom solutions or external tools to gather and interpret this data.
* Explanation of Incorrect Options:
* Option B (effectiveness based on reuse) does not directly predict failures.
* Option C (past invocation counts) offers historical usage data but does not inherently identify issues.
* Option D (ROI from API invocation) is a business metric and does not provide technical insights for failure prediction.
ReferencesFor more details on leveraging policy violation metrics for proactive monitoring, refer to MuleSoft documentation on Anypoint Monitoring.
質問 # 89
API 実装が更新されました。API の RAML 定義もいつ更新する必要がありますか?
- A. API の実装が、オンプレミスにデプロイされた従来のバックエンド システムとのやり取りから、最新のクラウドベース (SaaS) システムに変更される場合
- B. 平均応答時間を改善するために API 実装が最適化されている場合
- C. API 実装が要求または応答メッセージの構造を変更する場合
- D. API 実装が Mule ランタイムの古いバージョンから新しいバージョンに移行される場合
正解：C
解説：
When the API implementation changes the structure of the request or response messages
*****************************************
>> RAML definition usually needs to be touched only when there are changes in the request/response schemas or in any traits on API.
>> It need not be modified for any internal changes in API implementation like performance tuning, backend system migrations etc..
質問 # 90
Anypoint Platform が提供する API 呼び出しメトリクスは何を提供しますか?
- A. 特定の脅威のしきい値を超える可能性がある将来のポリシー違反のプロアクティブな識別
- B. 過去の API 呼び出しに関するデータで、さまざまな API の異常や使用パターンを特定するのに役立ちます
- C. ビジネス ユーザーと直接共有できる API からの ROI 指標
- D. 再利用のレベルに基づくアプリケーション ネットワークの有効性の測定
正解：B
解説：
正解: 過去の API 呼び出しに関するデータは、さまざまな API の異常と使用パターンを特定するのに役立ちます
********************************************
Anypoint Platform によって提供される API 呼び出しメトリクス:
>> 投資収益率 (ROI) 関連の情報は一切提供しません。したがって、それを示唆するオプションはアウトです。
>> API がどのように再利用されているか、API が効果的に使用されているかどうかなどについての情報は提供しません。
>> 将来のポリシー違反を積極的に特定するのに役立つ予測情報を提供しません。
そのため、このようなメトリクスから取得できるデータ/情報の種類は、過去の API 呼び出しに関するものであり、さまざまな API の異常や使用パターンを特定するのに役立ちます。
質問 # 91
ある組織では、InfoSec チームが Anypoint Platform 関連のデータ トラフィックを調査しています。
Anypoint Platform でモニタリングとアラートに使用できるデータのほとんどは、どこから取得されますか?
- A. データのタイプに応じて、Mule ランタイムまたは API Manager から
- B. 展開モデルに応じて、Mule ランタイムまたは API 実装から
- C. デプロイ モデルに関係なく、Mule ランタイムから
- D. 共有ロード バランサ、VPC、Mule ランタイムなど、Anypoint Platform のさまざまなコンポーネントから
正解：C
解説：
正解: デプロイ モデルに関係なく Mule ランタイムから
********************************************
>> モニタリングとアラートのメトリクスは、デプロイ モデルに関係なく、常に Mule Runtime から生成されます。
>> 一部のメトリクス (Runtime Manager) は Mule Runtime に由来し、一部のメトリクス (API Invocations/ API Analytics) は API Manager に由来するように見える場合があります。ただし、これは現実的には真実ではありません。その理由は、API マネージャは API インスタンスの単なる管理ツールですが、API に適用するすべてのポリシーは、最終的に Mule Runtimes (組み込みまたは API プロキシのいずれか) でのみ実行されるためです。
>> 同様に、すべての API 実装も Mule ランタイムで実行されます。
そのため、監視とアラートに必要な 1 日のほとんどは、展開モデルが MuleSoft によってホストされているか、顧客によってホストされているか、またはハイブリッドであるかに関係なく、Mule Runtimes のみから発信されます。
質問 # 92
組織は、OrderStatus System API の新しい実装を CloudHub の複数のワーカーにデプロイしています。この API は、IPsec トンネルを介して API 実装によってアクセスされる、組織のオンプレミス注文管理システムの前にあります。
通常、OrderStatus システム API のサービス停止に至らないエラーの種類はどれですか?
- A. 組織のオンプレミス データ センターでネットワークが停止しているため、注文管理システムにアクセスできません
- B. API 実装の初期デプロイ中に API Manager が長時間停止する
- C. AWS リージョンは、関連する AWS データ センターへの主要なネットワーク障害でオフラインになります
- D. CloudHub ワーカーがメモリ不足の例外で失敗する
正解：D
解説：
A CloudHub worker fails with an out-of-memory exception.
*****************************************
>> An AWS Region itself going down will definitely result in an outage as it does not matter how many workers are assigned to the Mule App as all of those in that region will go down. This is a complete downtime and outage.
>> Extended outage of API manager during initial deployment of API implementation will of course cause issues in proper application startup itself as the API Autodiscovery might fail or API policy templates and polices may not be downloaded to embed at the time of applicaiton startup etc... there are many reasons that could cause issues.
>> A network outage onpremises would of course cause the Order Management System not accessible and it does not matter how many workers are assigned to the app they all will fail and cause outage for sure.
The only option that does NOT result in a service outage is if a cloudhub worker fails with an out-of-memory exception. Even if a worker fails and goes down, there are still other workers to handle the requests and keep the API UP and Running. So, this is the right answer.
質問 # 93
Mule アプリケーションが CloudHub 共有ワーカー クラウドにデプロイされたときに作成される完全修飾ドメイン名 (FQDN) (別名 DNS エントリ) を最もよく表しているのはどれですか?
- A. FQDN はアプリケーション名によって決定されますが、展開後に管理者が変更できます
- B. 固定数の FQDN が作成され、環境と VPC の設計に関係なく作成されます
- C. FQDN は、アプリケーション名と Anypoint Platform 組織の両方によって決定されます。
- D. FQDN は、選択したアプリケーション名によって決まります。地域に関係なく、
正解：D
解説：
The FQDNs are determined by the application name chosen, IRRESPECTIVE of the region
*****************************************
>> When deploying applications to Shared Worker Cloud, the FQDN are always determined by application name chosen.
>> It does NOT matter what region the app is being deployed to.
>> Although it is fact and true that the generated FQDN will have the region included in it (Ex: exp- salesorder-api.au-s1.cloudhub.io), it does NOT mean that the same name can be used when deploying to another CloudHub region.
>> Application name should be universally unique irrespective of Region and Organization and solely determines the FQDN for Shared Load Balancers.
質問 # 94
ある組織では、Center for Enablement (C4E) を設立したいと考えています。IT ディレクターは、IT シニア マネージャーとの一連の会議をスケジュールします。
最初の会議の議題には何を含めるべきでしょうか?
- A. C4Eの目的、ミッションステートメント、指針、
- B. MuleSoft 統合部門の運用モデルを指定します
- C. MuleSoft を通じて特定されたユースケースに基づいて API 収益化オプションを探索する
- D. ログ記録、監査、例外処理、キャッシュ、ポリシーによるセキュリティ、ポリシーによるレート制限/スロットリングに関する共通サービスのベストプラクティスのウォークスルー
正解：A
解説：
In the initial meeting for establishing a Center for Enablement (C4E), it's essential to lay the foundational vision, objectives, and guiding principles for the team. Here's why this is crucial:
* Clear Vision and Mission:
* Defining the mission statement and objectives at the start ensures alignment within the organization and clarifies the C4E's role in supporting API-led development and integration practices.
* Guiding Principles:
* Establishing guiding principles will help the C4E maintain consistent practices and strategies across projects. This serves as a framework for decisions and fosters shared understanding among IT leaders and stakeholders.
* Explanation of Correct Answer (A):
* By prioritizing the C4E's objectives and mission, the organization builds a solid foundation, paving the way for subsequent meetings focused on technical standards, processes, and operating models.
* Explanation of Incorrect Options:
* Option B (API monetization) and Option C (common services best practices) are specific topics better suited for later discussions.
* Option D (specifying the operating model) is an important step but typically follows the establishment of the C4E's objectives and vision.
ReferencesFor more on C4E objectives and foundational setup, refer to MuleSoft's documentation on establishing a C4E and the roles and mission statements recommended for such initiatives.
質問 # 95
次の順序のうち、正しいものはどれですか?
- 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 にルーティングします
正解：B
解説：
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 bysome 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.
質問 # 96
多数の REST API を実装する Mule アプリケーションは、組織外からアクセスできない独自のサブネットにデプロイされます。
外部のビジネス パートナーは、これらの API にアクセスする必要があります。これらの API は、パートナー専用の別のサブネット (Partner-subnet と呼ばれます) からのみ呼び出すことができます。このサブネットはパブリック インターネットからアクセスできるため、これらの外部パートナーはサブネットにアクセスできます。
Anypoint Platform と Mule ランタイムは、パートナー サブネットに既にデプロイされています。これらの Mule ランタイムは、すでに API にアクセスできます。
現在 API を使用している他のアプリケーションへの影響を最小限に抑えながら、これらの要件に準拠するための最もリソース効率の高いソリューションは何ですか?
- A. Mule ランタイムを実行している同じサーバーに API 実装を再デプロイします。
- B. パートナーが使用できるようにするために、各 API に追加のエンドポイントを追加します。
- C. API を Mule アプリケーションとして複製し、Mule ランタイムにデプロイします。
- D. API ごとに API プロキシ Mule アプリケーションを実装 (または生成) し、API プロキシを Mule ランタイムにデプロイします。
正解：D
質問 # 97
次の順序のうち、正しいものはどれですか?
- 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 にルーティングします
正解：B
解説：
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.
質問 # 98
......
MCPA-Level-1日本語[2025年05月] 最新リリース] 試験問題あなたを必ず合格させます：https://www.goshiken.com/MuleSoft/MCPA-Level-1-JPN-mondaishu.html