[2024年01月07日] 無料MuleSoft MCPA-Level-1日本語試験問題と解答
検証済みMCPA-Level-1日本語問題集と解答は最新MCPA-Level-1日本語をダウンロード
質問 # 54
展示を参照してください。
新しいプロモーション プロセス 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. オプション D
- B. オプション B
- C. オプション A
- D. オプション C
正解:C
解説:
正解: マーケティング部門に依頼して、自動生成された API コンソールを使用して API のモック実装を操作してもらいます。
********************************************
MuleSoft の IT 運用モデルによると:
>> API コンシューマーは、完全な API 実装の準備が整うまで待つ必要はありません。
>> API を操作するために技術的なテスト スイートをエンド ユーザーと共有する必要はありません。
>> Anypoint Platform は、公開されているすべての API 仕様のモック機能を Anypoint Exchange に提供します。Anypoint Exchange には、API 機能と動作の性質のすべての詳細をカバーする豊富なドキュメントも含まれます。
>> フィードバックのためにエンドユーザーとワークショップの日を設定する必要はありません。
API コンシューマーは、プラットフォームで Anypoint Exchange 機能を使用し、モック機能を使用して API と対話できます。フィードバックをすばやく共有して、変更を組み込むことができます。
質問 # 55
コード中心の API ドキュメント環境では、API コンシューマーが、代表的なシナリオの一部として 1 つ以上の API を呼び出す方法を示す API クライアント ソース コードを調査および実行できるようにする必要があります。
Anypoint Platform を使用して、この種のコード中心の API ドキュメント環境を提供する最も効果的な方法は何ですか?
- A. 関連する API を Anypoint Exchange エントリを介して検出できるようにする
- B. Anypoint Exchange エントリと API コンソールを通じて API が十分に文書化されていることを確認し、これらのページをすべての API コンシューマーと共有します。
- C. 関連する API ごとにモック サービスを有効にし、Anypoint Exchange エントリを介してそれらを公開します。
- D. API ノートブックを作成し、関連する Anypoint Exchange エントリに含めます。
正解:D
解説:
正解: API ノートブックを作成し、関連する Anypoint exchange エントリに含める
********************************************
>> API ノートブックは、コード中心の API ドキュメントを提供できる Anypoint Platform のノートブックです。
質問 # 56
ビジネス ロジック オーケストレーションは、API 主導の接続のどのレイヤーに存在しますか?
- A. システム層
- B. 経験層
- C. プロセス層
正解:C
解説:
プロセスレイヤー
********************************************
>> エクスペリエンス レイヤーは、エンド ユーザー エクスペリエンスの強化専用です。このレイヤーは、さまざまな API クライアント/コンシューマーのニーズを満たすためのものです。
>> システム層は、本質的にモジュラーであり、バックエンド システムのさまざまな個々の機能を実装/公開する API 専用です。
>> プロセス レイヤーは、1 つまたは複数のシステム レイヤーのモジュラー API を呼び出すことによって、単純または複雑なビジネス オーケストレーション ロジックが記述される場所です。つまり、プロセス レイヤーが正解です。
質問 # 57
API 実装の準備が整い、API が API Manager に登録されたら、誰が Anypoint Exchange の API へのアクセスを要求する必要がありますか?
- A. なし
- B. API コンシューマ
- C. 両方
- D. API クライアント
正解:B
解説:
API コンシューマー
********************************************
>> API クライアントは、API コンシューマのクライアント資格情報を使用するコードまたはプログラムの一部ですが、Anypoint Exchange と直接やり取りしてアクセスを取得することはありません
>> API コンシューマーは、登録して API へのアクセスを要求する必要がある人です。次に、API クライアントは、それらのクライアント資格情報を使用して API にアクセスする必要があります。したがって、API コンシューマーは、Anypoint Exchange から API へのアクセスを要求する必要がある人です。
質問 # 58
システム API には、要求ごとに 100 ミリ秒の SLA が保証されています。システム API は、プライマリ環境とディザスター リカバリー (DR) 環境にデプロイされ、環境ごとに異なる DNS 名が使用されます。アップストリーム プロセス API はシステム API を呼び出します。このプロセス API の主な目的は、可能な限り短い時間でクライアントの要求に応答することです。システム API を呼び出す順序と、プロセス API からの要求に対する応答時間を短縮するには、どのような変更を加える必要がありますか?
- A. 並行して、プライマリ環境にデプロイされたシステム API と DR 環境にデプロイされたシステム API を、タイムアウトが設定されたスキャッター ギャザーを使用して呼び出し、その後、応答をマージします。
- B. プライマリ環境にデプロイされたシステム API を呼び出し、失敗した場合は DR 環境にデプロイされたシステム API を呼び出します。
- C. プライマリ環境にデプロイされたシステム API のみを呼び出し、タイムアウトと再試行ロジックを追加して、断続的な障害を回避します。
- D. 並行して、プライマリ環境にデプロイされたシステム API と DR 環境にデプロイされたシステム API を呼び出し、最初の応答のみを使用します。
正解:D
解説:
プライマリ環境にデプロイされたシステム API と DR 環境にデプロイされたシステム API を並行して呼び出し、最初の応答のみを使用します。
********************************************
>> 特定のシナリオでの API 要件は、可能な限り短い時間で応答することです。
>> 最初にプライマリ環境で API を試し、次に DR 環境で API にフォールバックすることを提案しているオプションは、応答は成功しますが、可能な限り短い時間ではありません。したがって、これは特定の要件に対する実装の正しい選択ではありません。
>> プライマリ環境でのみ API を呼び出し、タイムアウトと再試行を追加することを提案している別のオプションも、再試行時に成功する可能性がありますが、可能な限り短い時間ではありません。したがって、これは、特定の要件に対する実装の正しい選択でもありません。
>> Scatter-Gather を使用してプライマリ環境で API を呼び出し、DR 環境で API を並行して呼び出すことを提案しているもう 1 つのオプションは、マージされた結果を返すため、間違った API 応答になり、さらに、Scatter-Gather は物事を並行して実行します。ただし、その範囲内のすべてのルートを終了する場合にのみ、その範囲を完了します。繰り返しになりますが、特定の要件に対する実装の正しい選択ではありません。正しい選択は、プライマリ環境で API を呼び出し、DR 環境で API を並行して呼び出し、そのうちの 1 つから受信した最初の応答のみを使用することです。
質問 # 59
Anypoint Platform API からの応答ですぐにわかる、典型的な C4E の成功を測定する重要業績評価指標 (KPI) は何ですか?
- A. 過去 24 時間に報告された生産停止インシデントの数
- B. パブリックにアクセス可能な HTTP エンドポイントを持ち、Anypoint Platform によって管理されている API 実装の数
- C. CI/CD ツールを使用してデプロイされた API 実装と比較して、手動でデプロイされた API 実装の割合
- D. Anypoint Exchange に公開された RAML または OAS 形式の API 仕様の数
正解:D
解説:
Anypoint Exchange に公開されている RAML または OAS 形式の API 仕様の数
********************************************
>> C4E の成功は常に、構築と Anypoint Exchange への公開を支援してきた再利用可能なアセットの数に対する C4E の貢献にかかっています。
>> 停止の数、手動と CI/CD のデプロイ、またはパブリックにアクセス可能な HTTP エンドポイントに関する要因によるものではありません
>> Anypoint Platform API は、Anypoint Exchange に公開された RAML/OAS アセットの数をすばやく実行して取得するのに役立ちます。これは、応答で返されたアセットの数に基づいて、C4E チームがどれほど成功しているかを明確に示しています。
質問 # 60
REST API 実装の統合テストの特徴ではない可能性が最も高いのはどれですか?
- A. Mule アプリケーションがコンパイルおよびパッケージ化された直後にテストが実行されます。
- B. テストは、既知の要求ペイロードを準備し、応答ペイロードを検証します
- C. テストは外部 HTTP 要求によってトリガーされます
- D. テストでは、すべてのソースおよび/またはターゲット システムが構成され、アクセス可能である必要があります。
正解:A
解説:
正解: Mule アプリケーションがコンパイルおよびパッケージ化された直後にテストが実行されます。
********************************************
>> 統合テストは、完全にカバーするために追加する必要があるテストの最後の層です。
>> これらのテストは、実際には完全な構成で実行されている Mule に対して実行され、PROD で動作するように外部ソースからテストされます。
>> これらのテストは、実際のトランスポートを有効にしてアプリケーション全体をテストします。そのため、これらのテストを実行すると、外部システムが影響を受けます。
そのため、これらのテストは、Mule アプリケーションがコンパイルおよびパッケージ化された直後には実行されません。
参考までに...単体テストは、Mule アプリケーションがコンパイルおよびパッケージ化された直後に実行されるテストです。
質問 # 61
新しいアップストリーム API は、中央値 500 ミリ秒、最大 800 ミリ秒 (99 パーセンタイル) の応答時間の SLA を提供するように設計されています。対応する API 実装は、非常に類似した複雑さの 3 つのダウンストリーム API を順番に呼び出す必要があります。
これらのダウンストリーム API の最初のものは、応答時間について次の SLA を提供します: 中央値: 100 ミリ秒、80 パーセンタイル: 500 ミリ秒、95 パーセンタイル: 1000 ミリ秒。
可能であれば、新しいアップストリーム API の望ましい SLA を満たすために、最初のダウンストリーム API の呼び出しに対してアップストリーム API でタイムアウトを設定するにはどうすればよいですか?
- A. タイムアウトを 50 ミリ秒に設定します。これにより、その API のより多くの呼び出しがタイムアウトになりますが、再試行のための追加の余地が与えられます
- B. タイムアウトを設定しません。この API の呼び出しは必須であるため、応答するまで待つ必要があります
- C. 100 ミリ秒のタイムアウトを設定します。他の 2 つのダウンストリーム API が完了するまでに 400 ミリ秒かかります
- D. アップストリーム API の望ましい SLA を満たすためのタイムアウトはありません。別の SLA を最初のダウンストリーム API とネゴシエートするか、別の API を呼び出す必要があります
正解:C
解説:
正解: タイムアウトを 100 ミリ秒に設定します。これにより、他の 2 つのダウンストリーム API が完了するまでに 400 ミリ秒かかります
********************************************
特定のシナリオから取得する重要な詳細:
>> アップストリーム API の設計された SLA は 500 ミリ秒 (中央値) です。最大 SLA 応答時間を無視します。
>> この API は 3 つのダウンストリーム API を順番に呼び出しますが、これらはすべて同じような複雑さです。
>> 最初のダウンストリーム API は、SLA 中央値 100 ミリ秒、80 パーセンタイル: 500 ミリ秒を提供しています。95 パーセンタイル: 1000 ミリ秒。
上記の詳細に基づいて:
>> 50 ミリ秒のタイムアウトを設定することを提案しているオプションを除外できます。提供されている SLA の中央値自体が 100 ミリ秒である場合、ほとんどの呼び出しがタイムアウトになり、再試行に時間が費やされ、最終的にはすべての再試行で使い果たされるためです。いくつかの再試行が成功したとしても、残りの時間は、2 番目と 3 番目のダウンストリーム API が時間内に応答するのに十分な余地を残しません。
>> この API の呼び出しは必須であり、応答するまで待たなければならないため、タイムアウトを設定しないことを提案するオプションはばかげています。タイムアウトを設定しないと、適切な実装パターンに反することになります。さらに、最初の API が提供された SLA の中央値である 100 ミリ秒以内に応答しない場合は、おそらく 500 ミリ秒 (80 パーセンタイル) または 1000 ミリ秒 (95 パーセンタイル) で応答します。どちらの場合も、最初のダウンストリーム API から正常な応答を得ても、この時点ですでに 500 ミリ秒のアップストリーム API SLA に違反しているため、何の役にも立ちません。2 番目と 3 番目のダウンストリーム API を呼び出す時間はありません。
>> アップストリーム API が要求する SLA を満たすためのタイムアウトがないというのは事実ではありません。
最初のダウンストリーム API は 100 ミリ秒の中央値 SLA を提供しているため、ほとんどの場合、その時間内に応答を取得できます。したがって、100 ミリ秒のタイムアウトを設定すると、残りの 2 つのダウンストリーム API 呼び出しに対して 400 ミリ秒の十分な余地が残されるため、MOST 呼び出しに最適です。
質問 # 62
展示を参照してください。
API 主導の接続とアプリケーション ネットワークという意味で有効な API とは何ですか?
A) Java RMI over TCP
B) Java RMI over TCP
C) CORBA over HOP
D) XML over UDP
- A. オプション B
- B. オプション A
- C. オプション C
- D. オプション D
正解:D
解説:
正解: XML over HTTP
********************************************
>> API 主導の接続とアプリケーション ネットワークは、最も効果的な API とネットワークをその上に構築するために、HTTP ベースのプロトコルで API を使用することを強く求めています。
>> HTTP ベースの API により、プラットフォームはさまざまな種類のポリシーを適用して多くの NFR に対処できます
>> HTTP ベースの API により、HTTP ベースの w3c ルールに準拠した多くの標準的で効果的な実装パターンを実装することもできます。
質問 # 63
展示を参照してください。組織は、モバイル アプリと 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. オプション B
- C. オプション C
- D. オプション A
正解:C
解説:
正解: モバイル アプリと Web アプリ用に個別のエクスペリエンス API を使用しますが、データベースと CRM システム用に作成された個別のシステム API を呼び出す共通のプロセス API です。
********************************************
MuleSoft の API 主導の接続によると:
>> エクスペリエンス API は、各消費者のニーズとその経験に応じて構築する必要があります。
>> プロセス API には、ビジネス機能を実現するためのすべてのオーケストレーション ロジックが含まれている必要があります。
>> バックエンド システムごとにシステム API を構築して、データのロックを解除する必要があります。
リファレンス:
質問 # 64
組織は、顧客住所情報を取得するために顧客住所 API を実装しました。この API は複数の環境にデプロイされており、あらゆる場所でクライアント ID を適用するように構成されています。
開発者は、ユーザーが住所を更新できるようにするクライアント アプリケーションを作成しています。開発者は、Anypoint Exchange で Customer Address API を見つけ、それをクライアント アプリケーションで使用したいと考えています。
Anypoint Platform で自動的に実行できる API へのアクセス取得のステップはどれですか?
- A. クライアント アプリケーションの資格情報を使用して API を呼び出すようにクライアント アプリケーションを変更します。
- B. 選択した SLA レベルのクライアント アプリケーション要求を承認する
- C. クライアント アプリケーションの資格情報を使用して、複数の環境にデプロイされた適切な API インスタンスへのアクセスを要求します。
- D. API へのアクセスを要求するために、Anypoint Exchange で新しいアプリケーションを作成します。
正解:B
解説:
正解: 選択した SLA レベルのクライアント アプリケーション要求を承認する
********************************************
>> 選択した SLA レベルのクライアント アプリケーション リクエストの承認のみを自動化できます
>> 提供された残りのオプションは無効です
質問 # 65
Anypoint Platform で API ポリシーを使用して効果的に適用できないものは何ですか?
- A. バックエンド システムの過負荷
- B. DoS 攻撃に対する防御
- C. HTTP リクエストとレスポンスのロギング
- D. API 間で改ざん防止された資格情報を維持する
正解:B
解説:
正解: DoS 攻撃に対する防御
********************************************
>> バックエンド システムの過負荷は、「Spike Control Policy」を適用することで処理できます
>> HTTP リクエストとレスポンスのロギングは、「メッセージ ロギング ポリシー」を適用することで実行できます
>> クレデンシャルは「セキュリティ」および「コンプライアンス」ポリシーを使用して改ざん防止できます。ただし、残念ながら、現在 Anypoint Platform には DOS 攻撃を防ぐ適切な方法がありません。
質問 # 66
ある企業は、成功を収めたエンタープライズ データ モデル (EDM) を作成しました。同社は、同社の IT 運用モデルのコア イネーブラーとして最新の API を採用することにより、アプリケーション ネットワークの構築に取り組んでいます。最新の API データ モデルを設計する際に、企業はどの API 層 (経験、プロセス、システム) で EDM を再利用する必要がありますか?
- A. プロセス層とシステム層
- B. エクスペリエンス層とシステム層
- C. エクスペリエンス層とプロセス層
- D. エクスペリエンス、プロセス、およびシステム層
正解:A
解説:
プロセス層とシステム層で
********************************************
>> Experience Layer API は、エンド ユーザーのエクスペリエンス専用にモデル化および設計されています。そのため、エクスペリエンス レイヤーのデータ モデルは、そのような API コンシューマーの性質とタイプによって異なります。たとえば、モバイル消費者はネットワーク上で簡単に転送できる軽量のデータ モデルを必要とし、Web ベースの消費者は Web ページ上のほとんどの情報をレンダリングするために詳細なデータ モデルを必要とします。したがって、エンタープライズ データ モデルは正規モデルの目的には適していますが、エクスペリエンス API には適していません。
>> そのため、EDM はプロセスおよびシステム層で広く使用する必要がありますが、エクスペリエンス層では使用しないでください。
質問 # 67
API 実装は、要求している API クライアントに 3 つの X-RateLimit-* HTTP 応答ヘッダーを返します。これらの応答ヘッダーは、API クライアントにどのような種類の情報を示していますか?
- A. 次のリクエストで送信する相関 ID
- B. HTTP レスポンス サイズ
- C. スロットリングによるエラー コード
- D. API 実装によって許容される残りの容量
正解:D
解説:
正解: API 実装によって許可される残りの容量。
********************************************
>>参照: https://docs.mulesoft.com/api-manager/2.x/rate-limiting-and-throttling-sla-based-policies#response-headers
質問 # 68
プロセス API に適用される可能性が最も低い API ポリシーはどれですか?
- A. クライアント ID の強制
- B. カスタム サーキット ブレーカー
- C. レート制限
- D. JSON 脅威保護
正解:D
解説:
正解: JSON 脅威保護
********************************************
事実: 技術的には、どのポリシーをどのレイヤーに適用できるかについて制限はありません。任意のレイヤー API に任意のポリシーを適用できます。ただし、やみくもに API にポリシーを適用する前に、コンテキストも適切に考慮する必要があります。
そのため、この質問では、プロセス API に適用される可能性が最も低いポリシーを求めました。
指定されたオプションから:
>> 「JSON 脅威保護」を除くすべてのポリシーは、プロセス層の API にためらうことなく適用できます。
>> JSON 脅威保護ポリシーはエクスペリエンス API に最適で、外部 API クライアントからの疑わしい JSON ペイロードを防ぎます。これは、エクスペリエンス API を呼び出す外部クライアントからの悪意のある有害な JSON ペイロードを回避しようとすることで、より多くのセキュリティ面をカバーします。
外部 API クライアントがプロセス API を直接呼び出すことは決して許可されておらず、また、この種の悪意のある有害な JSON ペイロードは、このポリシーのみを使用してエクスペリエンス API レイヤーで常に停止されるため、この同じポリシーがプロセス レイヤー API に再び適用される可能性はほとんどありません。
質問 # 69
一緒に使用すると、IT 運用モデルを効果的にするのは次のうちどれですか?
- A. 再利用可能なアセットを作成する、作成したアセットを組織全体でマーケティングする、アセットが消費されているかどうかを確認するための LOB レビューを随時調整する
- B. 再利用可能なアセットを作成し、それらを検出可能にして、LOB チームがセルフサービスで API を参照できるようにします。
- C. 再利用可能なアセットを作成し、LOB チームがセルフサービスで API を閲覧できるようにそれらを検出可能にし、アクティブなフィードバックと使用状況の指標を取得します
正解:B
解説:
正解: 再利用可能なアセットを作成し、LOB チームがセルフサービスで API を参照できるようにそれらを検出可能にし、アクティブなフィードバックと使用状況の指標を取得します。
********************************************
質問 # 70
......
リアル問題集を使おう 100%無料MCPA-Level-1日本語試験問題集:https://www.goshiken.com/MuleSoft/MCPA-Level-1-JPN-mondaishu.html