Refer to the Exhibit Practice Questions

The transaction failed due to too many SOQL queries being executed.

Why it fails: The log shows only 15 SOQL queries were executed out of a limit of 100. This is well within the acceptable range for a single transaction. The failure is not related to query volume, but rather to the amount of time the CPU spent processing logic, as indicated by the CPU time limit usage.

The transaction failed because the heap size limit was exceeded during processing.

Why it fails: The heap size usage is reported as 2,500 bytes out of a 6,000,000 byte limit. This is a negligible amount of memory usage. The error in the log specifically points to the CPU time, not memory exhaustion. Developers must distinguish between these two separate resource limits when debugging performance issues.

The transaction failed because the number of query rows exceeded 50,000.

Why it fails: The log shows that only 1,200 query rows were retrieved out of the 50,000 allowed. This is a very small percentage of the total allowed rows. Therefore, the data volume retrieved via SOQL is not the cause of this specific failure; the focus should remain on the CPU time limit instead.

It automatically encrypts the payload for transit.

Why it fails: Named Credentials do not handle payload encryption; that is the responsibility of the HTTPS/TLS protocol and the developer's implementation. The primary benefit of Named Credentials is the secure storage and management of authentication tokens and endpoint URLs, not the modification of the request body's content or security.

It allows the code to bypass the 'Remote Site Settings' check.

Why it fails: While Named Credentials do simplify the allow-listing process, they do not bypass the platform's security mechanisms entirely. You must still configure the necessary security settings to ensure that the outbound request is authorized. The advantage is in credential abstraction, not in bypassing platform-level security checks for external communication.

It enables the use of custom HTTP verbs like PATCH or DELETE.

Why it fails: The choice of HTTP verb (GET, POST, PATCH, etc.) is determined by the 'req.setMethod()' call in the code, not by the Named Credential itself. Named Credentials provide an authentication layer but do not influence the protocol-level capabilities of the Apex HttpRequest object or the allowed HTTP methods.

Reduce the batch size in the Batch Apex class.

Why it fails: Reducing the batch size actually increases the number of transactions and overhead. While it might prevent a CPU limit error in a single batch, it does not address the underlying computational inefficiency of the code. The code itself needs to be optimized for better performance and scalability.

Increase the CPU limit in the organization configuration.

Why it fails: CPU limits are fixed platform constants and cannot be adjusted. They are enforced to ensure that no single process monopolizes the processing power of the multi-tenant server. Developers must write efficient code that operates within these predefined limits, as there is no setting to provide more processing time.

Use the 'transient' keyword for all variables.

Why it fails: The transient keyword is used to manage view state in Visualforce; it has no effect on the CPU usage of Apex code. It does not reduce the number of calculations performed during execution and will not resolve errors related to the CPU time limit in an Apex transaction.

req.setBody('Content-Type: application/json');

Why it fails: Putting header information into the body is incorrect because the request body is reserved for the payload data. External servers expect headers to be in the HTTP metadata section. Placing it in the body will result in a malformed request that the target API will likely reject.

req.setMethod('Content-Type: application/json');

Why it fails: The setMethod() method is used exclusively to define the HTTP verb, such as GET, POST, or PUT. Attempting to include headers or other metadata in this method will cause a runtime error, as the system expects a valid HTTP verb, not a header-value string combination.

h.setHeader('Content-Type', 'application/json');

Why it fails: The setHeader() method is a member of the HttpRequest class, not the Http class. The Http class is used solely for sending the request. Calling a method that doesn't exist on the Http instance will cause a compilation error, preventing the code from being saved or executed.

The user performing the deployment lacks field-level security.

Why it fails: Deployment failures due to missing components are system-level errors that occur during the metadata verification phase. User-level permissions like field-level security apply to runtime access, not to the structural metadata validation process. The issue is a missing metadata definition, not the user's personal access rights to that field.

The Apex class was compiled in the wrong API version.

Why it fails: API version mismatches can cause deprecation warnings or feature-set issues, but they do not cause a 'field not present' error. This error is specific to schema definitions. If a field exists, the API version will generally handle it; if it's missing, the compiler will error regardless of the version.

The custom field needs to be marked as 'Required'.

Why it fails: Marking a field as required is a schema definition choice that affects data entry, not metadata visibility. The error explicitly states that the field is 'not present'. Whether the field is required or optional, it must first exist in the metadata of the target org for the deployment to succeed.

The code is not bulkified to handle a list of IDs.

Why it fails: While the code is not bulkified, the immediate risk is the runtime exception caused by assigning a null result to an SObject variable. Addressing the 'no rows' exception is the priority for code reliability. While bulkification is a best practice, it is secondary to preventing a crashing exception during standard execution.

The code does not use 'with sharing' to enforce security.

Why it fails: Although enforcing sharing is a best practice for security, the most critical issue here is the stability of the application. An exception that crashes the transaction is more dangerous than an incorrect sharing context. Once the code is stable, security can be addressed as the next step in development.

The code uses hardcoded string values for the name.

Why it fails: While hardcoding values is not ideal, it does not cause a functional failure or a runtime exception. The primary issue is the potential for a 'List has no rows' error, which disrupts system operations. Refactoring the hardcoded string should be deferred until the fundamental reliability of the database interaction is secured.

The query is selecting too many fields and should use SELECT *.

Why it fails: Salesforce does not support the use of SELECT * in SOQL queries. Developers must explicitly define the fields they need. Furthermore, selecting more fields does not generally cause performance degradation compared to the filter criteria, which is the primary driver for high query execution time.

The batch size is too small, causing excessive API calls.

Why it fails: Batch size affects data transmission, not the internal query execution performance on the Salesforce servers. Even if the batch size were adjusted, the underlying issue of an unindexed filter condition on a related record remains, meaning the database would still take the same time to resolve.

The query needs to be converted into a subquery using a nested SELECT.

Why it fails: Using a subquery might change the data structure of the results but does not inherently optimize the filter performance. The primary bottleneck is the search condition on the parent object, which needs to be indexed regardless of whether the query uses joins or nested subqueries.

Increase the SOQL query limit by using a @future method to perform the query.

Why it fails: Governor limits are fixed and cannot be increased. Moving queries to a @future method only shifts the query execution to another transaction, which might hit the same limit if the logic is not bulkified. The only correct approach is to bulkify the SOQL query to process data in sets.

Use the Database.queryAll() method to bypass standard governor limits.

Why it fails: Database.queryAll() is used to query records including those in the recycle bin; it does not bypass or increase governor limits. All Apex code must adhere to the same governor limits, regardless of which query method is used, to ensure the multi-tenant platform remains stable for all users.

Wrap the loop in a try-catch block to ignore the error and proceed with the remaining records.

Why it fails: Ignoring a governor limit exception is not possible because the error is fatal and rolls back the entire transaction. A try-catch block will not prevent the transaction from failing. The root cause—the inefficient query inside the loop—must be corrected to ensure the code executes successfully for all records.

The external system needs to be whitelisted in the Remote Site Settings.

Why it fails: Remote Site Settings are for outbound callouts, not for inbound API requests. A 403 error specifically relates to authorization and permission within the Salesforce environment, not connectivity or whitelisting of external domains. The issue is clearly a lack of permission assigned to the guest user profile for the object.

The API endpoint is disabled for public access in the Setup menu.

Why it fails: There is no global 'public access' switch for APIs in Salesforce. Public access is governed by the specific profile and permission set assignments granted to the guest user account associated with the Experience Cloud site. The issue is permission-based, not a global setting that is currently 'disabled'.

The integration needs to be converted to a POST request to avoid security filters.

Why it fails: Changing the HTTP method will not bypass authorization controls. A 403 error is raised by the security layer after the request is received and authenticated. The security infrastructure verifies the permissions regardless of the HTTP method used, so this change would have no impact on the authorization outcome.

The classes are missing the 'global' access modifier.

Why it fails: The 'global' modifier is unrelated to circular dependency errors. It is used to expose classes to external namespaces or managed packages. Changing access modifiers will not resolve the underlying issue where the compiler cannot determine the order of dependency between two classes that reference each other's code.

The deployment is using a source-format package that lacks a proper 'package.xml' file.

Why it fails: While 'package.xml' is necessary for metadata-format deployments, the error message clearly indicates a code-level dependency conflict rather than a packaging configuration issue. The circular dependency is a logic error within the Apex source code itself, not an error related to how the files are grouped during the migration.

The test classes for these Apex classes were not included in the deployment package.

Why it fails: Test class inclusion is required for passing deployment validation, but the error message specifically identifies a circular dependency in the source classes. Omitting test classes would result in a 'missing coverage' error, not a circular dependency error. The issue is strictly located within the primary business logic classes.

The test class needs more setup data, so add more records.

Why it fails: Adding more data exacerbates the issue by increasing the number of trigger executions. If the code is not bulkified, the query count will scale linearly with the number of records. The solution is not to reduce data, but to optimize the code's data access pattern.

Increase the SOQL limit by modifying the Org settings.

Why it fails: Salesforce governor limits are hard-coded per transaction and cannot be increased by an administrator or developer. These limits exist to enforce multi-tenancy performance standards. Modifying the code is the only valid way to handle governor limit violations, ensuring consistent behavior across all Salesforce environments.

Change the test class to run as a user with fewer permissions.

Why it fails: Permission sets do not impact the number of SOQL queries allowed per transaction. The error is strictly related to resource consumption within the Apex execution context. Altering user permissions will not prevent the code from hitting the limit, as the logic remains inherently unoptimized for bulk operations.

The check should be performed using 'without sharing' to ensure all data is accessible.

Why it fails: Using 'without sharing' explicitly bypasses user security settings, which is a major vulnerability. Applications must respect the user's permissions to prevent unauthorized access or modification of records. Security should be enforced by default, only opting out when absolutely necessary for specific system-level tasks that require high-privilege access.

The class should be declared 'inherited sharing' to avoid performance overhead.

Why it fails: Inherited sharing does not provide security benefits; it simply allows the class to adopt the sharing model of the caller. This can lead to unpredictable behavior if the calling context is unknown. For a service class, explicit sharing declaration is preferred to ensure consistent, secure behavior regardless of the caller.

The method should be annotated with @AuraEnabled to ensure it is secure for Lightning.

Why it fails: The @AuraEnabled annotation is required for server-side controllers to interact with the Lightning Component framework, but it does not perform security validation automatically. It simply exposes the method to the client. Manual security enforcement remains mandatory within the method body regardless of the annotation used for the controller.

The developer forgot to add the '@salesforce/resource' prefix to the import.

Why it fails: The '@salesforce/resource' prefix is used for importing Static Resources, not for importing other Lightning Web Components or local utility modules. For component-to-component imports, the 'c/' namespace is the correct prefix, and the error indicates a resolution failure within that namespace.

The 'utils' component is missing the 'isExposed' tag in its metadata file.

Why it fails: The 'isExposed' tag determines if a component is visible in tools like the Lightning App Builder. It does not affect the ability of one component to import another in the source code. Internal imports are governed by file visibility and naming within the project structure, not by exposure metadata.

The developer needs to run 'sfdx force:source:pull' first to sync metadata.

Why it fails: Pulling metadata from the org is used to sync changes made in the UI back to the local workspace. It does not resolve compilation errors caused by incorrect local file naming or invalid import statements. The error is a local build issue that must be fixed in the source code.

Wrap the SOQL queries in a try-catch block to handle the exception gracefully.

Why it fails: Catching a LimitException is generally discouraged as it does not resolve the underlying issue of exceeding governor limits. The transaction will still fail, and the user will not receive the expected result. Proper bulkification is the only way to ensure the code executes successfully within the defined platform constraints.

Increase the Apex heap size in the class definition.

Why it fails: There is no configuration to increase governor limits for Apex heap or SOQL queries. These are fixed platform limits enforced to maintain multi-tenant health. Increasing heap size would not solve the SOQL limit issue, as the problem is related to the number of queries executed, not memory consumption.

Use an @future method to process each record individually.

Why it fails: Calling an @future method inside a loop will trigger a 'Too many future calls' limit exception. Even if it were allowed, it creates unnecessary asynchronous overhead and does not solve the underlying inefficiency of the original design. Bulkifying the SOQL query is the correct architectural solution for this scenario.

The trigger logic is attempting to update the same record more than 150 times.

Why it fails: The limit is per-transaction, not per-record. Updating a single record 150 times would also hit the limit, but the error message specifically points to the count of DML statements. The issue is the frequency of individual DML calls, not the number of updates performed on a single specific record instance.

The batch size in the data loader is set too high for the current trigger logic.

Why it fails: While batch sizing matters, the governor limit is absolute. Even with a batch size of 200, if the logic is unoptimized, it will fail. Adjusting the batch size is a workaround, not a fix. The code itself must be refactored to support bulk operations to ensure it remains compliant under load.

The org-wide daily DML limit has been exceeded due to high transaction volume.

Why it fails: The error shown is a transaction-level limit exception, not a daily limit. Daily limits trigger different messages and behaviors. The '151' value specifically refers to the count of DML statements within the current execution scope, clearly indicating a design pattern failure where individual statements are being executed too frequently.