Developer Fundamentals practice questions

SELECT Id, Name, CONCAT(Contacts) FROM Account

Why it fails: `CONCAT()` is a string function in SOQL used to concatenate field values into a single string, which tempts developers familiar with SQL string aggregation or formula fields. However, it fails because it cannot traverse parent-to-child relationships to retrieve related child records as an object list. To fetch Accounts alongside their associated Contacts in a single query, you must instead use a subquery syntax such as `SELECT Id, Name, (SELECT Id, LastName FROM Contacts) FROM Account`.

SELECT Id, Name, (SELECT Id, LastName FROM Contact) FROM Account

Why it fails: Using the singular relationship name `Contact` fails because Salesforce child-to-parent subqueries in SOQL require the plural relationship name, which defaults to `Contacts`. This syntax is tempting because it resembles standard object-oriented dot-notation or general SQL subqueries where the target table name is singular, making it a logical guess for developers querying child records. It would be correct if the child relationship on the Account object had been custom-named as a singular noun, or when querying a parent field from a child object.

SELECT Id, Name, Contacts__r FROM Account

Why it fails: Child-to-parent relationships in SOQL require traversing standard relationship names or custom relationship names ending in `__r` in the reverse direction, but querying contacts from an account requires a parent-to-child subquery enclosed in parentheses. This syntax is tempting because it resembles a standard child-to-parent traversal, such as retrieving an Account's related Parent Account using a custom relationship field like `Parent__c`. However, that specific dot-notation traversal syntax is exclusively designed for querying parent records from a child context, rather than nesting child records within a parent query.

Access standard relationship fields directly without querying if the records are in Trigger.new.

Why it fails: Standard relationship fields on newly inserted `Contact` records only populate parent fields like `AccountId`, but do not automatically populate grandparent fields or aggregated child records from the related `Account` object in memory. Developers often attempt this approach because accessing fields directly via dot notation avoids hitting SOQL query limits entirely when reading simple standard relationships. This technique successfully retrieves standard parent fields directly from `Trigger.new` without a database query, but fails here because the scenario explicitly requires querying related `Account` records, which necessitates an explicit SOQL query to fetch fields beyond what `Trigger.new` holds.

Loop through each Contact and issue a separate SOQL query for its Account.

Why it fails: Issuing a separate SOQL query inside a loop for each newly inserted record directly violates governor limits by exceeding the maximum limit of 100 queries per transaction when processing bulk data loads. This approach often seems tempting because individual record-by-record iteration feels intuitive for developers accustomed to procedural languages, and it would be the correct choice if you were intentionally processing a single, isolated record outside of a bulkified trigger context where query limits are not a concern.

Use the Database.getQueryLocator method with Trigger.new.

Why it fails: `Database.getQueryLocator` is designed exclusively to supply batch record scopes to Batch Apex jobs by accepting a SOQL query string rather than runtime collection bindings like `Trigger.new`. Developers are often tempted to use it when dealing with large volumes of trigger data because of its association with batch processing and heap-saving chunks. However, passing a trigger's context variable directly into a query locator fails because it does not support dynamic collection filtering, making it entirely useless for querying related records based on an in-memory trigger execution context.

merge()

Why it fails: `merge()` does not exist as a method for the Apex `Set` class, meaning it cannot perform a union operation between two sets. Developers often confuse this with the `merge` statement in DML, which is designed to combine two sObject records into one by deleting the duplicate and updating the surviving record. While the term implies combining data, it is strictly reserved for record-level deduplication within the database layer rather than managing collections in memory.

combine()

Why it fails: Apex Sets expose no combine() method; the platform provides addAll() for merging one Set's elements into another. The name misleads because combining collections is a common operation in other languages and libraries, so it feels like the natural API. combine() would be the right call only where a framework actually defines it for that collection type.

putAll()

Why it fails: The `putAll()` method operates exclusively on the `Map` collection type to merge key-value pairs from one map into another, rather than performing set union operations. Developers often mistake this for a generic collection utility because of its similar naming convention to `addAll()`, which is the actual method designed to perform a union of two `Set` instances. Consequently, `putAll()` fails to compile when invoked on a `Set` object, as the method signature does not exist for that data structure.

static readonly Integer MAX_COUNT = 10;

Why it fails: Apex does not support the `readonly` keyword for declaring constants, meaning this syntax will cause a compilation error. Developers migrating from languages like C# often find this syntax tempting because `readonly` is standard there for assigning immutable field values at runtime or during construction. In Apex, however, immutability and compile-time constants are instead enforced using the `final` keyword alongside `static`, ensuring the value cannot be modified after initialisation.

immutable Integer MAX_COUNT = 10;

Why it fails: Apex does not recognise the `immutable` keyword for variable declarations, leading to a compilation error when attempting to define constants this way. This syntax closely resembles access modifiers or immutability keywords found in other programming languages where developers explicitly mark state as read-only. Such a keyword would logically be utilised when creating globally shared application limits or fixed thresholds that must never be altered during runtime execution, making it a natural guess for those familiar with strict object-oriented paradigms.

const Integer MAX_COUNT = 10;

Why it fails: This option fails because Apex does not recognise the `const` keyword for declaring immutable variables; instead, Apex relies on the `final` modifier coupled with static context. Developers frequently attempt to use `const` due to its ubiquity across programming languages like JavaScript, TypeScript, C#, and Java, where `const` or `final` establishes compile-time constants. In those environments, `const` prevents reassignment and designates literal values for broader reuse, but in Apex, immutability is strictly enforced using `static final Integer MAX_COUNT = 10;`.

LIMIT 20 OFFSET 10

Why it fails: This configuration retrieves only 10 records after skipping the initial 10, thus returning records 11 through 20 rather than the required 21st through 30th. It looks plausible because `OFFSET` shifts the starting point for pagination, making it the correct choice when attempting to fetch the second page of a dataset where each page contains 10 records.

RANGE 20 TO 30

Why it fails: Standard SOQL syntax does not support a RANGE clause to specify absolute row numbers for query results, making this completely invalid in any Salesforce context. This syntax is common in other programming languages or database systems like SQL for limiting result sets by offset boundaries, which makes it feel intuitively correct for implementing pagination. However, developers must instead use the LIMIT and OFFSET keywords in Salesforce to achieve the same result.

SKIP 20 TAKE 10

Why it fails: Although `SKIP` is commonly used in other database query languages to bypass a specific number of rows for pagination, standard SOQL does not support a `SKIP` clause. This option is tempting because developers familiar with SQL often look for a direct equivalent to offset query results. In Salesforce, pagination from a specific starting point requires the `OFFSET` clause combined with `LIMIT` (such as `OFFSET 20 LIMIT 10`), rendering this syntax invalid and causing a compilation error.

webservice class without sharing

Why it fails: Declaring a class with the `webservice` keyword defines an obsolete SOAP web service rather than a modern REST service, rendering it completely incompatible with the required Apex REST architecture. Furthermore, omitting `with sharing` causes the class to run in system mode, ignoring the calling user's record-level security permissions. This modifier is typically used to expose legacy SOAP endpoints or integrations where bypassing sharing rules is explicitly intended, allowing developers to execute bulk operations without restriction when called by authorised external SOAP clients.

public class with sharing

Why it fails: REST services must be declared as global, not public.

private class inherited sharing

Why it fails: Restricting class visibility to `private` prevents external systems from invoking the Apex REST service entirely, as Salesforce web services require global visibility to expose endpoints via URLs. The `inherited sharing` keyword is tempting because it correctly respects the sharing rules of the calling context when executed, making it appropriate for standard utility classes or internal controllers that need to adapt to the calling user's security posture. However, because the class is marked `private`, the platform cannot route incoming REST requests to the method.

AccountTasks

Why it fails: AccountTasks is tempting because it follows the standard developer convention of appending the child object name to the parent object to form a custom relationship suffix. However, it fails because Salesforce assigns predefined standard relationship names to native objects rather than accepting custom suffixes constructed by the developer. This specific value would only be valid if a custom relationship had been explicitly defined on a custom object with that exact naming convention, whereas standard objects like Account use platform-defined names such as `OpenActivities` or `ActivityHistories` for querying tasks.

ActivityHistories

Why it fails: *ActivityHistories* represents closed activities and archived historical data rather than the complete, active set of open and closed Task records required by standard parent-to-child queries. It is tempting because it is a standard related list on the Account object that contains Task records, making it a natural guess when looking for historical interactions. This option would be correct if the developer specifically needed to query only completed tasks and closed events associated with the account, rather than the entire collection of related Task records.

ChildTasks

Why it fails: ChildTasks sounds plausible because it follows standard developer naming conventions for custom relationship suffixes, yet Salesforce actually exposes standard activity histories under a different nomenclature. This naming structure would only apply if you had explicitly defined a custom relationship on the Account object targeting a custom object named ChildTask. For standard Task relationships queried via SOQL, the platform strictly mandates the use of OpenActivities and ActivityHistories depending on whether you query open tasks or closed task records.

Trigger.isChanged('Discount_Percent__c')

Why it fails: This syntax fails because `isChanged()` does not exist as a built-in method on the `Trigger` context variable in Apex, meaning this code will cause a compilation error rather than evaluating field changes. Developers often attempt to use this syntax because it resembles conditional validation functions found in other frameworks or process automation tools, where it would normally serve to evaluate whether a specific field value has been modified during a record update transaction. To achieve this functionality natively in Apex, a developer must instead compare the old and new field values by referencing `Trigger.oldMap` and `Trigger.newMap`.

Trigger.new[i].Discount_Percent__c != Trigger.old[i].Discount_Percent__c

Why it fails: Trigger.old is a list, not guaranteed to be indexed identically to Trigger.new without using oldMap.

Trigger.new[i].Is_Modified__c == true

Why it fails: Is_Modified__c is a user-defined custom field, not a system flag; it holds whatever value was last saved and never reflects whether Discount_Percent__c changed in this transaction. The tempting pattern is a boolean sentinel field, which would be the right approach only if a workflow or Flow actually set it on update.

Trigger.oldMap

Why it fails: `Trigger.oldMap` is unavailable because records do not possess database IDs or prior state prior to their initial creation. This variable is tempting because developers frequently need to compare previous and current field values to detect changes or enforce validation rules, which makes it the correct choice in `BEFORE UPDATE` or `AFTER UPDATE` contexts where existing records are being modified rather than newly instantiated.

Trigger.old

Why it fails: Records undergoing insertion do not possess any prior state in the database, meaning `Trigger.old` evaluates to null in any `before insert` context. Developers often reach for this variable when attempting to reference existing field values to validate modifications or track historical changes. Consequently, this context variable becomes relevant only during `before update`, `after update`, and `after delete` operations, where prior database records already exist to populate the collection.

Trigger.operationType

Why it fails: While System.TriggerOperation exists, operationType as a direct context variable list is not standard terminology compared to new and newMap.

Trigger.newMap

Why it fails: Trigger.newMap holds IDs mapped to the new records being inserted.

Profiles and Permission Sets

Why it fails: Profiles and Permission Sets control user licensing, field-level security, and system permissions rather than enforcing record-level sharing rules defined in the organisation. This option is tempting because developers frequently rely on declarative security models to restrict data access, and such tools would be the correct choice when managing user-level feature licenses and object permissions across a broader administrative context.

Field-Level Security

Why it fails: The 'with sharing' keyword enforces record-level sharing rules only; it does not enforce field-level security, which requires WITH SECURITY_ENFORCED, stripInaccessible, or explicit describe checks. It is tempting because sharing and FLS are both access controls, but they operate on different axes: records versus fields.

Execute a separate SOQL query for every child record individually.

Why it fails: Executing individual queries within a loop triggers the SOQL query governor limit of 100 per transaction, causing runtime exceptions when processing large datasets. Developers often gravitate towards this approach when isolating specific records for granular logic or to circumvent complex join limitations in legacy systems. While this granularity provides precise control over individual record retrieval, it fails to utilise relationship queries or bulkification patterns, which are essential for maintaining performance within the multi-tenant architecture of the Salesforce platform.

Always use SELECT FIELDS(ALL) to ensure all data is retrieved.

Why it fails: SELECT FIELDS(ALL) retrieves every field, inflating query rows and heap consumption, and it demands a LIMIT clause, so it accelerates limit breaches. It suits ad-hoc exploration where all columns are genuinely needed. Avoiding limits means selecting only required fields and filtering with WHERE and LIMIT.

Integer variables default to 1 if unassigned.

Why it fails: Apex primitives, including the Integer type, initialise to null rather than 1 when declared without an explicit value. This statement is tempting because it mirrors the default behaviour found in certain other programming languages or database schemas where a default value of one is enforced for counter-based logic. Developers transitioning from environments that automatically assign non-null defaults to numeric types often assume this behaviour persists in Apex, yet the platform strictly adheres to a null-initialisation standard for all unassigned member variables.

Apex supports dynamic duck typing without variable declarations.

Why it fails: Apex is a strictly typed language that mandates explicit variable declarations, meaning it rejects the implicit dynamic typing found in languages like Python or JavaScript. This option is tempting because developers often utilise dynamic typing when working with loosely structured JSON data or generic object maps where the schema is unknown at compile time. In such scenarios, developers might use the `Object` type or `Map<String, Object>` to simulate flexible behaviour, yet they must still declare these variables explicitly within the code.

Boolean variables default to true if unassigned.

Why it fails: Boolean variables in Apex initialise to null rather than true, meaning this statement fails because it misrepresents the default state of unassigned primitives. Developers often confuse this with the behaviour of certain configuration settings or specific logical flags in other programming environments where a default truthy value is assumed. This option appears attractive because programmers frequently implement custom logic to initialise flags as true to satisfy specific business requirements, yet Apex enforces a null default to ensure developers explicitly define the initial state.

Set<String> s = new Set<String>('A', 'B');

Why it fails: Apex Set constructors do not accept individual elements as comma-separated arguments, causing this syntax to fail compilation. Developers often confuse this with the List constructor or the overloaded Set constructor that accepts a List or Set as an argument. This syntax would only be valid if the developer intended to pass an existing collection into the constructor to initialise the new Set with those pre-existing values, rather than attempting to define the initial elements directly as discrete parameters.

Set<String> s = Set.valueOf('A,B');

Why it fails: `Set.valueOf()` does not exist in Apex, as the `valueOf` method is exclusively reserved for converting strings into primitive types like `Integer` or `Boolean` or for parsing `Enum` values. Developers often confuse this with the `String.split()` method or the `Set` constructor that accepts a `List`. While developers might attempt this syntax to quickly initialise a collection from a delimited string, the method signature is incompatible with the `Set` class, which requires explicit instantiation via the `new` keyword and a constructor argument.

Set<String> s = ['A', 'B'];

Why it fails: Square brackets are reserved for SOQL queries and list inline notation in specific older contexts, not direct set assignment like this.

SELECT Id, (SELECT Id FROM Contact__r) FROM Account

Why it fails: Using the `Contact__r` suffix fails because custom relationships employ the double-underscore-r naming convention, whereas standard relationships like Account-to-Contact require the pluralised standard child relationship name, which is `Contacts`. This option is tempting because developers frequently use the `__r` suffix for custom relationship queries in SOQL, and it would be the correct syntax if you were querying child records from a custom parent-to-child relationship created on an object.

SELECT Id, (SELECT Id FROM Account.Contacts) FROM Account

Why it fails: Attempting to traverse a subquery using the parent object name prefix (`Account.Contacts`) is invalid because SOQL subqueries operate directly on the child relationship name rather than dot-notation. This syntax appears tempting because dot-notation is standard for querying parent fields from a child object, such as `SELECT Account.Name FROM Contact`, making it intuitive to assume the reverse works symmetrically. However, inner queries require the pluralised relationship name—`Contacts`—used standalone inside the parentheses.

SELECT Id, (SELECT Id FROM Contact) FROM Account

Why it fails: This query fails because it uses the singular object name `Contact` in the subquery rather than the plural child relationship name `Contacts`, which is required for standard parent-to-child queries in Salesforce. Developers often find this tempting because querying a single related object or parent-to-child field path typically uses the singular relationship name, such as `Account.Name`. Consequently, using `SELECT Id FROM Contact` would be the correct syntax if you were querying the Contact object directly at the root level rather than traversing the child relationship from Account.

public system mode class MyClass

Why it fails: Apex does not support a `system mode` keyword modifier in class declarations, making this syntax invalid and resulting in a compilation error. Developers often confuse this with the upcoming context modifier syntax or the `without sharing` declaration. While `without sharing` disables sharing rule enforcement while respecting object and field-level permissions, declaring a class in true system mode requires using `with sharing` or `without sharing` combined with specific programmatic checks, or executing logic inside an inner class or interface that inherits the appropriate context from the calling stack.

public without sharing class MyClass

Why it fails: Declaring a class with `without sharing` runs the code in system mode while explicitly disabling sharing rules, which directly violates the requirement to enforce organisation-wide sharing rules. This keyword is tempting because developers frequently use it when they need to bypass user-level object permissions and field-level security via system mode, but it would be the correct choice only in scenarios where both sharing rules and permission checks must be simultaneously ignored to allow users to process records they do not strictly own.

public inherited sharing class MyClass

Why it fails: `inherited sharing` evaluates sharing rules based on the calling context rather than enforcing system mode or ignoring field-level permissions, meaning it fails to enforce the required system mode behaviour. This keyword is tempting because developers often use it to preserve the sharing context of whichever class invokes the current logic. It is the correct choice when a utility or superclass needs to seamlessly adopt the sharing rules of whichever parent class or trigger executed it, ensuring consistent behaviour across various transaction paths.

acctList.save()

Why it fails: Standard DML operations and standard list methods in Apex do not provide a built-in method named `save()`, rendering this syntax entirely invalid for database interactions. Developers often confuse this with standard DML syntax or custom persistence frameworks from other programming languages where `.save()` acts as the primary commit mechanism. In Salesforce, record persistence is achieved exclusively through DML statements such as `insert` and `update`, or Database class methods like `Database.update()`, making this non-existent method incorrect for committing Account updates to the database.

Database.update(acctList, false)

Why it fails: Passing false for the allOrNone parameter enables partial success, allowing valid records to commit even if others fail.

update acctList;

Why it fails: Standard DML operations like `update acctList;` execute as an all-or-nothing transaction by default. If any single record in the collection encounters a validation rule failure or database constraint violation, the entire runtime transaction rolls back completely, preventing any partial updates. This directly satisfies the stem requirement that none of the records are committed if any individual record fails validation, unlike database methods with `allOrFalse` set to false which permit partial success.

200

Why it fails: Two hundred is the asynchronous Apex SOQL query limit, not the synchronous cap. Synchronous transactions allow 100 SOQL queries; the higher asynchronous allowance tempts candidates who conflate the two governor limits. 200 would be correct when reasoning about batch or future methods running asynchronously.

50000

Why it fails: 50,000 represents the maximum number of record rows that can be retrieved in a single SOQL query execution, rather than the governor limit for the total count of query statements issued. This value is tempting because it is a prominent governor limit threshold within Salesforce development, specifically governing data volume retrieval per individual query command rather than the cumulative transaction-level count of 100 synchronous queries.

50

Why it fails: 50 is lower than the actual synchronous SOQL query limit.

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.

Hierarchical Relationship

Why it fails: Hierarchical relationships exist exclusively on the User object to facilitate reporting structures, meaning they cannot link two arbitrary custom or standard objects to form a many-to-many association. This option appears attractive because it involves a lookup field, which developers often associate with connecting records. However, it serves solely to establish management chains within an organisation, whereas a many-to-many relationship requires a junction object containing two master-detail or lookup fields to bridge distinct entities.

Lookup Relationship

Why it fails: Lookup relationships fail to facilitate many-to-many modelling because they lack the structural capability to associate a single child record with multiple parent records simultaneously. While they are frequently utilised to establish loose associations where child records exist independently of their parents, they only support a one-to-many architecture. Developers choose lookups when they require optional relationships that do not enforce cascading record deletion or specific security inheritance, which is common when linking standard objects like Accounts to custom objects.

External Relationship

Why it fails: External relationships are for linking Salesforce records to external data sources, not for junction objects. The name tempts because many-to-many sounds like it spans systems, but junction objects require two master-detail relationships, which is the actual mechanism enabling the many-to-many model.

User.hasPermission('Opportunity', 'Delete')

Why it fails: The `User.hasPermission` method does not exist within the Apex `User` class, making this syntax invalid for checking object-level security. Developers often confuse this with the `UserPermission` object or custom permission checks used to verify specific assigned features or access rights. While custom permissions are useful for validating granular functional access within an application, they cannot evaluate standard CRUD permissions on objects like Opportunity, which requires the `Schema.DescribeSObjectResult.isDeletable()` method to ensure the current user possesses the necessary deletion authority.

System.hasDeleteAccess(Opportunity.class)

Why it fails: System.hasDeleteAccess does not exist; record-level access uses UserRecordAccess with SOQL.

Opportunity.sObjectType.getDescribe().isDeletable()

Why it fails: Opportunity.sObjectType.getDescribe().isDeletable() reports whether the running user's profile or permission sets grant delete access to the Opportunity object itself, but it ignores record-level sharing, so a user with object-level delete still fails on records they cannot access. It is tempting because it correctly answers object-level CRUD checks in triggers or Visualforce controllers.