CCNA Developer Fundamentals Questions

MVC divides LWC code so the model holds data and business logic, the template renders the view, and the controller handles user interaction. This separation satisfies the requirement for distinct components, improving maintainability, testability and reuse across the application.

Query optimisation through indexed fields directly addresses the requirement to prevent SOQL governor limits by drastically reducing database scan times. Standard fields like Id and Name, alongside custom indexed or external ID fields, allow the Salesforce query optimizer to bypass complete table scans and retrieve records via a B-tree lookup structure. This targeted retrieval consumes significantly fewer CPU time and database query resources, ensuring transactions execute well within strict multi-tenant resource boundaries.

`Trigger.old` is the correct context variable because it stores a collection of `Contact` sObjects representing the pre-update state of records during a DML update operation. This directly satisfies the requirement in the stem to reference old field values when executing a trigger on the `Contact` object. By providing access to the prior versions of records in bulk, it allows developers to compare previous field values against current values found in `Trigger.new` to evaluate changes before committing database transactions.

Child-to-parent queries in Salesforce Object Query Language utilise standard dot notation to traverse the data model from a child object to its related parent, successfully satisfying the requirement to identify the correct syntax for traversing relationships. By referencing the relationship name followed by the parent field (for example, `Account.Name` when querying Contacts), developers can retrieve fields from a single related parent record in a single query execution.

SOSL returns results grouped by object, so a single flat list cannot hold them. `List<List<SObject>>` preserves that per-object grouping, with each inner list holding matches for one searched object. This satisfies the stem's requirement to capture cross-object results from one SOSL query in Apex.

Custom events in Lightning Web Components are dispatched from the child component using the standard DOM `CustomEvent` API wrapped in the component's `this.dispatchEvent()` method. This fulfills the communication requirement specified in the stem—passing data upward from a child to a parent component—by bubbling the event up the DOM tree where a parent template can listen for it using an event listener directive.

addError() on an SObject instance marks that specific record as failed and blocks its DML while allowing other records in the transaction to save. This satisfies the requirement to reject only the offending record rather than throwing an exception that rolls back the entire operation.

`Schema.getGlobalDescribe()` successfully satisfies the requirement to inspect sObject field metadata dynamically by returning a map of all sObject tokens keyed by their API names across the entire organization. Developers can iterate through this dynamic map at runtime to programmatically resolve specific object types without hardcoding dependencies, which is essential for generic utility classes and managed packages that must adapt to custom customer schemas.

Using `Database.insert(records, false)` enables partial processing by passing `false` as the second parameter for the allOrNone argument. This satisfies the strict constraint that successfully processed records must be committed while failing records do not abort the entire batch. Instead of rolling back the entire transaction upon encountering a validation error, the runtime flags the specific failed records in the resulting `Database.SaveResult` array, allowing successful database operations to persist.

Salesforce Object Search Language (SOSL) satisfies the requirement to query multiple distinct objects simultaneously using the `FIND` clause to locate the exact phrase 'Acme Corp' across the specified fields of Contact, Lead, and Account records. Unlike SOQL, which is restricted to querying a single sObject at a time (unless utilizing parent-to-child relationships), SOSL is specifically engineered for text-based, multi-object searches executed against an inverted index, making it the correct architectural choice for cross-object retrieval.

Ensuring the application respects CRUD security requires developers to programmatically verify user permissions prior to executing database actions. Specifically, checking `sObject` createability via the `Schema.sObjectType.MyObject__s.isCreateable()` method satisfies the createability validation constraint for CRUD enforcement before performing an `insert` DML operation. This proactive validation prevents runtime exceptions and maintains data governance standards by stopping unauthorised record creation attempts at the application tier.

`Security.stripInaccessible()` satisfies the requirement to automatically remove fields and relationships that the current user lacks read, create, or update permissions for, without throwing an exception. By using the `AccessType` enum (such as `AccessType.READABLE`), the developer can pass lists of sObjects and have the runtime strip inaccessible fields in-place. This approach avoids explicit conditional permission checks and prevents the runtime exceptions that standard database operations or `ApexPages.addMessage()` patterns would otherwise trigger when encountering restricted data.

The built-in Apex `Location` data type directly satisfies the requirement for representing a precise geographic location with latitude and longitude coordinates. Unlike generic numeric or string variables, `Location` natively stores spatial data using compound fields, allowing developers to perform built-in distance calculations such as `EucDist` or `toMiles`. It ensures type safety and seamless integration with Salesforce geolocation fields and SOQL spatial functions like `DISTANCE()` and `GEOLOCATION()`, fulfilling the exact criteria specified in the stem.

A Map collection in Apex successfully satisfies the requirement from the stem to store elements as key-value pairs by associating unique keys with corresponding values. Unlike lists or sets that store individual items sequentially or uniquely, a Map provides a direct hashing mechanism where each distinct key maps to a single value, allowing developers to efficiently retrieve, update, or remove data using the specified key reference.

Collecting IDs from Trigger.new and issuing one SOQL query before the loop keeps the query inside governor limits regardless of the 300-record batch size. This satisfies the bulkification requirement by avoiding a query per record.

The `LIKE` operator combined with the wildcard character `%` satisfies the stem's requirement to locate accounts where the billing country field begins with a specific string. In Salesforce Object Query Language, the wildcard `%` represents zero or more characters, allowing the query engine to match any billing country value starting with the exact sequence 'United' followed by subsequent characters, such as 'United Kingdom' or 'United States'.

The `COUNT()` aggregate function evaluates the exact number of records matching the query criteria directly within the database layer, satisfying the constraint of not retrieving the records into memory. Unlike standard queries that instantiate record objects within the heap, this function returns a single integer value representing the total row count. This mechanism significantly reduces heap size consumption and prevents governor limit exceptions when developers need to verify record volumes efficiently.

`Database.update()` directly satisfies the requirement for partial success capability by accepting an optional `allOrNone` boolean parameter, which defaults to true. When explicitly set to false, this method processes records independently, allowing valid updates to commit to the database even if other records fail validation or trigger runtime exceptions. This contrasts with standard DML statements like `update`, which enforce an all-or-nothing execution model that rolls back the entire transaction upon encountering a single error.

getGlobalDescribe() returns a map of all sObject types keyed by API name, and newSObject() on the resulting token instantiates the concrete type from the string. This satisfies the stem's requirement for dynamic instantiation without hard-coded class references.

Adding `with sharing` to the Apex class definition enforces record-level security by ensuring that Salesforce applies organization-wide defaults, role hierarchies, and sharing rules during SOQL queries on custom objects. By default, Apex runs in system mode and ignores user-based sharing settings, which would bypass these constraints. Declaring the class `with sharing` forces the execution context to respect the requesting user's specific record permissions, directly satisfying the requirement to restrict data visibility according to the defined sharing model.

Salesforce Object Search Language (SOSL) is specifically designed to perform text-based searches across multiple standard and custom objects simultaneously through a single programmatic request. This capability directly satisfies the stem constraint requiring a query mechanism that can search across multiple sObjects and fields concurrently. Unlike SOQL, which retrieves records from a single object at a time using relational filters, a single SOSL `FIND` query tokenises search terms and indexes text fields across diverse, unrelated objects like Accounts, Contacts, and Leads within one execution.

Monetary amounts and calculations requiring strict precision must use the Decimal primitive data type to prevent the rounding errors inherent in binary floating-point representations. Unlike Double, which uses base-two approximation and introduces inaccuracies during arithmetic operations, Decimal operates using arbitrary-precision base-ten arithmetic. This exact decimal representation satisfies the high precision constraint specified in the stem, ensuring financial transactions and currency values calculate accurately without accumulating cumulative rounding discrepancies.

Apex classes in Salesforce DX require the `.cls` extension because the Salesforce CLI and underlying metadata API strictly enforce this suffix to identify and parse server-side controller logic during source synchronisation and deployment. This specific file extension directly satisfies the format constraint specified in the stem for source-tracked enterprise development artifacts.

The `LIMIT` clause directly satisfies the stem constraint requiring the retrieval of up to 5 records by capping the total number of search result rows returned by the SOSL query. While SOQL handles record limits natively, appending `LIMIT 5` to a SOSL query ensures that the Salesforce search engine restricts the output size across the specified objects, optimising data transfer and processing when developers only require a subset of recently viewed items.

Aggregating data across specific categories requires the `GROUP BY` clause to collapse multiple records into distinct groupings based on the specified field. In this scenario, the requirement to group opportunity amounts by their stage name directly satisfies the condition for using `GROUP BY`, as aggregate functions like `SUM()` cannot evaluate categorical fields without a designated grouping mechanism to define the summary boundaries.

Salesforce Record IDs satisfy the requirement that map keys must have a distinct hash code and support deterministic equality comparisons. Because the `Id` data type primitive is immutable, uniquely generated per record, and implements the necessary hashing algorithms natively within the Apex runtime, it functions reliably as a collection key. This ensures that lookups and insertions operate in constant time complexity without risking hash collisions or state mutations that would otherwise invalidate the map's internal index structure.

Using trigger context variables such as `Trigger.new` enables bulkified processing, which directly satisfies the requirement to prevent governor limit violations and optimise performance. Apex triggers execute once per batch of up to 200 records rather than per individual record. Accessing collections of records via these context variables ensures that SOQL queries and DML operations can be performed on entire lists simultaneously. This avoids hitting strict per-transaction limits, such as the maximum of 100 SOQL queries, regardless of whether a user updates a single record or thousands via a data load.

`public static final` satisfies both constraints: `static` binds the field to the class rather than an instance, so no object is needed, while `final` locks the value after assignment. `public` exposes it globally across the codebase. This combination is the standard Apex idiom for class-level constants.

`Trigger.old` provides a read-only list of the previous versions of sObject records, which is essential for comparing field values before a database modification occurs. This context variable is accessible exclusively during update and delete operations because these events involve existing records that possess prior state data. Consequently, this satisfies the requirement to identify valid trigger context variables, as `Trigger.old` is unavailable during insert operations where no previous record state exists to reference.

A Set is a fundamental collection type in Apex that satisfies the requirement for storing unordered, unique elements. Unlike Lists, which permit duplicate entries and maintain a specific index-based order, a Set enforces data integrity by ensuring that no two elements share the same value. This mechanism makes it the optimal choice for scenarios where you must eliminate redundancies within a dataset, providing efficient methods to verify the existence of specific items while maintaining high performance during data processing tasks.

Collecting external ID values into a Set allows for a single SOQL query executed outside the trigger loop, which directly satisfies the requirement to respect governor limits by avoiding the "too many SOQL queries" error. By mapping these retrieved records, the developer can perform constant-time lookups to validate duplicates efficiently. This approach ensures optimal performance when processing bulk data, as it minimises database round-trips and prevents the performance degradation associated with nested queries during high-volume record ingestion.

Executing nested loops over large collections of sObjects directly contributes to the synchronous Apex CPU time limit exception by exponentially increasing the number of programmatic iterations within a single transaction. As the outer loop iterates over each record, the inner loop processes the entire collection again, resulting in an algorithmic time complexity of $O(n^2)$. This heavy computational burden exhausts the strict 10-second CPU time allocation enforced by the Salesforce multi-tenant platform for synchronous executions.

Assigning a `String` value to a custom picklist field in Apex satisfies the requirement because the Salesforce Schema treats picklist values as text literals during DML operations. When instantiating a new Lead record, the developer must pass the API name of the desired picklist value as a `String` to the field variable. This mechanism ensures the platform validates the input against the defined picklist metadata, successfully setting the default value without requiring complex object mapping or external authentication protocols like Microsoft Entra ID.

The Salesforce CLI command sf apex run executes Anonymous Apex directly against an org from the terminal, supporting scripted and CI-friendly execution. This satisfies the requirement for a command-line context capable of running Anonymous Apex.

A `Set<Id>` collection inherently enforces uniqueness by design, ensuring that duplicate Account IDs cannot be stored, which satisfies the requirement to prevent duplicates automatically. Furthermore, Sets in Apex utilise a hash-based implementation, providing constant-time complexity for lookups. This mechanism allows the developer to verify the existence of an ID with exceptional efficiency, far outperforming the linear search required by a List. This makes the Set the optimal structure for managing unique identifiers when rapid retrieval is prioritised.

Exceeding a governor limit, such as the maximum number of SOQL queries allowed, triggers an unhandled exception that forces the Salesforce platform to abort the execution context. Because Apex transactions are atomic, the platform automatically rolls back all database changes performed during the request to maintain data integrity. This mechanism ensures that partial updates do not persist when a runtime governor limit is breached, satisfying the requirement for an automatic rollback within the transaction lifecycle.

`JSON.deserialize` accepts a target type as its second argument, allowing the developer to map a JSON string directly into a strongly-typed Apex collection. By passing `List<Account>.class`, the method instructs the serialisation engine to instantiate the appropriate list structure and populate it with Account objects. This mechanism satisfies the requirement to convert a raw string into a functional Apex List, ensuring type safety and immediate access to object fields without manual parsing or complex type casting.

The `containsKey()` method provides a boolean check against the map’s internal hash structure, returning true if the specified key is present. This mechanism directly satisfies the requirement to verify the existence of a key before retrieval, which prevents the developer from inadvertently triggering a null pointer exception or receiving an unexpected null value when accessing the map. By confirming the key's presence first, the code ensures robust data handling and avoids runtime errors during the subsequent value lookup process.

`Schema.DescribeFieldResult` provides the `isAccessible()` method, which directly evaluates the current user's field-level security permissions for a specific custom field. By invoking this method before rendering data in a Lightning Web Component, developers ensure that the application adheres to the principle of least privilege. This approach satisfies the requirement to verify read access programmatically, preventing unauthorised data exposure that could occur if the component relied solely on UI-level visibility without backend validation.

The Log Inspector provides a dedicated interface within the Developer Console specifically designed to parse and visualise complex debug logs. By offering granular controls for filtering entries based on both event categories and severity levels, it directly satisfies the requirement to inspect and refine log data. This tool enables developers to isolate specific execution paths efficiently, ensuring that they can practise effective debugging by stripping away irrelevant system noise to focus solely on the pertinent diagnostic information required for troubleshooting.

Salesforce enforces a strict governor limit of 100 SOQL queries per synchronous Apex transaction to ensure multi-tenant resource fairness. This constraint prevents any single process from monopolising database resources, which would otherwise degrade performance for other organisations sharing the same infrastructure. By restricting the total number of queries, the platform maintains consistent execution times and system stability. Developers must therefore optimise their code to batch data retrieval or utilise collections to remain within this defined threshold during their application logic.

`Database.setSavepoint()` creates a specific point in the database transaction, allowing a developer to revert partial DML operations if a subsequent error occurs. By invoking this method, the system captures the current state of the database, satisfying the requirement to establish a rollback point. When an exception arises, `Database.rollback(sp)` can be called to undo all changes made after the savepoint was defined, ensuring data integrity within the Apex trigger execution context without impacting the entire transaction.

A static Boolean variable in a handler class persists for the duration of the transaction and can be used to prevent recursive trigger execution. The trigger checks the variable before performing updates and sets it to true after the first run. This is a common and effective pattern to avoid recursion in bulk updates.

Integer.valueOf() converts a String containing a numeric value into an Integer primitive in Apex, throwing a TypeException if the string is not a valid number. This directly satisfies the requirement to convert a numeric String into an Integer.

Apex List exposes size(), returning the number of elements as an Integer. Unlike arrays in some languages, Apex collections provide no length property, so size() is the method satisfying the stem's requirement for counting elements.

Apex natively supports the Integer data type, which satisfies the requirement to identify a primitive data type within the language. This 32-bit signed value is a fundamental building block used to store whole numbers without decimal points, distinguishing it from complex objects or collections. By providing direct support for this primitive, the platform ensures developers can perform arithmetic operations and manage numeric state efficiently within their code, adhering to the strict typing constraints defined by the Apex runtime environment.

Salesforce Object Search Language (SOSL) natively enables text-based searches across multiple standard and custom objects simultaneously via a single programmatic request, satisfying the stem's requirement to query multiple objects concurrently. Unlike SOQL (Salesforce Object Query Language), which is inherently relational and restricted to querying a single sObject and its direct children per execution (unless joined via parent-to-child relationships), SOSL is specifically engineered for full-text indexing retrieval. By leveraging an underlying inverted index, it efficiently tokenises search terms and scans multiple disparate object definitions in one operation.

A public class exposing a static method that takes and returns a List<Opportunity> is callable from a trigger, an Apex controller, a batch class, or a queueable. This keeps the discount rule in one place, avoids duplication, and makes the logic unit-testable without firing DML, which aligns with the separation-of-concerns guidance for Apex.

Apex provides the `Map` class as a core collection interface, fulfilling the requirement to identify native collection types alongside lists and sets. A map stores data as key-value pairs, allowing developers to efficiently retrieve, update, or remove unique elements based on a distinct key rather than an integer index. This collection type is fundamental for handling relational Salesforce data, especially when caching query results or deduplicating records by a specific field value such as an ID or external identifier.

A Map in Apex directly satisfies the requirement to store elements as unique key-value pairs, where every distinct key maps precisely to a single value. This collection type provides rapid data retrieval by hashing keys, allowing developers to efficiently look up, update, or remove associated values without iterating through the entire collection. Its underlying architecture enforces uniqueness upon the keys, making it the definitive choice for scenarios that demand fast, relational data access based on specific identifiers.

Grouping a list of Case records by their AccountId requires mapping each unique parent identifier to multiple child records, perfectly satisfying the requirement to handle potential one-to-many relationships where multiple cases share the same account. Using a `Map<Id, List<Case>>` allows the developer to use the AccountId as the key, ensuring rapid O(1) lookups, while storing a `List<Case>` as the value to dynamically collect all associated records without data loss or overwriting during iteration.

Apex classes running on the server alongside Salesforce database objects directly satisfy the requirement to represent the data model and business logic layer within the MVC architecture. While client-side JavaScript controllers manage the presentation logic and user interface interactions, the combination of Apex and underlying database objects handles persistent data storage, SOQL queries, transactions, and complex server-side execution, fulfilling the precise functional boundaries of the model and logic tier.

Each loop iteration issues a separate SOQL call, so 200 Accounts consume 200 queries against the synchronous limit of 100. The constraint breached is the total SOQL query count, not rows returned. Bulkifying with a single WHERE Id IN :accountIds query avoids this.

`Trigger.isInsert` and `Trigger.isUpdate` are context variables provided by the Salesforce execution context, allowing an Apex class called from a trigger to precisely differentiate between operation types. Because the stem requires determining whether the invocation stemmed from an insert or update context, evaluating these boolean properties directly satisfies the requirement without needing custom parameter passing or workarounds.

Classes declared with `inherited sharing` adopt the sharing context of the class that invokes them. When called from a class defined with `with sharing`, the method executes in an enforced sharing context, thereby satisfying the calling class's restriction. This keyword ensures that the code maintains the security posture of its parent context if no explicit sharing declaration is provided on the class itself.

Binding a collection variable directly within a SOQL query using the colon syntax successfully satisfies the requirement to filter Account records against a list of strings called 'targetNames'. Apex run-time evaluates the `:` prefix as a bind variable, automatically serialising the entire collection into a comma-separated list enclosed in parentheses. This mechanism prevents SOQL injection vulnerabilities while efficiently handling multiple string criteria within the `IN` operator, avoiding the need for manual string concatenation or iterative query construction.

An `after` trigger executes subsequent to database operations committing records, which directly satisfies one of the two core trigger timing types requested in the stem. During this execution phase, record IDs are fully generated and system-generated fields are populated, allowing developers to access read-only record contexts and reliably perform related-record manipulations or cross-object operations on parent and child objects within the same transactional boundary.

`Database.setSavepoint()` captures the current state of an Apex transaction and explicitly returns a `Savepoint` object reference. This returned reference is a mandatory parameter for subsequent rollback operations using `Database.rollback()`, satisfying the core requirement of transaction control where developers must manage and revert partial DML failures within a single execution context. Storing this object reference allows code to safely target and restore the exact database state established at the moment the savepoint was initially invoked.

The `FORMAT()` keyword in SOQL applies locale-specific formatting directly to number, date, time, and currency fields within the query result set. This satisfies the requirement stated in the question stem by leveraging the running user's personal locale settings—such as specific date structures and currency symbols—without requiring developers to manually parse and transform raw database values in Apex code.

Moving the query outside the loop replaces 200 per-parent SOQL calls with one bulk query, satisfying the total SOQL governor limit. Gathering IDs into a Set and filtering with IN preserves correctness while issuing a single query.

Boolean is a fundamental primitive data type natively supported in Apex, directly satisfying the stem's constraint to select a primitive data type. In Apex, primitive types are passed by value and represent single, indivisible values rather than complex database objects or sObjects. The Boolean type specifically holds a truth value of true, false, or null, making it one of the foundational building blocks alongside other primitives like Integer, Double, and String for basic variable declarations and logical evaluations within developer code.

@TestSetup runs once before all test methods in the class, creating shared Account records that every method reuses. This satisfies the stem's efficiency and hardcoded-ID-avoidance constraints, since data is inserted via normal DML rather than fixed record IDs.

Applying the `@AuraEnabled` annotation to a custom Apex method explicitly exposes it to the Lightning Component framework, satisfying the security and accessibility requirement needed for a Lightning Web Component to invoke server-side logic. Without this annotation, the controller method remains hidden from client-side JavaScript execution in the Salesforce platform, preventing unauthorised or accidental remote calls. Additionally, setting `@AuraEnabled(cacheable=true)` allows read-only methods to cache data on the client side, optimising performance when fetching records from the database.

The `Object` data type in Apex is the universal base type capable of implicitly casting to and from any primitive data type, sObject, or collection. This satisfies the strict architectural constraint in the stem requiring a single dynamic variable type to store heterogeneous payloads without prior type casting. Unlike strongly typed declarations or generic wrappers, `Object` variables evaluate their runtime type dynamically, allowing developers to write flexible logging routines that accept arbitrary data structures at execution time.

Set stores only unique elements and provides constant-time contains() lookups via hashing, so duplicate emails collapse automatically and existence checks avoid scanning. This satisfies the uniqueness and efficient existence-checking constraints, which List and Map do not address as directly.

Traversing the sObject schema hierarchy via `Schema.sObjectType.Account.fields.AnnualRevenue.getDescribe()` accesses the field-level metadata natively within Apex. Calling the `.isAccessible()` method on this description object evaluates the running user's runtime field-level security permissions, satisfying the stem's requirement to check read access on the 'AnnualRevenue' field prior to executing the calculation.

`Security.stripInaccessible()` directly satisfies the requirement to enforce object- and field-level security (FLS) dynamically in Apex by automatically stripping inaccessible fields and sObjects from query and subquery results, or before performing DML operations like upserts. By inspecting the running user's permissions against the schema at runtime, this built-in method prevents unauthorised data exposure and insecure mutations without throwing exceptions, making it an essential tool for secure coding practices regarding CRUD and FLS compliance.

`Trigger.new` directly satisfies the requirement specified in the stem by returning a collection of sObject records that represent the updated or newly created versions of the records in question. This context variable provides in-memory access to the incoming records during before and after insert, update, and undelete trigger executions, allowing developers to inspect and manipulate field values prior to database operations or subsequent execution logic.

Using `Database.update(opps, false)` returns a collection of `Database.SaveResult` objects that correspond directly to the input records. To handle failures properly during bulk processing, the developer must iterate through this returned list and invoke the `isSuccess()` method on each instance. This satisfies the requirement to inspect partial success results without causing unhandled exceptions, allowing the code to isolate and log specific error messages using `getErrors()` for any failed records.

Using bind variables satisfies the constraint of executing a SOQL query using user-supplied search parameters securely. When developers integrate dynamic user input via string concatenation, malicious actors can manipulate the query logic. By substituting string concatenation with bind variables (using the colon syntax, such as `:userInput`), the Salesforce platform treats the input strictly as a literal value rather than executable query syntax. This completely neutralises SOQL injection attempts, ensuring the query structure remains unaltered regardless of the input's content.

`Database.query()` accepts a string variable as its sole argument, allowing developers to construct SOQL statements dynamically by concatenating object names and field identifiers at runtime. This capability directly satisfies the requirement to handle variable schema elements that are unknown during compilation. Unlike static SOQL, which requires hard-coded object and field references, this method processes the query string during execution, providing the necessary flexibility to adapt to changing runtime parameters while maintaining full integration with the Salesforce database engine.

The Datetime data type serves as the standard Apex primitive for capturing both calendar dates and clock times within a single variable. By storing values as Coordinated Universal Time (UTC) milliseconds, it satisfies the stem’s requirement for a specific point in time. Unlike the Date type, which lacks temporal precision, Datetime provides the necessary granularity to track events or timestamps accurately, ensuring developers can perform precise arithmetic and comparisons across different time zones when integrating with systems like Microsoft Entra ID.

Apex maps expose a values() method returning a collection of the map's values, which is iterable with the enhanced for-loop. Since the map is keyed by ID with Account sObjects as values, iterating values() yields each Account directly, matching the required processing.

A `Set<String>` automatically enforces uniqueness by preventing duplicate entries, which directly satisfies the requirement for storing unique email addresses. Internally, Apex sets utilise a hash table implementation to ensure that lookups, additions, and removals occur in constant time, $O(1)$, on average. This high-performance mechanism provides the fast lookup times necessary for efficient data retrieval within an Apex method, making it the optimal choice for managing collections where uniqueness and rapid access are the primary technical constraints.

Including the ALL ROWS clause in a SOQL query explicitly instructs the database engine to bypass the default filter that excludes soft-deleted records. By satisfying the requirement to retrieve data currently residing in the Recycle Bin, this keyword extends the query scope beyond active records. This mechanism is essential for auditing or recovering information that has not yet been permanently purged from the system, ensuring the developer can access the complete dataset regardless of its current lifecycle state within the platform.