Salesforce認定Platformアプリケーションビルダー100題 過去問+模擬問題集 全問解答解説付き(即わかる)
Salesforce認定Platformアプリケーションビルダーの過去問+模擬問題100題を全問解答＋全問解説しています。
この問題集では、正解、不正解の選択肢全てに解説を付けています。
初学者でもわかりやすく学習可能です。
Salesforce認定Platformアプリケーションビルダーとは
Salesforceプラットフォーム上でカスタムアプリケーションを構築、設計、実装する能力を持つことを証明する資格です。アプリケーションビルダーがSalesforceのデクラレーティブ（コーディング不要）の機能を利用してビジネス要件を満たすカスタムアプリケーションを効率的に構築できることを証明します。
試験範囲は？
以下出題の範囲が公開されています
試験範囲は以下のような主要なトピックをカバーしています：
セキュリティとアクセス (20%)
データモデリングと管理 (20%)
ビジネスロジックとプロセス自動化 (27%)
ユーザーインターフェース (14%)
アプリケーションの展開と管理 (14%)
レポートとダッシュボード (5%)
ここから問題と解答/解説になります。
過去問と模擬問題がセットになっており、模擬試験としても活用できます。
初めの10題のみ無料、合計100題、全問解答＋全問解説付きになります。
1.ある企業がSalesforce Platformを活用してカスタムアプリケーションを構築することを計画しており、Salesforce認定Platformアプリケーションビルダーのあなたにアドバイスを求めています。次の選択肢のうち、アプリケーション開発プロセスの初期段階で最も重要なステップはどれですか？
A. ビジネスプロセスと要件に基づいたカスタムオブジェクトとフィールドの設計。
B. Salesforceの標準オブジェクトとフィールドの利用可能性の評価。
C. LightningコンポーネントとVisualforceページの開発。
D. システム統合とAPIアクセスの構成。
正解：A
解説： A. カスタムオブジェクトとフィールドの設計 - 正解です。アプリケーション開発の初期段階では、ビジネスプロセスと要件を理解し、それに基づいて必要なカスタムオブジェクトとフィールドを設計することが最も重要です。これにより、アプリケーションがビジネスのニーズに適切に対応できるようになります。
B. 標準オブジェクトとフィールドの利用可能性の評価 - この選択肢も重要ですが、カスタムアプリケーションを構築する際には、カスタムオブジェクトとフィールドの設計が先行する必要があります。標準オブジェクトとフィールドは既存の機能との整合性を評価する際に重要です。
C. LightningコンポーネントとVisualforceページの開発 - この選択肢は開発プロセスの後半になります。最初にデータモデルとビジネスロジックを確立した後、ユーザーインターフェースの開発に進むことが一般的です。
D. システム統合とAPIアクセスの構成 - この選択肢は、ビジネス要件に基づいて他のシステムやサービスとの統合が必要な場合に重要ですが、初期段階ではデータモデルとビジネスロジックの設計に焦点を当てるべきです。
2.Salesforce認定Platformアプリケーションビルダーとして、ある企業がSalesforceで人事管理アプリケーションを開発する計画をしています。以下のオプションの中で、プロジェクトの初期段階で最も重要なステップはどれですか？
A. 人事プロセスに合わせてカスタムワークフローと承認プロセスを設計する。
B. ユーザーとの相互作用を向上させるためにユーザーインターフェイスをカスタマイズする。
C. 必要なカスタムオブジェクト、フィールド、およびリレーションシップを定義する。
D. 給与計算や従業員ベネフィット管理のための外部システムとの統合を計画する。
正解：C
解説： A. カスタムワークフローと承認プロセスの設計 - このステップは重要ですが、データモデルが確立される前に行うには早すぎます。初期段階では、まず基本となるデータ構造を確立することが重要です。
B. ユーザーインターフェイスのカスタマイズ - ユーザーインターフェイスのカスタマイズは、データモデルとビジネスプロセスの設計が完了した後の段階でより効果的です。初期段階では、まずデータ構造とビジネス要件に焦点を当てるべきです。
C. カスタムオブジェクト、フィールド、リレーションシップの定義 - 正解です。人事管理アプリケーション開発の初期段階で最も重要なのは、アプリケーションがカバーするビジネスプロセスを反映するデータモデルを確立することです。これには、必要なカスタムオブジェクト、フィールド、リレーションシップの定義が含まれます。
D. 外部システムとの統合の計画 - このステップもプロジェクトの後半で重要ですが、初期段階ではまずデータモデルの設計とビジネス要件の分析に集中することが重要です。統合の計画は、内部プロセスが確立された後に行うべきです。
3.ある企業がSalesforceを使用して顧客情報を管理しています。現在、営業チームが顧客の連絡先情報を更新する際に、その顧客が特定のキャンペーンに参加しているかどうかを手動でチェックしています。このプロセスを自動化し、連絡先が更新されるたびに特定のキャンペーンへの参加状況を自動的に確認し、関連するフィールドを更新するにはどうすればよいでしょうか？
A. ワークフロールールを使用して連絡先が更新された際にキャンペーン参加状況を確認し、フィールド更新を行う。
B. カスタムApexトリガを作成して、連絡先が更新されるたびにキャンペーン参加状況を確認し、必要に応じてフィールドを更新する。
C. プロセスビルダーを使用して、連絡先が更新されるたびに特定の条件を満たす場合にフィールド更新を行うプロセスを設計する。
D. レポートとダッシュボードを使用して、定期的にキャンペーン参加状況を確認し、必要に応じて連絡先のフィールドを手動で更新する。
解答: C
解説: A: ワークフロールールは比較的シンプルな自動化に適していますが、キャンペーン参加状況の確認など複雑なロジックを扱う場合、プロセスビルダーの方が柔軟性があります。
B: カスタムApexトリガは非常に柔軟ですが、開発とメンテナンスに専門知識が必要であり、よりシンプルな方法で要件を満たすことが可能です。
C: プロセスビルダーは、複数の条件とアクションを扱い、より複雑なビジネスプロセスを自動化するのに適しています。このシナリオでは、連絡先が更新されるたびに特定の条件を満たす場合に自動的にフィールドを更新するため、最適な選択です。
D: レポートとダッシュボードはデータの可視化と分析に役立ちますが、実際のデータ操作やプロセスの自動化には向いていません。このオプションでは手動での作業が必要となり、効率的ではありません。
4.Cloud Kicks (CK) は、アカウント レコード ページで顧客のサポート レベルを追跡します。CK は、関連するアカウントがプラチナ レベルの顧客である場合に、ケース レコード ページにテキスト通知を表示したいと考えています。
アプリビルダーはどのようにしてこの要件を満たすことができるでしょうか?
A.テキストのみの Visualforce ページを作成する > Visualforce コンポーネントをケース ページ レイアウトにドラッグする > アカウント サポート レベルがプラチナの場合に表示されるように設定します。
B.Case Lighting ページにリッチ テキスト エリアを追加 > アカウント サポート レベルがプラチナの場合に表示されるように、リッチ テキスト エリアのコンポーネントの可視性を設定します。
C.ケース Lightning ページをコピー > 新しいページにリッチテキストエリアを追加し、このページをプラチナアカウントに割り当てます。
D.テキストのみの Visualforce ページを作成する > ケース ページ レイアウトをコピーする > Visualforce コンポーネントをページにドラッグし、レイアウトをプラチナ ケースに割り当てます。
正解：B
解説：
A. Visualforce ページはカスタムコードを要し、単純なテキスト通知には過剰な機能を持っています。また、ケースページレイアウトにドラッグする方法では、顧客のサポートレベルに基づく動的な表示は直接実現できません。
B. リッチテキストエリアは、テキスト通知の表示に適しています。Lightningページのコンポーネントの可視性を利用することで、アカウントのサポートレベルがプラチナの場合のみ通知を表示させることができます。これは要件を満たし、最も効率的で簡単な方法です。
C. Lightningページをコピーして特定のアカウントに割り当てることは可能ですが、これはメンテナンスが大変で非効率的です。すべてのプラチナアカウントに対して新しいページを割り当てる必要があり、スケーラビリティに問題が生じます。
D. この方法でもAのオプションと同様にVisualforceページを利用していますが、さらにケースページレイアウトのコピーという追加のステップがあります。この方法も複雑で、シンプルなテキスト通知を表示するには過剰な機能を要しています。
5.アプリビルダーは Testimonial__c というカスタム オブジェクトを作成しており、Testimonial__c レコードを送信者の Contact レコードと Account レコードの両方に接続したいと考えています。アカウントが削除された場合、Testimonial__c も削除する必要があります。連絡先が削除されてもアカウントが残っている場合、Testimonial__c はそのままにしておく必要があります。
これはどのように達成されるべきですか？
A.Testimonial__c から Account への主従関係と、Testimonial__c から Contact への参照関係を作成します。
B.主従関係を使用して、Testimonial__c を Account と Contact の間の連結オブジェクトにします。
C.Testimonial__c から Account への参照関係と、Testimonial__c から Contact への主従関係を作成します。
D.Testimonial__c オブジェクトで Contact フィールドと Account フィールドの両方を必須にし、Testimonial__c から Contact および Account への参照関係を作成します。
正解：A
解説：
A. Testimonial__c から Account への主従関係を作成すると、Testimonial__c レコードは親である Account レコードに依存し、Account が削除されると Testimonial__c も削除されます。一方、Testimonial__c から Contact への参照関係を作成すると、Contact が削除されても Testimonial__c レコードは残ります。これは要件を満たしています。
B. 主従関係を使用してTestimonial__cを連結オブジェクトとして設定すると、Account と Contact の両方が削除された場合にのみ Testimonial__c が削除されます。これは要件と一致しないため、不適切です。
C. Testimonial__c から Account への参照関係と Testimonial__c から Contact への主従関係を作成すると、Contact が削除された場合に Testimonial__c も削除されますが、これは要件に反しています。
D. 参照関係を使用しても、Account が削除されたときに Testimonial__c を自動的に削除することはできません。また、Contact と Account 両方を必須フィールドとして設定することは、削除の挙動には影響しません。このため、Dの選択肢も要件を満たしていません。
6.UVCのマーケティングチームには、Salesforceにアップロードしたい400人のリードのリストがあります。チームは重複したレコードを作成しないようにする必要があります。この要件を満たすには、どの2つのアクションを実行する必要がありますか？ 2つ答えを選択してください
A.インポートウィザードを使用してリードリストをアップロードし、重複するリードが作成されないようにマッチングタイプを選択します。
B.データローダーの更新機能を使用して、リードをインポートし、電子メールアドレスに基づいて既存のレコードと照合します。
C.セットアップのデータ管理セクションで重複マッチングを有効にし、Lead-to_Leadシナリオをアクティブ化します。
D.リードマッチングルールと対応する重複ルールを利用して、新しく作成された重複リードをブロックします。
正解：A,D
解説：
A. インポートウィザードは、Salesforceにデータをアップロードする際に重複をチェックする機能を提供します。適切なマッチングタイプを選択することで、既存のリードと重複しないように新しいリードをアップロードできます。これは、重複を防ぐための有効な手段です。
B. データローダーの更新機能は、既存のレコードを更新するために使用されますが、新しいリードのアップロードと既存のレコードとの重複チェックには直接対応していません。新しいレコードの挿入時に重複を管理する機能は提供していないため、この要件には適していません。
C. セットアップのデータ管理セクションで重複マッチングを有効にすることは、重複を防止するための良い手段ですが、この選択肢自体では具体的なシナリオのアクティブ化や、インポートプロセスでどのように機能するかが明確にされていません。このため、この選択肢だけでは要件を満たすための完全な解決策とは言えません。
D. リードマッチングルールと対応する重複ルールを利用すると、新しく作成されるリードが既存のリードと重複している場合にそれをブロックまたは警告することができます。これは重複データの管理に非常に効果的な方法であり、重複を防ぐ上で重要な役割を果たします。
7.ユニバーサルコンテナは、営業担当者が商談を削除する前にマネージャーから許可を得ることを望んでいます。これらの要件を満たすために何が使用できますか?
A.フロー プロセスがトリガーされた承認プロセス。
B.時間依存のワークフロー アクションによる承認プロセス。
C.承認申請アクションを含むプロセスビルダー。
D.2 段階の承認プロセス。
正解：D
解説：
A. フロー プロセスでトリガーされる承認プロセスは、特定の条件下でプロセスを自動化するために使用されますが、営業担当者が商談を削除する前にマネージャーの承認を求めるという具体的な要件を満たすためには、より直接的な管理手段が必要です。フロー自体では商談削除の承認プロセスを直接管理することはできません。
B. 時間依存のワークフロー アクションは、指定された時間が経過した後にアクションを実行するために使用されます。このオプションは、特定のイベントの発生時に即時の承認が必要な場合には適していません。
C. プロセスビルダーは、レコードが特定の条件を満たした時に自動化されたアクションを実行するために使用されますが、承認プロセスはプロセスビルダーから直接管理できるものではありません。プロセスビルダーは、承認プロセスを開始するためのトリガーとして使用することは可能ですが、承認プロセス自体は別に設定する必要があります。
D. 2段階の承認プロセスは、商談を削除する前にマネージャーからの許可を得るための明確な手段を提供します。最初の段階でマネージャーに承認を求め、承認された場合にのみ商談を削除できるようにすることで、要件を正確に満たします。
8.Universal Containers は、カスタム オブジェクトのインターンシップとアプリケーションを使用するアプリケーション プロセスを実装しました。インターンシップの組織全体のデフォルトは非公開に設定されており、アプリケーションとの主従関係のマスターです。人事担当副社長は、アプリケーションへの編集アクセスを採用担当者に許可したいと考えています。
アプリビルダーは適切なアクセスをどのように構成する必要がありますか?
A.Web アプリケーションのキューを作成し、レコードを編集するユーザーにアクセス権を割り当てます。
B.アプリケーション オブジェクトの組織全体の既定値を読み取り/書き込みに設定します。
C.ユーザーにインターンシップ レコードへの読み取り/書き込みアクセスを許可する共有ルールを追加します。
D.アプリケーション レコードへの読み取り/書き込みアクセス権をユーザーに付与する共有ルールを作成します。
正解：C
解説：
A. キューは、特定のレコードタイプのグループ化されたリストを管理するために使用されますが、個々のレコードのアクセス権を直接管理するためのツールではありません。キューを使用しても、採用担当者にアプリケーションへの編集アクセス権を直接提供することはできません。
B. アプリケーション オブジェクトの組織全体の既定値を読み取り/書き込みに設定すると、すべてのユーザーがアプリケーション オブジェクトへの読み取り/書き込みアクセス権を持つことになります。これは、特定のユーザーグループ（この場合は採用担当者）に限定したアクセス権を設定するという要件には合致しません。
C. インターンシップ オブジェクトの組織全体のデフォルトが非公開に設定されているため、関連するアプリケーション（子オブジェクト）も非公開となります。共有ルールを使用して、特定のユーザーやグループにインターンシップ レコードへの追加の読み取り/書き込みアクセス権を提供することができます。この方法により、採用担当者がアプリケーション レコードを編集できるようになります。
D. アプリケーション レコードへのアクセスは、主従関係によりインターンシップ レコードのアクセス権に依存します。したがって、アプリケーション レコードに対する共有ルールを作成するよりも、マスターであるインターンシップ レコードに対してアクセス権を設定することが効果的です。
9.DreamMouse Realty には、経験豊富な不動産業者と新しい不動産業者をペアにする指導プログラムがあります。経験豊富な各不動産業者は、1 人または複数の新しい不動産業者を指導することができ、新しい不動産業者はそれぞれ、試用期間中報告する 1 人の経験豊富な不動産業者と協力する必要があります。
この仕様を満たすために、アプリビルダーはどのような関係を設定しますか?
A.間接参照
B.マスター詳細
C.多対多
D.ルックアップ
正解：B
解説：
A. 間接参照関係は、2つのオブジェクト間の関連を間接的に構築するために使用されますが、このシナリオでは経験豊富な不動産業者と新しい不動産業者の間に直接的な関係を設定する必要があります。間接参照は、この特定のニーズには適していません。
B. マスター詳細関係は、1つのオブジェクト（マスター）が他のオブジェクト（詳細）を支配する際に使用されます。詳細レコードはマスターレコードに依存しており、マスターレコードの削除時に詳細レコードも削除されます。この関係は、1人の経験豊富な不動産業者（マスター）が複数の新しい不動産業者（詳細）を指導する場合に適しています。また、新しい不動産業者が試用期間中に1人の経験豊富な不動産業者に報告するという要件も満たします。
C. 多対多関係は、2つのオブジェクト間で複数の関連レコードを持つことができる状況で使用されます。このシナリオでは、新しい不動産業者は1人の経験豊富な不動産業者にのみ報告するため、多対多関係は適切ではありません。
D. ルックアップ関係は、2つのオブジェクト間の単純な参照を提供します。この関係では、子オブジェクトは親オブジェクトにリンクされますが、親オブジェクトの削除時に子オブジェクトは削除されません。このシナリオでは、経験豊富な不動産業者と新しい不動産業者の間により強固な関係が必要であるため、ルックアップ関係は最適な選択ではありません。
10.Ursa Major Solar は、標準の連絡先オブジェクトとカスタムのソーラー プロジェクト オブジェクトの間にリレーションシップを作成したいと考えています。連絡先は複数のソーラー プロジェクト オブジェクトに関連している可能性があり、ソーラー プロジェクトには複数の連絡先を関連付けることができます。
アプリビルダーはデータモデルをどのように構成する必要がありますか?
A.Conuct に 1 つの主従関係、Solar Project に 1 つの主従関係
B.Contact で 1 つの参照関係、Solar Project で 1 つの参照関係
C.新しいカスタム オブジェクトの 2 つの主従関係
D.新しいカスタム オブジェクトの 2 つの参照関係
正解：C
解説：
A. 1つの主従関係は、1つの親レコードに複数の子レコードを関連付けることができますが、複数の親レコードに子レコードを関連付けることはできません。このシナリオでは、連絡先が複数のソーラープロジェクトに関連している可能性があり、ソーラープロジェクトも複数の連絡先に関連することができるため、このオプションは要件を満たしません。
B. 参照関係は、2つのオブジェクト間の単純なリンクを提供しますが、多対多の関係を直接サポートしていません。このシナリオでは、1つの連絡先が複数のソーラープロジェクトに、また1つのソーラープロジェクトが複数の連絡先に関連する可能性があるため、このオプションも要件を満たしません。
C. 新しいカスタムオブジェクトを作成し、そのカスタムオブジェクトに対して2つの主従関係（1つは連絡先に対して、もう1つはソーラープロジェクトに対して）を設定することで、多対多のリレーションシップを実現できます。このカスタムオブジェクトはジャンクションオブジェクトとして機能し、連絡先とソーラープロジェクトの間の多対多のリレーションシップを管理します。
D. 参照関係を使用して新しいカスタムオブジェクトを作成することもできますが、このオプションでは主従関係のような強固な連携や依存性を提供しません。多対多のリレーションシップを管理するためには、ジャンクションオブジェクトとしての役割を果たす主従関係を持つカスタムオブジェクトが最も効果的です。
ここから先は
¥ 2,000
この記事が気に入ったらサポートをしてみませんか？