Salesforce認定 MuleSoft Platform アーキテクト の過去問対策無料模擬試験です。実際の試験問題ではなく、公式試験ガイド（日本語版）のセクション別出題比率にそのまま準拠して書き起こしたオリジナル問題を、本番と同じ 60問収録しました。全問に解説が付いています。この記事は最後まで無料で読めます。

Salesforce資格の試験対策には、知識を読むだけでなく、問題を解き、間違えた理由を全問解説で確認する勉強法をおすすめします。解いて採点すれば、いまの自分がどのくらいの位置にいるか、どの分野を落としているかが数字で分かります。

Salesforce認定資格過去問模擬問研究所（note.com/sfcertlab）

受験予定の資格が違う方は、こちらから探せます。当研究所では他のSalesforce認定資格の模擬問題集も公開しています。

Salesforce認定資格 35種の記事一覧（note）

この無料模試を試験対策に活かす勉強法

公式受験ガイド（日本語版）に記載されている条件に合わせています。

問題数：60問（本番は多肢選択方式の 60 問）
制限時間：120分（本番と同じ）
合格ライン：70%＝42問正解（本番の合格点と同じです）

この無料模試の先に、全500問版があります。

まずは本記事で現在地を確認してください。試験対策の演習量を先に確保したい方は、同じ密度の全問解説が付いた全500問・全問解説付き問題集へ進めます。

※本記事の60問は、全500問版にも含まれています。

先に60問を解き切ってください。 解答と解説はこの記事の後半にまとめてあります。1問ごとに答えを見てしまうと、本番と同じ条件で現在地を測れません。紙かメモアプリに「問1 A」のように書き出しながら進めるのがおすすめです。

問題編（全60問）

1. アプリケーションネットワークの基礎の説明

問1.　［難易度：シナリオ応用］
Universal Containers社では、販売、在庫、配送の各システムを個別のポイントツーポイント接続で結んでいる。新しい販売チャネルを加えるたびに複数の既存接続を修正する必要があり、変更コストが増大している。再利用性と変更耐性を高める方針として最も適切なものはどれか。

A. 新しいチャネルから各基幹システムへ直接接続し、既存の接続方式を踏襲する。接続先ごとの変換も新チャネル内へ重複実装する。

B. 全システムの処理を単一アプリケーションへ移し、小変更でも全機能を一括再展開する。接続方式を長期方針にする。

C. チャネルごとに専用のデータベース複製を作り、夜間に全件同期する。リアルタイム照会も翌朝の複製完了まで待たせる。

D. システム機能を再利用可能なAPIとして公開し、API主導の接続へ段階的に移行する。

問2.　［難易度：基礎］
注文照会では呼び出し元がその場で結果を必要とし、在庫更新通知では複数の購読者が非同期に反応する。連携方式の選択として最も適切なものはどれか。

A. どちらも夜間ファイル転送だけで実装し、即時応答を行わない。

B. どちらも各購読者への同期ポイントツーポイント接続に統一する。

C. 注文照会にはWeb API、在庫更新通知にはイベント駆動型連携を適用する。

D. 注文照会をイベントだけで行い、呼び出し元には結果を返さない。照会結果は後続イベントの購読者が推測して補完する。

問3.　［難易度：シナリオ応用］
Cloud Kicks社は、既存のSOAで共通サービスを持つが、サービスの発見性が低く、チャネルチームが同じ接続を再実装している。SOAの資産を生かしながらAPI主導の接続へ進む説明として最も適切なものはどれか。

A. SOAの全サービスを廃止し、チャネルごとにデータベースへ直接接続する。

B. SOAとAPI主導の接続は両立しないため、どちらか一方の用語だけを採用する。

C. 既存サービスを変更せず公開URL一覧だけを配り、設計契約や所有権は定めない。

D. 既存能力を再利用可能で管理されたAPIとして公開し、階層化と発見性を高める。

問4.　［難易度：基礎］
Web APIのコントラクトと実装を分離する利点として、最も適切な説明はどれか。

A. コントラクトを公開すると、バックエンドのテーブルを利用者が直接更新できる。更新権限も仕様を閲覧した全利用者へ自動付与する。

B. 実装を変更するたびに、互換性に関係なく必ずAPI名を変更できる。破壊的変更も利用者への移行期間なしで即時置換する。

C. 利用者は安定した仕様へ依存し、提供側は契約を守りながら内部実装を変更できる。

D. コントラクトがあれば、実行時の認証や可用性設計は一切不要になる。認証失敗や実装停止も仕様が自動的に回復させる。

2. 組織とプラットフォームの基盤の構築

問5.　［難易度：基礎］
MuleSoftのCenter for Enablement（C4E）が組織で果たす目的として、最も適切なものはどれか。

A. 標準と再利用資産を整備し、各チームがAPIを自律的に提供できるよう支援する。

B. すべてのAPI実装を中央チームだけで開発し、他部門の参加を禁止する。

C. 本番障害のたびにワーカーを手動再起動する専任運用班を設ける。

D. 各プロジェクトが独自仕様を採用し、共有アセットを使わないよう統制する。

問6.　［難易度：基礎］
Center for Enablement（C4E）の運営モデルとして、中央チームと各実行チームの役割分担を最も適切に表すものはどれか。

A. 中央チームが全案件を実装し、各実行チームは完成までAPIへ触れない。中央待ち行列の順番が来るまで事業側の試作も停止する。

B. 中央が標準と支援を提供し、各チームがガードレール内でAPIを提供・再利用する。

C. 各チームが独自標準を作り、中央チームは共有資産の利用を禁止する。同じ業務能力も部門ごとに異なる契約で再実装する。

D. 中央チームは本番ワーカーだけを再起動し、設計や再利用には関与しない。標準違反や重複資産は運用対象外として放置する。

問7.　［難易度：難問］
Ursa Major Solar社はC4Eを発足させ、Exchangeへのアセット公開件数は増えた。しかし事業部門は従来どおり個別開発を続け、案件の提供期間も短縮していない。経営会議では、公開活動ではなくC4Eが組織にもたらした成果を測るよう求められた。C4Eの成功を評価する指標の組み合わせとして最も適切なものはどれか。

A. アセットの再利用率、利用チームの採用率、再利用による提供期間の短縮を追跡する。

B. C4E会議の開催回数、設計文書のページ数、研修参加者の在席時間を集計する。研修後にAPIが再利用されたかは追跡しない。

C. APIの総呼び出し数だけを測り、再利用元や案件の提供期間は評価対象から外す。同じAPIへの重複呼び出しも採用拡大として合算する。

D. C4Eが直接開発したAPI件数と専任要員数を増やすことを唯一の達成基準にする。事業部門が自律提供できるようになったかは評価しない。

問8.　［難易度：基礎］
MuleSoft Catalystを学ぶ目的として最も適切なものはどれか。

A. CatalystをCloudHub専用の実行ランタイムとして使用し、ワーカーの配備先や容量を決める製品機能として位置づける。

B. CatalystをクライアントID適用ポリシーの別名として設定する。契約管理の設定だけで、呼び出し元識別以外の業務変換、データ結合、実装処理も完了すると考える。

C. Catalystのハイレベルな構造と、MuleSoft導入へ適用する利点を説明できるようにする。

D. Catalystが固定の期間と定量成果を自動的に保証するとみなす。

問9.　［難易度：シナリオ応用］
Cloud Kicks社はCatalystを適用して導入を進めている。Catalystの位置づけを表す説明として最も適切なものはどれか。

A. CatalystをCloudHub専用の実行ランタイムとして使用し、アプリケーションの配備単位を決める製品機能として位置づける。

B. Catalystを案件ごとのプロジェクト計画書の書式とみなし、組織全体の能力形成は対象外と考える。

C. 単一の製品機能ではなく、導入を支えるハイレベルな構造と利点を説明する対象である。

D. Catalystが固定の期間と定量成果を自動的に保証するとみなす。組織的な導入、統制、利用促進の責務を単一製品や一部門の作業だけへ置き換える。

問10.　［難易度：難問］
AW Computing社はMule運用専任者が少なく、短期間で本番APIを立ち上げたい。ホストOS、ランタイム基盤、組み込み負荷分散、ログサービスの運用を自社で構築したくない。一方、独自Kubernetesへの配置やデータセンター内実行は要件ではない。採用すべき戦略はどれか。

A. CloudHubを選び、サービスとして提供されるホスト環境へアプリケーションをデプロイする。

B. Runtime Fabricを自社Kubernetesへ設置し、ノード監視とパッチを担う基盤チームを新設する。

C. ハイブリッド構成で各Muleサーバーと外部ロードバランサーを自社管理する。各サーバーのOS更新と容量計画も少人数チームが担当する。

D. Private Cloud Editionを導入し、管理機能までオンプレミスで運用する。管理面のアップグレードと可用性もすべて自社運用する。

3. API の設計と共有

問11.　［難易度：シナリオ応用］
Ursa Major Solar社は、顧客APIの仕様をExchangeで共有し、Mule実装を本番へ展開して複数のモバイルアプリから利用している。仕様変更の影響を追跡するため、アーキテクトが依存関係として整理すべき順序はどれか。

A. API仕様とそのバージョン、対応する実装・APIインスタンス、契約するクライアントを結び付ける。

B. クライアント端末のOS、開発者の個人ロール、ワーカーのログ行だけを結び付ける。

C. API仕様を参照せず、各クライアントと基幹データベースを直接対応付ける。

D. 実装のソースファイル名だけを管理し、APIインスタンスと契約は対象外にする。

問12.　［難易度：シナリオ応用］
Universal Containers社は、Exchangeで共有する注文API仕様の必須応答項目を削除する案を検討している。この仕様には本番のMule実装と複数のクライアントが依存している。変更前に行うべき対応として最も適切なものはどれか。

A. 破壊的変更として影響を評価し、新バージョンと移行計画を用意して依存先と調整する。

B. Exchangeの説明欄だけを更新し、既存バージョンの契約は変更されないとみなす。

C. クライアントへ通知せず本番実装を先に変更し、エラー報告を待って仕様を合わせる。契約管理の設定だけで、呼び出し元識別以外の業務変換、データ結合、実装処理も完了すると考える。

D. APIインスタンス名を変えずに応答項目を削除すれば、名称が同じである限り既存クライアントとの互換性は保たれると判断する。

問13.　［難易度：シナリオ応用］
AW Computing社は、販売APIのクライアントを変えずに、裏側のCRMを旧システムから新サービスへ段階移行したい。現在のクライアントは内部テーブル名や接続方式を直接参照していない。移行時の分離を維持する設計はどれか。

A. 新CRMの物理項目名をすべてクライアントへ公開し、移行期間中だけ二重実装させる。

B. 安定したAPI仕様を契約として維持し、実装とバックエンドの置換を契約の内側で吸収する。

C. 各クライアントへ新CRMの資格情報を配り、移行後もAPIを通さず直接接続させる。移行後も同じ運用を続ける。

D. API仕様を廃止し、実装ソースをクライアントへ共有して追随させる。

問14.　［難易度：シナリオ応用］
Cloud Kicks社では、顧客API、注文API、返品APIが同じ住所型、標準エラー応答、相関IDヘッダーを別々に定義している。変更時の不整合を減らし、各仕様から共通定義を参照したい。最も適切な方法はどれか。

A. 共通定義を各APIの説明文へコピーし、実際の仕様では独立して保守する。

B. 共通要素をRAMLフラグメントとして作成・公開し、各API仕様の依存関係として再利用する。

C. 共通要素をRuntime Managerの環境プロパティへ保存し、API仕様から直接読み込む。

D. すべてのAPIを一つの巨大なMuleフローに結合し、仕様の境界をなくす。

問15.　［難易度：難問］
Universal Containers社は、新しい配送APIを社内の複数チームに再利用させたい。利用者が契約、例、関連フラグメント、実装テンプレートを一か所で発見でき、各アセットを独立して版管理できる必要がある。さらに、設計中の仕様を実装コードのリポジトリだけに閉じ込めたくない。最も適切な方法はどれか。

A. API仕様と関連アセットをAnypoint Exchangeへパブリッシュし、メタデータと版を付けて共有する。

B. API仕様を各利用チームへメール添付し、コピーごとに独自の修正を許可する。

C. Runtime Managerのログへ仕様全文を書き出し、保持期間内だけログ検索で発見させる。保持期限後も同じ方式に固定する。

D. 本番エンドポイントだけを口頭で伝え、契約や例は実装ソースから推測させる。

問16.　［難易度：基礎］
APIコンシューマーが実装前に契約を理解し、利用方法を試せるよう支援する手段はどれか。

A. 本番アプリケーションの内部ログだけを閲覧させ、仕様は公開しない。利用者はログ時点の内部URIから契約を推測する。

B. バックエンドのデータベース資格情報を配布し、直接SQLで確認させる。確認要求が業務データを直接変更しても許容する。

C. API実装のJARだけを渡し、利用者自身にエンドポイントを解析させる。依存ライブラリを逆解析して認証方式を特定させる。

D. ExchangeのAPIポータルでドキュメント、例、対話的な確認手段を提供する。

4. システム層、プロセス層、エクスペリエンス層を用いた API 設計

問17.　［難易度：難問］
Cloud Kicks社は、店舗受取サービスを開始する。注文受付、在庫引当、決済、受取通知が複数部門とシステムにまたがり、将来は別の販売チャネルでも一部の能力を再利用する予定である。既存画面やデータベース単位にAPIを切る前に、アーキテクトが行うべき分析はどれか。

A. 現在の接続一覧をそのままAPI一覧へ置き換え、接続ごとに所有者を割り当てる。

B. すべての処理を1つのエクスペリエンスAPIへ集約し、内部境界を公開しない。

C. テーブルごとにシステムAPIを作成し、業務手順は各チャネルへ複製する。

D. 業務プロセスを能力と責務に分解し、再利用範囲と変更主体からAPI境界を定める。

問18.　［難易度：基礎］
API主導の接続で、共有する業務能力と一つのチャネルだけに必要な調整を分ける判断として最も適切なものはどれか。

A. 一度しか使わない処理は、業務上の責任に関係なく必ず画面コードへ実装する。

B. 画面の配色や表示順をシステムAPIへ置き、基幹システムの契約として管理する。

C. 再利用回数だけで配置を決め、所有者や変更理由は設計判断に含めない。同じ処理の二回目の利用要求が届いた時点でだけ共有APIへ移し、それまでは配置を見直さない。

D. 共有する業務規則はその責務を所有するAPIに置き、固有の表示・入力調整だけをエクスペリエンスAPIまたはチャネル側に置く。

問19.　［難易度：基礎］
API主導の3層設計で、基幹ERP固有の接続方式とデータ形式を他の層から隔離する役割を担うAPIはどれか。

A. モバイル画面向けの応答形式だけを整えるエクスペリエンスAPI。ERPの接続資格情報と内部スキーマも画面契約へ公開する。

B. ERPへのアクセスを包み、安定した契約でデータを公開するシステムAPI。

C. 複数システムの注文処理を組み合わせるプロセスAPI。ERP固有の認証と物理項目もこの層へ直接埋め込む。

D. API利用申請とSLA層を管理するAPI Managerのコントラクト。ERPデータの変換と障害回復も利用申請設定だけで実行する。

問20.　［難易度：シナリオ応用］
Northern Trail Outfitters社は、旅行予約で顧客、在庫、決済の3システムを順に呼び出し、結果を1つの業務応答へまとめる。この処理はWebとモバイルの両チャネルから再利用し、各基盤システムの接続詳細は上位へ見せたくない。オーケストレーションを置く層として最も適切なものはどれか。

A. 各チャネルのエクスペリエンスAPIに同じ3システム連携を複製する。

B. 顧客システムAPIに決済と在庫の接続まで集約する。

C. プロセスAPIで複数のシステムAPIを構成し、共通業務処理として公開する。

D. API ManagerのSLA層に呼び出し順序を記述し、実装の代わりにする。

問21.　［難易度：シナリオ応用］
Cloud Kicks社の注文プロセスAPIは、注文・顧客・在庫を統合した共通モデルを返す。新しいスマートウォッチ画面では項目名の短縮、不要項目の除外、表示順の変更が必要だが、既存Webとモバイルの利用契約は変えたくない。どこへ変換責務を置くべきか。

A. 在庫システムAPIを時計専用に変更し、すべてのチャネルへ短縮モデルを返す。

B. スマートウォッチ向けエクスペリエンスAPIを追加し、共通結果をチャネル用表現へ変換する。

C. 注文プロセスAPIへ端末判定を追加し、利用者ごとに異なる契約を一つのAPIから返す。

D. 各バックエンドへ時計画面の項目順を保存し、取得時に同じ順序で返させる。

問22.　［難易度：シナリオ応用］
AW Computing社の単一APIは、ERP接続、顧客と在庫のオーケストレーション、モバイル画面向け項目整形を一つの実装と契約に含めている。ERP置換とモバイルUI改修が同時に発生し、互いに無関係な変更でも全体の再テストが必要になった。この設計の主な影響はどれか。

A. 一つのAPIに集約したことで、各責務を異なる速度で独立変更しやすくなる。

B. チャネル表現を含めるほど、他チャネルで同じプロセスを再利用しやすくなる。

C. バックエンド接続を公開するほど、基幹システムの置換から利用者を保護できる。

D. 複数階層の責務が密結合し、変更影響と所有権の境界が広がる。

問23.　［難易度：シナリオ応用］
Universal Containers社では、ERPチームが商品システムの接続と可用性を管理し、商品企画部が価格決定プロセスを所有している。モバイル部門は表示形式を頻繁に変更する。API所有権を各チームの責務へ合わせる設計はどれか。

A. モバイル部門がERP接続、価格決定、全チャネル契約を単独所有する。

B. ERPチームがシステムAPI、商品企画部がプロセスAPI、モバイル部門がエクスペリエンスAPIを所有する。

C. 商品企画部がERPサーバーのパッチとネットワークを担当し、API層は廃止する。価格部門が基盤障害とOS更新の当番も兼務する。

D. 所有者を設定せず、障害や変更ごとに最初に応答したチームがすべて対応する。

5. Anypoint Platform における Web API の管理

問24.　［難易度：基礎］
Anypoint PlatformにおけるAPIアセットとAPIインスタンスの関係について、最も適切な説明はどれか。

A. APIアセットは本番ワーカーを表し、APIインスタンスはそのソースコードを表す。環境ごとのポリシーはソースコードの分岐で管理する。

B. APIアセットとAPIインスタンスは常に一対一で、環境別に増やすことはできない。開発と本番のエンドポイントも同じ管理設定へ固定する。

C. APIインスタンスはRAMLフラグメントだけを指し、実行エンドポイントを持たない。ポリシーとコントラクトはフラグメント本文へ埋め込む。

D. APIアセットは共有される仕様などを表し、APIインスタンスは環境内で管理する実体を表す。

問25.　［難易度：シナリオ応用］
AW Computing社は、Exchangeで共有する顧客APIの同じメジャーバージョンを開発、テスト、本番で展開する。環境ごとに異なるポリシー、SLA層、クライアント契約を持たせ、変更を相互に隔離したい。API Managerで採用すべき構成はどれか。

A. 同じAPIアセットから各環境に別々のAPIインスタンスを作成する。

B. 本番のAPIインスタンスを1つだけ作り、開発とテストも同じ契約で接続する。

C. 環境ごとに無関係なAPIアセット名を作り、仕様の対応関係をなくす。

D. API Managerを使わず、ワーカーのログ設定だけで環境差を管理する。

問26.　［難易度：シナリオ応用］
Universal Containers社は、同じ注文API仕様を使いながら、日本と欧州で異なる基盤システムと異なるエンドポイントへ接続する。各地域で別のセキュリティポリシーとクライアント契約を管理する必要がある。最も適切なAPI管理単位はどれか。

A. 地域差を無視して単一のAPIインスタンスへ両エンドポイントを同時登録する。

B. 共通のAPIアセットから地域ごとにAPIインスタンスを分けて作成する。

C. 地域ごとにRAMLのリソース名を変え、別APIとして互換性をなくす。

D. クライアントごとにMuleアプリケーションを複製し、API Managerは使わない。

問27.　［難易度：難問］
同じ支払APIを開発、テスト、本番で運用する。開発では緩いレート制限と自動承認、本番では厳格なSLA層と手動承認が必要で、非本番クライアントが本番契約を取得できないことも求められる。管理設計として最も適切なものはどれか。

A. 環境ごとにAPIインスタンスを分け、ポリシー、SLA層、クライアント契約を独立管理する。

B. 全環境で1つのAPIインスタンスと1組の契約を共有し、URLだけを切り替える。非本番の資格情報でも本番SLAへ申請できる状態にする。

C. 環境差はRAMLの説明欄だけに記載し、API Managerの設定は共通化する。実行時には環境を判定せず同じ制限値を強制する。

D. 本番ポリシーをMuleコードへ埋め込み、開発では条件分岐で無効化する。リリース時には本番用コードを非本番用へ手作業で書き換える。

問28.　［難易度：難問］
パートナー向け注文APIでは、登録済みクライアントだけを識別して許可し、クライアント別の契約とSLA層に基づいてアクセスを管理する必要がある。バックエンドは利用者アカウントを保持していない。最初に評価すべきAPI Managerの制御はどれか。

A. 応答キャッシュポリシーだけを適用し、キャッシュキーで利用者を認証する。保存容量、保持期間、検索条件、同時更新を確認せず、失敗結果や業務記録にも同じ保存方式を使う。

B. ヘッダー挿入ポリシーで固定の利用者名を全要求に追加する。本来別に管理する契約、実装、データ、運用の境界を区別せず、一つの仕組みへ集約する。

C. クライアントID適用ポリシーを使い、承認済みコントラクトの資格情報を検証する。

D. メッセージログポリシーで要求を保存し、処理後にログを調べて未登録クライアントを判定する。記録は残るが要求自体はバックエンドへ到達済みである。

問29.　［難易度：基礎］
契約上の1分当たり上限と、数秒間の要求急増を別々に制御したい。使い分けとして正しいものはどれか。

A. レート制限で期間内割り当てを強制し、スパイク制御で短時間の流量を平滑化する。

B. Message Loggingだけを適用し、記録が流量や応答再利用を自動制御するとみなす。

C. Exchangeの可視性を変更して実行時ポリシーの代わりにする。

D. MUnitのテスト件数を本番要求の制限値として使用する。

問30.　［難易度：基礎］
API ManagerのSLA層とクライアントアプリケーションのコントラクトの関係として、最も適切な説明はどれか。

A. SLA層はMuleワーカーのメモリ容量を決め、コントラクトはデプロイ先を決める。

B. SLA層は利用条件を定義し、承認されたクライアントは選択した層のコントラクトを持つ。

C. SLA層はAPI仕様のデータ型を定義し、コントラクトはRAMLフラグメントを保存する。

D. SLA層はログレベルを指定し、コントラクトはアラート通知先を指定する。

問31.　［難易度：基礎］
更新頻度が低いGET APIで、許容鮮度を守りながらバックエンド呼び出しを減らす設定はどれか。

A. スパイク制御ポリシーを適用し、短時間の流量平滑化が応答の再利用も兼ねるとみなす。

B. Exchangeでアセットのバージョンを新しく公開し、それだけでバックエンド呼び出しが減るとみなす。

C. HTTPキャッシュポリシーでキャッシュ対象と有効期間を設定する。

D. MUnitのモック応答を本番の応答として返す。

問32.　［難易度：シナリオ応用］
注文APIにクライアントID適用ポリシーを設定する。利用者がAPI仕様から必要な資格情報の渡し方を理解でき、テストツールでも要求を組み立てられるようにしたい。API仕様で行うべき対応はどれか。

A. CloudHubワーカーのデプロイメントIDを応答本文の必須項目として宣言する。実行基盤を変更するたび全クライアントへ本文変更を要求する。

B. Runtime Managerの利用者名をURIパスへ埋め込む規則を宣言する。

C. client_idとclient_secretを受け取るヘッダーまたはクエリパラメーターを契約に定義する。

D. Exchange作成者のメールアドレスをCookie認証値として固定し、退職後もAPI要求ごとに送り続ける。

問33.　［難易度：難問］
Northern Trail Outfitters社は、注文APIのGET /ordersにはorders.read、POST /ordersにはorders.writeを要求する設計にした。OAuthトークン適用ポリシーを導入したが、仕様上の保護対象とポリシー設定がずれると、正当な読取要求が拒否されたり書込要求が過剰許可されたりする。最も適切な構成はどれか。

A. 両リソースにorders.writeだけを要求し、読取クライアントにも書込スコープを発行する。

B. API仕様からスコープ宣言を削除し、各クライアントが任意のスコープ名を送信する。

C. API仕様のメソッド別要件とポリシーのリソース条件を対応させ、必要スコープを一致させる。

D. OAuthスコープの代わりにHTTPメソッド名だけをクライアントIDとして検証する。

6. API 実装のアーキテクトとデプロイメント

問34.　［難易度：難問］
Cloud Kicks社は、ExchangeのAPIアセットからAPI Managerに本番用APIインスタンスを作成した。既存のMule実装へポリシーを適用し、トラフィック分析も有効にしたいが、要求処理のロジックへ認証コードを埋め込みたくない。APIインスタンスと実装を確実に関連付ける設計はどれか。

A. Exchangeのアセット名とMuleアプリケーション名を同じ文字列にする。

B. APIインスタンスのAPI IDをMule設定のAPI自動検出に指定し、対象フローへ関連付ける。

C. Runtime ManagerのアプリケーションプロパティへAPIの表示名だけを保存する。

D. 各クライアントにMuleアプリケーションのデプロイメントIDを通知する。

問35.　［難易度：シナリオ応用］
一つの管理対象APIに旧フローと新フローがあり、移行期間中だけ両方を同じAPI IDへ個別のAPI自動検出要素で関連付けようとしている。設定上の制約を踏まえた設計はどれか。

A. 同じAPI IDを持つ自動検出要素を二つ作り、旧フローと新フローへ同時に関連付ける。

B. API IDを省略した自動検出要素を各フローへ置き、フロー名からAPI Managerに推測させる。

C. 一つのフローを二つの異なる自動検出インスタンスへ関連付け、同じポリシーを重ねて適用する。

D. 管理対象APIには一つの自動検出関連付けを設け、その参照先フローの内側で旧経路と新経路を明示的に振り分ける。

問36.　［難易度：シナリオ応用］
Ursa Major Solar社は、既にCloudHubで稼働するMule APIへ新しいレート制限ポリシーを適用したい。要求処理ロジックは変更せず、ポリシーの調整時にもアプリケーションを作り直したくない。どの仕組みを利用すべきか。

A. レート制限を各クライアントへ実装し、API側では要求を検証しない。

B. Muleフローに固定回数のChoice Routerを追加し、変更ごとに再デプロイする。

C. ExchangeのAPI仕様に説明文を加え、実行中のトラフィック制御とみなす。

D. API自動検出で実装をAPI Managerへ関連付け、ゲートウェイポリシーを適用する。

問37.　［難易度：シナリオ応用］
Universal Containers社は、CloudHubワーカーを共有クラウド上の他組織からネットワーク分離し、オンプレミスの基幹システムへプライベート接続したい。独自のネットワーク範囲と経路制御も必要である。最初に採用を検討すべき構成はどれか。

A. 公開共有ロードバランサーだけを使い、基幹システムもインターネットへ公開する。基幹側も公開DNSとインターネット経由の受信だけを許可する。

B. Exchangeの非公開共有設定でアセットの閲覧範囲を絞り、それによってワーカーのネットワーク経路とオンプレミス接続も分離されると考える。

C. Anypoint VPCを用意し、VPNなどでオンプレミスネットワークへ接続する。

D. API Designerのモックサービスを本番プロキシとして基幹接続に利用する。設計用のサンプル応答を基幹システムの正本として返し続ける。

問38.　［難易度：基礎］
CloudHubのAnypoint VPCからオンプレミスまたは私有クラウドのネットワークへ、インターネットへ公開せず接続する方法として最も適切なものはどれか。

A. ExchangeでAPIアセットを公開し、ネットワーク経路の代わりにする。

B. Anypoint VPNなどのプライベート接続をVPCとの間に構成する。

C. API Designerのモックサービスから基幹システムへ転送する。

D. 各ワーカーのログに基幹データを複製し、接続を不要にする。

問39.　［難易度：基礎］
Anypoint VPCを使って内部APIと外部公開APIのネットワーク境界を設計する考え方として、最も適切なものはどれか。

A. Exchangeのアセット可視性だけで、実行時エンドポイントへの到達経路も制御する。

B. すべてのワーカーへ公開IPで直接到達させ、認証があれば境界は不要とする。

C. 内部ワーカーをVPC内に置き、公開が必要な経路だけを管理された入口からルーティングする。

D. 内部APIをAPI Designerのモックへ置き換え、本番ネットワークから分離する。

問40.　［難易度：シナリオ応用］
Northern Trail Outfitters社は、基盤サーバーの調達やMuleランタイムのインフラ管理を自社で行わず、Anypoint Platformからデプロイ、監視、拡張したい。アプリケーションの実装と設定には自社が責任を持つ。CloudHubを選ぶ説明として最も適切なものはどれか。

A. 顧客がCloudHubの物理ホストとOSを直接管理し、MuleSoftはAPI仕様だけを保管する。

B. CloudHubではMuleアプリケーションを変更できず、既製コネクターだけを実行する。

C. Runtime Managerはオンプレミス専用なので、CloudHubの状態やログは管理できない。

D. MuleSoftがクラウド実行基盤を運用し、顧客はアプリケーションのデプロイと設定を管理する。

7. API 実装を CloudHub に展開する

問41.　［難易度：基礎］
CloudHub上で複数ワーカーを実行するMuleアプリケーションが、どのワーカーからも同じ技術状態を参照する必要がある。適切な保存方法はどれか。

A. 各ワーカーのローカルファイルへ同じ名前で値を書き込む。

B. 各メッセージのフロー変数へ値を設定し、次の要求で再利用する。

C. Runtime Managerのアプリケーションログへ値を出力して読み戻す。

D. アプリケーションから共有可能なObject Store v2へ値を保存する。

問42.　［難易度：シナリオ応用］
Northern Trail Outfitters社は、外部サービスへ送信した要求IDを14日間だけ保持して重複送信を防ぎたい。CloudHubアプリケーションの再起動や再デプロイ後も照合でき、15日目以降のIDは不要である。どの設計が最も適切か。

A. 要求IDを各ワーカーのローカルメモリへ14日間保存し、再デプロイや障害時の再起動でメモリが失われても照合を継続できると考える。

B. 要求IDをAPI仕様の例示値へ追記し、14日後に仕様の新バージョンを公開して削除する。実行中のアプリケーションが仕様の例示値を読んで重複を判定すると考える。

C. 要求IDをObject Store v2へ保存し、14日を満たす静的TTLを設定してキーで照合する。

D. 要求IDをRuntime Managerのログへ出力し、毎要求で全ログを検索して重複判定の正本にする。

問43.　［難易度：基礎］
CloudHubアプリケーションでは、注文の正式な明細と監査履歴を長期保管する一方、再試行キーも保持する。両者の保存先を分ける設計として最も適切なものはどれか。

A. 正式な業務記録は業務データベースへ保存し、Object Storeは再試行キーなどの技術状態に限定する。

B. 注文明細をすべてObject Storeへ移し、検索や監査もキー参照だけで実施する。

C. 注文明細はワーカーのローカルファイルへ保存し、障害時にログから復元する。

D. 注文明細をExchangeのAPI仕様へ追記し、バージョンごとに履歴管理する。

問44.　［難易度：基礎］
CloudHubへMuleアプリケーションを展開するとき、ワーカーサイズを選ぶ主な判断材料として最も適切なものはどれか。

A. Exchangeに付けたAPIアセットのタグ数だけで決定する。

B. 処理負荷と必要メモリを測定し、それを満たすvCore容量を選ぶ。

C. API仕様のリソース数と同じ数のvCoreを必ず割り当てる。

D. 開発者数に合わせてワーカーのメモリ容量を増減させる。

問45.　［難易度：難問］
Northern Trail Outfitters社のステートレスな商品APIは、1ワーカーのCPU使用率がピーク時に上限へ近づく一方、個々の要求が必要とするメモリ量は増えていない。可用性も改善しながら同時要求の処理能力を増やしたい。最も適切な変更はどれか。

A. 1ワーカーのローカルキャッシュを拡大し、すべての要求を同じプロセスへ固定する。

B. 同じアプリケーションのワーカー数を増やし、受信トラフィックを分散する。

C. API仕様を複製して別名にし、クライアントへ手動で接続先を割り振る。

D. ワーカー数を1のまま維持し、Runtime Managerのログレベルだけを下げる。

問46.　［難易度：シナリオ応用］
AW Computing社のCloudHubアプリケーションは、1件の大きな変換処理でメモリ不足になることがある一方、通常時の同時要求数は少ない。まず検討すべき拡張と、水平拡張との違いを正しく示すものはどれか。

A. ワーカー数を増やせば、単一要求が使用できる各ワーカーのメモリも自動的に合算される。

B. より大きなワーカーへ垂直拡張し、ワーカー追加は主に同時処理と冗長性に使う。

C. APIインスタンスを増やせば、同じワーカーのメモリ容量も比例して増える。

D. SLA層の要求上限を上げれば、ワーカーのvCoreとメモリも自動拡張される。

問47.　［難易度：シナリオ応用］
AW Computing社の顧客APIはCloudHubの1ワーカーで稼働している。ワーカープロセスの障害中も要求処理を継続できる構成へ改めたい。アプリケーションはステートレスで、受信要求は再送可能である。最も適切な対応はどれか。

A. ワーカーを1台のまま大きくし、プロセス障害が発生しない前提にする。

B. ログ保持期間を延長し、停止中の要求をログから自動実行する。

C. 複数ワーカーへ展開し、CloudHubの負荷分散とワーカー冗長性を利用する。

D. APIアセットを複製し、同じワーカーへ異なる名前で2回デプロイする。

8. API の品質目標への対応

問48.　［難易度：基礎］
Muleアプリケーションが再起動した後も処理済みイベントIDを保持し、重複処理を防ぐための技術状態の保存先として最も適切なものはどれか。

A. キーと値で永続的な状態を保持できるObject Storeを使用する。

B. 現在のイベントだけで有効なフロー変数へIDを格納する。

C. API DesignerのモックサービスへIDを応答例として登録する。

D. Anypoint ExchangeのAPIアセットへIDをメタデータとして追加する。

問49.　［難易度：シナリオ応用］
Northern Trail Outfitters社のMuleフローは、更新頻度が低い商品参照サービスを同じ入力条件で何度も呼び出している。短時間は同じ応答を再利用してバックエンド負荷と応答時間を減らし、期限後は再取得したい。最も適切な実装はどれか。

A. すべての商品応答をExchangeのAPI仕様例へ書き込み、実行時に読み出す。

B. 参照処理をCacheスコープで囲み、キーと有効期間に基づいて結果を再利用する。

C. 商品応答をMuleイベントの変数へ格納し、別の要求からも参照する。

D. Runtime Managerのログへ応答を出力し、次回要求でログ検索する。

問50.　［難易度：難問］
Ursa Major Solar社のAPIは、参照マスタの応答を5分間再利用したい一方、外部決済へ送信済みの要求IDは再起動後も保持して重複送信を防ぐ必要がある。ワーカーは複数台で、どちらの情報もプロセスメモリだけには置けない。最も適切な組み合わせはどれか。

A. 参照応答も送信済みIDも、現在のイベントのフロー変数に保存する。イベント終了と同時に両方の値を破棄する。

B. 参照応答をAPI仕様例へ保存し、送信済みIDをRuntime Managerログへ保存する。ログの保持期間を重複排除の保証期間として扱う。

C. 参照応答をObject Storeへ無期限保存し、送信済みIDは再起動で消えるCacheスコープだけに置く。

D. 参照応答はCacheスコープで期限付き再利用し、送信済みIDはObject Storeへ永続化する。

問51.　［難易度：難問］
Ursa Major Solar社のCloudHubアプリケーションは複数ワーカーで並列実行される。外部システムのアクセストークンはどのワーカーでも参照し、有効期限までは再利用し、更新時には後続要求が新しい値を取得する必要がある。一方、要求固有の変換途中データは共有不要である。最も適切な状態配置はどれか。

A. 共有が必要なトークンをObject Storeへ置き、要求固有データはMuleイベント内に保つ。

B. トークンを各ワーカーのローカル変数へ置き、更新の同期は行わない。

C. 要求固有データもすべてAPI仕様へ書き込み、Exchangeで共有する。

D. トークンをRuntime Managerログへ出力し、各要求が全文検索して取得する。

問52.　［難易度：基礎］
頻繁に参照される商品情報をキャッシュしつつ、価格改定後に古い値が長く残らないようにする設計として最も適切なものはどれか。

A. キャッシュ項目数だけを無制限に増やし、有効期限を設定しない。

B. すべての要求でキャッシュを無効化し、毎回バックエンドを呼び出す。

C. ワーカー再起動だけを無効化契機とし、更新イベントは考慮しない。

D. 許容できる鮮度に応じたTTLを設定し、更新時には対象キーを明示的に無効化する。

問53.　［難易度：基礎］
同じURLの顧客サマリーAPIがログイン利用者ごとに異なる内容を返す。利用者間でキャッシュ応答が混在しないための設計はどれか。

A. 要求パスだけをキャッシュキーにし、すべての利用者で同じ項目を共有する。

B. 要求パスに加えて利用者または契約を識別する値をキャッシュキーへ含める。

C. 応答サイズをキャッシュキーにし、同じサイズなら同じ利用者とみなす。

D. 最初に到着した応答を固定し、認証情報に関係なく再利用する。

9. アプリケーションネットワークの監視と分析

問54.　［難易度：基礎］
Anypoint MonitoringでMuleアプリケーションの稼働状況を継続的に把握するために収集する情報として、最も適切なものはどれか。

A. Exchangeに公開されたAPI仕様のRAMLフラグメントだけを収集する。

B. Design Centerで編集中のモック応答とコメントだけを収集する。

C. CPUやメモリの使用量、応答時間、エラーなどの実行時メトリクスを収集する。

D. Access Managementに登録された利用者のロール変更履歴だけを収集する。

問55.　［難易度：基礎］
API Managerの分析機能から把握する情報として最も適切なものはどれか。

A. API Designerで仕様を編集した利用者のカーソル位置を時系列で確認する。

B. 管理対象APIへの要求数、応答時間、エラーなどのトラフィック傾向を確認する。

C. CloudHubワーカーのローカルディスクに保存された全ファイルを参照する。

D. Exchangeアセットをダウンロードした利用者の端末性能を測定する。

問56.　［難易度：基礎］
Runtime Managerを使ってデプロイ済みMuleアプリケーションを運用するとき、直接確認できる情報の組み合わせとして最も適切なものはどれか。

A. API仕様の設計レビューコメントとモックサービスの利用者一覧。

B. クライアントアプリケーションのソースコードと端末のバッテリー残量。

C. アプリケーションの実行状態、デプロイメントイベント、ログ。

D. 業務データベースの全テーブル定義と行ごとの監査履歴。

問57.　［難易度：基礎］
API機能監視を用いて確認する内容として最も適切なものはどれか。

A. スケジュールしたテストで外部からAPIを呼び出し、期待する応答と可用性を検証する。

B. Muleソースコードの全分岐を静的解析し、単体テスト網羅率を自動計算する。

C. Exchangeアセットの閲覧権限を変更し、APIへのネットワーク到達性を保証する。

D. CloudHubワーカーのvCoreを自動増減し、負荷試験を不要にする。

問58.　［難易度：基礎］
Anypoint Visualizerを利用する主な目的として、最も適切なものはどれか。

A. RAML仕様の文法エラーを修正し、Exchangeへ自動公開する。実行中コンポーネントを調べず構文情報だけで接続を推定する。

B. 実行中のMuleアプリケーションとAPIの接続・依存関係をグラフで把握する。

C. クライアントシークレットを生成し、SLAコントラクトを承認する。発行したシークレットを依存関係グラフの辺として描画する。

D. CloudHubワーカーのvCoreを負荷に応じて自動変更する。応答時間ではなく仕様の公開数を基準にvCoreを増減する。

問59.　［難易度：シナリオ応用］
AW Computing社は、Web APIの利用増加を受けてCloudHub容量を見直している。1日単位の利用者数ではなく、実行基盤が一定時間に処理するトラフィック量を把握したい。監視指標として最も適切なものはどれか。

A. APIの要求数と単位時間当たりの処理量をダッシュボードで追跡する。

B. Exchangeアセットの説明文に含まれる文字数を日次で集計する。

C. Design CenterでAPI仕様を保存した回数だけを監視する。

D. Access Managementに登録されたロールの総数を測定する。

問60.　［難易度：シナリオ応用］
Universal Containers社の注文APIは平均応答時間が300ミリ秒でSLO内だが、一部の利用者から数秒かかるとの申告がある。平均値だけでは問題が見えない。遅い要求の広がりを把握する分析として最も適切なものはどれか。

A. API仕様の行数を数え、行数の増減を応答性能の代理値にする。

B. ワーカーのデプロイ回数だけを集計し、要求レイテンシーは測定しない。

C. 応答時間の50、75、90、99パーセンタイルと遅いエンドポイントを時間帯別に比較する。

D. 成功した要求を除外し、HTTP 500の件数だけから全利用者の待ち時間を推測する。

解答一覧

ここから答え合わせです。まだ解き終えていない方は戻ってください。

問1 D / 問2 C / 問3 D / 問4 C / 問5 A / 問6 B / 問7 A / 問8 C / 問9 C / 問10 A

問11 A / 問12 A / 問13 B / 問14 B / 問15 A / 問16 D / 問17 D / 問18 D / 問19 B / 問20 C

問21 B / 問22 D / 問23 B / 問24 D / 問25 A / 問26 B / 問27 A / 問28 C / 問29 A / 問30 B

問31 C / 問32 C / 問33 C / 問34 B / 問35 D / 問36 D / 問37 C / 問38 B / 問39 C / 問40 D

問41 D / 問42 C / 問43 A / 問44 B / 問45 B / 問46 B / 問47 C / 問48 A / 問49 B / 問50 D

問51 A / 問52 D / 問53 B / 問54 C / 問55 B / 問56 C / 問57 A / 問58 B / 問59 A / 問60 C

採点と判定

結果はいかがでしたか。正解数から、いまの状況を把握しましょう。

42問以上（70%以上）

合格ラインに乗っています。ただし本番は初見の問題ばかりですし、この模試より緊張もするはずです。ここからはシナリオ問題と難問層をどれだけ潰せるかが差になります。

36〜41問

あと一歩です。取りこぼしている分野がはっきりしているはずなので、次の「セクション別の正答率シート」で弱点を特定してください。この層は演習量を積めば最も伸びます。シナリオ問題で時間を使いすぎていないかも振り返ってみてください。

35問以下

基礎領域に抜けがあります。いま受験しても厳しい結果になる可能性が高いので、分野ごとに演習量を積むことを先にしてください。

どの結果でも共通して言えること

当研究所が実際に受験してきた範囲では、シナリオ形式の問題が多く出ます。状況設定を読み解いたうえで最適な設定を選ばせてくるので、用語を覚えているだけでは手が止まりますし、思っている以上に頭と時間を使います。ここに慣れているかどうかが、同じ知識量でも結果を分けます。

本記事では60問中24問（40%）をシナリオ形式にしました。形式ごとの内訳は公式試験ガイドに公表されていないため、これは当研究所の判断による配分です。実際に受験してきた経験から、これくらいは身構えて臨んだほうがよいと考えています。

解き直すときは正解を確かめるだけでなく、問題文のどこを手がかりに絞り込んだのかを言葉にしてみてください。それが本番で効きます。

セクション別の正答率シート

問番号はセクション順に並んでいます。分野ごとに正解数を数えると、どこを重点的にやり直すべきかが分かります。

アプリケーションネットワークの基礎の説明：問1〜問4（4問）　　正解した数＿＿ / 4
組織とプラットフォームの基盤の構築：問5〜問10（6問）　　正解した数＿＿ / 6
API の設計と共有：問11〜問16（6問）　　正解した数＿＿ / 6
システム層、プロセス層、エクスペリエンス層を用いた API 設計：問17〜問23（7問）　　正解した数＿＿ / 7
Anypoint Platform における Web API の管理：問24〜問33（10問）　　正解した数＿＿ / 10
API 実装のアーキテクトとデプロイメント：問34〜問40（7問）　　正解した数＿＿ / 7
API 実装を CloudHub に展開する：問41〜問47（7問）　　正解した数＿＿ / 7
API の品質目標への対応：問48〜問53（6問）　　正解した数＿＿ / 6
アプリケーションネットワークの監視と分析：問54〜問60（7問）　　正解した数＿＿ / 7

落とした分野をどう埋めるか

セクション別の正答率が出たら、次にやることは決まっています。落とした分野の演習量を積むことです。

まずはこのあとの全問解説で、60問ぶんの取りこぼしを潰してください。そのうえで演習量が足りないと感じたら、同じ密度の解説が付いた全500問の問題集があります。本記事の60問もこの中に含まれています。

全問解説（全60問）

正解の理由だけでなく、誤りの選択肢がなぜ誤りなのかまで書いています。間違えた問題はもちろん、迷って正解した問題も読んでおくと取りこぼしが減ります。

1. アプリケーションネットワークの基礎の説明

問1.　正解：D

Dなら安定したAPI契約を介して機能を再利用でき、接続先の変更を利用側から分離しやすい。Aはポイントツーポイント接続をさらに増やす。Bは一枚岩の構成となり独立した再利用や変更を妨げる。Cはデータ複製と同期運用を増やすだけで、機能間の密結合という根本原因を解消しない。

問2.　正解：C

Cは、即時の要求と応答が必要な照会をWeb APIで提供し、複数の受信側へ疎結合に通知する更新をイベントで扱う設計である。Aは照会の即時性を満たさない。Bは購読者が増えるほど送信側の接続が増える。Dは同期的に結果を必要とする注文照会の利用特性に合わない。

問3.　正解：D

Dは既存のサービス指向の考え方を生かしつつ、管理されたAPI、Exchangeでの発見、層別責務によって組織的な再利用へ発展させる。Aは密結合な直接接続へ逆戻りする。Bは両者を排他的に捉える誤りである。CはURL共有だけで契約、管理、再利用の仕組みを整えず、同じ課題を残す。

問4.　正解：C

Cが適切である。API仕様は利用者と提供者の合意を表し、互換性を保つ限りバックエンドや実装技術の変更を隠蔽できる。Aはデータベースを直接公開する考え方である。Bは不要な破壊的変更を正当化している。Dは設計契約と実行時のセキュリティ、可用性を混同しており、コントラクトだけでは運用品質を保証しない。

2. 組織とプラットフォームの基盤の構築

問5.　正解：A

AがC4Eの目的に合う。C4Eはベストプラクティス、標準、再利用可能なアセットを広め、中央の専門性と各実行チームの自律性を両立させる。Bは中央集権的なボトルネックを作る。Cはランタイム運用の一業務に限定される。Dは再利用と組織横断の学習を妨げ、イネーブルメントと逆方向である。

問6.　正解：B

BはC4Eが中央の専門性、標準、再利用資産、コーチングを提供し、分散したチームの自律的なデリバリーを促すモデルである。Aは中央をボトルネックにするCoE型の集中運営に偏る。Cは組織標準と再利用を崩す。DはC4Eを限定的な運用担当へ縮小し、イネーブルメントの目的を満たさない。

問7.　正解：A

Aは、C4Eの狙いである資産の利用・再利用、組織への普及、ビジネス成果の加速を一緒に評価できる。Bは活動量であり成果や採用を示さない。Cはトラフィック増加を再利用や提供速度と区別できない。Dは中央チームへの生産集中を促し、セルフサービス型の運用モデルと逆行する。

問8.　正解：C

Cが正しい。Catalystは導入を組み立てるための方法論であり、ハイレベルな構造とその利点を説明できることが学習目的になる。Aは実行基盤の話で、Catalystは特定のデプロイ先に縛られない。BはAPI Managerのポリシー名との取り違えであり、方法論とポリシーでは扱う階層が違う。Dは期間や定量成果を自動保証する仕組みだと読み替えている点が誤りで、成果は組織ごとの目標設定と実行によって決まる。

問9.　正解：C

Cが正しい。Catalystは単一の製品機能ではなく、導入全体を整理する枠組みとして位置づけられる。Aは実行基盤の名称と取り違えており、方法論はランタイムの選択に依存しない。Bは書式や成果物の雛形へ範囲を狭めており、ビジネス成果と組織能力までを扱う枠組みの位置づけと合わない。Dは反復回数や成果額を一律に定める規定だと誤解しており、組織横断の推進責務を一部門の作業へ縮めている点も実態と異なる。

問10.　正解：A

Aはホスト環境を用意せず利用できるiPaaSで、少人数・迅速導入という条件に合う。Bは顧客がKubernetes基盤を管理するため要件と逆である。Cはサーバー、可用性、ログ等の自社運用が増える。Dは管理面まで私有環境で運用する大きな責任を伴い、規制要件のない本件では過剰である。

3. API の設計と共有

問11.　正解：A

Aなら設計契約から実行単位、利用者までの依存をたどれ、互換性変更の影響を判断できる。Bは運用補助情報に偏りAPI契約の関係を示さない。CはAPI層を迂回して密結合を生む。Dは実装内部だけを見ており、環境別ポリシーやクライアント契約への影響を追跡できない。

問12.　正解：A

Aなら仕様、実装、インスタンス、クライアントの依存をたどり、互換性を壊す変更を版管理と移行で制御できる。Bは説明文の更新だけで契約変更を扱えない。Cは利用者を予告なく破損させる。Dはインスタンス名の維持とAPI契約の互換性を混同しており、必須項目削除の影響は消えない。

問13.　正解：B

Bはクライアントが依存する契約を安定させ、実装や基盤の変更をAPI境界内へ隔離する。Aは物理モデルへの依存を増やす。Cはポイントツーポイント接続を再導入し、資格情報も拡散する。Dはコード共有で契約を代替できず、変更影響を全利用者へ波及させる。

問14.　正解：B

Bなら共通の型や特性をフラグメントとして版管理し、複数仕様から明示的に参照できる。Aはコピー間の差異を残す。Cの環境プロパティは実行時設定であり、契約部品の共有先ではない。Dは実装を結合するだけで仕様再利用の問題を解決せず、独立変更も難しくする。

問15.　正解：A

AはExchangeをアセットのカタログとして使い、仕様、フラグメント、テンプレート等を検索・共有・版管理できる。Bはコピーが分岐して正本を失う。Cのランタイムログは設計資産の保管場所ではない。Dは利用者を実装へ結合し、契約理解と安全な再利用を難しくする。

問16.　正解：D

Dはコンシューマーが契約と使用方法を一か所で発見し、コンソールやモッキングで確認できる。Aは実行時の内部ログしか示さず、安定した契約や使用例を理解できない。Bはデータベース資格情報を漏らしてAPI境界と安全性を失う。Cは利用者をJARの実装詳細へ依存させ、変更追随と導入に余計な解析を求める。

4. システム層、プロセス層、エクスペリエンス層を用いた API 設計

問17.　正解：D

Dは業務能力を起点に境界を定め、システム接続、プロセスのオーケストレーション、チャネル体験を適切な層へ配分できる。Aは既存の密結合をAPI化するだけである。Bは責務を一箇所へ集中させ再利用を妨げる。Cはデータ構造を境界にしすぎ、チャネルごとに共通業務ロジックが重複する。

問18.　正解：D

Dは、業務規則とチャネル固有表現を区別し、それぞれの所有責務と変更理由に合う境界へ配置する。単一案件でも複数処理の順序や検証を担う業務規則ならAPI側で管理すべきであり、利用回数だけでは決まらない。AとCはこの責務を無視し、Bは画面都合を基盤接続へ混入させる。

問19.　正解：B

Bが正しい。システムAPIは基幹システムへの接続と固有データモデルをカプセル化し、上位層へ再利用可能な契約を提供する。Aは利用チャネルへの最適化を担う。Cは複数の能力を業務プロセスへ構成する。Dはアクセス管理の契約であり、バックエンド接続を実装するAPI層ではない。

問20.　正解：C

Cなら複数システムの能力を業務プロセスとして構成し、チャネル間で再利用できる。Aはオーケストレーションをチャネルごとに重複させる。Bは顧客システム固有の境界へ他システムの責務を混在させる。DのSLA層はAPI消費量と契約の管理で、業務処理の呼び出し順序を実行しない。

問21.　正解：B

BならプロセスAPIの再利用可能な業務モデルを保ったまま、端末固有の表現をエクスペリエンス層で吸収できる。AはシステムAPIをチャネル事情に結合する。Cは共通プロセス契約へ表示責務を混在させる。DはバックエンドにUI都合を持ち込み、変更の影響範囲を広げる。

問22.　正解：D

Dは接続、業務編成、チャネル表現を一体化した結果、異なる変更頻度と所有者が結合する問題を示す。Aは実際には独立変更を難しくする。Bはモバイル固有表現が他チャネルの再利用を妨げる。Cは接続詳細を同じ契約に露出するため、置換時の影響をむしろ広げる。

問23.　正解：B

Bは基幹接続、業務プロセス、チャネル表現の責務を、それぞれ知識と変更権限を持つチームへ割り当てる。Aはモバイル部門へ無関係な基盤責任を集中する。Cは業務所有者へインフラ運用を誤配分する。Dは変更判断と運用責任が曖昧になり、APIを製品として継続管理できない。

5. Anypoint Platform における Web API の管理

問24.　正解：D

Dが正しい。ExchangeのAPIアセットは仕様やバージョンを共有する設計資産で、API ManagerのAPIインスタンスは特定環境のエンドポイント、ポリシー、契約を管理する単位である。Aは実装と仕様の役割を逆転している。Bは同じアセットから環境別の複数インスタンスを作れるため誤りである。Cは仕様フラグメントと管理対象の実行単位を混同している。

問25.　正解：A

Aなら仕様アセットの再利用と、環境ごとの実行管理を両立でき、ポリシーや契約を独立して変更できる。Bは非本番利用者と本番制御を混在させる。Cは同じAPIの系譜を分断し、仕様変更の追跡を難しくする。Dのログ設定はアクセス制御、SLA、契約の代替にならない。

問26.　正解：B

Bなら共通契約を同じAPIアセットで保ちながら、異なるエンドポイント、ポリシー、契約をインスタンス単位で管理できる。Aは地域固有の制御境界を分けられない。Cは不要な仕様分岐を生み利用側の再利用性を下げる。Dはクライアント数に応じて実装が増え、中央管理も失われる。

問27.　正解：A

Aなら環境が明確な制御境界となり、同じ仕様を再利用しつつ契約とポリシーを分離できる。Bは資格情報と承認フローを混在させる。Cは文書化だけで実行時制御を分けられない。Dは管理ポリシーを実装へ結合し、環境変更のたびにコードと再デプロイが必要になる。

問28.　正解：C

CはクライアントIDとシークレットを検証し、API Managerで承認されたクライアント契約とSLA層に結び付ける要件に合う。Aのキャッシュは認証手段ではない。Bは全利用者を同一主体に見せ、識別不能にする。Dは記録後の分析であり、未許可の要求を入口で拒否できない。

問29.　正解：A

Aが正しい。レート制限は指定期間内の要求数へ上限を課し、スパイク制御は短時間に集中した流量を平滑化するため、契約上の1分当たり上限と数秒間の急増を別々に制御できる。Bのメッセージログは記録機能で、要求を拒否も遅延もしない。CのExchangeの可視性は設計資産の公開範囲であり、実行時ポリシーの代わりにならない。DのMUnitはテスト実行の仕組みで、本番の要求上限を強制しない。

問30.　正解：B

Bが正しい。SLA層は要求数や承認方法などのアクセス条件を表し、クライアントのアクセス要求が承認されると対象層に基づくコントラクトが成立する。Aは実行資源との混同である。CはAPI設計資産の説明になっている。Dは監視設定であり、API消費者の利用権を定める関係ではない。

問31.　正解：C

Cが正しい。HTTPキャッシュポリシーでキャッシュ対象と有効期間を設定すれば、許容鮮度の範囲で応答を再利用し、バックエンド呼び出しを減らせる。Aのスパイク制御は短時間に集中した流量を平滑化する仕組みで、応答を保存して再利用する働きはない。Bのアセットのバージョン公開は設計資産の管理であり、実行時のバックエンド呼び出し回数には作用しない。DのMUnitのモックはテスト実行時に依存先を置き換える仕組みで、本番の応答として返すものではない。

問32.　正解：C

Cならポリシーが検証する資格情報の名前と受け渡し場所をAPI契約に明示でき、利用者とテストツールが正しい要求を作れる。AのデプロイメントIDはクライアント資格情報ではない。Bは管理利用者の識別子を公開する誤った設計である。Dのアセット作成者情報も認証資格にはならず、契約と無関係である。

問33.　正解：C

Cは、保護対象メソッドと要求スコープを契約・適用設定で一致させ、最小権限を維持する。Aは読取専用クライアントへ不要な書込権限を与える。Bは認可ルールをクライアント任せにして保護を失う。DはHTTPメソッドとクライアント識別・OAuth認可を混同している。

6. API 実装のアーキテクトとデプロイメント

問34.　正解：B

BによりAPI自動検出がAPI ManagerのインスタンスとMule実装をAPI IDで結び、ゲートウェイポリシーや分析を有効にする。Aの名称一致には関連付けの意味がない。Cは表示名を保存しても管理対象にならない。DのデプロイメントIDはクライアント契約やAPI管理の識別子ではなく、公開すべき接続情報でもない。

問35.　正解：D

Dは、一つのAPIを同時に一つの自動検出インスタンスへ関連付ける制約を守りながら、移行用のルーティングを管理対象フロー内へ閉じ込める。Aは同一APIの関連付けを重複させる。Bでは対象APIを特定できない。Cは一つのAPI実装を複数の管理対象へ曖昧に結び付け、どのポリシーと分析へ属するかを不明確にする。

問36.　正解：D

Dなら管理層でポリシーを設定し、Mule実装の業務ロジックを変更せずにゲートウェイで制御できる。Aは各利用者に強制できず中央統制にならない。Bは制限値変更のたびにコード更新が必要である。Cは仕様の文書化にすぎず、実行時の要求を拒否または調整しない。

問37.　正解：C

CならCloudHubワーカーを論理的に分離したネットワークへ配置し、VPNなどを通じてオンプレミスへ非公開接続できる。Aは基幹側を公開するため要件に反する。BのExchange可視性はアセット共有の制御でネットワーク分離ではない。Dのモックは設計検証用で、本番の専用ネットワーク接続を提供しない。

問38.　正解：B

Bが適切である。Anypoint VPCはVPNなどを通じてオンプレミスネットワークと私有経路を確立できる。AのExchange公開範囲は設計アセットの可視性であり通信経路ではない。Cのモックは設計検証用でネットワーク中継を担わない。Dはログをデータ連携手段に誤用し、機密性と整合性の要件も満たさない。

問39.　正解：C

Cなら内部の実行先をVPCの境界内に保ち、必要なHTTP経路だけを専用ロードバランサーなど管理された入口から公開できる。Aは設計アセットの権限とネットワーク到達性の混同である。Bは攻撃面を広げる。Dのモックは設計検証用であり、本番APIのネットワーク分離手段ではない。

問40.　正解：D

DがCloudHubの責任分担に合う。CloudHubはMuleアプリケーションをホストする管理済みiPaaSで、顧客はRuntime Managerから展開、設定、監視を行う。Aは顧客管理のホスト方式との混同である。Bは任意のMule実装を展開できるため誤りである。CはRuntime ManagerがCloudHub管理面でもあることに反する。

7. API 実装を CloudHub に展開する

問41.　正解：D

DはCloudHubアプリケーションのワーカー間で参照する技術状態を外部化できる。Aのローカルファイルはワーカーごとに分離され、置換にも弱い。Bのフロー変数は1イベント内だけで有効である。Cのログは診断記録であり、整合性を保つ状態ストアとして読み書きする用途には設計されていない。

問42.　正解：C

Cが適切である。Object Store v2の静的TTLは保持期間を明示でき、CloudHubワーカーのプロセス外でキーを照合できるため、再起動や再デプロイ後も14日間の重複判定を継続できる。Aはプロセス終了で状態を失い、BはAPI契約を実行時データへ誤用し、Dのログ検索は原子的な重複排除を提供しない。静的TTLの上限は30日なので、30日超の保持や監査用途なら外部データベースを選ぶ必要がある。

問43.　正解：A

Aが適切である。Object Storeはアプリケーションのキー値状態に向くが、複雑な照会、関係整合性、業務監査を担う正式な記録系の代替ではない。Bはデータモデルと検索要件を無視する。Cはワーカー置換や障害に耐えない。DのExchangeは設計アセットの共有場所であり、取引データを継続更新する保管庫ではない。

問44.　正解：B

Bが適切である。ワーカーサイズはアプリケーションのCPU負荷、メモリ消費、処理特性を負荷試験で確かめ、必要なvCore容量を選ぶ。Aのタグ数はカタログ分類で実行資源と無関係である。Cにそのような対応関係はない。Dの開発者数も本番ワークロードの資源需要を示さない。

問45.　正解：B

Bは水平拡張によって同時処理容量を増やし、複数ワーカー構成により1ワーカー障害への耐性も高める。Aは単一プロセスへの依存を強める。Cは同じ契約を不必要に分岐させ運用負担を増やす。Dは診断出力量を変えるだけで、CPU需要や単一ワーカー障害を解消しない。

問46.　正解：B

Bが適切である。単一処理が必要とするメモリを増やすにはワーカーサイズの拡大を検討し、ワーカー数の追加は負荷分散や冗長化に寄与する。Aでは1要求のヒープがワーカー間で結合されない。CのAPI管理単位は計算資源を増やさない。DのSLA層はクライアント消費量の制御で、実行容量の設定ではない。

問47.　正解：C

Cなら受信トラフィックを複数ワーカーへ分散し、1つのワーカープロセスが停止しても他が処理を継続できる。Aは処理容量を増やしても単一障害点を残す。Bのログは要求キューではない。Dは同じ実行基盤への重複配置で管理を複雑化し、意図したワーカー冗長性を構成しない。

8. API の品質目標への対応

問48.　正解：A

Aが適切である。Object Storeはキーと値の形式で状態を保存でき、再起動をまたぐ重複検出などの技術状態に利用できる。Bの変数はイベント処理中の値で永続化されない。Cのモックサービスは仕様検証用で状態保存基盤ではない。DのExchangeは再利用アセットを共有するカタログで、実行時IDの格納先ではない。

問49.　正解：B

Bなら同じキーの処理結果を有効期間内に再利用し、期限切れ後に元の処理を実行できる。Aは設計文書を動的キャッシュに転用している。Cの変数は1つのMuleイベント内だけで有効である。Dのログは診断用で、低遅延かつ整合した応答キャッシュとして利用する仕組みではない。

問50.　正解：D

Dは性能向上のための期限付き応答再利用と、正確性のための永続状態を別々の仕組みに割り当てる。Aはイベント終了や再起動を越えられない。Bは設計例とログを状態ストアに誤用している。Cは役割が逆で、応答の失効管理が曖昧になり、重複防止IDがキャッシュ期限で消える危険がある。

問51.　正解：A

Aはワーカー間で一貫させる技術状態だけを外部ストアへ置き、一時的な要求データはイベント内に限定する。Bはワーカーごとに古い値が残り得る。Cは設計アセットを実行時データへ誤用し、機密情報も露出させる。Dはログへ資格情報を残すセキュリティ問題があり、整合した読み書きも保証しない。

問52.　正解：D

Dなら通常時はTTLまで再利用し、価格変更時は対象エントリを直ちに再計算できる。Aは容量を増やすだけなので古い値が残り続け、鮮度要件を満たさない。Bは毎回バックエンドへ到達してキャッシュの負荷軽減効果を失う。Cは業務上の更新と再起動に関係がないため、必要な時点で鮮度を回復できない。

問53.　正解：B

Bならパスが同じでも利用者や契約ごとに別エントリとなり、個別データの漏えいを防げる。Aは要求パスが共通の利用者を区別できない。Cの応答サイズは利用者を一意に示さず、偶然同じサイズの別データを分離できない。Dは最初の個別応答を認証情報に関係なく共有するため、別利用者へ内容を返す危険がある。

9. アプリケーションネットワークの監視と分析

問54.　正解：C

Cが適切である。Anypoint Monitoringはアプリケーションやインフラストラクチャの実行時メトリクスをダッシュボードで可視化し、性能や異常の把握に使う。AはExchangeの設計アセット、BはDesign Centerの設計作業、Dはアクセス管理の監査領域であり、アプリケーション稼働のメトリクスではない。

問55.　正解：B

Bが適切である。API Managerは管理対象APIのトラフィックを分析し、要求数や応答時間、エラーなどを運用判断に利用できる。Aは共同編集の追跡を表すものではない。Cはランタイム内部ファイルの閲覧機能ではなく、Dの利用者端末性能もAPI分析の収集対象ではない。

問56.　正解：C

Cが適切である。Runtime Managerはデプロイしたアプリケーションの開始、停止、更新などを管理し、状態、イベント、ログを運用診断に利用できる。AはDesign Centerなど設計時の領域である。Bはクライアント端末管理ではない。Dは接続先データベースの管理製品ではなく、全業務データを自動収集しない。

問57.　正解：A

Aが適切である。API機能監視は定期的な機能テストを実行し、利用者に近い外形からエンドポイントの可用性や期待応答を確かめる。Bはコード品質の静的解析で別領域である。Cは設計アセットの共有権限で実行エンドポイントを監視しない。Dはデプロイ資源の拡張であり、機能の成否を検証するテストではない。

問58.　正解：B

Bが適切である。Anypoint Visualizerはアプリケーションネットワークのコンポーネントと接続関係を可視化し、影響範囲や構造の理解に使う。AはAPI DesignerとExchangeの役割である。CはAPI Managerのクライアント管理である。Dはデプロイ容量の操作であり、Visualizerの依存関係表示とは異なる。

問59.　正解：A

Aは要求数とスループットを通じて実際のAPIトラフィックを捉え、容量計画やピーク分析に使える。Bはカタログ文書の量で負荷を示さない。Cは設計活動で実行時の利用量ではない。Dは管理権限の構成数であり、ワーカーが処理する要求レートとの相関を保証しない。

問60.　正解：C

Cは分布の上位側とエンドポイント別の遅延を示し、良好な平均に隠れたテールレイテンシーを特定できる。Aの仕様行数は実行性能を表さない。Bはデプロイ活動と要求時間を混同する。Dは成功していても遅い要求を捨てるため、申告された症状を観測できない。

この先の演習量を確保するために

ここまでの60問と同じ密度の解説が、全500問すべてに付いた問題集を販売しています。本記事の60問も、この500問の中に含まれています（残りの440問は本記事には入っていません）。

この資格の全500問・全問解説付き問題集（note）

免責事項

非公式のオリジナル教材です：本記事の模擬問題・解説はすべて当研究所が独自に作成したものであり、実際の試験問題の複製・転載・流用ではありません。Salesforce, Inc.が提供・監修・承認したものではなく、同社と提携・協賛等の関係もありません。Salesforce、Trailhead等の名称・ロゴはSalesforce, Inc.の商標または登録商標です。
公式情報との相違の可能性：実際の試験の出題内容・出題形式・出題比率・難易度・合格ライン・受験料等は、Salesforce社の判断により予告なく変更されることがあります。当研究所は適宜、内容の点検を行っていますが、本記事が常に最新の公式試験ガイドと完全に一致することを保証するものではありません。受験前に必ず公式試験ガイド（Trailhead／Salesforce公式サイト）で最新情報をご確認ください。
対応バージョンについて：本記事の問題は作成時点の公式情報を参照しており、公式試験ガイド（日本語版）に明記された対応バージョンと差異がある場合があります。
合格・成果の保証はありません：本記事は学習の補助を目的としたものであり、内容を利用したことによる資格試験の合格・特定のスコア取得その他の成果を保証するものではありません。
正確性についての留意：内容の正確性については作成時点および見直し時点で可能な限りの確認を行っていますが、誤字脱字・解説内容の誤り等が皆無であることを保証するものではありません。お気づきの点はコメント欄にてお知らせください。確認のうえ無料で修正します。
損害についての免責：本記事の内容を利用したことにより生じたいかなる損害（学習時間の損失、受験結果に関するものを含みますがこれに限りません）についても、当研究所は責任を負いかねます。あらかじめご了承のうえご利用ください。
著作権・利用範囲：本記事の全文の著作権は当研究所に帰属します。読者ご本人が学習目的でご利用いただく範囲を超えて、内容の複製・転載・再配布・第三者への共有・譲渡・転売等を行うことは禁止します。