最新の[2023年06月24日] 実際に出る検証済みのMCPA-Level-1日本語問題集 [Q27-Q50]

最新の[2023年06月24日] 実際に出る検証済みのMCPA-Level-1日本語問題集

合格させるMuleSoft MCPA-Level-1日本語試験更新されたのは97問があります

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

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

正解：A

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

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

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

正解：A

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

質問 # 29
トラフィックは、API プロキシを介して API 実装にルーティングされます。API プロキシは API Manager によって管理され、API 実装は Runtime Manager を使用して CloudHub VPC にデプロイされます。この API には API ポリシーが適用されています。この展開シナリオでは、着信 API クライアント要求に API ポリシーが適用されるのはどの時点ですか?

A. API実装時
B. API プロキシと API 実装の両方で
C. API プロキシで
D. MuleSoft がホストするロードバランサ

正解：C

解説：
正解: API プロキシで
********************************************
>> API ポリシーは、Mule プラットフォームの 2 つの場所で適用できます。
>> 1 - API 実装が実行されている同じ Mule Runtime での埋め込みポリシーの適用として。
>> 2 - API 実装が実行されている Mule Runtime の前にある API プロキシ。
>> 問題のデプロイシナリオには API プロキシが関係しているため、ポリシーは API プロキシで適用されます。

質問 # 30
Anypoint Platform が提供する 4 つの重要なプラットフォーム機能は何ですか?

A. API の設計と開発、API の廃止、API のバージョニング、API コンシューマエンゲージメント
B. API の設計と開発、API ランタイムの実行とホスティング、API のバージョニング、API の廃止
C. API の設計と開発、API ランタイムの実行とホスティング、API の運用と管理、API コンシューマーエンゲージメント
D. API バージョニング、API ランタイムの実行とホスティング、API 呼び出し、API コンシューマーエンゲージメント

正解：C

解説：
正解: API の設計と開発、API ランタイムの実行とホスティング、API の運用と管理、API コンシューマーエンゲージメント
********************************************
>> API の設計と開発 - Anypoint Studio、Anypoint Design Center、Anypoint Connectors
>> API ランタイムの実行とホスティング - Mule ランタイム、CloudHub、ランタイムサービス
>> API の運用と管理 - Anypoint API Manager、Anypoint Exchange
>> API コンシューマー管理 - API コントラクト、パブリックポータル、Anypoint Exchange、API ノートブック

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

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

正解：C

解説：
正解: 資産の生産と同じくらい消費を促進します。これにより、開発者は他のプロジェクトのアセットを発見して再利用できるようになり、標準化が促進されます
********************************************
>> 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

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

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

正解：A

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

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

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

正解：C

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

質問 # 34
次の順序のうち、正しいものはどれですか?

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 実装

正解：D

解説：
正解: API コンシューマーが API へのアクセスを要求する >> API クライアントが API を呼び出すロジックを実装する >> API が要求をルーティングする >> API 実装
********************************************
>> API コンシューマは、API を呼び出すロジックを実装していません。それはただの役割です。したがって、「API コンシューマーは API を呼び出すロジックを実装する」というオプションは無効です。
>> API 実装はリクエストをルーティングしません。これは、ターゲットシステムの機能が公開される最後のロジックです。そのため、リクエストは他のエンティティによって API 実装にルーティングされる必要があります。したがって、「API 実装が要求を >> API にルーティングする」というオプションは無効です
>> 選択肢の 1 つのステートメントは正しいですが、順序が間違っています。シーケンスは、「API クライアントが API を呼び出すロジックを実装する >> API コンシューマが API へのアクセスを要求する >> API が要求をルーティングする >> API 実装」として与えられます。ここでは、オプションのステートメントは有効ですが、順序が間違っています。
>> 正しいオプションとシーケンスは、API コンシューマーが最初に Anypoint Exchange 上の API へのアクセスを要求し、クライアント資格情報を取得するものです。次に、API クライアントは、API コンシューマーによって要求されたアクセスクライアント資格情報を使用して API を呼び出すロジックを記述します。要求は、API Manager によって管理される API を介して API 実装にルーティングされます。

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

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

正解：B

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

質問 # 36
ある会社は、アプリケーションネットワークの作成を開始し、現在、Center for Enablement (C4E) 組織モデルの実装を計画しています。会社が中央集権型の C4E ではなく連合型の C4E を決定する主な要因は何ですか?

A. 開発がすでに複数の独立したイニシアチブまたはグループに編成されている場合
B. 開発チームが共有する既存の共通アセットが多数ある場合
C. API の作成を担当するさまざまなチームが統合に慣れていないため、広範なトレーニングが必要な場合
D. アプリケーションネットワーク内のアプリケーションの大部分がクラウドベースの場合

正解：A

解説：
開発がすでにいくつかの独立したイニシアチブまたはグループに組織化されている場合
********************************************
>> 単一の C4E チームが、複数の独立したイニシアチブに参加している既に組織化された複数の開発チームと調整するためには、組織内で多くのプロセス作業が必要になります。単一の C4E は、少なくとも共通のイニシアチブを持つさまざまなチームでうまく機能します。したがって、このシナリオでは、集中型 C4E の代わりにフェデレーテッド C4E が適切に機能します。

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

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

正解：B

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

質問 # 38
CloudHub Dedicated Load Balancer を使用する必要があるのはどのような条件ですか?

A. 顧客がホストする Mule ランタイムにデプロイされた API 実装にカスタム DNS 名が必要な場合
B. API 実装と API クライアント間でサーバー側の負荷分散 TLS 相互認証が必要な場合
C. 同じ Mule アプリケーションの個別のデプロイ間でリージョン間の負荷分散が必要な場合
D. 複数の CloudHub ワーカーにまたがる API 呼び出しの負荷を分散する必要がある場合

正解：B

解説：
API実装とAPIクライアント間でサーバー側負荷分散TLS相互認証が必要な場合
********************************************
事実/記憶のヒント: CloudHub Dedicated Load Balancer には多くの利点がありますが、それを検討する際に心に留めておくべき重要な点が 2 つあります。
>> CloudHub でデプロイされたアプリにカスタム DNS 名を持つ URL エンドポイントを持つ
>> HTTPS と双方向 (相互) 認証の両方のカスタム証明書を構成します。
これに提供されるオプションに来る
>>私たちは
DLB を使用して、同じ Mule アプリケーションの個別のデプロイメント間でリージョン間の負荷分散を実行することはできません。
>> 同じ Mule アプリを指す複数の DLB URL を持つマッピングルールを設定できます。ただし、その逆 (同じ DLB URL を持つ複数の Mule アプリ) は不可能です。
>> DLB が Cloudhub でデプロイされた Mule アプリのカスタム DNS 名をセットアップするのに役立つことは事実ですが、顧客がホストする Mule ランタイムにデプロイされたアプリには当てはまりません。
>> DLB を使用して複数の CloudHub ワーカー間で API 呼び出しの負荷を分散できることは事実ですが、必須ではありません。SLB (Shared Load Balancer) を使用しても同じ (負荷分散) を実現できます。それを達成するために必ずしもDLBを必要とするわけではありません。
したがって、シナリオに適合し、DLB を使用する必要がある唯一の適切なオプションは、API 実装と API クライアントの間で TLS 相互認証が必要な場合です。

質問 # 39
次のうち、API 主導の接続の定義に最も適しているのはどれですか?

A. API 主導の接続は、単なるアーキテクチャやテクノロジではなく、組織内で IT を効率的に提供するために人やプロセスを編成する方法でもあります。
B. API主導のコネクティビティは、エクスペリエンス、プロセス、およびシステム層ベースのAPIの実装を可能にするテクノロジーです。
C. API 主導の接続は、エクスペリエンス、プロセス、およびシステム層をカバーする 3 層アーキテクチャです。

正解：A

解説：
正解: API 主導の接続は、単なるアーキテクチャやテクノロジではなく、組織内で IT を効率的に提供するために人やプロセスを編成する方法でもあります。
********************************************
リファレンス：

質問 # 40
以下のオプションから正しいオーナー層の組み合わせを選択してください

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. アプリ開発者は Experience Layer API を所有し、これに注力しています
2. LOB IT が所有し、プロセスレイヤー API に注力
3. 中央 IT が所有し、システム層 API に集中する

参考文献:
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/

質問 # 41
システム API の API データモデルが、対応するバックエンドシステムによって公開されたデータモデルを合理的に模倣し、バックエンドシステムのデータモデルを最小限に改善できるのはいつですか?

A. 組織全体で広く使用されている既存のエンタープライズデータモデルがある場合
B. システム API を、対応するデータモデルを使用して境界付けられたコンテキストに割り当てることができる場合
C. 近い将来、対応するバックエンドシステムのリプレースが予想される場合
D. バックエンドシステムからの限定的な分離のみを伴う実用的なアプローチが適切であると見なされる場合

正解：D

解説：
正解: バックエンドシステムからの限定的な分離のみを行う実用的なアプローチが適切と見なされる場合。
********************************************
データモデルの選択に関する一般的なガイダンス:
>> エンタープライズデータモデルが使用されている場合、システム API の API データモデルは、そのエンタープライズデータモデルのデータ型を利用する必要があり、対応する API 実装は、エンタープライズデータモデルのデータ型とネイティブデータモデルとの間で変換する必要があります。バックエンドシステムの。
>> エンタープライズデータモデルが使用されていない場合、各システム API を境界コンテキストに割り当てる必要があります。システム API の API データモデルは、対応する境界コンテキストデータモデルのデータ型を使用する必要があり、対応する API 実装は、 Bounded Context Data Model およびバックエンドシステムのネイティブデータモデルからのこれらのデータ型。このシナリオでは、Bounded Context Data Model のデータ型は純粋にビジネス特性の観点から定義されており、通常はバックエンドシステムのネイティブデータモデルとは関係ありません。つまり、翻訳作業はかなりの量になる可能性があります。
>> エンタープライズデータモデルが使用されておらず、クリーンな Bounded Context Data Model の定義が手間がかかりすぎると考えられる場合、システム API の API データモデルは、バックエンドシステムのデータ型をほぼ反映したデータ型を使用する必要があります。バックエンドシステムと同じセマンティクスとネーミングを軽くサニタイズし、特定のシステム API の機能に必要なすべてのフィールドを公開しますが、それほど多くはなく、REST 規則をうまく利用します。
後者のアプローチ、つまり、基本的にバックエンドシステムの API データモデルを反映する API データモデルをシステム API で公開する方法では、システム API 層を介してバックエンドシステムから十分に分離することはできません。特に、バックエンドシステムの前にあるすべてのシステム API を大幅に変更せずにバックエンドシステムを「スワップアウト」することは通常不可能であり、したがって、それらのシステム API に依存するすべてのプロセス API の API 実装を変更することはできません。これは、以前のバックエンドシステムのデータモデルの寿命を、現在新しいバックエンドシステムの前面にあるシステム API の API データモデルの形で延長することは望ましくないためです。したがって、このアプローチに従うシステム API の API データモデルは、バックエンドシステムが置き換えられるときに変更する必要があります。
一方で：
>> バックエンドシステムに直接アクセスするよりもオーバーヘッドが比較的少ない、非常に実用的なアプローチです
>> API クライアントを、データモデルの外側のバックエンドシステムの複雑な要素 (プロトコル、認証、接続プーリング、ネットワークアドレスなど) から分離します。
>> 通常の API ポリシーをシステム API に適用できるようにする
>> システム API の RAML 定義で公開することにより、バックエンドシステムと対話するための API データモデルを明示的かつ可視的にします。
>> バックエンドシステムデータモデルからのさらなる分離は、プロセス API 層の API 実装で行われます

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

A. ファイルベースのストレージ
B. Redis 分散キャッシュ
C. java.util.WeakHashMap
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 が正解です。

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

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

正解：C

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

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

質問 # 45
アプリケーションネットワークは再構成可能です。「曲がっても壊れない」ため、変更のために構築されています。

A. TRUE
B. 偽

正解：A

解説：
********************************************
>> アプリケーションネットワークは使い捨てのアーキテクチャです。
>> つまり、アーキテクチャ全体とそのコンポーネントに影響を与えることなく変更できます。
>> 要件や設計変更に応じて曲がりますが、壊れません

質問 # 46
何千もの店舗を持つ小売会社には、購入に関するデータを受け取り、それを単一のデータベースに挿入するための 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 人のワーカーによってのみ処理されます。したがって、ディスク容量の問題は「ワーカーごと」に取り組む必要があります。複数のワーカーを使用しても、特定のワーカーのディスク容量が不足している場合、そのワーカーでバッチが失敗する可能性があるため、役に立ちません。
したがって、この問題に対処してこれを解決する正しい方法は、より多くのディスク容量を持つ新しいワーカーがプロビジョニングされるように、ワーカーの仮想コアサイズを増やすことです。

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

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

正解：B

質問 # 48
Anypoint VPC の技術アーキテクチャについて正しいのはどれですか?

A. Anypoint VPC のプライベート IP アドレス範囲は、CloudHub によって自動的に選択されます
B. 各 CloudHub 環境には個別の Anypoint VPC が必要です
C. VPC ピアリングを使用して、基盤となる AWS VPC をオンプレミス (AWS 以外) のプライベートネットワークにリンクできます。
D. Anypoint VPC にデプロイされた Mule アプリケーションとオンプレミスシステム間のトラフィックは、プライベートネットワーク内に留まることができます。

正解：D

解説：
正解: Anypoint VPC にデプロイされた Mule アプリケーションとオンプレミスシステム間のトラフィックは、プライベートネットワーク内にとどまることができます。
********************************************
>> Anypoint VPC のプライベート IP アドレス範囲は、CloudHub によって自動的に選択されません。これは、CIDR ブロックを使用して VPC を作成するときに選択されます。
CIDR ブロック: Classless Inter-Domain Routing (CIDR) 表記での Anypoint VPC のサイズ。
たとえば、10.111.0.0/24 に設定すると、Anypoint VPC には 10.111.0.0 から 10.111.0.255 までの 256 個の IP アドレスが付与されます。
理想的には、Anypoint VPC 用に選択する CIDR ブロックは、プライベート IP スペースからのものであり、他の Anypoint VPC の CIDR ブロック、または企業ネットワークで使用されている CIDR ブロックと重複しないようにする必要があります。

各 CloudHub 環境には個別の Anypoint VPC が必要です。Anypoint VPC が作成されると、複数の環境で同じ VPC を選択できます。ただし、通常は、Non-Prod 環境と Prod 環境で常に個別の Anypoint VPC を使用することがベストで推奨される方法です。
>> Anypoint VPN を使用して、基盤となる AWS VPC をオンプレミス (非 AWS) プライベートネットワークにリンクします。VPC ピアリングではありません。
リファレンス：
与えられた選択肢の唯一の真実は、Anypoint VPC にデプロイされた Mule アプリケーションとオンプレミスシステム間のトラフィックがプライベートネットワーク内にとどまることができるということです。
https://docs.mulesoft.com/runtime-manager/vpc-connectivity-methods-concept

質問 # 49
システム 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 を呼び出します

正解：D

解説：
正解: プライマリ環境にデプロイされたシステム 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を呼び出してください。

質問 # 50
......

今すぐ試そう2023年最新の無料更新されたMuleSoft MCPA-Level-1日本語試験問題と解答：https://www.goshiken.com/MuleSoft/MCPA-Level-1-JPN-mondaishu.html

関するブログ

もっと

MCPA-Level-1-JPN無料問題集