• ホーム
  • ブログ
  • [Q44-Q66] リアルMuleSoft MCPA-Level-1日本語試験問題 [更新されたのは2023年]

[Q44-Q66] リアルMuleSoft MCPA-Level-1日本語試験問題 [更新されたのは2023年]

Share

リアルMuleSoft MCPA-Level-1日本語試験問題 [更新されたのは2023年]

MCPA-Level-1日本語試験問題集で合格させるのは更新されたのは2023年年最新のMuleSoft Certified Platform Architect - Level 1 (MCPA-Level-1日本語版)

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

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

正解：B

解説：
正解: 規制要件により、メタデータを含むすべてのデータ項目のオンプレミス処理が義務付けられている場合。
********************************************
以下では、Anypoint Platform PCE または PCF を使用する必要はありません。したがって、これらのオプションはアウトです。
>> CloudHub も使用して、複数のデータセンターですべてのアプリケーションを高可用性にすることができます。
>> Anypoint VPN と CloudHub からのトンネリングを使用して、組織のイントラネットに展開されているアプリケーション ネットワーク内のすべてのバックエンド システムに接続できます。
>> Anypoint VPC とファイアウォール ルールを使用して、すべての API をプライベートにし、パブリック クラウドに公開しないようにすることができます。
指定されたオプションで Anypoint Platform PCE/PCF を使用する必要がある唯一の正当な理由は、規制要件により、メタデータを含むすべてのデータ項目のオンプレミス処理が義務付けられている場合です。


質問 # 45
組織は、顧客住所情報を取得するために顧客住所 API を実装しました。この API は複数の環境にデプロイされており、あらゆる場所でクライアント ID を適用するように構成されています。
開発者は、ユーザーが住所を更新できるようにするクライアント アプリケーションを作成しています。開発者は、Anypoint Exchange で Customer Address API を見つけ、それをクライアント アプリケーションで使用したいと考えています。
Anypoint Platform で自動的に実行できる API へのアクセス取得のステップはどれですか?

  • A. クライアント アプリケーションの資格情報を使用して API を呼び出すようにクライアント アプリケーションを変更します。
  • B. 選択した SLA レベルのクライアント アプリケーション要求を承認する
  • C. API へのアクセスを要求するために、Anypoint Exchange で新しいアプリケーションを作成します。
  • D. クライアント アプリケーションの資格情報を使用して、複数の環境にデプロイされた適切な API インスタンスへのアクセスを要求します。

正解：B

解説：
正解: 選択した SLA レベルのクライアント アプリケーション要求を承認する
********************************************
>> 選択した SLA レベルのクライアント アプリケーション リクエストの承認のみを自動化できます
>> 提供された残りのオプションは無効です


質問 # 46
複数の CloudHub ワーカーにデプロイされた Mule アプリケーションとして実装された非同期実行の長時間実行プロセスでトランザクション状態を追跡するための、Anypoint Platform で最もパフォーマンスの高いすぐに使えるソリューションは何ですか?

  • A. java.util.WeakHashMap
  • B. Redis 分散キャッシュ
  • C. ファイルベースのストレージ
  • D. 永続オブジェクト ストア

正解：D

解説：
永続オブジェクトストア
********************************************
>> Redis 分散キャッシュは高性能ですが、Anypoint Platform のすぐに使えるソリューションではありません
>> Anypoint Platform では、ファイル ストレージはパフォーマンスが高くなく、すぐに使えるソリューションでもありません
>> java.util.WeakHashMap は、Java コードを使用してゼロからキャッシュを完全にカスタム実装する必要があり、それが実行されている JVM に限定されます。つまり、キャッシュ内の状態は、複数のワーカーで実行されている場合、ワーカーを認識しません。このタイプのキャッシュはワーカーに対してローカルです。そのため、これはすぐに使用できるものでも、cloudhub 上の複数のワーカー間でワーカーを認識するものでもありません。https://www.baeldung.com/java-weakhashmap
>> Persistent Object Store は Anypoint Platform が提供するすぐに使用できるソリューションであり、CloudHub で実行されている複数のワーカー間でパフォーマンスが高く、ワーカーを認識します。https://docs.mulesoft.com/object-store/ したがって、Persistent Object Store が正解です。


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

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

正解：A

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


質問 # 48
API 実装の準備が整い、API が API Manager に登録されたら、誰が Anypoint Exchange の API へのアクセスを要求する必要がありますか?

  • A. 両方
  • B. API クライアント
  • C. なし
  • D. API コンシューマ

正解：D

解説：
API コンシューマー
********************************************
>> API クライアントは、API コンシューマのクライアント資格情報を使用するコードまたはプログラムの一部ですが、Anypoint Exchange と直接やり取りしてアクセスを取得することはありません
>> API コンシューマーは、登録して API へのアクセスを要求する必要がある人です。次に、API クライアントは、それらのクライアント資格情報を使用して API にアクセスする必要があります。したがって、API コンシューマーは、Anypoint Exchange から API へのアクセスを要求する必要がある人です。


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

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

正解：C

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


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

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

正解：D

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


質問 # 51
API では、クライアント リクエスト (TPS) vth 小さなメッセージ ペイトアドの割合が高くなります。クライアント アプリケーションの種類に基づいて、API に使用制限を課すにはどうすればよいですか?

  • A. クライアント アプリケーションの種類ごとに要求数を制限するスパイク制御ポリシーを使用する
  • B. クロスオリジン リソース共有 (CORS) ポリシーを使用して、クライアント アプリケーションの種類によって構成された、クライアント アプリケーション間のリソース共有を制限します。
  • C. レート制限ポリシーとクライアント ID 強制ポリシーを使用します。それぞれクライアント アプリケーション タイプによって構成されます。
  • D. SLA ベースのレート制限ポリシーを使用し、クライアント アプリケーションをそのタイプに基づいて一致する SLA 層に割り当てます。

正解：D

解説：
正解: SLA ベースのレート制限ポリシーを使用し、クライアント アプリケーションをそのタイプに基づいて一致する SLA 層に割り当てます。
********************************************
>> クライアントの種類に基づいて API に制限が課されるときはいつでも、SLA 層が有効になります


質問 # 52
ある小売会社は、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. 2 つの CloudHub ワーカーのそれぞれのサイズを、少なくとも 4 倍 (4x) ずつ 1 つの仮想コアに永続的に増やします。
  • B. CPU 使用率が 70% を超えるとトリガーされる水平 CloudHub 自動スケーリング ポリシーを使用します。
  • C. CloudHub ワーカーの数を 4 倍 (4x) から 8 つの CloudHub ワーカーに永続的に増やします。
  • D. CPU 使用率が 70% を超えるとトリガーされる垂直方向の CloudHub 自動スケーリング ポリシーを使用する

正解：B

解説：
正解: CPU 使用率が 70% を超えるとトリガーされる水平方向の CloudHub 自動スケーリング ポリシーを使用する
********************************************
問題のシナリオは、その年の通常のトラフィックが、CPU が 70% をはるかに下回って実行されている既存のワーカー構成によってかなりうまく処理されていることを非常に明確に示しています。この問題は、注文数が急増したときに「ときどき」発生することがあります。
したがって、上記に基づいて、各ワーカーのサイズを永続的に増やす必要も、ワーカーの数を永続的に増やす必要もありません。これは、リソースがアイドル状態で浪費される「時折」の時間以外は不要です。
現在、2 つのオプションが残っています。水平方向の Cloudhub 自動スケーリング ポリシーを使用してワーカーの数を自動的に増やすか、垂直方向の Cloudhub 自動スケーリング ポリシーを使用して各ワーカーの仮想コア サイズを自動的に増やします。
ここで、次の 2 つのことを考慮する必要があります。
1.CPU
2. JMS キューへの注文発注率
>> CPU の観点からは、両方のオプション (水平スケーリングと垂直スケーリング) が問題を解決します。どちらも使用率を 90% 未満に抑えるのに役立ちます。
>> ただし、垂直スケーリングを使用する場合、注文送信率の観点から見ると、アプリケーションはまだ 2 つのワーカーのみで負荷分散されているため、受信リクエストの処理率と JMS キューへの注文送信率はあまり改善されない可能性があります. スループットは以前と同じになります。CPU 使用率だけが下がります。
>>しかし、水平スケーリングを使用すると、新しいワーカーが生成され、より多くのワーカーが現在負荷分散されているため、スループットを向上させるために追加のハンドが追加されます。このようにして、CPU と注文提出率の両方に対処できます。
したがって、水平 CloudHub 自動スケーリング ポリシーが適切で最良の答えです。


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

  • A. プライマリ環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。それでも失敗する場合は、DR 環境にデプロイされたシステム API を呼び出します
  • B. プライマリ環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。それでも失敗する場合は、DR 環境にデプロイされたプロセス API のコピーを呼び出します
  • C. 並行して、プライマリ環境にデプロイされたシステム API と DR 環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。プロセス 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を呼び出してください。


質問 # 54
API 実装は、要求している API クライアントに 3 つの X-RateLimit-* HTTP 応答ヘッダーを返します。これらの応答ヘッダーは、API クライアントにどのような種類の情報を示していますか?

  • A. API 実装によって許容される残りの容量
  • B. 次のリクエストで送信する相関 ID
  • C. HTTP レスポンス サイズ
  • D. スロットリングによるエラー コード

正解：A

解説：
正解: API 実装によって許可される残りの容量。
********************************************
>>参照: https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies#response-headers


質問 # 55
REST API は、Mule アプリケーションを実装するために設計されています。
REST API の定義に使用できる標準インターフェース定義言語は?

  • A. AsyncAPI 仕様
  • B. YAML
  • C. Web サービス定義言語 (WSDL)
  • D. OpenAPI 仕様 (OAS)

正解：D


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

顧客がホストする Mule ランタイムを MuleSoft がホストする Anypoint Platform コントロール プレーン (ハイブリッド展開) とともに使用する場合、正しいのはどれですか?

  • A. Anypoint Runtime Manager は、Mule アプリケーションをデプロイするために Mule ランタイムへのネットワーク接続を開始します。
  • B. MuleSoft がホストする共有ロード バランサを使用して、Mule ランタイムへの API 呼び出しの負荷を分散できます。
  • C. API 実装は、コントロール プレーンと通信できない場合でも、顧客がホストする Mule ランタイムで正常に実行できます。
  • D. Anypoint Runtime Manager は、ノードに障害が発生した場合に新しい Mule ランタイム インスタンスを作成することで、コントロール プレーンの HA を自動的に確保します。

正解：C

解説：
正解: API 実装は、コントロール プレーンと通信できない場合でも、顧客がホストする Mule ランタイムで正常に実行できます。
********************************************
>> 共有ロード バランサーを使用して、お客様がホストするランタイムで API の負荷を分散することはできません

>> ハイブリッド展開モデルの場合、オンプレミスは最初に Runtime Manager エージェントを使用して Runtime Manager に接続されます。そのため、最初にオンプレミスから Runtime Manager への接続が開始されます。その後、Runtime Manager からすべての制御を行うことができます。
>> Anypoint Runtime Manager は自動 HA を保証できません。クラスター/サーバー グループなどは、事前に構成する必要があります。
指定された選択肢で TRUE ステートメントのみが、API 実装は、コントロール プレーンと通信できない場合でも、顧客がホストする Mule ランタイムで正常に実行できます。この声明を正当化するために、以下にいくつかの参考文献があります。
参考文献:
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-US-Control-Plane-June-25th-2019
https://help.mulesoft.com/s/article/On-premise-Runtimes-Appear-Disconnected-in-Runtime-Manager-May-29th-2018



質問 # 57
Mule アプリケーションは HTTPS エンドポイントを公開し、CloudHub 共有ワーカー クラウドにデプロイされます。その Mule アプリケーションへのすべてのトラフィックは、AWS VPC 内にとどまる必要があります。
その Mule アプリケーションへの API 呼び出しは、どの TCP ポートに送信する必要がありますか?

  • A. 0
  • B. 1
  • C. 2
  • D. 3

正解：D

解説：
8082
********************************************
>> 8091 および 8092 ポートは、HTTP および HTTPS アプリをローカル VPC に対してそれぞれ非公開にする場合に使用されます。
>> 上記の 2 つのポートは、共有 AWS VPC/共有ワーカー クラウド用ではありません。
>> 8081 は、共有 LB を介して HTTP エンドポイント アプリをインターネットに公開するときに使用されます。
>> 8082 は、共有 LB を介して HTTPS エンドポイント アプリをインターネットに公開するときに使用されます。そのため、この HTTPS ベースのアプリを呼び出すときは、API 呼び出しをポート 8082 に送信する必要があります。
参考文献:
https://docs.mulesoft.com/runtime-manager/cloudhub-networking-guide
https://help.mulesoft.com/s/article/Configure-Cloudhub-Application-to-Send-a-HTTPS-Request-Directly-to-Another-Cloudhub-Application
https://help.mulesoft.com/s/question/0D52T00004mXXULSA4/multiple-http-listerners-on-cloudhub-one-with-port-9090


質問 # 58
MuleSoft がイノベーションとクロック速度を改善するために組織に推奨する IT 運用モデルの主な変更点は何ですか?

  • A. マスター データ管理 (MDM) システムを使用して資産を公開します。これにより、プロジェクトが標準化され、開発者は他のプロジェクトのアセットをすばやく見つけて再利用できます
  • B. 資産の生産と同じくらい消費を促進します。これにより、開発者は他のプロジェクトのアセットを発見して再利用できるようになり、標準化が促進されます
  • C. 毎日多くの小さな決定を下す、無駄のない機敏な組織を作成します。これにより、意思決定が迅速化され、各事業部門がプロジェクトの所有権を取得できるようになります
  • D. 再利用可能な API に SOA を実装して、消費よりも生産に集中する。これにより、XML および WSDL 形式で標準化され、意思決定が高速化されます。

正解：B

解説：
正解: 資産の生産と同じくらい消費を促進します。これにより、開発者は他のプロジェクトのアセットを発見して再利用できるようになり、標準化が促進されます
********************************************
>> MuleSoft が推奨し、普及させた新しい IT 運用モデルの主なモットーは、API 主導の接続と呼ばれる API 戦略を通じて、運用モデルから運用 + 消費モデルへの配信方法を変更することです。
>> 構築されたアセットは、LOB や組織全体で再利用できるように、検出可能でセルフサービス可能でなければなりません。
>> MuleSoft の IT オペレーティング モデルは、SDLC モデル (アジャイル/リーンなど) や MDM についてはまったく言及していません。したがって、これらを示唆するオプションは無効です。
参考文献:
https://blogs.mulesoft.com/biz/connectivity/what-is-a-center-for-enablement-c4e/
https://www.mulesoft.com/resources/api/secret-to-managing-it-projects


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

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

正解：C

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


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

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

正解：A

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


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

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

正解：B

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


質問 # 62
コード中心の 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 コンシューマーと共有します。

正解：B

解説：
正解: API ノートブックを作成し、関連する Anypoint exchange エントリに含める
********************************************
>> API ノートブックは、コード中心の API ドキュメントを提供できる Anypoint Platform のノートブックです。


質問 # 63
共有ロード バランサで CloudHub を使用する場合、Anypoint Platform ではなく、API 実装 (Mule アプリケーション) によって排他的に管理されるものは何ですか?

  • A. 特定の CloudHub ワーカーへの各 HTTP リクエストの割り当て
  • B. API 実装に割り当てられた DNS エントリの数
  • C. ログ エントリを Runtime Manager で表示できるようにするロギング構成
  • D. HTTPS エンドポイントを公開するために API 実装によって使用される SSL 証明書

正解：D

解説：
正解: 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 はこれを行いません。


質問 # 64
組織は、既知のパートナーのみが組織の API を呼び出せるようにしたいと考えています。このセキュリティー目標を達成するために、組織は API Manager で Client ID Enforcement ポリシーを実施して、登録済みのパートナー・アプリケーションのみが組織の API を呼び出すことができるようにしたいと考えています。アプリケーションの JVM にポリシーを直接埋め込むのではなく、API プロキシを追加して Client ID Enforcement ポリシーを適用することを MuleSoft が推奨する API 実装のタイプはどれですか?

  • A. カスタム Java コードで変更された Mule 3 または Mule 4 アプリケーション
  • B. API 仕様を持つ Mule 4 アプリケーション
  • C. Mule 以外のアプリケーション
  • D. APIkit を使用する Mule 3 アプリケーション

正解：C

解説：
正解: Mule 以外のアプリケーション
********************************************
>> Mule ランタイムで実行されているすべてのタイプの Mule アプリケーション (Mule 3/ Mule 4/ APIkit を使用する/ カスタム Java コードを使用するなど) は、組み込みポリシーの適用をサポートしています。
>> 埋め込みポリシーの適用ができない、またはサポートされておらず、API プロキシが必要な唯一のオプションは、Mule 以外のアプリケーション用です。
したがって、Non Mule アプリケーションが正解です。


質問 # 65
API 実装が更新されました。API の RAML 定義もいつ更新する必要がありますか?

  • A. API 実装が要求または応答メッセージの構造を変更する場合
  • B. 平均応答時間を改善するために API 実装が最​​適化されている場合
  • C. API 実装が Mule ランタイムの古いバージョンから新しいバージョンに移行される場合
  • D. API の実装が、オンプレミスにデプロイされた従来のバックエンド システムとのやり取りから、最新のクラウドベース (SaaS) システムに変更される場合

正解：A

解説：
API 実装によってリクエストまたはレスポンス メッセージの構造が変更された場合
********************************************
>> RAML 定義は通常、リクエスト/レスポンス スキーマまたは API の特性に変更がある場合にのみ変更する必要があります。
>> パフォーマンス チューニング、バックエンド システムの移行など、API 実装の内部変更のために変更する必要はありません。


質問 # 66
......

MCPA-Level-1日本語試験問題集、MCPA-Level-1日本語練習テスト問題：https://www.goshiken.com/MuleSoft/MCPA-Level-1-JPN-mondaishu.html

関するブログ

もっと
MCPA-Level-1-JPN無料問題集