Salesforce Certified Platform Developer II 1-10

The key points of this question are that holding a large number of records at once bloats the view state and that the display processing itself slows down due to the large number of records retrieved.
Visualforce has a defined upper limit on view state size, and for list displays, managing the record set with a StandardSetController is effective.
Therefore, reducing the number of records handled at once with a SOQL LIMIT or a StandardSetController is the appropriate action.
Option B is counterproductive, because transient indicates that a value is not retained in the view state, so removing it could actually worsen the problem.
Options A and D are insufficient as a direct solution to this question.
StandardSetController Class
Visualforce Limits

This question asks how to retrieve picklist values in the running user’s language in an environment where the Translation Workbench is enabled.
In SOQL, using the toLabel() function lets you retrieve the display label of a picklist or reference field according to the user’s language.
In other words, toLabel() is the mechanism that returns the translated label rather than the API value.
This enables appropriate display even in a multilingual environment.
There is no mechanism to convert values after retrieval as in options B and C, and there is no Locale clause in SOQL as in option D.
Therefore, using toLabel(), which converts at SOQL execution time, is the correct answer.
toLabel()

In this question, the key point is whether the trigger processing is bulkified. The most efficient is Option D.
First, it collects the ZIP codes from Trigger.new into a Set, then retrieves all matching Region__c records in a single SOQL query, and finally uses a Map to look up the Region from each Lead’s PostalCode.
This results in an implementation resilient to governor limits because SOQL is not executed inside a loop.
Option B does reduce the number of queries, but it uses a nested loop, so it becomes inefficient as the record count increases.
Option C is a typical “SOQL inside a loop” and is inappropriate.
Therefore, Option D, which loads the result of a single retrieval into a Map and assigns it to each Lead, is the most efficient.
Bulk Triggers
Trigger and Bulk Request Best Practices

Because Queueable Apex is asynchronous processing, the test must use Test.startTest() and Test.stopTest() to force the processing to run.
In particular, it is important that the asynchronous processing is actually executed at the point of Test.stopTest().
Therefore, enqueueJob must be called after startTest(), and the results must be verified after stopTest().
Also, the correct procedure is to re-query the results of the asynchronous processing with SOQL after stopTest() and verify them.
Options A and D verify before the asynchronous processing completes, so they are inaccurate, and a technique like Option C is not a common verification method.
Using limits, startTest, and stopTest
Queueable Apex

The key point of this question is data consistency across environments and availability during test execution.
Because custom settings are treated as data, their contents may change or be lost when a sandbox is refreshed.
Custom metadata, on the other hand, is managed as metadata, so it can be deployed and is always available at test execution time.
In other words, the ability to guarantee identical data across environments is a major advantage of custom metadata.
Also, the fact that it can be referenced without creating data during tests contributes to improved stability.
Therefore, from the perspective of stable operation going forward, migrating to custom metadata is the optimal action.
Apex Developer Guide
Isolating Test Data from Organization Data in Unit Tests

The key point of this question is displaying multiple errors at once with “minimal JavaScript.”
In Salesforce, using validation rules lets you implement condition checks on multiple fields declaratively.
In particular, validation rules can define multiple conditions and return multiple error messages at the same time.
Also, lightning-record-edit-form natively supports error display via validation rules, so no additional JavaScript implementation is required.
Options A and B are unnecessarily complex, and Option D is server-side processing, so it is not suited to real-time on-screen display.
Therefore, the best action is validation rules.
Introduction to Aura Components
About This Quick Reference

When dealing with large data volumes, “selectivity” and the use of indexes are important.
Fields configured as External IDs are automatically indexed, so a query that includes one as a condition is faster.
Therefore, Option B, which includes Customer_Number__c (an External ID) as a condition, uses the index and is optimal.
Option D also narrows the target with IsDeleted = false, improving efficiency by excluding unnecessary deleted data.
Option A cannot use an index and is inefficient, and Option C depends on the size of the list, so selectivity is not guaranteed.
Thus, from the perspective of index usage and data narrowing, Options B and D are appropriate.
Apex Developer Guide
Working with Very Large SOQL Queries

This error occurs when the recursive invocation of a trigger exceeds the limit.
To prevent infinite loops, Salesforce sets an upper limit on the number of trigger nestings (recursions), which is a maximum of 16.
Therefore, when the same trigger or a related trigger repeatedly invokes update processing, this limit is reached.
Typically, the cause is a circular structure in which an after update updates another object, which in turn re-invokes the update of the original object.
Therefore, it is important to control trigger re-execution by implementing a recursion-prevention flag or by revisiting the design.
Options B and C are different governor limit errors and are not direct causes of this error.
Triggers and Order of Execution
Triggers

In Lightning Web components, the wire service is used for data retrieval.
When using getRecord, you must specify both the recordId and the fields to retrieve.
Therefore, it is essential to specify the fields as well, as in @wire(getRecord, { recordId: ‘$recordId’, fields: ‘$fields’ }).
This retrieves the required field data of the specified record.
Also, it is important that @wire works reactively and automatically re-retrieves when recordId or fields change.
Option B has incorrect syntax, and Option C is incomplete because it does not specify fields.
Understand the Wire Service
getRecord

This question is a case where you need to investigate the possibility that the trigger is running multiple times or interfering with other automation (flows or workflows).
For that, a detailed trace using logs is the most effective.
In particular, it is important to use System.debug() to visualize the execution order and count of the processing.
Also, by checking the Developer Console logs, you can identify trigger re-execution and the influence of other automation.
Option A can be an effective way to isolate the issue in some cases, but it is inefficient; Option B is not directly related to solving this problem; and Option C has too broad a scope, making it difficult to identify the cause.
Therefore, the best action is Option D.
Debugging Apex
Apex Developer Guide