Explanation:

This question tests the correct syntax for using the @wire decorator with the getRecord adapter in a Lightning Web Component to retrieve Salesforce data. The wire service automatically provisions data to the decorated property based on the configuration object passed to getRecord.

✅ Correct Option:

D. @wire(getRecord, { recordId: '$recordId', fields: '$fields' })
The @wire decorator must wrap the adapter function (getRecord) along with a configuration object containing the required parameters. The recordId and fields properties are referenced dynamically using the $ prefix, which tells the wire service to re-evaluate when those reactive properties change. This is the only option that correctly uses @wire with both necessary parameters.

❌ Incorrect options:

A. @api(getRecord, { recordId: '$recordId' })
The @api decorator is used to make a property or method public for parent components, not to invoke wire adapters. Additionally, this option omits the required fields parameter, which getRecord needs to determine which fields to retrieve from the record.

B. @wire(getRecord, { recordId: '$recordId' })
This option uses the correct @wire decorator and dynamically references recordId, but it fails to include the fields parameter. Without specifying which fields to query, getRecord cannot retrieve the desired data, making this configuration incomplete.

C. @api(getRecord, { recordId: '$recordId', fields: '$fields' })
This option incorrectly uses the @api decorator instead of @wire. While it includes both parameters correctly, @api does not invoke wire adapters or provision data to properties. It is used solely for exposing public properties or methods.

🔧 Reference:
→ Salesforce Developers — Get Record Data — Confirms that @wire(getRecord, { recordId, fields }) is the correct syntax for retrieving record data with reactive parameters.

→ Salesforce Developers — Data and Communication Anti-Patterns in Lightning Web Components — Confirms that @wire is for read operations and that getRecord requires a fields array specifying which fields to fetch.

Explanation

The issue is caused by the Case automation executing the counter logic more than once within the same transaction.
A static Boolean can act as a recursion guard because its value persists throughout the current Apex transaction.
The trigger should check the flag before executing the handler and set it to false afterward.
The flag must not be reset to true every time the trigger fires.
A local Boolean inside the trigger also cannot prevent a subsequent trigger execution.
Therefore, A–B is the correct code pattern.

Correct Option

🟢 A–B. Use a static firstRun Boolean and set it to false after the handler executes.
This solution uses a static Boolean in the handler class as a transaction-level recursion guard. On the first trigger execution, firstRun is true, so the handler increments Edit_Count__c. The trigger then sets the flag to false. If the trigger executes again during the same transaction, the condition fails and the handler is skipped. Because Apex static variables retain their values within a transaction, this prevents duplicate trigger processing.

Incorrect Options

❌ C–D. Reset CaseTriggerHandler.firstRun to true inside the trigger.
This defeats the recursion guard. Every time the trigger executes, firstRun is first reset to true, so the condition always succeeds and the handler executes again. The static variable must retain its previous value instead of being reset on every trigger invocation.

❌ E–F. Declare firstRun as a non-static class variable.
This approach cannot be used as a transaction-level guard in the static handle() method because firstRun is an instance variable while handle() is static. More importantly, the guard must be shared across trigger invocations in the transaction, which is why a static variable is required.

❌ G. Declare firstRun as a local Boolean inside the trigger.
A local variable is initialized every time the trigger executes. Therefore, firstRun becomes true again on each invocation, allowing the handler to run repeatedly. A static class variable is required so its value persists across trigger executions within the same transaction.

Reference
⇒ Before-Save Record-Triggered Flows — Confirms that before-save flows execute during the record-save process and can modify fields on the triggering record.

⇒ Leveling Up Your Apex Skills — Confirms that Apex static variables are scoped to the transaction, supporting their use for transaction-level state such as recursion guards.

Explanation:

The Lightning Web Component must display Accounts in a lightning-datatable and allow users to filter the results by up to five fields that can change at runtime based on the user’s selections. Because the set of filter fields (and their values) is not known until the page runs, the SOQL query’s WHERE clause must be constructed programmatically. Dynamic SOQL (building a query string at runtime and executing it with Database.query or Database.queryWithBinds) is the Apex feature that enables this flexibility.

✅ Correct Option:

✅ D. Dynamic SOQL
In the Apex controller the developer builds a SOQL string that includes only the fields the user has chosen to filter on, binds the corresponding values safely, and executes the query with Database.query (or the safer Database.queryWithBinds). The resulting list of Accounts is returned to the LWC and bound to the lightning-datatable. This approach supports any combination of up to five filter fields without hard-coding multiple static queries.

❌ Incorrect options:

❌ A. describeSObjects()
Schema.DescribeSObjectResult (obtained via Schema.describeSObjects) is used to inspect object and field metadata. While it can help validate that a chosen filter field exists and is accessible, it does not execute a query or return record data.

❌ B. REST API
The REST API is an external interface. An LWC that needs data from the same org calls an Apex method directly; using the REST API would be unnecessary overhead and is not required for this use case.

❌ C. SOSL queries
SOSL is designed for free-text search across multiple objects and fields. It is not suited to structured, field-specific filtering (e.g., “Industry = ‘Technology’ AND BillingState = ‘CA’”) that a datatable filter typically requires.

🔧 Reference:
→ Dynamic SOQL (Apex Developer Guide – Salesforce Developers)
Explains how to construct and execute SOQL strings at runtime with Database.query / Database.queryWithBinds, which is exactly what is needed when filter fields vary according to user input.

Explanation

This question tests how to make a callout to an external web service when a record is created.
Apex triggers cannot make synchronous callouts, so the callout must run asynchronously after the insert.
The best choice is the asynchronous tool that is flexible, lightweight, and started directly from the trigger.

✅ C. Create an Apex trigger, execute a Queueable job from it, and make a callout from the Queueable job.
An Apex trigger on Account insert can find records with blank address fields and enqueue a Queueable job with their IDs. The Queueable class implements Database.AllowsCallouts, so it can call the third-party service asynchronously and then update the Address fields. Queueable Apex accepts complex parameters, handles bulk record sets, and supports chaining, which makes it the recommended pattern.

❌ A. Create a Before Save Flow, execute a Queueable job from it, and make a callout from the Queueable job.
A before-save record-triggered flow can only update field values on the triggering record. It cannot call Apex actions or launch a Queueable job, and the record does not yet exist in the database for the job to reference. Callouts also cannot run in the before-save context, so this design does not work.

❌ B. Create an Apex class, execute a Batch Apex job from it, and make a callout from the Batch Apex job.
Batch Apex is built for processing very large data volumes, not for reacting to individual inserts. Starting a batch job for every Account insert is heavy and can exhaust the limit of 100 jobs in the flex queue, delaying other jobs. It also runs later than needed, which makes it a poor fit for this requirement.

❌ D. Create an Apex class, execute a Future method from it, and make a callout from the Future method.
Future methods can make callouts, but they accept only primitive parameters, so sObjects cannot be passed in. They cannot be chained or monitored by job ID, and one future method cannot call another. A transaction is also limited to 50 future calls. Queueable Apex avoids these restrictions and is the preferred approach.

Reference
🔗 Queueable Apex - Apex Developer Guide, Salesforce Developers → confirms Queueable jobs run asynchronously, accept non-primitive types, and support callouts with Database.AllowsCallouts.
🔗 Future Methods - Apex Developer Guide, Salesforce Developers → confirms future methods accept only primitive parameters and cannot be chained.

Explanation:

This question tests the source-driven development model in Salesforce. In this model, metadata is stored as source files in a local Salesforce DX project and managed in a version-control system, rather than treating the production org as the primary source of truth.

Salesforce CLI supports retrieving metadata into source format, tracking changes in supported orgs, and deploying controlled metadata changes through source-driven development and CI/CD processes.

✔️ Correct Option:

✔️ Option C — Salesforce CLI with Salesforce DX
Salesforce CLI is the appropriate tool for source-driven deployment because it manages metadata as files in a Salesforce DX project. Developers can retrieve metadata with sf project retrieve start, store and version it in Git, validate deployments, run tests, and deploy source using sf project deploy start. Source tracking can identify differences between local project files and supported scratch orgs or sandboxes.

❌ Incorrect Options:

❌ Option A — Data Loader
Data Loader is used to import, export, update, delete, and upsert Salesforce record data. It does not manage metadata source files, track source changes, integrate metadata with version control, or deploy Apex, objects, permission sets, Lightning components, and other configuration between environments. Therefore, it is not a source-driven deployment mechanism.

❌ Option B — Change Sets
Change Sets provide an org-based mechanism for moving selected metadata between related Salesforce organizations, such as a sandbox and its production org. They do not provide local source representation, Git-based version control, automated deployment pipelines, or source tracking. Therefore, Change Sets do not support a modern source-driven development workflow.

❌ Option D — Unmanaged Packages
Unmanaged packages can distribute metadata but are not intended to manage an ongoing source-driven deployment lifecycle. They do not provide source tracking, version-control integration, automated validation, or continuous deployment controls. Once installed, their components can be modified directly in the target organization, which makes controlled release management more difficult.

🔧 Reference:
→ Track Changes Between Your Project and Org
— Confirms that Salesforce CLI source tracking detects changes between a local project and supported scratch orgs or sandboxes.

→ project deploy start
— Confirms that Salesforce CLI deploys metadata from a local project and supports source-formatted metadata deployment.