MCPA-Level-1日本語問題集最新の2024年11月23日練習テスト95リアル解答があります
2024年最新の100%試験高合格率MCPA-Level-1日本語問題集PDF
質問 # 11
CloudHub Dedicated Load Balancer を使用する必要があるのはどのような条件ですか?
- A. 複数の CloudHub ワーカーにまたがる API 呼び出しの負荷を分散する必要がある場合
- B. 同じ Mule アプリケーションの個別のデプロイ間でリージョン間の負荷分散が必要な場合
- C. API 実装と API クライアント間でサーバー側の負荷分散 TLS 相互認証が必要な場合
- D. 顧客がホストする Mule ランタイムにデプロイされた API 実装にカスタム DNS 名が必要な場合
正解：C
解説：
When server-side load-balanced TLS mutual authentication is required between API implementations and API clients
*****************************************
Fact/ Memory Tip: Although there are many benefits of CloudHub Dedicated Load balancer, TWO important things that should come to ones mind for considering it are:
>> Having URL endpoints with Custom DNS names on CloudHub deployed apps
>> Configuring custom certificates for both HTTPS and Two-way (Mutual) authentication.
Coming to the options provided for this question:
>> We CANNOT use DLB to perform cross-region load balancing between separate deployments of the same Mule application.
>> We can have mapping rules to have more than one DLB URL pointing to same Mule app. But vicevera (More than one Mule app having same DLB URL) is NOT POSSIBLE
>> It is true that DLB helps to setup custom DNS names for Cloudhub deployed Mule apps but NOT true for apps deployed to Customer-hosted Mule Runtimes.
>> It is true to that we can load balance API invocations across multiple CloudHub workers using DLB but it is NOT A MUST. We can achieve the same (load balancing) using SLB (Shared Load Balancer) too. We DO NOT necessarily require DLB for achieve it.
So the only right option that fits the scenario and requires us to use DLB is when TLS mutual authentication is required between API implementations and API clients.
質問 # 12
API 主導の接続のどのレイヤーが、主要なシステム、レガシー システム、データ ソースなどのロックを解除し、機能を公開することに重点を置いていますか?
- A. システム層
- B. プロセス層
- C. 経験層
正解：A
解説：
システムレイヤー
接続に対する API 主導のアプローチで使用される API は、次の 3 つのカテゴリに分類されます。
システム API - これらは通常、基幹システム オブ レコードにアクセスし、基盤となるシステムの複雑さや変更からユーザーを隔離する手段を提供します。構築すると、多くのユーザーが基盤となるシステムを学習する必要なくデータにアクセスでき、これらの API を複数のプロジェクトで再利用できます。
プロセス API - これらの API は、単一システム内またはシステム間でデータとやり取りしてデータを形成し (データ サイロを打破)、そのデータが発生するソース システムや、そのデータが通過するターゲット チャネルに依存することなくここで作成されます。配信されます。
エクスペリエンス API - エクスペリエンス API は、チャネルごとに個別のポイントツーポイント統合を設定するのではなく、すべて共通のデータ ソースから、対象とする対象者が最も簡単に消費できるようにデータを再構成できる手段です。通常、エクスペリエンス API は、API が特定のユーザー エクスペリエンスを念頭に置いて設計されている API ファーストの設計原則に基づいて作成されます。
質問 # 13
システム API の API データ モデルが、対応するバックエンド システムによって公開されたデータ モデルを合理的に模倣し、バックエンド システムのデータ モデルを最小限に改善できるのはいつですか?
- A. バックエンド システムからの限定的な分離のみを伴う実用的なアプローチが適切と見なされる場合
- B. システム API を、対応するデータ モデルを使用して境界付けられたコンテキストに割り当てることができる場合
- C. 近い将来、対応するバックエンド システムのリプレースが予想される場合
- D. 組織全体で広く使用されている既存のエンタープライズ データ モデルがある場合
正解：A
質問 # 14
プロセス API に適用される可能性が最も低い API ポリシーはどれですか?
- A. レート制限
- B. クライアント ID の強制
- C. JSON 脅威保護
- D. カスタム サーキット ブレーカー
正解：C
解説：
JSON threat protection
*****************************************
Fact: Technically, there are no restrictions on what policy can be applied in what layer. Any policy can be applied on any layer API. However, context should also be considered properly before blindly applying the policies on APIs.
That is why, this question asked for a policy that would LEAST likely be applied to a Process API.
From the given options:
>> All policies except "JSON threat protection" can be applied without hesitation to the APIs in Process tier.
>> JSON threat protection policy ideally fits for experience APIs to prevent suspicious JSON payload coming from external API clients. This covers more of a security aspect by trying toavoid possibly malicious and harmful JSON payloads from external clients calling experience APIs.
As external API clients are NEVER allowed to call Process APIs directly and also these kind of malicious and harmful JSON payloads are always stopped at experience API layer only using this policy, it is LEAST LIKELY that this same policy is again applied on Process Layer API.
質問 # 15
Mule アプリケーションの単体テストを正しく特徴付けるものは何ですか?
- A. 環境専用の Mule ランタイムを備えた単体テスト環境で実行する必要があります。
- B. ソース システムとターゲット システムの入出力の妥当性をテストします。
- C. 外部のクライアント ツールまたはイベント ソースによってトリガーされる必要があります。
- D. 通常、MUnit を使用して記述され、外部接続を必要としない組み込み Mule ランタイムで実行されます。
正解：D
解説：
They are typically written using MUnit to run in an embedded Mule runtime that does not require external connectivity.
*****************************************
Below TWO are characteristics of Integration Tests but NOT unit tests:
>> They test the validity of input and output of source and target systems.
>> They must be triggered by an external client tool or event source.
It is NOT TRUE that Unit Tests must be run in a unit testing environment with dedicated Mule runtimes for the environment.
MuleSoft offers MUnit for writing Unit Tests and they run in an embedded Mule Runtime without needing any separate/ dedicated Runtimes to execute them. They also do NOT need any external connectivity as MUnit supports mocking via stubs.
https://dzone.com/articles/munit-framework
質問 # 16
Anypoint Platform でクライアント管理に外部 ID プロバイダを使用する場合の主な要件は何ですか?
- A. アプリケーション ネットワークには、ID プロバイダーと対話するシステム API が含まれている必要があります。
- B. Anypoint Platform によって管理される API は、SAML 2.0 ポリシーによって保護される必要があります
- C. Anypoint Platform にサインインするには、シングル サインオンが必要です。
- D. Anypoint Platform によって管理される OAuth 2.0 で保護された API を呼び出すには、API クライアントは、同じ ID プロバイダーによって発行されたアクセス トークンを送信する必要があります。
正解：D
解説：
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/
質問 # 17
Anypoint Platform REST API、Anypoint CU、Mule Maven プラグインなどのツールを使用した Anypoint Platform との対話の自動化について正しいのはどれですか?
- A. Anypoint Platform API は CloudHub との対話のみを自動化できますが、顧客がホストする Mule ランタイムへのデプロイには Mule Maven プラグインが必要です。
- B. Anypoint Platform API と Anypoint CU へのアクセスは、Anypoint Platform のロールと権限によって個別に制御できるため、特定のユーザーは Anypoint CLI にアクセスでき、他のユーザーはプラットフォーム API にアクセスできます。
- C. デフォルトでは、Anypoint CLI と Mule Maven プラグインは Mule ランタイムに含まれていないため、デプロイされた Mule アプリケーションでは使用できません。
- D. API ポリシーを Anypoint Platform API に適用して、特定の LOB のみが特定の機能にアクセスできるようにすることができます。
正解：C
解説：
正解: デフォルトでは、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 つです。
これらは、展開または自動化のプロセス以外の一部ではありません。
質問 # 18
コード中心の API ドキュメント環境では、API コンシューマーが、代表的なシナリオの一部として 1 つ以上の API を呼び出す方法を示す API クライアント ソース コードを調査および実行できるようにする必要があります。
Anypoint Platform を使用して、この種のコード中心の API ドキュメント環境を提供する最も効果的な方法は何ですか?
- A. 関連する API ごとにモック サービスを有効にし、Anypoint Exchange エントリを介してそれらを公開します。
- B. 関連する API を Anypoint Exchange エントリを介して検出できるようにする
- C. Anypoint Exchange エントリと API コンソールを通じて API が十分に文書化されていることを確認し、これらのページをすべての API コンシューマーと共有します。
- D. API ノートブックを作成し、関連する Anypoint Exchange エントリに含めます。
正解：D
解説：
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
質問 # 19
API 実装の準備が整い、API が API Manager に登録されたら、誰が Anypoint Exchange の API へのアクセスを要求する必要がありますか?
- A. API クライアント
- B. なし
- C. API コンシューマ
- D. 両方
正解：C
解説：
API コンシューマー
********************************************
>> API クライアントは、API コンシューマのクライアント資格情報を使用するコードまたはプログラムの一部ですが、Anypoint Exchange と直接やり取りしてアクセスを取得することはありません
>> API コンシューマーは、登録して API へのアクセスを要求する必要がある人です。次に、API クライアントは、それらのクライアント資格情報を使用して API にアクセスする必要があります。したがって、API コンシューマーは、Anypoint Exchange から API へのアクセスを要求する必要がある人です。
質問 # 20
次の順序のうち、正しいものはどれですか?
- 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.
質問 # 21
以下にリストされている Anypoint Platform の機能のうち、API および API 呼び出し/コンシューマーのカテゴリに該当するものはどれですか? 2 つを選択します。
- A. API の設計と開発
- B. API ランタイムの実行とホスティング
- C. API の運用と管理
- D. API 消費者エンゲージメント
正解：A
解説：
Correct Answers: API Design and Development and API Runtime Execution and Hosting
*****************************************
>> API Design and Development - Anypoint Studio, Anypoint Design Center, Anypoint Connectors
>> API Runtime Execution and Hosting - Mule Runtimes, CloudHub, Runtime Services
>> API Operations and Management - Anypoint API Manager, Anypoint Exchange
>> API Consumer Management - API Contracts, Public Portals, Anypoint Exchange, API Notebooks
Explanation:
Correct Answers: API Operations and Management and API Consumer Engagement
*****************************************
>> API Design and Development - Anypoint Studio, Anypoint Design Center, Anypoint Connectors
>> API Runtime Execution and Hosting - Mule Runtimes, CloudHub, Runtime Services
>> API Operations and Management - Anypoint API Manager, Anypoint Exchange
>> API Consumer Management - API Contracts, Public Portals, Anypoint Exchange, API Notebooks
Bottom of Form
Top of Form
質問 # 22
展示を参照してください。
新しいプロモーション プロセス API 用に RAML 定義が提案され、Anypoint Exchange に公開されました。
プロモーション API の重要な利用者となるマーケティング部門には、満たさなければならない重要な要件と期待があります。
Anypoint Platform の機能を使用して、この初期の API 設計フェーズにマーケティング部門を関与させる最も効果的な方法は何ですか?
A) マーケティング部門に、自動生成された API コンソールを使用して API のモック実装と対話するように依頼します。
B) マーケティング IT システムのデータベース スキーマを RAML に変換する、マーケティング部門の DBA との設計ワークショップを開催する
C) Anypoint Studio を使用して API を Mule アプリケーションとして実装し、その API 実装を CloudHub にデプロイして、マーケティング部門に操作を依頼します。
D) API デザイナーから統合テスト スイートをエクスポートし、マーケティング部門にテストを実行してもらい、そのスイートで合格することを確認します。
- A. オプション B
- B. オプション C
- C. オプション D
- D. オプション A
正解：D
解説：
正解: マーケティング部門に依頼して、自動生成された API コンソールを使用して API のモック実装を操作してもらいます。
********************************************
MuleSoft の IT 運用モデルによると:
>> API コンシューマーは、完全な API 実装の準備が整うまで待つ必要はありません。
>> API を操作するために技術的なテスト スイートをエンド ユーザーと共有する必要はありません。
>> Anypoint Platform は、公開されているすべての API 仕様のモック機能を Anypoint Exchange に提供します。Anypoint Exchange には、API 機能と動作の性質のすべての詳細をカバーする豊富なドキュメントも含まれます。
>> フィードバックのためにエンドユーザーとワークショップの日を設定する必要はありません。
API コンシューマーは、プラットフォームで Anypoint Exchange 機能を使用し、モック機能を使用して API と対話できます。フィードバックをすばやく共有して、変更を組み込むことができます。
質問 # 23
アップストリーム API とその実装を設計する際、ダウンストリーム API には信頼できる SLA がないため、開発チームはダウンストリーム API を呼び出すときにタイムアウトを設定しないようにアドバイスされています。これは、そのアップストリーム API の唯一のダウンストリーム API 依存関係です。
ダウンストリーム API がクラッシュすることなく中断なく実行されると仮定します。このアドバイスはどのような影響を与えますか?
- A. アップストリーム API の SLA は提供できません
- B. ダウンストリーム API 実装が実行される Mule ランタイムによって、1000 ミリ秒未満のヒキガエル依存タイムアウトが適用されます。
- C. ダウンストリーム API の呼び出しは、タイムアウトせずに完了するまで実行されます。
- D. アップストリーム API 実装が実行される Mule ランタイムによって、500 ミリ秒のデフォルトのタイムアウトが自動的に適用されます。
正解：A
解説：
An SLA for the upstream API CANNOT be provided.
*****************************************
>> First thing first, the default HTTP response timeout for HTTP connector is 10000 ms (10 seconds). NOT
500 ms.
>> Mule runtime does NOT apply any such "load-dependent" timeouts. There is no such behavior currently in Mule.
>> As there is default 10000 ms time out for HTTP connector, we CANNOT always guarantee that the invocation of the downstream API will run to completion without timing out due to its unreliable SLA times.
If the response time crosses 10 seconds then the request may time out.
The main impact due to this is that a proper SLA for the upstream API CANNOT be provided.
質問 # 24
API 実装をステージング環境にデプロイする前に、一連のテストを実行する必要があります。データ セキュリティとアクセス制限により、テストされていない API にバックエンド システムへのアクセスを許可することはできないため、これらのテストにはモック データを使用する必要があります。利用可能なモック データとそのコンテンツの量は、バックエンド システムへのアクティブな接続なしで API 実装を完全にテストするのに十分です。この模擬データを組み込むには、どのような種類のテストを使用する必要がありますか?
- A. 性能試験
- B. 単体テスト (ホワイトボックス)
- C. 機能テスト (ブラックボックス)
- D. 統合テスト
正解：B
解説：
Unit tests (Whitebox)
*****************************************
質問 # 25
ある企業は、EU コントロール プレーンと顧客がホストする Mule ランタイムを組み合わせたハイブリッド Anypoint Platform デプロイ モデルを使用しています。ステージング環境で Mule API 実装を正常にテストした後、Mule API 実装は環境固有のプロパティで設定され、本番環境に昇格する必要があります。MuleSoft が Mule API 実装を設定し、本番環境への昇格を自動化するために推奨する方法は何ですか?
- A. API Manager の [プロパティ] タブで Mule API 実装のプロパティを変更し、API Manager を使用して Mule API 実装を本番環境にプロモートします。
- B. Anypoint Exchange で Mule API 実装のプロパティを変更し、Runtime Manager を使用して Mule API 実装を本番環境にプロモートします。
- C. API ポリシーを使用してステージング環境にデプロイされた Mule API 実装のプロパティを変更し、別の API ポリシーを使用して Mule API 実装を本番環境にデプロイします。
- D. 各環境のプロパティ ファイルを Mule API 実装の展開可能なアーカイブにバンドルし、Anypoint CLI または Anypoint Platform REST APIsB を使用して Mule API 実装を本番環境に昇格させます。
正解：D
解説：
Bundle properties files for each environment into the Mule API implementation's deployable archive, then promote the Mule API implementation to the Production environment using Anypoint CLI or the Anypoint Platform REST APIs
*****************************************
>> Anypoint Exchange is for asset discovery and documentation. It has got no provision to modify the properties of Mule API implementations at all.
>> API Manager is for managing API instances, their contracts, policies and SLAs. It has also got no provision to modify the properties of API implementations.
>> API policies are to address Non-functional requirements of APIs and has again got no provision to modify the properties of API implementations.
So, the right way and recommended way to do this as part of development practice is to bundle properties files for each environment into the Mule API implementation and just point and refer to respective file per environment.
質問 # 26
組織は、今日の見積もりをキャッシュする Quote of the Day API を実装しています。
オブジェクト ストア コネクタ経由で GoudHub オブジェクト ストアを使用して、キャッシュの状態を永続化できるシナリオはどれですか?
- A. キャッシュ状態を共有する必要がある 3 つの CloudHub ワーカーへの API 実装の 1 つの CloudHub デプロイがある場合
- B. キャッシュ状態を共有する必要がある同じ CloudHub リージョンに、2 つの Anypoint Platform ビジネス グループによる API 実装の 2 つの CloudHub デプロイがある場合
- C. API 実装の 3 つの CloudHub デプロイメントが、キャッシュ状態を共有する必要がある 3 つの個別の CloudHub リージョンにある場合
- D. CloudHub への API 実装のデプロイと、顧客がホストする Mule ランタイムへの anottV デプロイがあり、キャッシュ状態を共有する必要がある場合
正解：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 デプロイがある場合です。
質問 # 27
ある企業は、EU コントロール プレーンと顧客がホストする Mule ランタイムを組み合わせたハイブリッド Anypoint Platform デプロイ モデルを使用しています。ステージング環境で Mule API 実装を正常にテストした後、Mule API 実装は環境固有のプロパティで設定され、本番環境に昇格する必要があります。MuleSoft が Mule API 実装を設定し、本番環境への昇格を自動化するために推奨する方法は何ですか?
- A. API Manager の [プロパティ] タブで Mule API 実装のプロパティを変更し、API Manager を使用して Mule API 実装を本番環境にプロモートします。
- B. Anypoint Exchange で Mule API 実装のプロパティを変更し、Runtime Manager を使用して Mule API 実装を本番環境にプロモートします。
- C. API ポリシーを使用してステージング環境にデプロイされた Mule API 実装のプロパティを変更し、別の API ポリシーを使用して Mule API 実装を本番環境にデプロイします。
- D. 各環境のプロパティ ファイルを Mule API 実装の展開可能なアーカイブにバンドルし、Anypoint CLI または Anypoint Platform REST APIsB を使用して Mule API 実装を本番環境に昇格させます。
正解：D
解説：
正解: 各環境のプロパティ ファイルを Mule API 実装の展開可能なアーカイブにバンドルし、Anypoint CLI または Anypoint Platform REST API を使用して Mule API 実装を本番環境に昇格させます。
********************************************
>> Anypoint Exchange は、資産の発見と文書化に使用されます。Mule API 実装のプロパティを変更するための準備はまったくありません。
>> API Manager は、API インスタンス、そのコントラクト、ポリシー、および SLA を管理するためのものです。また、API 実装のプロパティを変更するための規定もありません。
>> API ポリシーは、API の非機能要件に対処するためのものであり、API 実装のプロパティを変更する規定はありません。
そのため、開発プラクティスの一環としてこれを行う正しい方法と推奨される方法は、各環境のプロパティ ファイルを Mule API 実装にバンドルし、環境ごとにそれぞれのファイルをポイントして参照することです。
質問 # 28
Anypoint VPC の技術アーキテクチャについて正しいのはどれですか?
- A. VPC ピアリングを使用して、基盤となる AWS VPC をオンプレミス (AWS 以外) のプライベート ネットワークにリンクできます。
- B. 各 CloudHub 環境には個別の Anypoint VPC が必要です
- C. Anypoint VPC のプライベート IP アドレス範囲は、CloudHub によって自動的に選択されます
- 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
質問 # 29
一部の HTTP 要求への応答は、要求で使用される HTTP 動詞に応じてキャッシュできます。HTTP 仕様によると、どの HTTP 動詞に対してこれを安全に行うことができますか?
- A. GET、OPTIONS、HEAD
- B. GET、HEAD、POST
- C. GET、PUT、オプション
- D. PUT、POST、DELETE
正解：A
解説：
GET,OPTIONS,HEAD
http://restcookbook.com/HTTP%20Methods/べき等性/
質問 # 30
展示を参照してください。
組織は、すべての CloudHub デプロイメントに対して 1 つの特定の CloudHub (AWS) リージョンを使用します。
組織の Mule アプリケーションがアベイラビリティーゾーン (AZ) の CloudHub にデプロイされている場合、CloudHub ワーカーはどのようにアベイラビリティーゾーン (AZ) に割り当てられますか?
- A. 特定の環境に属するワーカーは、そのリージョン内の同じ AZ に割り当てられます。
- B. Mule アプリケーション用に AZ がランダムに選択され、Mule アプリケーションのすべての CloudHub ワーカーがその 1 つの AZ に割り当てられます。
- C. ワーカーは、そのリージョン内の利用可能な AZ にランダムに分散されます
- D. AZ は、Mule アプリケーションのデプロイ構成の一部として選択されます
正解：B
解説：
Workers are randomly distributed across available AZs within that region.
*****************************************
>> Currently, we only have control to choose which AWS Region to choose but there is no control at all using any configurations or deployment options to decide what Availability Zone (AZ) to assign to what worker.
>> There are NO fixed or implicit rules on platform too w.r.t assignment of AZ to workers based on environment or application.
>> They are completely assigned in random. However, cloudhub definitely ensures that HA is achieved by assigning the workers to more than on AZ so that all workers are not assigned to same AZ for same application.
質問 # 31
MuleSoft が提案する IT 運用モデルの主な利点は何ですか?
- A. 1. IT デリバリー ギャップを減らす
2. IT キャパシティを増やすことなく、さまざまなビジネス ニーズに対応
3. まず、再利用可能なアセットの作成に集中します。考えられるすべてのアセットの作成が完了したら、組織内の LOB にそれらの使用を開始するよう通知します。 - B. 1. IT デリバリー ギャップを減らす
2. IT能力の増強と多様なIT部門の形成により、多様なビジネス需要に対応
3.資産の消費を生産速度で行う - C. 1. IT デリバリー ギャップを減らす
2. IT キャパシティを増やすことなく、さまざまなビジネス ニーズに対応
3.資産の消費を生産速度で行う
正解：C
解説：
1. Decrease the IT delivery gap
2. Meet various business demands without increasing the IT capacity
3. Make consumption of assets at the rate of production.
*****************************************
質問 # 32
バックエンド システムの制限により、システム API は 1 秒あたり最大 500 リクエストしか処理できません。バックエンド システムの過負荷を避けるために、システム API に適用するのに最適な API ポリシーのタイプはどれですか?
- A. レート制限
- B. スパイク制御
- C. レート制限 - SLA ベース
- D. HTTP キャッシング
正解：B
解説：
スパイクコントロール
********************************************
>> まず最初に、HTTP キャッシング ポリシーは、バックエンド システムの過負荷を回避することとは別の目的のためのものです。これはアウトです。
>> レート制限およびスロットリング/スパイク制御ポリシーは、API アクセスを制限するように設計されていますが、意図は異なります。
>> レート制限は、アクセスにハード制限を適用することで API を保護します。
>> スロットリング/スパイク制御は、トラフィックのスパイクを平滑化することで API アクセスを形作ります。
そのため、Spike Control は適切なオプションです。
質問 # 33
Anypoint Platform が提供する API 呼び出しメトリクスは何を提供しますか?
- A. ビジネス ユーザーと直接共有できる API からの ROI 指標
- B. 過去の API 呼び出しに関するデータで、さまざまな API の異常や使用パターンを特定するのに役立ちます
- C. 特定の脅威のしきい値を超える可能性がある将来のポリシー違反のプロアクティブな識別
- D. 再利用のレベルに基づくアプリケーション ネットワークの有効性の測定
正解：B
解説：
Data on past API invocations to help identify anomalies and usage patterns across various APIs
*****************************************
API Invocation metrics provided by Anypoint Platform:
>> Does NOT provide any Return Of Investment (ROI) related information. So the option suggesting it is OUT.
>> Does NOT provide any information w.r.t how APIs are reused, whether there is effective usage of APIs or not etc...
>> Does NOT prodive any prediction information as such to help us proactively identify any future policy violations.
So, the kind of data/information we can get from such metrics is on past API invocations to help identify anomalies and usage patterns across various APIs.
質問 # 34
......
検証済みMCPA-Level-1日本語問題集と解答100%合格はFast2test：https://jp.fast2test.com/MCPA-Level-1-JPN-premium-file.html