SF-Data-Arch Data Migration Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Temporarily deactivate the validation rule during the data load, then reactivate it afterward.

  Why it's wrong here

  Deactivating the validation rule is a common workaround, but it is risky because it allows invalid data to be loaded. If the rule is reactivated, existing records with blank Status__c may cause issues in future updates. The requirement is to succeed without modifying the validation rule, so this approach violates that constraint.

• ✗

  Load the records with blank Status__c using the Data Loader's 'Bulk' mode, which bypasses validation rules.

  Why it's wrong here

  Bulk API does not bypass validation rules. All validation rules are enforced regardless of the API used. This is a common misconception. The load would fail for records with blank Status__c. The correct approach is to transform the data before loading.

• ✓

  Transform the legacy data by setting a default value of 'Inactive' for any records with a blank Status__c before loading.

  Why this is correct

  This is correct because the validation rule requires a specific value. Transforming the data to populate a valid default ensures that all records pass validation. This approach is simple, does not require changing the validation rule, and maintains data quality. It is a standard data cleansing step in migration projects.

• ✗

  Create a before insert trigger to set a default value for Status__c when it is blank.

  Why it's wrong here

  A before insert trigger can set default values, but it adds unnecessary complexity and may not be allowed if the requirement is to avoid code changes. It also does not address the root cause: the data needs to be cleansed before loading. The simplest solution is to transform the data during extraction or before load. Triggers also consume governor limits.