Summary
This scenario involves two distinct operations: creating a new Contact record and then updating the Account's "Primary Contact" lookup field to point to this new record. A standard field mapping in a DataRaptor Load can create the Contact, but a special type of mapping is required to populate a lookup field on one object (Account) with the Id of a newly created record from a different object (Contact) within the same transaction.

Correct Option

B. Linked Mapping
This is the correct and specific feature for this requirement. A Linked Mapping in a DataRaptor Load allows you to create or update a related record in one object and then use the system-generated ID (e.g., the new Contact's Id) to populate a lookup field on the primary object being saved (e.g., the Primary_Contact__c field on the Account). It creates a data link between the two operations within the same DataRaptor execution.

Incorrect Option

A. Relationship Query
This term is associated with DataRaptor Extracts, not Loads. It is used to traverse and retrieve data from related objects (like a SOQL parent-child subquery), not to create records and establish lookup relationships during a save operation.

C. Lookup Mapping
A Lookup Mapping is used to populate a lookup field by searching for an existing record in another object based on a matching value (e.g., finding an existing Contact by email and setting the Account's Primary Contact to that found Id). It is not designed to use the Id of a record that is being created within the same DataRaptor execution.

D. Lookup Key
A Lookup Key is the specific field used in a Lookup Mapping to find the existing related record (e.g., Email or External_Id__c). It is a component of the Lookup Mapping process but is not the overarching feature that handles creating a new record and then using its Id.

Reference
Salesforce OmniStudio Developer Guide: Linked Mapping in DataRaptor Load

Summary
Retrieving data from a Salesforce object involves querying and reading records. In OmniStudio, specific tools are designed for this purpose. The correct options will be components whose primary function is to fetch data from the database and make it available within the OmniScript or Integration Procedure, as opposed to components designed for writing data or capturing user input.

Correct Option

B. A DataRaptor Extract Action
This is a primary tool for data retrieval. A DataRaptor Extract is explicitly designed to read data from one or more Salesforce objects. It can be configured with SOQL-like filters and relationships to return specific sets of data, which can then be used to populate an OmniScript or be processed within an Integration Procedure.

C. A Lookup Input Element
The Lookup element serves a dual purpose. While it provides a user interface to search for a record, it also automatically retrieves and pre-fills data from the selected record into other fields on the OmniScript. This inherently involves querying and reading data from a Salesforce object based on the user's selection.

Incorrect Option

A. A DataRaptor Load Action
A DataRaptor Load Action is used for writing data to the database. Its purpose is to create, update, or upsert records in a Salesforce object. It does not retrieve data for use in the application; it persists data from the application to the database.

D. A DataRaptor Post Action
This is not a standard OmniStudio action type. "DataRaptor Post" is likely a distractor and is not a recognized category. DataRaptors are categorized as Extract, Transform, or Load. There is no "Post" type, and if it refers to anything, it would be synonymous with a Load action, which is for data creation/update, not retrieval.

Reference
Salesforce OmniStudio Developer Guide: DataRaptor Extract

Summary
The requirement is to retrieve a field (Name) from a parent object (Account) for a starting record (Contact). In a DataRaptor, this is accomplished by leveraging a lookup relationship. The correct approach is to define the extraction starting from the source object (Contact) and then use a JSON Path that traverses the relationship field (Account) to the target field (Name), without needing separate extraction steps for each object.

Correct Option

A. Define an extraction step for the Contact object and set the Extract JSON Path to Contact.Account.Name
This is the correct and most efficient best practice. A single DataRaptor Extract step starting from the Contact object can traverse the Account relationship to get the Account.Name using the JSONPath Contact.Account.Name. The DataRaptor internally handles the SOQL join, eliminating the need for multiple, manually configured extraction steps and simplifying the configuration.

Incorrect Option

B. Define extraction steps for the Contact and the Account objects, and set the Extract JSON Path to Contact.Account.Name
This is redundant and not a best practice. Defining a separate step for the Account object is unnecessary because the relationship from Contact to Account can be traversed directly in the JSON Path within a single step. Multiple steps would complicate the DataRaptor without providing any benefit for this simple lookup.

C. Define extraction steps for the Contact and the Account objects, and set the Extract JSON Path to Account.Name
This is incorrect. The JSON Path Account.Name is not rooted in the starting object of the extraction. The first step is based on the Contact object, so the pipeline data at that point is a Contact record. Referring directly to Account.Name without the Contact. prefix would be invalid as the context is wrong.

D. Define an extraction step for the Account object, and set the Extract JSON Path to Account.Contact.Name
This reverses the relationship logic. The requirement is to start from a Contact and get its parent Account's name. This option starts from the Account and tries to traverse to a child Contact (Account.Contact.Name), which is not a standard relationship and would not work. The relationship is Contact.Account, not Account.Contact.

Reference
Salesforce OmniStudio Developer Guide: Configure a DataRaptor Extract

Explanation:

FlexCards can have multiple states, each with conditions. A state displays only if its condition evaluates to true.
When multiple states evaluate to true, the FlexCard evaluates them in order of their sequence (top to bottom).
The first matching state (closest to the top of the canvas) is the one that displays.
If no conditions evaluate to true, then the default state (if defined) will display.

❌ Why the other options are incorrect:

B. The first state with true nested condition, regardless of sequence in the FlexCard canvas, will display.
→ Wrong. Sequence matters, not nesting.

C. The state sequenced first in the FlexCard canvas will display.
→ Only true if that first state’s condition evaluates to true. If its condition is false, it won’t display.

D. The first state with a true AND condition, regardless of sequence in the FlexCard canvas, will display.
→ Incorrect. There’s no special priority for AND vs. OR conditions; evaluation order is by sequence only.

📖 Reference:
Salesforce OmniStudio FlexCards Developer Guide → States section:
“If more than one state evaluates to true, the FlexCard renders the first state in sequence.”

Summary
The requirement is to retrieve data for a single field from a Salesforce record directly within an OmniScript. This is a common need for populating a field based on a selected record ID, such as getting an Account's phone number after an Account Id is entered. The element must perform a lightweight, real-time data lookup without the overhead of a full DataRaptor or external call.

Correct Option

A. Lookup
The Lookup element is specifically designed for this purpose. It is a dual-purpose element that provides a searchable interface to find a record and, upon selection, can automatically populate other fields on the OmniScript with data from that selected record. Its "Pre-fill Field Mappings" property allows a developer to map a field from the selected record (e.g., Account.Phone) to a field in the OmniScript, efficiently retrieving the value for a single field.

Incorrect Option

B. Select
The Select element is used to present a static or dynamically sourced list of options for a user to choose from (like a picklist). It does not perform a real-time data retrieval from a Salesforce record based on an ID. It is for user selection, not for auto-populating field values from a database.

C. HTTP Action
An HTTP Action is used to call an external REST API or web service. It is not the right tool for a simple, internal data retrieval from a Salesforce record. Using it for this purpose would be overly complex, require custom Apex, and violate the principle of using the simplest tool for the job.

D. DataRaptor Post Action
A DataRaptor Post Action is used to create, update, or upsert records in the database. It is a data loading tool, not a data retrieval tool. For extracting a single field value, a DataRaptor Extract would be more appropriate, but even that is more heavyweight than a Lookup element for this specific single-field use case.

Reference
Salesforce OmniStudio Developer Guide: Lookup Element