About this exam
Data-Architect is the Salesforce exam Salesforce Certified Data Architect.
Paid practice material for this exam is not available yet, but you can try its free sample questions.
- Exam code
- Data-Architect
- Vendor
- Salesforce
- Practice questions
- Not available yet
- Free sample questions
- 5
- Question bank last updated
- Not available yet
Try 2 sample questions
Taken from the free sample set for Data-Architect.
Question 1
Cloud Kicks has the following requirements:
• Their Shipment custom object must always relate to a Product, a Sender, and a Receiver (all
separate custom objects).
• If a Shipment is currently associated with a Product, Sender, or Receiver, deletion of those records
should not be allowed.
• Each custom object must have separate sharing models.
What should an Architect do to fulfill these requirements?
- AOption A:
Associate the Shipment to each parent record by using a VLOOKUP formula field.
- BOption B:
Create a required Lookup relationship to each of the three parent records.
- COption C:
Create a Master-Detail relationship to each of the three parent records.
- DOption D:
Create two Master-Detail and one Lookup relationship to the parent records.
Show answer and explanation
Correct answer: B
You nailed it again. B. Create a required Lookup relationship to each of the three parent records is the absolute correct architectural choice here.
This is a classic Salesforce Platform Architect question that tests your understanding of the strict differences between Master-Detail and Lookup relationships. Let’s break down exactly how Option B satisfies every single constraint from Cloud Kicks:
1. Requirement: "Each custom object must have separate sharing models."
Why this points to Lookup: Master-Detail relationships are incredibly restrictive with security; the detail record completely inherits the sharing and visibility settings of its master record. If you used Master-Detail, Shipment would be forced to inherit security from its parents.
The Solution: By using a Lookup relationship, the Shipment, Product, Sender, and Receiver objects all maintain completely independent sharing models, satisfying this requirement perfectly.
2. Requirement: "Their Shipment custom object must always relate to a Product..."
The Solution: While Lookups are optional by default, you can check the "Always require a value in this field in order to save a record" box during setup. This forces the lookup to behave like a mandatory link, ensuring a shipment can never be orphaned.
3. Requirement: "If a Shipment is currently associated... deletion of those records should not be allowed."
The Solution: Salesforce lookup fields have a built-in behavior setting for when a parent record is deleted. To fulfill this, the Architect simply selects the option: "Don't allow deletion of the lookup record that's part of a lookup relationship." If someone tries to delete a Sender who has an active Shipment, Salesforce will block the deletion and throw an error.
Why the other options fail:
A. VLOOKUP formula field: VLOOKUP formulas only work in validation rules, not as actual data modeling relationships, and they cannot enforce deletion blocks or independent sharing models.
C. Master-Detail relationship to each: This fails on two fronts. First, a custom object can have a maximum of two Master-Detail relationships, so you physically cannot create three on Shipment. Second, it completely violates the requirement for separate sharing models.
D. Two Master-Detail and one Lookup: While this sneaks under the max limit of two Master-Detail relationships, the two Master-Detail links would still destroy the requirement for Shipment to have its own completely separate sharing model.
Question 2
Universal Containers (UC) is planning to move away from legacy CRM to Salesforce. As part of one
time data migration, UC will need to keep the original date when a contact was created in the legacy
system. How should an Architect design the data migration solution to meet this requirement?
- AOption A:
After the data is migrated, perform an update on all records to set the original date in a standard CreatedDate field.
- BOption B:
Create a new field on Contact object to capture the Created Date. Hide the standard CreatedDate field using Field -Level Security.
- COption C:
Enable "Set Audit Fields" and assign the permission to the user loading the data for the duration of the migration.
- DOption D:
Write an Apex trigger on the Contact object, before insert event to set the original value in a standard CreatedDate field.
Show answer and explanation
Correct answer: C
Spot on! C. Enable "Set Audit Fields" and assign the permission to the user loading the data for the duration of the migration is the definitive best practice for this scenario.
This is a very common requirement for data migration architects. Here is why C is the perfect solution and why the platform blocks the other approaches:
Why "Set Audit Fields" is the Correct Path
By default, Salesforce strictly protects its system audit fields—like CreatedDate, CreatedById, LastModifiedDate, and LastModifiedById—and sets them automatically at the exact second a record is inserted. They are read-only and cannot be altered by normal users, API calls, or automation.
However, Salesforce provides a specific feature designed exactly for one-time historical data migrations:
The Feature: You turn on "Enable Set Audit Fields upon Record Creation" in User Interface settings.
The Permission: You assign the "Set Audit Fields upon Record Creation" system permission to your Data Migration user profile or permission set.
The Result: This temporary superpower allows your data loading tool (like Data Loader) to explicitly pass the legacy system's original timestamp directly into the standard CreatedDate field during insertion.
Why the Other Options Fail
A & D (Updating via API or Apex Trigger): Both options fail because standard audit fields cannot be updated after record creation, nor can they be intercepted and overridden by an Apex trigger. CreatedDate is fundamentally immutable once the record hits the database.
B (Creating a custom field & hiding the standard one): While this technically lets you save the data, it is a poor architectural choice. Hiding the standard CreatedDate field breaks native Salesforce functionality. Standard reports, list views, dashboards, and features like history tracking rely heavily on the system CreatedDate. Creating a duplicate field causes long-term confusion for users and developers alike.
See all 5 free sample questions