[2025年04月04日] MCPA-Level-1日本語 PDF問題とテストエンジンには154問があります [Q25-Q48]

25、ある電子商取引会社が、自社の Web サイトに新しい製品詳細機能を追加しています。顧客が製品カタログページを開くと、製品ごとに新しい製品詳細リンクが表示され、クリックすると製品の詳細な説明を取得できます。製品詳細データは、年に 1 回または 2 回の製品更新リリースで更新されますが、現在、データベースの応答時間は、データ量が多いため非常に遅くなっています。
応答時間が最も短く、フォールトトレラントで、データの一貫性を保ちながら製品の詳細を取得するアクションは何ですか。

キャッシュスコープ内のデータベースから製品の詳細を選択し、APIレスポンス内で返します。

データベースから製品の詳細を選択し、Anypoint MQ に格納します。Anypoint MO サブサーバーは製品の詳細を受信し、API 応答内で返します。

オブジェクトストアを使用して、データベースから読み取った製品の詳細を保存および取得し、APIレスポンス内で返します。

データベースから製品の詳細を選択し、APIレスポンス内で返します。

* Scenario Analysis:
* The eCommerce company’s Product Details feature requires low response time and consistent data for a feature where data rarely changes (only once or twice a year).
* The database response time is slow due to high volume, so querying the database directly on each request would lead to poor performance and higher response times.
* Optimal Solution Requirements:
* Low Response Time: Data retrieval should be fast and not depend on database performance.
* Fault Tolerance and Data Consistency: Cached or stored data should be consistent and resilient in case of database unavailability, as the product details data changes infrequently.
* Evaluating the Options:
* Option A: Using a Cache scope would temporarily store the product details in memory, which could improve performance but might not be suitable for infrequent updates (only twice a year), as cache expiration policies typically require shorter durations.
* Option B: Storing product details in Anypoint MQ and then retrieving it through a subscriber is not suitable for this use case. Anypoint MQ is better for messaging rather than as a data storage mechanism.
* Option C (Correct Answer): Using an object store to store and retrieve product details is ideal.
Object stores in MuleSoft are designed for persistent storage of key-value pairs, which allows storing data retrieved from the database initially. This provides quick, consistent access without querying the database on every request, aligning with requirements for low response time, fault tolerance, and data consistency.
* Option D: Selecting data directly from the database for each request would not meet the performance requirement due to known slow response times from the database.
* Conclusion:
* Option C is the best answer, as using an object store allows caching the infrequently updated product details. This approach reduces the dependency on the database, significantly improving response time and ensuring consistent data.
Refer to MuleSoft documentation on Object Store v2 and best practices for data caching to implement this solution effectively.

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

再利用可能なアセットを作成する、作成したアセットを組織全体でマーケティングする、アセットが消費されているかどうかを確認するための LOB レビューを随時調整する

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

再利用可能なアセットを作成し、それらを検出可能にして、LOB チームがセルフサービスで API を参照できるようにします。

27、MuleSoft が提案する IT 運用モデルの主な利点は何ですか?

1. IT デリバリーギャップを減らす
2. IT キャパシティを増やすことなく、さまざまなビジネスニーズに対応
3. まず、再利用可能なアセットの作成に集中します。考えられるすべてのアセットの作成が完了したら、組織内の LOB にそれらの使用を開始するよう通知します。

1. IT デリバリーギャップを減らす
2. IT能力の増強と多様なIT部門の形成により、多様なビジネス需要に対応
3.資産の消費を生産速度で行う

1. IT デリバリーギャップを減らす
2. IT キャパシティを増やすことなく、さまざまなビジネスニーズに対応
3.資産の消費を生産速度で行う

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

APIkit を使用する Mule 3 アプリケーション

カスタム Java コードで変更された Mule 3 または Mule 4 アプリケーション

API 仕様を持つ Mule 4 アプリケーション

Mule 以外のアプリケーション

29、ある企業は、成功を収めたエンタープライズデータモデル (EDM) を作成しました。同社は、同社の IT 運用モデルのコアイネーブラーとして最新の API を採用することにより、アプリケーションネットワークの構築に取り組んでいます。最新の API データモデルを設計する際に、企業はどの API 層 (経験、プロセス、システム) で EDM を再利用する必要がありますか?

エクスペリエンス層とプロセス層

エクスペリエンス層とシステム層

プロセス層とシステム層

エクスペリエンス、プロセス、およびシステム層

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

複数のデータセンターですべてのアプリケーションを高可用性にする必要がある場合

すべての API を非公開にし、パブリッククラウドに公開しないことが必要な場合

規制要件により、メタデータを含むすべてのデータ項目のオンプレミス処理が義務付けられている場合

アプリケーションネットワーク内のすべてのバックエンドシステムが組織のイントラネットに展開されている場合

31、API ポリシーが Anypoint Platform で定義されている場所と、それが API インスタンスにどのように適用されるかについて正しいのはどれですか?

API ポリシーは、Mule ランタイムへの API デプロイメントの一部として Runtime Manager で定義され、特定の API インスタンスにのみ適用されます。

API ポリシーは、特定の API インスタンスに対して API Manager で定義され、特定の API インスタンスにのみ適用されます。

API ポリシーは API Manager で定義され、すべての API インスタンスに自動的に適用されます。

API ポリシーは API Manager で定義され、指定された環境のすべての API インスタンスに適用されます。

正解: API ポリシーは、特定の API インスタンスに対して API Manager で定義され、特定の API インスタンスにのみ適用されます。
********************************************
>> API 仕様の準備が整い、Exchange に公開されたら、API Manager にアクセスして、各 API の API インスタンスを登録する必要があります。
>> API Manager は、NFR にポリシーを適用して NFR に対処するなど、API の側面の管理が行われる場所です。
>> 同じ API に対して複数のインスタンスを作成し、目的ごとに異なる方法で管理できます。
>> 1 つのインスタンスに API ポリシーのセットを適用し、同じ API の別のインスタンスに別の目的で別のポリシーのセットを適用できます。
>> これらの API とそのインスタンスは、環境ごとに定義されています。そのため、環境ごとに個別に管理する必要があります。
>> プラットフォーム機能を使用してより高い環境に昇格するときに、API インスタンス (SLA、ポリシーなど) の同じ構成が昇格されるようにすることができます。ただし、これはオプションのみです。必要に応じて、環境ごとに変更することもできます。
>> Runtime Manager は、API 実装とその Mule ランタイムを管理する場所ですが、API 自体は管理しません。API ポリシーは Mule Runtimes で実行されますが、Runtime Manager で API ポリシーを強制することはできません。環境内の厳選されたインスタンスに対してのみ、API Manager を介してこれを行う必要があります。
したがって、これらの事実に基づいて、指定された選択肢の正しいステートメントは、「API ポリシーは、特定の API インスタンスに対して API Manager で定義され、特定の API インスタンスにのみ適用されます」です。

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

更新はプロジェクトリスクとして識別し、この API を使用する機能の完全な回帰テストを実行する必要があります。

API プロデューサーに連絡して、既存の機能への変更を理解する必要があります。

API プロデューサーは、新しいバージョンと並行して古いバージョンを実行するように要求する必要があります。

API クライアントコードは、新しい機能を利用する必要がある場合にのみ変更する必要があります。

33、チームは Experience API 仕様の強化を計画しており、API 主導の接続設計原則に従っています。
API を強化する動機は何ですか?

主要なAPIコンシューマーは、特定の種類のエンドポイントをCenter for Enablement標準からコンシューマーシステム標準に変更することを望んでいます。

基盤となるシステムAPIが更新され、頻繁に使用されるリソースのより詳細なデータが提供されるようになりました。

開発環境とステージング環境のAPIインスタンスにIP許可リストポリシーが追加されています

APIに含まれるいくつかの種類のデータに影響を与える標準データモデルが採用されています。

34、展示を参照してください。

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

STAGING 環境で API を所有する Anypoint Platform アカウントのクライアント ID とシークレット

Anypoint Platform アカウントの STAGING 環境のクライアント ID とシークレット

STAGING 環境の API インスタンス用に Anypoint Exchange から取得したクライアント ID とシークレット

Anypoint Platform から取得した有効な OAuth トークンと、それに関連付けられたクライアント ID とシークレット

35、システム API を構築する際のベストプラクティスは何ですか?

RAML 定義のような簡単に使用できるアセットを使用して API を文書化します。

すべての API リソースとメソッドをモデル化して、バックエンドシステムの操作を厳密に模倣する

バックエンドシステムごとに Enterprise Data Model (Canonical Data Model) を構築し、システム API に適用します。

バックエンドシステムとの API 実装の相互作用のすべての技術的詳細を API クライアントに公開します。

36、展示を参照してください。

新しいプロモーションプロセス 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

オプション C

オプション D

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

顧客がホストするランタイムプレーンと顧客がホストするコントロールプレーンを手動でプロビジョニング

MuleSoft がホストするランタイムプレーンと顧客がホストするコントロールプレーン

顧客がホストするランタイムプレーンと MuleSoft がホストするコントロールプレーンを手動でプロビジョニング

iPaaS でプロビジョニングされた顧客がホストするランタイムプレーンと MuleSoft がホストするコントロールプレーン

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

Anypoint Platform API と Anypoint CU へのアクセスは、Anypoint Platform のロールと権限によって個別に制御できるため、特定のユーザーは Anypoint CLI にアクセスでき、他のユーザーはプラットフォーム API にアクセスできます。

Anypoint Platform API は CloudHub との対話のみを自動化できますが、顧客がホストする Mule ランタイムへのデプロイには Mule Maven プラグインが必要です。

デフォルトでは、Anypoint CLI と Mule Maven プラグインは Mule ランタイムに含まれていないため、デプロイされた Mule アプリケーションでは使用できません。

API ポリシーを Anypoint Platform API に適用して、特定の LOB のみが特定の機能にアクセスできるようにすることができます。

39、組織は、さまざまなクラウドベースの SaaS システムと複数のオンプレミスシステムを使用しています。オンプレミスシステムは、組織のアプリケーションネットワークの重要な部分であり、組織のイントラネット内からのみアクセスできます。
クラウドベースの SaaS システムとオンプレミスシステムの両方との統合をサポートするために、Anypoint Platform を構成して使用する最良の方法は何ですか?
A) Anypoint Platform Private Cloud Edition コントロールプレーンによって管理される Anypoint VPC で、CloudHub でデプロイされた Mule ランタイムを使用する

B) MuleSoft がホストする Anypoint Platform コントロールプレーンによって管理される共有ワーカークラウドで、CloudHub でデプロイされた Mule ランタイムを使用する

C) Anypoint Platform Private Cloud Edition コントロールプレーンによって管理される、外部ネットワークアクセスなしで完全に分離された Mule ランタイムのオンプレミスインストールを使用する

D) MuleSoft がホストする Anypoint Platform コントロールプレーンによって管理される、クラウドハブでデプロイされ、手動でプロビジョニングされたオンプレミスの Mule ランタイムの組み合わせを使用する

オプション A

オプション B

オプション C

オプション D

40、Order API は、大量の統合ロジックを含み、Product API の呼び出しを伴うように設計する必要があります。
Order API と Product API の間の力関係は、「顧客/サプライヤー」の関係の 1 つです。なぜなら、Product API は組織全体で頻繁に使用され、CTO のオフィスにいる専任の開発チームによって開発されるからです。
Order API 内で Product API の API データモデルを処理するには、どのような戦略を使用する必要がありますか?

Order API の統合ロジックが 1 つの一貫した内部データモデルで動作できるように、Order API の API データモデルを採用するよう、Product API の開発チームを説得します。

注文 API が製品 API と同じ (変更されていない) データ型を使用するように、注文 API の統合ロジックを実装するときに、製品 API の API データ型を直接操作します。

Order API に、製品 API データモデルを Order API の内部データ型に変換する腐敗防止レイヤーを実装します。

製品 API と注文 API の両方で使用されるエンタープライズデータモデルをもたらす、組織全体のデータモデリングイニシアチブを開始します。

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

Anypoint Platform にサインインするには、シングルサインオンが必要です。

アプリケーションネットワークには、ID プロバイダーと対話するシステム API が含まれている必要があります。

Anypoint Platform によって管理される OAuth 2.0 で保護された API を呼び出すには、API クライアントは、同じ ID プロバイダーによって発行されたアクセストークンを送信する必要があります。

Anypoint Platform によって管理される API は、SAML 2.0 ポリシーによって保護される必要があります

42、正しいか間違っているか。より多くの工数とリソースが必要な場合でも、設計および開発されている API がセルフサービス可能であることを常に確認する必要があります。

FALSE

TRUE

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

すべての機能がさまざまな操作/リソースとしてラップされている customerManagement という名前のシステム API を実装します。

createCustomer、amendCustomer、retrieveCustomer、suspendCustomer という名前の異なるシステム API を実装します。それらはモジュール化されており、懸念事項が分離されているためです。

createCustomerInCRMZ、amendCustomerInCRMZ、retrieveCustomerFromCRMZ、suspendCustomerInCRMZ という名前の異なるシステム API を実装します。それらはモジュール化されており、懸念事項が分離されているためです。

44、API ポリシーが Anypoint Platform で定義されている場所と、それが API インスタンスにどのように適用されるかについて正しいのはどれですか?

API ポリシーは、Mule ランタイムへの API デプロイメントの一部として Runtime Manager で定義され、特定の API インスタンスにのみ適用されます。

API ポリシーは、特定の API インスタンスに対して API Manager で定義され、特定の API インスタンスにのみ適用されます。

API ポリシーは API Manager で定義され、すべての API インスタンスに自動的に適用されます。

API ポリシーは API Manager で定義され、指定された環境のすべての API インスタンスに適用されます。

45、展示を参照してください。

新しいプロモーションプロセス 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

オプション C

オプション D

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

組織全体で広く使用されている既存のエンタープライズデータモデルがある場合

システム API を、対応するデータモデルを使用して境界付けられたコンテキストに割り当てることができる場合

バックエンドシステムからの限定的な分離のみを伴う実用的なアプローチが適切であると見なされる場合

近い将来、対応するバックエンドシステムのリプレースが予想される場合

When a pragmatic approach with only limited isolation from the backend system is deemed appropriate.
*****************************************
General guidance w.r.t choosing Data Models:
>> If an Enterprise Data Model is in use then the API data model of System APIs should make use of data types from that Enterprise Data Model and the corresponding API implementation should translate between these data types from the Enterprise Data Model and the native data model of the backend system.
>> If no Enterprise Data Model is in use then each System API should be assigned to a Bounded Context, the API data model of System APIs should make use of data types from the corresponding Bounded Context Data Model and the corresponding API implementation should translate between these data types from the Bounded Context Data Model and the native data model of the backend system. In this scenario, the data types in the Bounded Context Data Model are defined purely in terms of their business characteristics and are typically not related to the native data model of the backend system. In other words, the translation effort may be significant.
>> If no Enterprise Data Model is in use, and the definition of a clean Bounded Context Data Model is considered too much effort, then the API data model of System APIs should make use of data types that approximately mirror those from the backend system, same semantics and naming as backend system, lightly sanitized, expose all fields needed for the given System API’s functionality, but not significantly more and making good use of REST conventions.
The latter approach, i.e., exposing in System APIs an API data model that basically mirrors that of the backend system, does not provide satisfactory isolation from backend systems through the System API tier on its own. In particular, it will typically not be possible to “swap out” a backend system without significantly changing all System APIs in front of that backend system and therefore the API implementations of all Process APIs that depend on those System APIs! This is so because it is not desirable to prolong the life of a previous backend system’s data model in the form of the API data model of System APIs that now front a new backend system. The API data models of System APIs following this approach must therefore change when the backend system is replaced.
On the other hand:
>> It is a very pragmatic approach that adds comparatively little overhead over accessing the backend system directly
>> Isolates API clients from intricacies of the backend system outside the data model (protocol, authentication, connection pooling, network address, …)
>> Allows the usual API policies to be applied to System APIs
>> Makes the API data model for interacting with the backend system explicit and visible, by exposing it in the RAML definitions of the System APIs
>> Further isolation from the backend system data model does occur in the API implementations of the Process API tier

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

OAuth 2.0 アクセストークンの適用

クライアント ID の強制

JSON 脅威保護

IPwhitellst

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

経験層

プロセス層

システム層

[2025年04月04日] MCPA-Level-1日本語 PDF問題とテストエンジンには154問があります [Q25-Q48]

コメントを残すコメントをキャンセル

関連認証

MCPA-Level-1-JPN 練習テスト

最近の投稿

アーカイブ

カテゴリー

[2025年04月04日] MCPA-Level-1日本語 PDF問題とテストエンジンには154問があります [Q25-Q48]

コメントを残す コメントをキャンセル

関連認証

MCPA-Level-1-JPN 練習テスト

最近の投稿

アーカイブ

カテゴリー

コメントを残すコメントをキャンセル