Text preview & study summary

Salesforce App Builder - Platform App Builder Certification - Data Model Security Automation UI Deployment

A free sample of 5 questions from this quiz, shown in full with answer choices and explanations. No interactivity — everything is visible on this page for study and review.

Want to test your knowledge? Launch the Interactive Exam Simulator

Question 1

An App Builder is evaluating whether to use a Custom Object or a Big Object for storing IoT sensor readings that will generate 10 billion records over 3 years, with queries primarily filtering by device ID and timestamp. What is the recommendation?

Answer choices

  • A. Use a standard Custom Object — Salesforce can handle any volume

  • B. Use a Salesforce Big Object — designed for storing and querying massive datasets (billions of records) that exceed standard custom object capacity; define an Index on device ID + timestamp for performant queries; note that SOQL on Big Objects is limited (no WHERE clause on non-indexed fields), and DML operations are async (Correct)

  • C. Use an External Object connected to an external database

  • D. Store all readings as Attachments in the Files library

Explanation

Salesforce Big Objects are designed for exactly this use case: massive datasets (billions of records) requiring efficient querying by defined Index fields. Big Objects: store data in Salesforce infrastructure with massive scale, define an Index that determines query performance (device ID + timestamp as a compound index enables efficient range queries), use a specialized SOQL syntax (must filter on indexed fields in indexed order), and support async DML via Async SOQL and standard DML. Standard Custom Objects have practical limits (storage limits, query performance degrades at very high volumes). Option A overstates standard custom object scalability — 10 billion records would severely impact standard storage costs and query performance. Option C (External Object) stores data outside Salesforce, adding latency. Option D (Files as Attachments) is completely inappropriate for structured time-series sensor data.

Question 2

A company needs a field on Opportunity that automatically shows the Account's Billing Country without requiring users to enter it. This field should update automatically if the Account's Billing Country changes. What Salesforce field type accomplishes this?

Answer choices

  • A. Custom text field with a Workflow Rule to copy the value

  • B. Formula field on Opportunity that references the parent Account's Billing Country: Account.BillingCountry

  • C. Roll-Up Summary field counting Account records

  • D. Cross-object formula field that references: Account.BillingCountry (pulling the Billing Country from the related Account in real-time) (Correct)

Explanation

A Cross-Object Formula field on Opportunity referencing Account.BillingCountry (the parent record's field via the Lookup/Master-Detail relationship) automatically displays the related Account's current Billing Country value. Crucially, it's always current — it doesn't copy/store the value, it references the parent record's live value, so if the Account's Billing Country is updated, the Opportunity formula field reflects the change immediately. Option A (Workflow Rule with field copy) creates a stored copy that can become stale if the Account changes. Options B and D describe the same thing — a cross-object formula field; D is the more precise description of what this field type is called.

Question 3

An App Builder configures a record-triggered Before Save Flow on Contact that sets the "Preferred Name" field to the "First Name" value if Preferred Name is blank. During testing, the developer reports that Apex Triggers on Contact are firing BEFORE the Flow sets the value — they see blank Preferred Name in Before Triggers. Why?

Answer choices

  • A. Flows always run before Triggers

  • B. Flows always run after Triggers

  • C. Before Save Flows run BEFORE Before Triggers in the Salesforce order of execution — if the developer sees blank Preferred Name in the Before Trigger, the Before Save Flow should have already set it. The developer's testing may have an error, or the Flow condition isn't evaluating correctly (Correct)

  • D. Before Save Flows run at the same time as Before Triggers, with unpredictable ordering

Explanation

Salesforce's order of execution: Before Save Flows execute BEFORE Before Triggers. So if a Before Save Flow correctly sets "Preferred Name," the Before Trigger should see the populated value. If the developer sees blank values in the Before Trigger, investigate: (1) Is the Flow's entry condition correct? (2) Is the Flow paused or deactivated? (3) Is the Flow actually a Before Save type (not After Save)? (4) Is there a specific condition preventing execution? The order of execution documentation clearly places Before Save Flows ahead of Before Triggers — if the developer's observation contradicts this, the Flow has a configuration issue, not an order-of-execution issue. Options B and D are incorrect per Salesforce's published order of execution.

Question 4

An App Builder is configuring a picklist field "Contract Tier" on Account with values: Bronze, Silver, Gold, Platinum. Management wants to prevent future users from selecting "Bronze" for new accounts but keep existing Bronze accounts with that value. What is the correct approach?

Answer choices

  • A. Delete the "Bronze" value from the picklist

  • B. Make "Bronze" inactive in the picklist definition — inactive values no longer appear in the selection dropdown but existing records retain the value; the value still appears in reports for historical records (Correct)

  • C. Create a Validation Rule preventing "Bronze" selection

  • D. Replace "Bronze" with a blank value on all existing accounts

Explanation

Making a picklist value "Inactive" is the correct approach when a value should no longer be selectable for new records but historical data must be preserved: (1) In Object Manager → Account → Fields → Contract Tier picklist, select "Bronze" and check "Inactive"; (2) Inactive values disappear from the picklist dropdown during record creation/editing; (3) Existing records with "Bronze" retain the value and it appears correctly in reports/views; (4) The value can be reactivated if needed. Option A (Delete) prompts you to replace the value on all existing records — this permanently changes historical data. Option C (Validation Rule) would work but is extra configuration when the "Inactive" setting handles it natively. Option D (replace with blank) corrupts historical data.

Question 5

An App Builder needs to quickly see a summary of all open Opportunities, total pipeline by stage, and win rate for the quarter — all on a single screen. Which Salesforce feature provides this consolidated operational view?

Answer choices

  • A. Run four separate reports and compare the results

  • B. Create a Salesforce Dashboard with report-based widgets: one widget showing Opportunities Donut Chart by Stage, one showing Total Pipeline as a metric, one showing Win Rate as a gauge, one showing an Opportunities List view — all on a single configurable canvas refreshed from live report data (Correct)

  • C. Create a complex joined report with all metrics

  • D. Use an Excel pivot table exported from Salesforce data

Explanation

Salesforce Dashboards aggregate multiple reports onto a single canvas, providing an at-a-glance operational view: (1) Donut/Bar chart widget for Opportunities grouped by Stage; (2) Metric widget showing Total Open Pipeline amount (SUM of Amount from an Opportunities report); (3) Gauge widget showing Win Rate (Closed Won / Total Closed from a metrics report); (4) Table widget with recent open Opportunities. Dashboard widgets refresh from live report data (on demand or scheduled). This is the correct tool for consolidated operational monitoring. Option A (separate reports) requires navigating between pages. Option C (Joined Report) shows data in a report, not a visual dashboard. Option D (Excel) is disconnected from live Salesforce data.