[2023年12月]更新のMCPA-Level-1日本語試験問題集合格させるのは2023年最新のMuleSoft Certified Platform Architect - Level 1 (MCPA-Level-1日本語版)
無料で使えるMCPA-Level-1日本語試験問題集で合格させるお手軽に試験合格
質問 # 35
システム API は、プライマリ環境とディザスター リカバリー (DR) 環境にデプロイされ、環境ごとに異なる DNS 名が使用されます。プロセス API はシステム API のクライアントであり、システム API によってレート制限されており、環境ごとに異なる制限があります。システム API の DR 環境は、プライマリ環境によって提供されるレート制限の 20% しか提供しません。これらの条件と制約を考慮して、プロセス API の全体的なエラーを減らすための最良の API フォールト トレラント呼び出し戦略は何ですか?
- A. 並行して、プライマリ環境にデプロイされたシステム API と DR 環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。プロセス API にロジックを追加して結果を組み合わせる
- B. プライマリ環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。それでも失敗する場合は、DR 環境にデプロイされたシステム API を呼び出します
- C. プライマリ環境にデプロイされたシステム API を呼び出します。再試行ロジックをプロセス API に追加して、DR 環境にデプロイされたシステム API を呼び出して断続的な障害を処理する
- D. プライマリ環境にデプロイされたシステム API を呼び出します。プロセス API にタイムアウトと再試行のロジックを追加して、断続的なエラーを回避します。それでも失敗する場合は、DR 環境にデプロイされたプロセス API のコピーを呼び出します
正解：B
解説：
正解: プライマリ環境にデプロイされたシステム 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を呼び出してください。
質問 # 36
展示を参照してください。組織は、モバイル アプリと 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. オプション A
- B. オプション D
- C. オプション C
- D. オプション B
正解：C
解説：
正解: モバイル アプリと Web アプリ用に個別のエクスペリエンス API を使用しますが、データベースと CRM システム用に作成された個別のシステム API を呼び出す共通のプロセス API です。
********************************************
MuleSoft の API 主導の接続によると:
>> エクスペリエンス API は、各消費者のニーズとその経験に応じて構築する必要があります。
>> プロセス API には、ビジネス機能を実現するためのすべてのオーケストレーション ロジックが含まれている必要があります。
>> バックエンド システムごとにシステム API を構築して、データのロックを解除する必要があります。
リファレンス：
質問 # 37
システム API の API データ モデルが、対応するバックエンド システムによって公開されたデータ モデルを合理的に模倣し、バックエンド システムのデータ モデルを最小限に改善できるのはいつですか?
- A. 近い将来、対応するバックエンド システムのリプレースが予想される場合
- B. 組織全体で広く使用されている既存のエンタープライズ データ モデルがある場合
- C. システム API を、対応するデータ モデルを使用して境界付けられたコンテキストに割り当てることができる場合
- D. バックエンド システムからの限定的な分離のみを伴う実用的なアプローチが適切と見なされる場合
正解：D
質問 # 38
アップストリーム API とその実装を設計する際、ダウンストリーム API には信頼できる SLA がないため、開発チームはダウンストリーム API を呼び出すときにタイムアウトを設定しないようにアドバイスされています。これは、そのアップストリーム API の唯一のダウンストリーム API 依存関係です。
ダウンストリーム API がクラッシュすることなく中断なく実行されると仮定します。このアドバイスはどのような影響を与えますか?
- A. アップストリーム API の SLA は提供できません
- B. ダウンストリーム API の呼び出しは、タイムアウトせずに完了するまで実行されます。
- C. アップストリーム API 実装が実行される Mule ランタイムによって、500 ミリ秒のデフォルトのタイムアウトが自動的に適用されます。
- D. ダウンストリーム API 実装が実行される Mule ランタイムによって、1000 ミリ秒未満のヒキガエル依存タイムアウトが適用されます。
正解：A
解説：
正解: アップストリーム API の SLA は提供できません。
********************************************
>> まず最初に、HTTP コネクタのデフォルトの HTTP 応答タイムアウトは 10000 ミリ秒 (10 秒) です。500ミリ秒ではありません。
>> Mule ランタイムは、そのような「負荷依存」のタイムアウトを適用しません。現在、Mule にはそのような動作はありません。
>> HTTP コネクタにはデフォルトで 10000 ミリ秒のタイムアウトがあるため、SLA 時間が信頼できないため、ダウンストリーム API の呼び出しがタイムアウトせずに完了することを常に保証することはできません。応答時間が 10 秒を超えると、リクエストがタイムアウトになる可能性があります。
これによる主な影響は、アップストリーム API の適切な SLA を提供できないことです。
質問 # 39
REST API 実装の統合テストの特徴ではない可能性が最も高いのはどれですか?
- A. Mule アプリケーションがコンパイルおよびパッケージ化された直後にテストが実行されます。
- B. テストでは、すべてのソースおよび/またはターゲット システムが構成され、アクセス可能である必要があります。
- C. テストは外部 HTTP 要求によってトリガーされます
- D. テストは、既知の要求ペイロードを準備し、応答ペイロードを検証します
正解：A
解説：
正解: Mule アプリケーションがコンパイルおよびパッケージ化された直後にテストが実行されます。
********************************************
>> 統合テストは、完全にカバーするために追加する必要があるテストの最後の層です。
>> これらのテストは、実際には完全な構成で実行されている Mule に対して実行され、PROD で動作するように外部ソースからテストされます。
>> これらのテストは、実際のトランスポートを有効にしてアプリケーション全体をテストします。そのため、これらのテストを実行すると、外部システムが影響を受けます。
そのため、これらのテストは、Mule アプリケーションがコンパイルおよびパッケージ化された直後には実行されません。
参考までに...単体テストは、Mule アプリケーションがコンパイルおよびパッケージ化された直後に実行されるテストです。
質問 # 40
特定のビジネス プロセスを実装するために、粗粒度の API デプロイ モデルではなく細粒度の API デプロイ モデルを使用した場合の典型的な結果は何ですか?
- A. API の範囲と複雑さが小さくなった結果、エンド ユーザーの応答時間が短縮されました。
- B. 各きめ細かな API が消費するリソースが少ないため、リソースの全体的なタワー使用量
- C. アプリケーション ネットワークで検出可能な API 関連アセットの数が多い
- D. ビジネス プロセスをサポートするアプリケーション ネットワーク内の接続数の減少
正解：C
解説：
正解: アプリケーション ネットワークで検出可能な API 関連アセットの数が多い。
********************************************
>> 粗粒度のアプローチと比較して、細粒度のアプローチでは応答時間が速くなりません。
>> 実際、粒度の細かい API モデルを持つネットワークよりも、粒度の粗い API を持つネットワークの方が応答時間が速くなります。理由は以下です。
きめの細かいアプローチ:
1. 粗視化に比べて API が多くなる
2. したがって、ビジネス プロセスで機能を実現するには、さらにオーケストレーションを行う必要があります。
3. つまり、多数の API 呼び出しを行う必要があります。したがって、より多くの接続を確立する必要があります。そのため、バルク機能が組み込まれた API が少ない粗粒度アプローチと比較して、明らかにホップ数、ネットワーク I/O 数、統合ポイント数が多くなります。
4. これが、これらすべての余分なホップと追加のレイテンシーのために、粗粒度アプローチに比べて細粒度アプローチの応答時間が少し長くなる理由です。
5. 遅延と接続が追加されるだけでなく、API の数が増えるため、きめの細かいアプローチでより多くのリソースが消費されます。
そのため、細粒度の API は、ネットワーク内でより多くの再利用可能なアセットを公開し、それらを発見できるようにするのに適しています。ただし、ネットワーク ホップと応答時間に関して少し妥協して、統合ポイント、接続、リソースを処理する、より多くのメンテナンスが必要です。
質問 # 41
Anypoint Platform で API ポリシーを使用して効果的に適用できないものは何ですか?
- A. DoS 攻撃に対する防御
- B. HTTP リクエストとレスポンスのロギング
- C. バックエンド システムの過負荷
- D. API 間で改ざん防止された資格情報を維持する
正解：A
解説：
正解: DoS 攻撃に対する防御
********************************************
>> バックエンド システムの過負荷は、「Spike Control Policy」を適用することで処理できます
>> HTTP リクエストとレスポンスのロギングは、「メッセージ ロギング ポリシー」を適用することで実行できます
>> クレデンシャルは「セキュリティ」および「コンプライアンス」ポリシーを使用して改ざん防止できます。ただし、残念ながら、現在 Anypoint Platform には DOS 攻撃を防ぐ適切な方法がありません。
質問 # 42
API ポリシーを適用できる Mule アプリケーション
その Mule アプリケーションによって公開されたエンドポイントへの Anypoint Platform?
A) HTTP/1.x 経由でリクエストを受け入れる Mule アプリケーション
B) TCP 経由で JSON 要求を受け入れるが、応答を提供する必要がない Mule アプリケーション
C) WebSocket 経由で JSON リクエストを受け入れる Mute アプリケーション
D) HTTP/2 経由で gRPC リクエストを受け入れる Mule アプリケーション
- A. オプション A
- B. オプション D
- C. オプション C
- D. オプション B
正解：A
解説：
選択肢A
********************************************
>> Anypoint API Manager と API ポリシーは、すべてのタイプの HTTP/1.x API に適用されます。
>> WebSocket API、HTTP/2 API、gRPC API には適用されません
質問 # 43
システム API を構築する際のベスト プラクティスは何ですか?
- A. バックエンド システムとの API 実装の相互作用のすべての技術的詳細を API クライアントに公開します。
- B. バックエンド システムごとに Enterprise Data Model (Canonical Data Model) を構築し、システム API に適用します。
- C. RAML 定義のような簡単に使用できるアセットを使用して API を文書化します。
- D. すべての API リソースとメソッドをモデル化して、バックエンド システムの操作を厳密に模倣する
正解：D
解説：
正解: すべての API リソースとメソッドをモデル化して、バックエンド システムの操作を厳密に模倣します。
********************************************
>> API のデータ モデルを選択する際に、固定された明確なベスト プラクティスはありません。それらは完全に文脈に依存し、多くの要因に依存します。これらの要因に基づいて、企業は、エンタープライズ標準データ モデルまたは境界コンテキスト モデルなどを使用する必要があるかどうかを選択できます。
>> API 実装の技術的な詳細を API クライアントに決して公開しないでください。API インターフェイス/RAML のみが API クライアントに公開されます。
>> 確かに、API の RAML 定義はできる限り詳細に記述し、ほとんどのドキュメントを反映する必要があります。ただし、それだけでは API を最もよく文書化された API と呼ぶには不十分です。開発者にとって使いやすい API とリポジトリを作成および作成するために、Anypoint Exchange と API ノートブックなどに関するさらに多くのドキュメントが必要です。
>> システム API を作成する際のベスト プラクティスは、そのバックエンド システムの操作と機能を厳密に反映するようにリソースとメソッドをモデル化して API インターフェースを作成することです。
質問 # 44
API 実装は、CloudHub 上の単一のワーカーにデプロイされ、外部 API クライアント (CloudHub の外部) によって呼び出されます。API 実装が API 呼び出しに応答しなくなるとすぐにトリガーされることが保証されているアラートを設定するにはどうすればよいですか?
- A. Anypoint Runtime Manager で「ワーカーが応答していません」アラートを構成する
- B. API が指定された期間内にリクエストを受信しなかった場合のアラートを作成します
- C. API 内にハートビート/ヘルス チェックを実装し、Anypoint Platform の外部から呼び出して、ハートビートが応答しない場合にアラートを出す
- D. 呼び出し元の API クライアント内で API 呼び出しの例外を処理し、API が使用できない場合にその API クライアントからアラートを生成します。
正解：A
解説：
Anypoint Runtime Manager で「ワーカーが応答していません」アラートを設定します。
********************************************
>> すべてのオプションは、最終的に、アプリケーションが応答を停止したときに必要なアラートを生成するのに役立ちます。
>> ただし、API を呼び出して例外を処理し、API クライアントからアラートを発生させるのは不適切でばかげています。API 実装を呼び出す多くの API クライアントが存在する可能性があり、すべてのクライアントで一貫してこの設定を行うことは理想的ではありません。現実的な方法ではありません。
>> API でヘルス チェック/ハートビートを実装し、外部から呼び出してヘルスを判断することは問題ないように聞こえますが、追加のセットアップが必要であり、同時に、外部ツール間で断続的なネットワークの問題が発生すると、誤ったアラームが生成される可能性が非常に高くなりますAPI 実装でヘルスチェック API を呼び出す。API の実装自体には問題がない場合がありますが、他の要因により誤報が発生する場合があります。
>> 指定された時間内に API がリクエストを受信しない場合に API Manager でアラートを作成すると、実際には現実的なアラートが生成されますが、ここでも、API クライアントからのリクエストが本当にない場合に誤ったアラームが発生する場合があります。
この要件を達成するための最善かつ適切な方法は、「ワーカーが応答していません」という条件で、Runtime Manager にアラートを設定することです。これにより、ワーカーが応答しなくなるとすぐにアラートが生成されます。
質問 # 45
組織は、既知のパートナーのみが組織の API を呼び出せるようにしたいと考えています。このセキュリティー目標を達成するために、組織は API Manager で Client ID Enforcement ポリシーを実施して、登録済みのパートナー・アプリケーションのみが組織の API を呼び出すことができるようにしたいと考えています。アプリケーションの JVM にポリシーを直接埋め込むのではなく、API プロキシを追加して Client ID Enforcement ポリシーを適用することを MuleSoft が推奨する API 実装のタイプはどれですか?
- A. APIkit を使用する Mule 3 アプリケーション
- B. カスタム Java コードで変更された Mule 3 または Mule 4 アプリケーション
- C. API 仕様を持つ Mule 4 アプリケーション
- D. Mule 以外のアプリケーション
正解：D
解説：
正解: Mule 以外のアプリケーション
********************************************
>> Mule ランタイムで実行されているすべてのタイプの Mule アプリケーション (Mule 3/ Mule 4/ APIkit を使用する/ カスタム Java コードを使用するなど) は、組み込みポリシーの適用をサポートしています。
>> 埋め込みポリシーの適用ができない、またはサポートされておらず、API プロキシが必要な唯一のオプションは、Mule 以外のアプリケーション用です。
したがって、Non Mule アプリケーションが正解です。
質問 # 46
API クライアントは、既存の API 実装から 1 つのメソッドを呼び出します。API の実装は後で更新されます。API クライアントの呼び出しロジックも更新する必要がある API 実装の変更はどれですか?
- A. API クライアントが使用するリソースに新しいメソッドが追加された場合
- B. API クライアントから呼び出されるメソッドに新しい必須フィールドが追加された場合
- C. API クライアントから呼び出されるメソッドに子メソッドを追加する場合
- D. APIクライアントから呼び出されるメソッドに対して、レスポンスのデータ型を変更した場合
正解：B
解説：
APIクライアントから呼び出されるメソッドに新たに必須フィールドを追加した場合
********************************************
>> 通常、API コントラクトが壊れた場合、API クライアントのロジックを更新する必要があります。
>> 新しいメソッドまたは子メソッドが API に追加されても、既存のメソッドを引き続き使用できるため、API クライアントは壊れません。したがって、これらの2つのオプションはありません。
>> 「変更された場合の応答のデータ型」と「新しい必須フィールドの追加」の 2 つが残ります。
>> 応答のデータ型を変更すると、API コントラクトが壊れます。ただし、質問は「呼び出し」ロジックを主張しており、応答処理ロジックについてではありません。API クライアントは引き続き API を正常に呼び出して応答を受信できますが、応答の一部のフィールドのデータ型が異なります。
>> 新しい必須フィールドを追加すると、API の呼び出し規約が壊れます。新しい必須フィールドを追加すると、API コントラクトは、API クライアント/API コンシューマーと API プロバイダーの間で結ばれている RAML または API 仕様の合意を破ります。そのため、API クライアント呼び出しロジックも更新する必要があります。
質問 # 47
共有ロード バランサで CloudHub を使用する場合、Anypoint Platform ではなく、API 実装 (Mule アプリケーション) によって排他的に管理されるものは何ですか?
- A. API 実装に割り当てられた DNS エントリの数
- B. HTTPS エンドポイントを公開するために API 実装によって使用される SSL 証明書
- C. ログ エントリを Runtime Manager で表示できるようにするロギング構成
- D. 特定の CloudHub ワーカーへの各 HTTP リクエストの割り当て
正解：B
解説：
正解: 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 はこれを行いません。
質問 # 48
API 実装が更新されました。API の RAML 定義もいつ更新する必要がありますか?
- A. API 実装が要求または応答メッセージの構造を変更する場合
- B. API の実装が、オンプレミスにデプロイされた従来のバックエンド システムとのやり取りから、最新のクラウドベース (SaaS) システムに変更される場合
- C. 平均応答時間を改善するために API 実装が最適化されている場合
- D. API 実装が Mule ランタイムの古いバージョンから新しいバージョンに移行される場合
正解：A
解説：
API 実装によってリクエストまたはレスポンス メッセージの構造が変更された場合
********************************************
>> RAML 定義は通常、リクエスト/レスポンス スキーマまたは API の特性に変更がある場合にのみ変更する必要があります。
>> パフォーマンス チューニング、バックエンド システムの移行など、API 実装の内部変更のために変更する必要はありません。
質問 # 49
API では、クライアント リクエスト (TPS) vth 小さなメッセージ ペイトアドの割合が高くなります。クライアント アプリケーションの種類に基づいて、API に使用制限を課すにはどうすればよいですか?
- A. クライアント アプリケーションの種類ごとに要求数を制限するスパイク制御ポリシーを使用する
- B. SLA ベースのレート制限ポリシーを使用し、クライアント アプリケーションをそのタイプに基づいて一致する SLA 層に割り当てます。
- C. クロスオリジン リソース共有 (CORS) ポリシーを使用して、クライアント アプリケーションの種類によって構成された、クライアント アプリケーション間のリソース共有を制限します。
- D. レート制限ポリシーとクライアント ID 強制ポリシーを使用します。それぞれクライアント アプリケーション タイプによって構成されます。
正解：B
解説：
正解: SLA ベースのレート制限ポリシーを使用し、クライアント アプリケーションをそのタイプに基づいて一致する SLA 層に割り当てます。
********************************************
>> クライアントの種類に基づいて API に制限が課されるときはいつでも、SLA 層が有効になります
質問 # 50
組織は、さまざまな API レイヤーを使用してモバイル クライアントをバックエンド システムと統合する API 主導のアーキテクチャを作成しました。バックエンド システムは、多数の特殊なコンポーネントで構成され、REST API を介してアクセスできます。プロセス API とエクスペリエンス API は、バックエンド データ モデルとは異なる同じ境界コンテキスト モデルを共有します。バックエンド システムから消費されるデータの処理を支援するために、このアーキテクチャにどの追加の標準モデル、境界コンテキスト モデル、または腐敗防止レイヤーを追加するのが最適ですか?
- A. バックエンド モデルと API 主導のモデルを組み合わせた正規モデルを作成して、データ モデルを簡素化および統合し、データ変換を最小限に抑えます。
- B. すべての API に対して腐敗防止レイヤーを作成し、すべてのデータ モデルが相互に一致するように変換を実行し、API 間でデータを簡単に移動できるようにして、正規モデルの構築の複雑さとオーバーヘッドを回避します。
- C. システム レイヤーの境界コンテキスト モデルを作成してバックエンド データ モデルと厳密に一致させ、腐敗防止レイヤーを追加して、さまざまな境界コンテキストがシステム レイヤーとプロセス レイヤー全体で連携できるようにします。
- D. すべてのレイヤーの境界コンテキスト モデルを作成し、境界コンテキストが重複する場合はそれらを重複させて、上流と下流のデータ モデルの違いを API 開発者に知らせます。
正解：C
解説：
正解: システム レイヤーの境界コンテキスト モデルを作成してバックエンド データ モデルと厳密に一致させ、腐敗防止レイヤーを追加して、さまざまな境界コンテキストがシステム レイヤーとプロセス レイヤー全体で連携できるようにします。
********************************************
>> 標準モデルはここではオプションではありません。組織はすでに努力を重ね、エクスペリエンス API とプロセス API 用の境界コンテキスト モデルを作成しているためです。
>> エクスペリエンス API とプロセス API は同じ境界コンテキスト モデルを共有すると述べられているため、すべての API の腐敗防止レイヤーは不要で無効です。今すぐアプローチを選択する必要があるのは、システム層の API だけです。
>> したがって、プロセス レイヤーとシステム レイヤーの間に腐敗防止レイヤーを配置するとうまく機能します。また、アプローチを高速化するために、システム API はバックエンド システム データ モデルを模倣できます。
質問 # 51
......
MCPA-Level-1日本語試験問題集、MCPA-Level-1日本語練習テスト問題：https://jp.fast2test.com/MCPA-Level-1-JPN-premium-file.html