Hard Difficulty Questions

for(KeyValue kv : myMap.entrySet()) { ... }

Why it fails: Apex does not support a `KeyValue` class for map iteration, causing a compilation error when attempting to access entries this way. Developers often confuse this syntax with the `Map.Entry` interface found in Java, which provides a structured way to handle key-value pairs. While this pattern is standard in other object-oriented languages for iterating over map entries, Apex requires the use of the `keySet()` method or the `values()` method to process map data within a loop.

for(Account acc : myMap) { ... }

Why it fails: Iterating directly over a `Map` variable in this manner attempts to treat the collection as a simple list of values, which fails because Apex does not implicitly destructure maps during iteration. This syntax would be tempting because it mirrors standard for-each loops used to process lists of sObjects, and it *would* be the correct choice if `myMap` were instead declared as a `List<Account>`, allowing direct traversal of the record collection without needing to separately extract the values.

for(Id id : myMap.iterator()) { ... }

Why it fails: Map.iterator() returns an Iterator<Id> over keys, not values, so assigning each element to an Id and iterating values fails to compile. It is tempting because iterator() exists on Map, but iterating values requires myMap.values() or keySet() with get().

Use a Database.setSavepoint() before the DML operation to rollback if recursion occurs.

Why it fails: A savepoint rolls back the DML but does not stop the trigger from re-firing, so the recursion and depth limit still occur. Savepoints are genuinely for partial rollback within a transaction. The fix is a static Boolean guard variable that prevents re-entry, or narrowing the trigger entry criteria.

Convert the trigger logic into a Queueable Apex job to defer execution to a separate transaction.

Why it fails: Queueable Apex still performs the same Contact DML, so the Account update re-fires the trigger and recursion continues; it only defers it to a new transaction. Queueable is genuinely for asynchronous, long-running work. The fix is a static Boolean guard variable that skips re-entry, or filtering the trigger entry criteria.

Check Trigger.isExecuting to determine if the trigger is running in a recursive context.

Why it fails: `Trigger.isExecuting` is a Boolean context variable that simply returns true whenever any trigger code is currently running, meaning it evaluates to true during both the initial execution and every subsequent recursive iteration of the same trigger. Developers often find this property tempting because its name implies it tracks execution states, making it seem useful for detecting loops; however, it is actually designed to differentiate between trigger-driven execution and other code contexts such as web services or scheduled jobs, rendering it entirely useless for counting or blocking recursive depth within the same trigger cycle.

lightning/uiRecordApi

Why it fails: `lightning/uiRecordApi` provides modules for working with Salesforce UI records, such as `getRecord` and `updateRecord`, making it tempting if you incorrectly assume record data operations share a namespace with messaging features. It would be the correct choice when a component needs to retrieve, create, or update standard Salesforce record data directly from the user interface without writing custom Apex controllers, rather than publishing messages across the Lightning Message Service channel.

lightning/empApi

Why it fails: `lightning/empApi` is used to interact with the Streaming API to publish and subscribe to platform events or PushTopics over cometD, failing here because it does not interface with Lightning Message Service channels. Developers often confuse these two real-time event mechanisms within Salesforce. This module would be the correct choice if the requirement explicitly specified publishing a platform event to external subscribers or backend systems rather than communicating between sibling or loosely coupled components within the same Lightning page.

lightning/navigation

Why it fails: `lightning/navigation` is used to navigate to record pages, list views, or web URLs within a Lightning Experience application, making it tempting if you confuse component communication with page routing. However, it fails in this scenario because it lacks any methods for publishing messages across the Lightning Message Service, whereas the correct implementation requires importing the `publish` function and the specific message channel from `@salesforce/messageChannel`.

:content

Why it fails: The `:content` pseudo-class fails in this scenario because it does not target slotted content passed from a parent Lightning Web Component into a child; instead, it is a legacy selector historically associated with shadow DOM styling proposals that are not supported in Salesforce Lightning Web Components. It is tempting because developers often confuse it with standard CSS shadow piercing or slot-targeting syntax, where it would theoretically be used to style distributed child nodes if native CSS shadow mechanisms permitted direct piercing of encapsulation boundaries.

:scope

Why it fails: Targeting slotted content requires the `::slotted()` pseudo-element rather than `:scope`, rendering the latter ineffective for styling markup passed from a parent component into a child's slot. Developers often find `:scope` tempting because it is designed to reference the element that is currently matching the style rule within a scoping context, such as selecting the host element or scoping queries within a shadow DOM subtree. Consequently, `:scope` would be the correct choice when you need to target the component's root host element directly from within its own stylesheet, rather than styling distributed child nodes residing inside a named slot.

:host

Why it fails: Targeting the host element rather than slotted content, `:host` applies styles to the boundaries of the custom component itself instead of piercing the shadow DOM to style external markup injected into named `<slot>` elements. This is tempting because developers frequently use `:host` to customise component styling from within, and it *would* be the correct choice if the requirement were to style the root container of the child component or apply state-based styling via host context selectors.

Total heap size allocation

Why it fails: Heap size is consumed by in-memory data, not by issuing queries; 200 SOQL queries inside a loop breach the 100 synchronous query limit first. Heap tempts developers because large result sets do consume memory, but the immediate breach here is the query count, not accumulated heap allocation.

Maximum CPU time on Salesforce servers

Why it fails: CPU time is a cumulative processing limit, not the first ceiling hit by repeated queries; 200 SOQL calls breach the 100-query synchronous governor limit immediately. CPU time tempts developers because loops are computationally costly, but the query count is exhausted before CPU time becomes the binding constraint.

Total number of records retrieved by SOQL queries

Why it fails: SOQL queries inside a loop hit the 100-query governor limit first, not the 50,000-record retrieval cap; 200 iterations breach query count long before record totals. The record-retrieval limit is tempting because it is the headline SOQL limit, and it would be the correct answer if a single query returned too many rows.

Disable FLS checks in user profile settings before executing queries.

Why it fails: FLS enforcement is not a profile toggle; it is applied by the platform when queries run in user mode, so disabling it is neither possible nor secure. The option is tempting because profile settings do govern many permissions, but FLS is enforced through WITH SECURITY_ENFORCED or stripInaccessible, not configuration.

Execute queries inside an asynchronous @future method.

Why it fails: Executing queries within an asynchronous `@future` method fails to enforce the user's field-level security because asynchronous processing runs in system context, stripping away running-user context entirely. This approach is tempting because it is designed to offload long-running operations or bypass governor limits during heavy transaction processing, making it the correct choice when executing batch tasks or callouts that must run independently of the current user interface transaction.

Use the 'without sharing' keyword on all transaction controllers.

Why it fails: Applying the `without sharing` keyword explicitly disables the enforcement of organisation-wide defaults and sharing rules, directly exposing unauthorised data records that the scenario demands be protected. Developers are often tempted to use this modifier in controller classes when they need to deliberately bypass current user permissions to aggregate data or process background operations across all records, which would be the correct architectural choice if the business logic specifically required privileged access rather than strict security compliance.

Only the failing test class is ignored.

Why it fails: Salesforce deployments via the Metadata API enforce an all-or-nothing transactional model where a single test failure causes the entire deployment to roll back, meaning failing tests can never be selectively ignored. This behaviour mimics local development where developers often run specific subsets of tests to isolate issues, which makes it tempting to assume that the platform would similarly isolate failures during automated deployments. Running a targeted subset of tests *would* be the correct choice when executing local validation via the Salesforce CLI using the `sfdx force:apex:test:run` command, where you can explicitly specify individual test classes rather than subjecting the entire codebase to mandatory validation.

The deployment succeeds but flags a warning.

Why it fails: A failed test class during a Metadata API deployment halts the entire transaction and causes the complete deployment to roll back, preventing the deployment from succeeding with merely a warning. This behaviour mirrors the less stringent validation logic applied in some packaging or asynchronous environments where test failures generate notifications rather than blocking updates. Such a tolerant outcome would only occur if running tests were explicitly bypassed in specific non-production contexts using targeted API parameters rather than standard deployment validation rules.

The deployment continues but prevents Apex compilation.

Why it fails: Failing test classes cause the entire Metadata API deployment to roll back rather than allowing partial continuation, because Salesforce enforces a zero-failure policy for unit tests during production deployments to maintain code quality. This behaviour mimics developer debugging phases where compiling code without strict test validation is occasionally useful for isolating syntax errors before writing assertions. Consequently, bypassing test execution entirely is sometimes desired during rapid initial code scaffolding, which is why developers might mistakenly assume compilation issues alone would trigger a partial deployment continuation.

AsyncException

Why it fails: AsyncException is related to asynchronous job queueing limits.

LimitException

Why it fails: LimitExceptions are thrown when governor limits such as CPU time or queries are exceeded, not specifically for callouts after DML.

SystemException

Why it fails: This option is tempting because developers frequently encounter general runtime errors when managing transaction limits, making a generic system fault appear to be the logical catch-all for boundary violations. It is actually designed to catch unexpected platform failures, unhandled low-level runtime faults, or fatal resource exhaustion within the JVM. However, performing a DML operation prior to a web service callout triggers a strict governor limit error specifically to prevent uncommitted database locks during external latency, which is governed by a `CalloutException` rather than a system-level exception.

@api

Why it fails: @api exposes a public property or method to the parent component; it does not subscribe the property to wire data changes. It is tempting because @api is the standard decorator for passing values into a component, which is the correct choice when a parent must supply a record ID or configuration value.

@track

Why it fails: @track makes a private field reactive for internal mutations such as adding array elements, but it does not connect the property to the wire service's data stream. It is tempting because @track is the decorator historically used for reactivity in Lightning Web Components, and it is correct when a component mutates its own object fields.

@readonly

Why it fails: @readonly marks a wired property as non-reactive, so the wire adapter provisions data once and never refreshes it when the record changes. It is tempting because @readonly is genuinely correct when a component only needs to display data once and performance matters more than live updates.

Permanent production status with unlimited user licenses.

Why it fails: Scratch orgs are disposable, time-limited environments with capped user licences, so permanent production status and unlimited licences are impossible. It is tempting because scratch orgs do resemble production configurations for testing, but that scenario would use a sandbox or Developer Edition org instead.

Directly modifying standard Salesforce platform source code.

Why it fails: Salesforce scratch orgs rely on metadata-driven development where standard platform source code is proprietary and immutable, preventing developers from directly altering internal system binaries or core product code. This option sounds plausible because standard objects and platform features are fully customisable through metadata extensions like fields, triggers, and Apex classes. Developers would modify application logic directly in legacy monolithic architectures or open-source software platforms where source code access is permitted, whereas the Salesforce metadata model restricts customisation strictly to configurable layers above the core platform base.

Unlimited

Why it fails: Chaining is strictly capped to prevent infinite loops.

1

Why it fails: Chaining a Queueable job that implements `Database.AllowsCallouts` is permitted up to 50 times in an execution sequence, making a limit of one incorrect because it would prematurely halt the asynchronous processing chain. This single-job limitation is tempting because it reflects the stricter constraints applied to asynchronous callouts in older paradigms, or synchronous governor limits, where subsequent executions are restricted to prevent infinite loops. A limit of one would apply if you were restricted to a single initial asynchronous execution without further self-perpetuating chaining.

50

Why it fails: 50 exceeds the queueable chain limit.

To force the deployment despite test failures.

Why it fails: Forcing a deployment despite test failures requires the `--ignore-errors` flag, not the `check-only` flag. The `check-only` flag serves a different purpose: it validates the deployment against the target environment without committing any changes to the metadata. Developers use this option to verify that code will compile and pass tests in a production-like environment before finalising the release, ensuring that the deployment package is valid without actually modifying the organisation’s configuration.

To skip the compilation check.

Why it fails: The `--check-only` flag performs a validation-only deployment, which mandates that all Apex code must compile successfully before the process completes. This option fails because it does not bypass the compilation phase; rather, it enforces it to ensure the deployment would succeed without committing changes to the metadata. Developers often confuse this with flags intended to ignore test execution or specific components, yet the compilation check remains a non-negotiable requirement for all Salesforce deployments regardless of the validation status.

To run only the tests.

Why it fails: Check-only validates the deployment by running the specified tests without saving components to the org; it does not run only the tests. It is tempting because test execution is part of its behaviour, but it would be the correct choice when validating a deployment before committing changes.

Triggers cannot be defined on standard objects, only custom objects.

Why it fails: Apex triggers can indeed be defined on standard objects such as Account and Contact, as well as custom objects. Developers frequently need to automate business logic and enforce data validation rules upon DML operations for standard platform objects. This statement appears plausible because standard objects initially feel distinct from custom objects within the schema, leading to the false assumption that programmatic automation is restricted to user-defined data structures.

Triggers cannot process more than 200 records in a single batch chunk.

Why it fails: Trigger batch size is typically 200, but platform architecture can pass collections in batch contexts; however, the primary limitation option is correct regarding callouts, stack depth, and DML limits.

Query the AsyncApexJob object

Why it fails: Querying the `AsyncApexJob` object only tracks queueable, batch, and future jobs, making it ineffective for scheduled Apex which resides in the `CronTrigger` table until execution. Developers are often tempted to use `AsyncApexJob` because it successfully monitors the asynchronous execution status of standard batch and queueable transactions. However, verifying a scheduled job requires querying `CronTrigger` and checking the `NextFireTime` or `TimesTriggered` fields to confirm the job has run, rather than relying on `AsyncApexJob`.

Use System.runAs()

Why it fails: `System.runAs()` is tempting because developers frequently encounter it when writing unit tests to enforce user context and profile permissions during data manipulation. Therefore, one might mistakenly believe it controls transaction timing or test execution order. However, it fails in this scenario because it only sets the user context for database operations and has zero effect on the asynchronous queue, meaning it cannot force the test to wait for a scheduled job to complete before running assertions.

Use Thread.sleep()

Why it fails: Pausing execution using `Thread.sleep()` is tempting because developers frequently rely on sleep methods in multi-threaded programming languages to wait for background threads or timers to complete their execution cycles. However, Salesforce operates on a multi-tenant architecture where `Thread.sleep()` is blocked entirely to prevent developers from freezing platform worker threads and consuming valuable synchronous transaction time limits. Instead of artificially pausing thread execution, asynchronous Apex testing requires wrapping the assertion logic inside `Test.startTest()` and `Test.stopTest()` blocks, which forces the platform to synchronously process all queued scheduled jobs before resuming the test execution flow.

The failed record is placed in a retry queue for asynchronous reprocessing.

Why it fails: Incorrect. Salesforce does not automatically retry failed batch records unless custom error handling is written.

Only the failed record is rolled back, and the batch continues processing the remaining records.

Why it fails: Incorrect. By default, unhandled exceptions in the execute method will cause the entire transaction for that batch chunk to fail.

The entire database transaction is rolled back, but the batch continues to the next execute method.

Why it fails: Executing a batch job without specifying the optional scope-handling parameter relies on the default all-or-nothing transactional behaviour applied to the entire batch scope, meaning an unhandled exception rolls back only that specific execution chunk rather than the whole job. This mechanism appears tempting because database transactions conventionally roll back entirely upon encountering an error to preserve data integrity. Such all-or-nothing behaviour would be correct in a financial ledger scenario where a partial update corrupts dependent balances and requires total atomicity, but it fails here because Batch Apex processes large volumes asynchronously where failing an entire chunk due to a single bad record disrupts millions of valid updates.

It creates data that is isolated from the test methods.

Why it fails: Test setup methods are specifically designed to insert common test records once per test class to reduce execution time and avoid repetition, making them the correct choice when multiple test methods require a shared baseline dataset. However, this option fails because test setup data is not isolated from individual test methods; rather, any modifications made to that data within a test method roll back after that method completes, meaning the original state is preserved for subsequent methods rather than being completely partitioned away.

It cannot interact with the database.

Why it fails: Test setup methods are explicitly designed to insert common test records into the database once per test class execution to streamline data preparation. Developers often find this appealing when writing unit tests that require shared prerequisite data across multiple test methods without violating governor limits. However, the assertion that these methods cannot interact with the database is factually incorrect, because their primary operational purpose is to perform DML operations to set up state before individual test methods run.

It can only be used once per project.

Why it fails: Methods annotated with `@testSetup` can actually be executed once per test *class* to efficiently create common test data for all test methods within that class, making it a tempting choice when developers want to avoid repeating setup code across multiple tests. However, this option fails because the constraint limits usage per test class rather than per entire project, allowing numerous setup methods across a large code base.

Ignore the custom settings in the test.

Why it fails: Tests will fail.

Hardcode the values into the test.

Why it fails: Hardcoding values fails because Custom Settings are designed to be retrieved via Apex methods like `getOrgDefaults()` or `getInstance()`, which return null during test execution unless explicitly inserted into the database. While developers often use hardcoded values for local unit tests to bypass external dependencies, this approach ignores the requirement to simulate the actual runtime data access pattern. You should instead use `Test.loadData()` or manual DML insertion to populate the settings, ensuring the class under test interacts with the data layer as it would in production.

Use the production custom settings.

Why it fails: Violates test isolation.

rehashData()

Why it fails: `rehashData()` fails this scenario because no such function exists within the Lightning Data Service API, meaning its invocation will throw a runtime JavaScript error. Developers often confuse it with standard JavaScript object manipulation methods or hashing algorithms used to validate data integrity. It would theoretically be the correct choice if a cryptographic hash or internal data structure re-indexing were required to verify payload uniqueness or map collections in custom client-side utility functions, but it plays no role in Salesforce record cache management.

force:refreshView

Why it fails: `force:refreshView` triggers a full page refresh by reloading the entire component tree and re-fetching data for all standard components, which is excessive for updating a single record cache. Developers often confuse this with targeted cache invalidation because it effectively synchronises the UI with server-side state. However, it is intended for Aura components or scenarios requiring a complete page reset rather than the granular, programmatic cache refresh provided by `refreshApex` when working with the `@wire` service in Lightning Web Components.

reloadRecord()

Why it fails: Incorrect because reloadRecord is specific to uiRecordApi functions.

Before triggers execute after custom validation rules.

Why it fails: Custom validation rules run after before triggers in the save sequence, making this timing incorrect for intercepting data early. This sequence appears plausible because administrators frequently use validation rules to enforce data integrity before database commits, leading to the assumption that declarative validation logically precedes programmatic manipulation. Such validation rules would be the correct choice if the requirement were specifically to halt invalid user input subsequent to initial field-level apex adjustments.

Before triggers execute after the record is committed to the database.

Why it fails: Before triggers run prior to the record being saved, so nothing is committed at that point; the commit occurs after validation rules and duplicate rules have passed. It is tempting because triggers do execute early in the save order, but that position is before validation, not after database commit.

Before triggers execute concurrently with custom validation rules.

Why it fails: Custom validation rules and before triggers do not evaluate simultaneously; the save order enforces a strict sequential separation where before triggers run first to sanitise field values before validation rules assess data integrity against business requirements. Concurrency would be tempting if Salesforce executed database constraints in a multi-threaded parallel processing model to reduce overall transaction time, a design pattern that would apply in high-throughput asynchronous batch processing where independent validation checks run concurrently without inter-field dependency constraints.

Executing SOQL queries inside a for loop iterating over all child records.

Why it fails: Placing a SOQL query inside a loop causes a separate database round-trip for every single iteration, which rapidly exhausts the synchronous governor limit of 100 queries. Developers are often tempted by this pattern when attempting to retrieve child records dynamically for every parent record processed in a collection. It would only be the correct choice if querying a tiny, fixed number of records outside governor limits, or when leveraging lazy loading in specific UI extensions where query counts are strictly controlled and bounded.

Calling Database.query() for every single record processed in a trigger.

Why it fails: Executing SOQL queries inside a loop or for every individual record triggers a distinct query against the database on each iteration, causing the transaction to rapidly exhaust the strict governor limit of 100 SOQL queries per transaction in bulk operations. This approach appears attractive when developers need to dynamically construct queries based on specific field values of individual records or implement polymorphic queries where filter criteria change per record. While `Database.query()` is the correct mechanism for constructing dynamic SOQL strings at runtime—such as building flexible search filters with variable user inputs—it must be supplied with a collection of values or a single aggregated string rather than being executed inside an iterative loop processing records.