Salesforce Certified Platform Developer Practice Exam

Correct: B — after insert and after update, delegating to a handler class. After triggers are the correct context when the operation requires DML on related records, because the records being saved already have IDs. Delegating the logic to a handler class follows the widely adopted one-trigger-per-object pattern and keeps the trigger itself thin.

Why not the others: Before triggers (A and C) are for modifying the records currently in the transaction, not for performing DML on related objects. A future method (D) adds asynchronous complexity to a requirement that is synchronous, and future methods carry their own governor limits and cannot be chained.

Correct: C — implement HttpCalloutMock and register it with Test.setMock(). Test methods do not perform real callouts. Implementing the HttpCalloutMock interface lets you define a deterministic response, and Test.setMock() registers it so callouts made in the test context return that response instead.

Why not the others: Test.startTest and Test.stopTest (A) reset governor limits for the enclosed block; they do not enable real callouts. SeeAllData (B) grants a test access to existing org data and is unrelated to callouts. Skipping the method (D) leaves code uncovered and does not address the requirement.

Correct: A — the getRecord wire adapter with an api-decorated recordId. The Lightning Data Service wire adapters in lightning/uiRecordApi let a component retrieve record data declaratively. When the component is placed on a record page, the api-decorated recordId property is populated automatically, so no Apex is required.

Why not the others: Direct REST calls from the browser (B) bypass Lightning Data Service and its caching and sharing enforcement. An Apex method (C) works but contradicts the stated no-Apex requirement. Parsing the URL manually (D) is fragile and unnecessary when the framework supplies the record ID.

Correct: D — implement Database.AllowsCallouts on the batch class. A Batch Apex class must declare Database.AllowsCallouts alongside Database.Batchable for callouts to be permitted from start, execute, or finish. Without it the callout throws a runtime exception.

Why not the others: The future annotation (A) cannot be used inside a batch execute method. There is no Allow Callouts setting on an Apex job (B). Chaining a Queueable (C) is a legitimate pattern in other contexts but is unnecessary complexity when the interface exists for exactly this purpose.

Correct: C — create the data inside the test. Apex tests are isolated from org data by default, which is deliberate: tests must be deterministic and must pass in any org, including a fresh sandbox or a subscriber org. Building the Account in the test, usually via a shared test data factory, satisfies that requirement.

Why not the others: SeeAllData (A) couples the test to whatever data happens to exist and is discouraged for exactly that reason. Querying arbitrary existing records (B) rests on the same false assumption. Depending on other tests' data (D) is unreliable, since each test method runs in its own context.

Correct: B — the query runs per record and exhausts the SOQL limit. Governor limits are enforced per transaction, and a query inside a loop over Trigger.new executes once per record. The remedy is bulkification: query once outside the loop, collect the results into a map keyed by ID, and reference that map inside the loop.

Why not the others: Triggers can contain SOQL (A) — the problem is where it sits. Trigger.new is a list and is perfectly iterable (C). Bulk loads do fire triggers (D); that is precisely why bulkification matters.

Correct: A — a roll-up summary field. The exam explicitly tests declarative-versus-programmatic judgement, and roll-up summary fields exist for this exact case on master-detail relationships. The declarative option carries no governor limit cost, no test coverage requirement, and no maintenance burden.

Why not the others: A trigger (B) is the standard answer only when the relationship is lookup rather than master-detail, where roll-up summaries are unavailable. A nightly batch (C) makes the total stale between runs. Formula fields (D) cannot aggregate across child records.

Correct: B — declare the controller with sharing. Apex runs in system context by default, ignoring the running user's sharing rules. Declaring a class with sharing enforces those rules for records the class queries, which is the documented approach to preventing data access vulnerabilities in Visualforce and Apex.

Why not the others: Rendering context (A) has no bearing on record access. Client-side hiding (C) is not a security control, since the data has already reached the browser. Query limits (D) constrain volume, not visibility.

Correct: C — a unique external ID field. External IDs let records be referenced by a key from an outside system, which enables upsert operations to match on that field rather than the Salesforce ID. The exam outline lists external IDs alongside objects, fields, and relationships as part of determining and accessing the appropriate data model.

Why not the others: A formula field (A) cannot be used as an upsert key. A master-detail relationship (B) defines record ownership and roll-up behaviour, not external matching. A roll-up summary (D) aggregates child records and has no matching role.

Correct: D — Salesforce DX with the Salesforce CLI. The exam outline names Salesforce DX, the Salesforce CLI, and the Developer Console as the developer tools a candidate should know how and when to use. Salesforce DX is specifically the source-driven model, supporting scratch orgs and version control as the unit of truth.

Why not the others: Change sets (A) move metadata between connected orgs but are org-driven rather than source-driven and have no version control story. The Developer Console (B) is useful for quick edits and log inspection, not project-scale source management. Inline Setup editing (C) is the practice this model exists to replace.