[更新されたのは2023年]MuleSoft MCPA-Level-1日本語問題準備には無料サンプルのPDF [Q19-Q34]

[更新されたのは2023年]MuleSoft MCPA-Level-1日本語問題準備には無料サンプルのPDF

2023年最新の認定サンプル問題MCPA-Level-1日本語問題集と練習試験合格させます

質問 # 19
Anypoint Exchange の API は、承認されたセマンティックバージョニングの慣行に従って API プロデューサーによってバージョン 3.1.1 から 3.2.0 に更新され、変更は API のパブリックポータルを介して通知されました。
API エンドポイントは、新しいバージョンでは変更されません。
API クライアントの開発者は、この変更にどのように対応する必要がありますか?

A. 更新はプロジェクトリスクとして識別し、この API を使用する機能の完全な回帰テストを実行する必要があります。
B. API プロデューサーに連絡して、既存の機能への変更を理解する必要があります。
C. API クライアントコードは、新しい機能を利用する必要がある場合にのみ変更する必要があります。
D. API プロデューサーは、新しいバージョンと並行して古いバージョンを実行するように要求する必要があります。

正解：C

質問 # 20
Anypoint Platform 組織は、ID 管理とクライアント管理用の外部 ID プロバイダー (IdP) で構成されています。Anypoint Platform API に対してコマンドを実行するには、Anypoint CLI にどの資格情報またはトークンを提供する必要がありますか?

A. クライアント管理のために IdP によって提供される資格情報
B. ID 管理のために IdP によって提供される資格情報
C. ID 管理のために IdP によって提供された資格情報を使用して生成された OAuth 2.0 トークン
D. クライアント管理用に IdP によって提供された資格情報を使用して生成された OAuth 2.0 トークン

正解：B

解説：
正解: ID 管理のために IdP によって提供される資格情報
********************************************
リファレンス：
>> クライアント/ID プロバイダーからの OAuth 2.0 トークンを Anypoint CLI 経由で認証することはサポートされていません。可能なトークンのみが、https://anypoint.mulesoft.com/accounts/login からの Anypoint 組織/環境クライアント ID とシークレットを使用してのみ生成される「ベアラートークン」です。クライアントプロバイダーのクライアント資格情報ではありません。したがって、OAuth 2.0 は使用できません。さらに、トークンは主に API Manager 用であり、ユーザーには関連付けられていません。この Mulesoft ナレッジ記事に従って、ほとんどの API (Cloudhub など) を呼び出すために使用することはできません。
>> Anypoint CLI で許可されているもう 1 つのオプションは、クライアント資格情報を使用することです。クライアントプロバイダーのクライアント資格情報を使用することは可能ですが、クライアント管理で接続アプリを設定する必要がありますが、そのような詳細は質問で説明されているシナリオには記載されていません。
>> したがって、残された唯一のオプションは、identify プロバイダーからのユーザー資格情報を使用することです

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

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

正解：B

解説：
正解: Anypoint exchange で適切な既存のフォールバック API を検索し、注文 API に加えてこのフォールバック API への呼び出しを実装します
********************************************
>> API クライアントとの間で、HTTP 3xx の一時的なリダイレクトステータスコードを受け取り、別の API を呼び出すためにフォールバックロジックを実装する必要があるという事前承認済みの合意がない限り、これは理想的で適切なアプローチではありません。
>> API マネージャーで同じ注文 API の別のエントリを作成すると、同じ API 実装の上に別のインスタンスが作成されるだけです。そのため、同じ API のクローンをフォールバック API として使用しても意味がありません。フォールバック API は、理想的には、プライマリ API とは異なる別の API 実装である必要があります。
>>現在、応答で特定の HTTP ステータスコードを受信したときにフォールバック API を呼び出すことができる Anypoint HTTP コネクタによって提供されるオプションはありません。
指定されたオプションで唯一の文 TRUE は、Anypoint exchange で適切な既存のフォールバック API を検索し、注文 API に加えてこのフォールバック API への呼び出しを実装することです。

質問 # 22
API 実装での自動検出の使用を最もよく説明しているのはどれですか?

A. Anypoint Exchange がアセットを検出し、再利用できるようにします。
B. Anypoint Analytics が API の使用状況を把握できるようにします。
C. API Manager に API 実装を認識させ、ポリシーを適用できるようにします。
D. Anypoint Studio が Anypoint Platform で構成された API 定義を検出できるようにします。

正解：C

解説：
正解: API Manager に API 実装を認識させ、ポリシーを適用できるようにします。
********************************************
>> API Autodiscovery は、デプロイされたアプリケーションをプラットフォーム上で作成された API とペアリングすることにより、API Manager から API を管理するメカニズムです。
>> API Management には、追跡、適用する場合のポリシーの適用、および API 分析のレポートが含まれます。
>> 自動検出プロセスにとって重要なのは、API の名前とバージョンを提供して API を識別することです。
参考文献:
https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-concept
https://docs.mulesoft.com/api-manager/1.x/api-auto-discovery
https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-concept

質問 # 23
API は、承認されたセマンティックバージョニングの慣行に従い、その API プロデューサーによって Anypoint exchange でバージョン 3.1.1 から 3.2.0 に更新され、変更は API パブリックポータルを介して通知されました。API エンドポイントは、新しいバージョンでは変更されません。API クライアントの開発者は、この変更にどのように対応する必要がありますか?

A. API プロデューサーに連絡して、既存の機能への変更を理解する必要があります。
B. API クライアントコードは、新しい機能を利用する必要がある場合にのみ変更する必要があります。
C. API クライアント側でコードを更新し、完全な回帰を行う必要があります。
D. API プロデューサーは、新しいバージョンと並行して古いバージョンを実行するように要求する必要があります。

正解：B

質問 # 24
多数の REST API を実装する Mule アプリケーションは、組織外からアクセスできない独自のサブネットにデプロイされます。
外部のビジネスパートナーは、これらの API にアクセスする必要があります。これらの API は、パートナー専用の別のサブネット (Partner-subnet と呼ばれます) からのみ呼び出すことができます。このサブネットはパブリックインターネットからアクセスできるため、これらの外部パートナーはサブネットにアクセスできます。
Anypoint Platform と Mule ランタイムは、パートナーサブネットに既にデプロイされています。これらの Mule ランタイムは、すでに API にアクセスできます。
現在 API を使用している他のアプリケーションへの影響を最小限に抑えながら、これらの要件に準拠するための最もリソース効率の高いソリューションは何ですか?

A. API を Mule アプリケーションとして複製し、Mule ランタイムにデプロイします。
B. API ごとに API プロキシ Mule アプリケーションを実装 (または生成) し、API プロキシを Mule ランタイムにデプロイします。
C. Mule ランタイムを実行している同じサーバーに API 実装を再デプロイします。
D. パートナーが使用できるようにするために、各 API に追加のエンドポイントを追加します。

正解：B

質問 # 25
システム API は、プライマリ環境とディザスターリカバリー (DR) 環境にデプロイされ、環境ごとに異なる DNS 名が使用されます。プロセス API はシステム API のクライアントであり、システム API によってレート制限されており、環境ごとに異なる制限があります。システム API の DR 環境は、プライマリ環境によって提供されるレート制限の 20% しか提供しません。これらの条件と制約を考慮して、プロセス API の全体的なエラーを減らすための最良の API フォールトトレラント呼び出し戦略は何ですか?

A. プライマリ環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。それでも失敗する場合は、DR 環境にデプロイされたシステム API を呼び出します
B. 並行して、プライマリ環境にデプロイされたシステム API と DR 環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。プロセス API にロジックを追加して結果を組み合わせる
C. プライマリ環境にデプロイされたシステム API を呼び出します。再試行ロジックをプロセス API に追加して、DR 環境にデプロイされたシステム API を呼び出して断続的な障害を処理する
D. プライマリ環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。それでも失敗する場合は、DR 環境にデプロイされたプロセス API のコピーを呼び出します

正解：A

解説：
正解: プライマリ環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。それでも失敗する場合は、DR 環境にデプロイされたシステム API を呼び出します
********************************************
質問で注意すべき重要な考慮事項が 1 つあります。それは、DR 環境のシステム API は、プライマリ環境によって提供されるレート制限の 20% しか提供しないということです。そのため、プライマリ環境とは対照的に、DR 環境 API に許可される呼び出しは比較的少なくなります。これを念頭に置いて、適切で最適なフォールトトレラントな呼び出し戦略を分析してみましょう。
1. DR 環境には 20% の制限があるため、両方のシステム API を並行して呼び出すことは、現実的なアプローチではありません。毎回並行して呼び出すと、DR 環境のレート制限を簡単かつ迅速に使い果たしてしまい、必要なときに真の断続的なエラーシナリオを許容する機会が得られない可能性があります。
2. 与えられた別のオプションは、プライマリ環境のシステム API を呼び出すときに API を処理するためにタイムアウトと再試行ロジックを追加することを提案することです。ここまでは良いです。ただし、すべての再試行が失敗した場合、オプションは DR 環境でプロセス API のコピーを呼び出すことを提案していますが、これは正しくないか、推奨されていません。フォールバックの対象となるのはシステム API のみであり、プロセス API 全体ではありません。通常、プロセス API には、他の多くの API を呼び出す重いオーケストレーションが多数含まれており、DR のプロセス API を呼び出すことによって、それらを繰り返したくありません。したがって、このオプションは適切ではありません。
3. 与えられたもう 1 つのオプションは、最初にプライマリ環境のシステム API を再試行する代わりに、API を処理するための再試行 (タイムアウトなし) ロジックを追加して、DR 環境のシステム API で直接再試行することを提案することです。これは適切なフォールバックではありません。適切なフォールバックは、最初にプライマリ環境ですべての再試行が実行されて使い果たされた後にのみ発生する必要があります。ただし、ここでは、メイン API を試行せずに、最初の失敗自体でフォールバック API を直接再試行することをオプションが提案しています。したがって、このオプションも適切ではありません。
これにより、適切で最適なオプションが 1 つ残ります。
- プライマリ環境にデプロイされたシステム API を呼び出す
- プロセス API でタイムアウトと再試行ロジックを追加します。
・リトライしても失敗する場合は、DR環境に配備したシステムAPIを呼び出してください。

質問 # 26
Mule アプリケーションの単体テストを正しく特徴付けるものは何ですか?

A. 通常、MUnit を使用して記述され、外部接続を必要としない組み込み Mule ランタイムで実行されます。
B. ソースシステムとターゲットシステムの入出力の妥当性をテストします。
C. 外部のクライアントツールまたはイベントソースによってトリガーされる必要があります。
D. 環境専用の Mule ランタイムを備えた単体テスト環境で実行する必要があります。

正解：A

解説：
正解: これらは通常、MUnit を使用して記述され、外部接続を必要としない組み込み Mule ランタイムで実行されます。
********************************************
以下の 2 つは統合テストの特徴ですが、単体テストではありません。
>> ソースシステムとターゲットシステムの入出力の妥当性をテストします。
>> それらは、外部のクライアントツールまたはイベントソースによってトリガーされる必要があります。
環境専用の Mule ランタイムを備えた単体テスト環境で単体テストを実行する必要があるというのは正しくありません。
MuleSoft は単体テストを作成するための MUnit を提供しており、それらは組み込みの Mule ランタイムで実行され、実行するための個別の専用ランタイムは必要ありません。また、MUnit はスタブによるモックをサポートしているため、外部接続も必要ありません。
https://dzone.com/articles/munit-framework

質問 # 27
アップストリーム API とその実装を設計する際、ダウンストリーム API には信頼できる SLA がないため、開発チームはダウンストリーム API を呼び出すときにタイムアウトを設定しないようにアドバイスされています。これは、そのアップストリーム API の唯一のダウンストリーム API 依存関係です。
ダウンストリーム API がクラッシュすることなく中断なく実行されると仮定します。このアドバイスはどのような影響を与えますか?

A. アップストリーム API の SLA は提供できません
B. アップストリーム API 実装が実行される Mule ランタイムによって、500 ミリ秒のデフォルトのタイムアウトが自動的に適用されます。
C. ダウンストリーム API 実装が実行される Mule ランタイムによって、1000 ミリ秒未満のヒキガエル依存タイムアウトが適用されます。
D. ダウンストリーム API の呼び出しは、タイムアウトせずに完了するまで実行されます。

正解：A

解説：
正解: アップストリーム API の SLA は提供できません。
********************************************
>> まず最初に、HTTP コネクタのデフォルトの HTTP 応答タイムアウトは 10000 ミリ秒 (10 秒) です。500ミリ秒ではありません。
>> Mule ランタイムは、そのような「負荷依存」のタイムアウトを適用しません。現在、Mule にはそのような動作はありません。
>> HTTP コネクタにはデフォルトで 10000 ミリ秒のタイムアウトがあるため、SLA 時間が信頼できないため、ダウンストリーム API の呼び出しがタイムアウトせずに完了することを常に保証することはできません。応答時間が 10 秒を超えると、リクエストがタイムアウトになる可能性があります。
これによる主な影響は、アップストリーム API の適切な SLA を提供できないことです。

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

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

正解：B

解説：
正解: 説明、タイプ、および例を含む 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

質問 # 29
ある企業は、CloudHub にデプロイされた Mule アプリケーションを非本番環境と本番環境の間で分離する必要があります。これは、非実稼働環境にデプロイされた Mule アプリケーションが、顧客がホストする非実稼働環境で実行されているバックエンドシステムにのみアクセスできるようにするためであり、実稼働環境にデプロイされた Mule アプリケーションが、顧客がホストする実稼働環境で実行されているバックエンドシステムにのみアクセスできるようにするためです。MuleSoft は、Mule アプリケーションとバックエンドシステム間のこの種の環境ごとの分離をサポートするために、Mule アプリケーションの変更、環境の構成、またはインフラストラクチャの変更をどのように推奨していますか?

A. 対応する Anypoint Platform 環境の IP アドレスのみが対応するバックエンドシステムと通信できるように、顧客がホストする各環境内のインフラストラクチャでファイアウォールルールを構成します。
B. Anypoint Platform 本番環境にデプロイされた Mule アプリケーションのプロパティを変更して、非本番 Mule アプリケーションからのアクセスを防止します。
C. 非本番環境と本番環境用に別の Anypoint VPC を作成し、対応する顧客ホスト環境のバックエンドシステムへの接続を構成します。
D. 異なる Anypoint Platform ビジネスグループに非本番環境と本番環境を作成する

正解：C

解説：
正解: 非本番環境と本番環境用に別の Anypoint VPC を作成し、対応する顧客ホスト環境のバックエンドシステムへの接続を設定します。
********************************************
>> 異なるビジネスグループを作成しても、お客様がホストする非本番環境と本番環境へのアクセスに違いはありません。それでも、プロセスネットワークの制限が設定されていない限り、両方のビジネスグループからアクセスします。
>> Mule アプリケーションの実装を変更するか、環境と結合する必要があります。実際、環境をプロパティにバインドすることで環境と結合したアプリケーションを実装するべきではありません。エンドポイント URL などの基本的なもののみをプロパティにバンドルする必要がありますが、環境レベルのアクセス制限はバンドルしないでください。
>> CloudHub の IP アドレスは、特別な静的アドレスが割り当てられない限り動的です。そのため、顧客がホストするインフラストラクチャでファイアウォールルールを設定することはできません。さらに、たとえ静的 IP アドレスが割り当てられていたとしても、何百ものアプリケーションがクラウドハブで実行されている可能性があり、それらすべてにルールを設定することは多忙な作業であり、メンテナンスが不可能であり、間違いなく良い習慣になります.
>> Mulesoft (実際にはすべてのクラウドプロバイダー) が推奨するベストプラクティスは、Anypoint VPC を本番用と非本番用に分離し、これらの Anypoint VPC の VPC ピアリングまたは VPN トンネリングを、それぞれの本番用と非本番用の顧客に対して実行することです。ホスト環境ネットワーク。
リファレンス：

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

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

正解：B

解説：
システムレイヤー

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

質問 # 31
ある企業は、Mule API 実装をできるだけ早く本番環境に移行したいと考えています。すべての Mule アプリケーションのデータとメタデータへのアクセスを保護するために、会社はすべての Mule アプリケーションを企業のファイアウォール内の顧客がホストするインフラストラクチャに展開することを要求しています。これらのプロジェクトライフサイクルの目標を満たすランタイムプレーンとコントロールプレーンのオプションの組み合わせはどれですか?

A. iPaaS でプロビジョニングされた顧客がホストするランタイムプレーンと MuleSoft がホストするコントロールプレーン
B. 顧客がホストするランタイムプレーンと顧客がホストするコントロールプレーンを手動でプロビジョニング
C. MuleSoft がホストするランタイムプレーンと顧客がホストするコントロールプレーン
D. 顧客がホストするランタイムプレーンと MuleSoft がホストするコントロールプレーンを手動でプロビジョニング

正解：B

解説：
お客様がホストするランタイムプレーンとお客様がホストするコントロールプレーンを手動でプロビジョニング
********************************************
質問で示されたシナリオから考慮すべき 2 つの重要な要素があります。
>> 会社では、データとメタデータの両方を会社のファイアウォール内に常駐させる必要があります
>> 会社は、顧客がホストするインフラストラクチャを使用したいと考えています。
直接的または間接的にクラウド (Mulesoft がホストする、または Azure、AWS などのお客様独自のクラウド) を処理する展開モデルは、少なくともメタデータを共有する必要があります。
アプリケーションデータは、顧客がホストするランタイムプレーンに Mule ランタイムを配置することで、ファイアウォール内で制御できます。しかし、Mulsoft でホストされた/クラウドベースのコントロールプレーンを使用する場合、コントロールプレーンは、企業のファイアウォールの外側に送信されるために、少なくともいくつかの最小限のレベルのメタデータを必要としました。
お客様の要件は、データとメタデータの両方が企業のファイアウォール内にあることについて非常に明確であるため、お客様はできるだけ早く本番環境に移行したいと考えていますが、残念ながらセキュリティ要件の性質上、他の選択肢はありません。手動でプロビジョニングされた、顧客がホストするランタイムプレーンと顧客がホストするコントロールプレーンを使用します。

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

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

正解：A

解説：
CloudHub 共有ロードバランサー
********************************************
この質問のシナリオは、次のように分割できます。
>> 3 つの CloudHub ワーカーがあります (そのため、大量のリクエストを処理するのに十分な数のワーカーが既に存在します)
>> ワーカーは静的 IP アドレスを使用していません (したがって、静的 IP なしで顧客の負荷分散ソリューションを使用することはできません)
>> ワーカー間でクライアントリクエストの負荷を分散するための最も費用対効果の高いコンポーネントを探しています。
シナリオで指定された上記の詳細に基づいて:
>> ランタイムの自動スケーリングは、追加のコストが発生するため、まったく費用対効果が高くありません。ほとんどの場合、すでに 3 つのワーカーが実行されています。これは適切な数です。
>> お客様がホストするロードバランサーは費用対効果が最も高くなく (メンテナンスとライセンスのためにカスタムロードバランサーが必要)、Mule アプリケーションには静的 IP アドレスがないため、カスタムロードを使用することはできません。バランスをとる。
>> API プロキシは、大量の処理や負荷分散に関して果たす役割がないため、そこには関係ありません。
したがって、最も費用対効果の高いシナリオの目的に適合する唯一の適切なオプションは、CloudHub 共有ロードバランサーを使用することです。

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

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

正解：A

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