• ホーム
  • ブログ
  • 最新版無料体験を掴み取れ！MuleSoft MCPA-Level-1日本語問題集PDFは更新されたのは2024年 [Q58-Q77]

最新版無料体験を掴み取れ！MuleSoft MCPA-Level-1日本語問題集PDFは更新されたのは2024年 [Q58-Q77]

Share

最新版無料体験を掴み取れ！MuleSoft MCPA-Level-1日本語問題集PDFは更新されたのは2024年

最新リリースのMCPA-Level-1日本語問題集はMuleSoft Certified Platform Architect認証済みです

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

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

正解：A

解説：
永続オブジェクトストア
********************************************
>> 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 が正解です。


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

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

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

正解：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



質問 # 60
ある小売会社は、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

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


質問 # 61
組織は、最新の API (MuleSoft によって定義されている) を使用して再利用可能な IT 資産の消費を強調する IT 運用モデルに移行するという戦略的な決定を下します。
この新しい IT 運用モデルに関連する各最新 API を最もよく表しているのはどれですか?

  • A. 各最新 API は REST および HTTP ベースである必要があります
  • B. 最新の API にはそれぞれ独自のソフトウェア開発ライフサイクルがあり、ドキュメント化と自動化の必要性が減ります。
  • C. 最新の各 API は使いやすくなければならないため、SAML や JWT D などの複雑な認証メカニズムを避ける必要があります。
  • D. 各モデム API は製品のように扱われ、特定の対象ユーザー (モバイル アプリ開発者など) 向けに設計されている必要があります。

正解：D

解説：
正解:
1. 各最新 API は製品のように扱われ、特定の対象ユーザー (モバイル アプリ開発者など) 向けに設計されている必要があります。
********************************************


質問 # 62
システム API は、スケーラビリティの課題があるバックエンド システムからデータを取得するように設計されています。バックエンド システムを最もよく保護できる API ポリシーはどれですか?

  • A. クライアント ID の強制
  • B. IPホワイトリスト
  • C. SLA ベースのレート制限
  • D. Auth 2 トークンの強制

正解：C

解説：
正解: SLA ベースのレート制限
********************************************
>> Client Id enforement ポリシーは「コンプライアンス」関連の NFR であり、「Quality of Service (QoS)」の維持には役立ちません。バックエンド システムをスケーラビリティの課題から保護することはできませんし、意図したものでもありません。
>> IP ホワイトリストと OAuth 2.0 トークンの適用は「セキュリティ」関連の NFR であり、「サービスの品質 (QoS)」の維持には役立ちません。バックエンド システムをスケーラビリティの課題から保護することはできませんし、意図したものでもありません。
Rate Limiting、Rate Limiting-SLA、Throttling、Spike Control は、「Quality of Service (QOS)」に関連する NFR であり、バックエンド システムが過負荷になるのを防ぐのに役立つポリシーです。
https://dzone.com/articles/how-to-secure-apis


質問 # 63
ビジネス ロジック オーケストレーションは、API 主導の接続のどのレイヤーに存在しますか?

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

正解：A

解説：
プロセスレイヤー
********************************************
>> エクスペリエンス レイヤーは、エンド ユーザー エクスペリエンスの強化専用です。このレイヤーは、さまざまな API クライアント/コンシューマーのニーズを満たすためのものです。
>> システム層は、本質的にモジュラーであり、バックエンド システムのさまざまな個々の機能を実装/公開する API 専用です。
>> プロセス レイヤーは、1 つまたは複数のシステム レイヤーのモジュラー API を呼び出すことによって、単純または複雑なビジネス オーケストレーション ロジックが記述される場所です。つまり、プロセス レイヤーが正解です。


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

  • A. ログ エントリを Runtime Manager で表示できるようにするロギング構成
  • B. API 実装に割り当てられた DNS エントリの数
  • C. 特定の CloudHub ワーカーへの各 HTTP リクエストの割り当て
  • 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 はこれを行いません。


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

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

正解：D

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


質問 # 66
組織は、さまざまな API レイヤーを使用してモバイル クライアントをバックエンド システムと統合する API 主導のアーキテクチャを作成しました。バックエンド システムは、多数の特殊なコンポーネントで構成され、REST API を介してアクセスできます。プロセス API とエクスペリエンス API は、バックエンド データ モデルとは異なる同じ境界コンテキスト モデルを共有します。バックエンド システムから消費されるデータの処理を支援するために、このアーキテクチャにどの追加の標準モデル、境界コンテキスト モデル、または腐敗防止レイヤーを追加するのが最適ですか?

  • A. システム レイヤーの境界コンテキスト モデルを作成してバックエンド データ モデルと厳密に一致させ、腐敗防止レイヤーを追加して、さまざまな境界コンテキストがシステム レイヤーとプロセス レイヤー全体で連携できるようにします。
  • B. すべてのレイヤーの境界コンテキスト モデルを作成し、境界コンテキストが重複する場合はそれらを重複させて、上流と下流のデータ モデルの違いを API 開発者に知らせます。
  • C. バックエンド モデルと API 主導のモデルを組み合わせた正規モデルを作成して、データ モデルを簡素化および統合し、データ変換を最小限に抑えます。
  • D. すべての API に対して腐敗防止レイヤーを作成し、すべてのデータ モデルが相互に一致するように変換を実行し、API 間でデータを簡単に移動できるようにして、正規モデルの構築の複雑さとオーバーヘッドを回避します。

正解：A

解説：
正解: システム レイヤーの境界コンテキスト モデルを作成してバックエンド データ モデルと厳密に一致させ、腐敗防止レイヤーを追加して、さまざまな境界コンテキストがシステム レイヤーとプロセス レイヤー全体で連携できるようにします。
********************************************
>> 標準モデルはここではオプションではありません。組織はすでに努力を重ね、エクスペリエンス API とプロセス API 用の境界コンテキスト モデルを作成しているためです。
>> エクスペリエンス API とプロセス API は同じ境界コンテキスト モデルを共有すると述べられているため、すべての API の腐敗防止レイヤーは不要で無効です。今すぐアプローチを選択する必要があるのは、システム層の API だけです。
>> したがって、プロセス レイヤーとシステム レイヤーの間に腐敗防止レイヤーを配置するとうまく機能します。また、アプローチを高速化するために、システム API はバックエンド システム データ モデルを模倣できます。


質問 # 67
組織は、OrderStatus System API の新しい実装を CloudHub の複数のワーカーにデプロイしています。この API は、IPsec トンネルを介して API 実装によってアクセスされる、組織のオンプレミス注文管理システムの前にあります。
通常、OrderStatus システム API のサービス停止に至らないエラーの種類はどれですか?

  • A. API 実装の初期デプロイ中に API Manager が長時間停止する
  • B. AWS リージョンは、関連する AWS データ センターへの主要なネットワーク障害でオフラインになります
  • C. CloudHub ワーカーがメモリ不足の例外で失敗する
  • D. 組織のオンプレミス データ センターでネットワークが停止しているため、注文管理システムにアクセスできません

正解：C

解説：
正解: CloudHub ワーカーがメモリ不足の例外で失敗します。
********************************************
>> AWS リージョン自体がダウンすると、そのリージョン内のすべてのワーカーがダウンするため、Mule アプリケーションに割り当てられたワーカーの数に関係なく、確実に停止します。これは完全なダウンタイムと機能停止です。
>> API 実装の初期展開中に API マネージャーが長時間停止すると、当然、アプリケーションの適切な起動自体に問題が発生します。これは、API 自動検出が失敗したり、アプリケーションの起動時に API ポリシー テンプレートとポリシーがダウンロードされて埋め込まれなかったりする可能性があるためです。 . 問題を引き起こす可能性のある多くの理由があります。
>> もちろん、オンプレミスのネットワークが停止すると、注文管理システムにアクセスできなくなります。アプリに割り当てられたワーカーの数に関係なく、すべてのワーカーが失敗し、確実に停止します。
サービス停止に至らない唯一のオプションは、cloudhub ワーカーがメモリ不足の例外で失敗した場合です。ワーカーに障害が発生してダウンした場合でも、他のワーカーがリクエストを処理し、API の稼働と実行を維持します。ですから、これが正しい答えです。


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

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

正解：B

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


質問 # 69
Anypoint Platform でクライアント管理に外部 ID プロバイダを使用する場合の主な要件は何ですか?

  • A. Anypoint Platform によって管理される OAuth 2.0 で保護された API を呼び出すには、API クライアントは、同じ ID プロバイダーによって発行されたアクセス トークンを送信する必要があります。
  • B. Anypoint Platform によって管理される API は、SAML 2.0 ポリシーによって保護される必要があります
  • C. Anypoint Platform にサインインするには、シングル サインオンが必要です。
  • D. アプリケーション ネットワークには、ID プロバイダーと対話するシステム API が含まれている必要があります。

正解：A

解説：
https://www.folkstalk.com/2019/11/mulesoft-integration-and-platform.html 説明:
正解: Anypoint Platform によって管理される OAuth 2.0 で保護された API を呼び出すには、API クライアントは、同じ ID プロバイダーによって発行されたアクセス トークンを送信する必要があります。
********************************************
>> クライアント管理に外部 ID プロバイダーを使用しているため、Anypoint Platform へのサインインにシングル サインオンは必要ありません
>> Anypoint Platform で管理されるすべての API を SAML 2.0 ポリシーで保護する必要はありません。これは、クライアント管理に外部 ID プロバイダーを使用しているためです。
>> クライアント管理に外部 ID プロバイダーを使用しているため、アプリケーション ネットワークに ID プロバイダーと対話するシステム API を含める必要があるというのは正しくありません。 、API クライアントは、同じ ID プロバイダーによって発行されたアクセス トークンを送信する必要があります。
https://docs.mulesoft.com/api-manager/2.x/external-oauth-2.0-token-validation-policy
https://blogs.mulesoft.com/dev/api-dev/api-security-ways-to-authenticate-and-authorize/


質問 # 70
たとえば、以下の機能を提供する CRM-Z と呼ばれる従来の CRM システムがあるとします。
1. 顧客の創造
2.既存の顧客の詳細を修正する
3. 顧客の詳細を取得する
4. 顧客を一時停止する

  • A. すべての機能がさまざまな操作/リソースとしてラップされている customerManagement という名前のシステム API を実装します。
  • B. createCustomer、amendCustomer、retrieveCustomer、suspendCustomer という名前の異なるシステム API を実装します。それらはモジュール化されており、懸念事項が分離されているためです。
  • C. createCustomerInCRMZ、amendCustomerInCRMZ、retrieveCustomerFromCRMZ、suspendCustomerInCRMZ という名前の異なるシステム API を実装します。それらはモジュール化されており、懸念事項が分離されているためです。

正解：B

解説：
正解: createCustomer、amendCustomer、retrieveCustomer、suspendCustomer という名前の異なるシステム API を実装します。それらはモジュール化されており、懸念事項が分離されているためです。
********************************************
>> 単一の API と異なる Verb + Resource の組み合わせを使用するのはごく普通のことです。ただし、これはエクスペリエンス API やプロセス API には適していますが、システム API には最適なアーキテクチャ スタイルではありません。したがって、customerManagement API を 1 つだけ使用するオプションは、ここでは最良の選択ではありません。
>> createCustomerInCRMZ 形式の API を使用するオプションは、モジュール化とメンテナンスの軽減という点で次に近い選択肢ですが、API の命名はレガシー システムと直接結び付いています。より適切な方法として、バックエンド システムの名前を抽象化して API に名前を付けることをお勧めします。これにより、バックエンド システムをいつでもシームレスに交換/移行できるようになります。したがって、これも正しい選択ではありません。
>> createCustomer、amendCustomer、retrieveCustomer、suspendCustomer は適切なアプローチであり、他のオプションと比較して最適です。これらは両方ともモジュラーであり、同時に名前がバックエンド システムから切り離されており、システム API が必要とするすべての要件をカバーしているためです。


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

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

正解：A

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


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

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

正解：A

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


質問 # 73
何千もの店舗を持つ小売会社には、購入に関するデータを受け取り、それを単一のデータベースに挿入するための API があります。個々の店舗は、約 30 分ごとに購入データのバッチを API に送信します。API 実装では、データベース一括挿入コマンドを使用して、データ分析ソリューション プロバイダーが提供するカスタム JDBC ドライバーを使用して、すべての購入データをデータベースに送信します。API 実装は、単一の CloudHub ワーカーにデプロイされます。JDBC ドライバーはデータを CloudHub ワーカー上の複数の一時ディスク ファイルのセットに処理し、データは独自のプロトコルを使用して分析エンジンに送信されます。通常、このプロセスには数分もかかりません。リクエストが失敗することがあります。この場合、ログには、ファイル領域不足メッセージを示す JDBC ドライバーからのメッセージが表示されます。リクエストが再送信されると、それは成功しています。このスループットの問題を解決する最善の方法は何ですか?

  • A. CloudHub 自動スケーリング ポリシーを使用して、CloudHub ワーカーのサイズを増やします
  • B. CloudHub 自動スケーリング ポリシーを使用して、CloudHub ワーカーを追加します
  • C. CloudHub ワーカーの数を増やす
  • D. CloudHub ワーカーのサイズを大きくします

正解：C

解説：
正解: CloudHub ワーカーのサイズを大きくする
********************************************
与えられたシナリオから取り出せる重要な詳細は次のとおりです。
>> API 実装では、データベースの一括挿入コマンドを使用して、すべての購入データをデータベースに送信します
>> JDBC ドライバーはデータを CloudHub ワーカー上の複数の一時ディスク ファイルのセットに処理します
>> 要求が失敗し、ログにファイル領域不足メッセージを示すメッセージが表示されることがあります。上記の詳細に基づいて:
>> エラー メッセージに基づいて自動スケーリング ルールを設定できないため、どちらの自動スケーリング オプションも役に立ちません。自動スケーリング ルールは、特定のエラーやディスク容量の問題ではなく、CPU/メモリの使用量に基づいて開始されます。
>> CloudHub ワーカーの数を増やしても、ここでは役に立ちません。なぜなら、失敗の理由は、CPU やメモリに関するパフォーマンスの側面によるものではないからです。これは、ディスク容量が原因です。
>> さらに、API は受信したバッチ データを送信するために一括挿入を行っています。つまり、すべてのデータは一度に 1 人のワーカーによってのみ処理されます。したがって、ディスク容量の問題は「ワーカーごと」に取り組む必要があります。複数のワーカーを使用しても、特定のワーカーのディスク容量が不足している場合、そのワーカーでバッチが失敗する可能性があるため、役に立ちません。
したがって、この問題に対処してこれを解決する正しい方法は、より多くのディスク容量を持つ新しいワーカーがプロビジョニングされるように、ワーカーの仮想コア サイズを増やすことです。


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

開発者は、クライアント ID 強制ポリシーによって管理される STAGING 環境にデプロイされた API を呼び出すクライアント アプリケーションを構築しています。
API を正常に呼び出すには何が必要ですか?

  • A. STAGING 環境で API を所有する Anypoint Platform アカウントのクライアント ID とシークレット
  • B. Anypoint Platform から取得した有効な OAuth トークンと、それに関連付けられたクライアント ID とシークレット
  • C. STAGING 環境の API インスタンス用に Anypoint Exchange から取得したクライアント ID とシークレット
  • D. Anypoint Platform アカウントの STAGING 環境のクライアント ID とシークレット

正解：C

解説：
Anypoint Exchange から取得した STAGING 環境の API インスタンスのクライアント ID とシークレット
********************************************
>> Anypoint Platform アカウントのクライアント ID とシークレット、または API にアクセスするための個々の環境を使用することはできません
>> 問題の API に適用されるポリシーのタイプが「クライアント ID 適用ポリシー」であるため、OAuth トークン ベースのアクセスは機能しません。
API にアクセスする正しい方法は、Anypoint Exchange から取得したクライアント ID とシークレットを使用して、作業する特定の環境の API インスタンスに使用することです。
参考文献:
API Manager での API インスタンス コントラクトの管理
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


質問 # 75
コード中心の API ドキュメント環境では、API コンシューマーが、代表的なシナリオの一部として 1 つ以上の API を呼び出す方法を示す API クライアント ソース コードを調査および実行できるようにする必要があります。
Anypoint Platform を使用して、この種のコード中心の API ドキュメント環境を提供する最も効果的な方法は何ですか?

  • A. Anypoint Exchange エントリと API コンソールを通じて API が十分に文書化されていることを確認し、これらのページをすべての API コンシューマーと共有します。
  • B. 関連する API ごとにモック サービスを有効にし、Anypoint Exchange エントリを介してそれらを公開します。
  • C. API ノートブックを作成し、関連する Anypoint Exchange エントリに含めます。
  • D. 関連する API を Anypoint Exchange エントリを介して検出できるようにする

正解：C

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


質問 # 76
展示を参照してください。組織は、モバイル アプリと Web アプリケーションの両方から顧客データにアクセスできるようにする必要があり、それぞれが共通のフィールドと特定の固有のフィールドにアクセスする必要があります。
データの一部はデータベースで、一部はサードパーティの CRM システムで利用できます。
これらの設計要件に最も適合するには、どの API を作成する必要がありますか?

A) Web アプリとモバイル アプリの両方で必要なデータを含むプロセス API。これらのアプリケーションが直接呼び出して必要なデータにアクセスできるようにすることで、API の変更を必要とせずに将来的にフィールドを追加する柔軟性を提供します。

B) Web アプリ用の 1 セットの API (エクスペリエンス API、プロセス API、およびシステム API) と、モバイル アプリ用の別のセット

C) モバイル アプリと Web アプリ用の個別のエクスペリエンス API ですが、データベースと CRM システム用に作成された個別のシステム API を呼び出す共通のプロセス API

D) Web アプリとモバイル アプリの両方で使用される共通のエクスペリエンス API ですが、データベースと CRM システムとやり取りする Web アプリとモバイル アプリには個別の Process API があります。

  • A. オプション D
  • B. オプション C
  • C. オプション A
  • D. オプション B

正解：B

解説：
正解: モバイル アプリと Web アプリ用に個別のエクスペリエンス API を使用しますが、データベースと CRM システム用に作成された個別のシステム API を呼び出す共通のプロセス API です。
********************************************
MuleSoft の API 主導の接続によると:
>> エクスペリエンス API は、各消費者のニーズとその経験に応じて構築する必要があります。
>> プロセス API には、ビジネス機能を実現するためのすべてのオーケストレーション ロジックが含まれている必要があります。
>> バックエンド システムごとにシステム API を構築して、データのロックを解除する必要があります。
リファレンス：


質問 # 77
......

最新のMCPA-Level-1日本語試験問題集でMuleSoft試験問題にトレーニング：https://www.goshiken.com/MuleSoft/MCPA-Level-1-JPN-mondaishu.html

関するブログ

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