Salesforce Platform Data Architect Practice Test

Correct answer: B. Master-detail relationship from Warranty Claim (child) to Asset (parent)

Only master-detail gives you both requirements natively: the detail record inherits sharing and ownership from the master, and roll-up summary fields are only available on the master side of a master-detail relationship.

A lookup plus scheduled Apex (A) would work mechanically but adds custom code and does not inherit sharing — it fails the stated requirement and violates the declarative-first principle. Option C inverts the relationship: the claim is the many side, so Asset cannot be the child. Hierarchical relationships (D) exist only on the User object.

Exam section: Data Modeling & Database Design  ·  Difficulty: Medium

Correct answer: D. Account data skew — distribute the placeholder Cases across multiple bucket Account records

This is classic account data skew (sometimes called parent-child or lookup skew): more than roughly 10,000 child records under one parent. Salesforce locks the parent during child DML and must recalculate implicit sharing for its children, producing record-lock errors and slow sharing recalculation.

The standard remedy is to spread the child records across a set of bucket parent records so no single parent exceeds the threshold. Ownership skew (C) is a related but distinct problem — many records owned by one user, which hurts role-hierarchy recalculation; here the issue is the parent lookup, not ownership. Neither FLS (A) nor storage capacity (B) causes locking.

Exam section: Data Modeling & Database Design  ·  Difficulty: Hard

Correct answer: A. When you need to retain hundreds of millions of immutable historical records that are queried by a known, predefined key

Big Objects are designed for massive volumes of append-only historical data — event logs, historical transactions, archived records — queried through a predefined index (the composite key defined when the object is created), either with SOQL on the index fields or asynchronously via Async SOQL.

Big Objects deliberately trade away platform features: no triggers on standard use, no roll-up summaries or validation rules (D), no standard sharing model (B), and no general-purpose ad-hoc editing in list views (C). If you need those features, a custom object — with an archiving strategy — is the right choice.

Exam section: Data Modeling & Database Design  ·  Difficulty: Medium

Correct answer: C. Enable and use the standard Contacts to Multiple Accounts feature (AccountContactRelation)

Salesforce ships Contacts to Multiple Accounts, which exposes the standard AccountContactRelation junction. It supports a primary account plus many related accounts, with roles, and it is reportable and API-accessible with no custom build.

Building your own junction (B) duplicates a standard capability and forfeits the standard UI and reporting. Master-detail (D) makes the single-parent constraint stricter, not looser. Storing Ids in a text field (A) is unqueryable, unenforceable, and breaks referential integrity.

Exam section: Data Modeling & Database Design  ·  Difficulty: Medium

Correct answer: B. Field descriptions and help text, Data Classification metadata fields, and Field Usage / Field Dependency reporting exported to a maintained business glossary

Salesforce provides declarative metadata about metadata: field Description and Help Text for business definitions, and the Data Classification attributes (Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization) for governance. These are retrievable via the Metadata and Tooling APIs, so they can be exported into a maintained business glossary and kept in source control.

A hand-maintained custom object (C) drifts from reality immediately. Encryption (D) protects data at rest and says nothing about lineage. Field History Tracking (A) records value changes and is capped at 20 fields per object — it is not a lineage or metadata-management tool.

Exam section: Data Modeling & Database Design  ·  Difficulty: Hard

Correct answer: A. DML on child records locks the parent, which can cause row-lock contention under concurrent load

When a detail record is inserted, updated, or deleted, Salesforce locks the master record to maintain roll-up summaries and sharing. Under high-concurrency writes this produces UNABLE_TO_LOCK_ROW errors, so a lookup relationship (with asynchronous roll-ups if needed) is often the better fit for volatile transactional children.

Master-detail relationships are fully reportable (C) and fully API-accessible (D). There is no hard 10,000-record cap (B) — 10,000 is the widely cited guideline above which data skew symptoms appear, not an enforced limit.

Exam section: Data Modeling & Database Design  ·  Difficulty: Medium

Correct answer: D. To surface data that physically resides in an external system, retrieved on demand via Salesforce Connect

External objects are the data-virtualisation mechanism of Salesforce Connect. The records live in the external system; Salesforce issues a live callout through an OData, cross-org, or custom Apex adapter when the data is requested. Nothing is persisted in Salesforce.

Options C and A both describe copying data into Salesforce, which is the opposite of virtualisation and would consume storage. Option B describes a permission concern, not the purpose of the object type.

Exam section: Data Modeling & Database Design  ·  Difficulty: Easy

Correct answer: C. Lookup skew causing record-lock contention during bulk Opportunity loads

Concentrating ~60,000 child records under a single lookup parent creates lookup skew. During bulk DML Salesforce briefly locks the parent record referenced by each child; with tens of thousands of children pointing at one parent, concurrent batches contend for the same lock and fail with row-lock errors.

Mitigations include spreading records across more parent records, reducing batch size, sorting the load by the parent Id so each batch touches one parent, and disabling the lookup during the initial migration. Storage (B) is negligible at this scale, the name-field limit (D) is 80 characters and irrelevant, and lookups are fully reportable (A).

Exam section: Data Modeling & Database Design  ·  Difficulty: Hard

Correct answer: A. A master-detail relationship with the "Allow reparenting" option enabled on the child relationship field

Master-detail relationships support the "Child records can be reparented to other parent records after they are created" option on the relationship field. With it enabled you retain sharing inheritance and roll-ups while allowing the parent to change.

A lookup (D) allows reparenting but does not inherit sharing. Hierarchical relationships (B) apply only to User. Option C states an outdated limitation — reparenting has been supported for many releases.

Exam section: Data Modeling & Database Design  ·  Difficulty: Medium

Correct answer: B. Custom metadata types for deployable, packageable configuration; hierarchy custom settings for per-user or per-profile runtime overrides

Custom metadata types hold configuration records that are metadata: they deploy between orgs with change sets or packages, are cached, and do not count against data storage. Hierarchy custom settings retain one genuinely useful capability metadata types lack — per-profile and per-user value overrides resolved at runtime.

Option C reverses the two. They are not equivalent (D). Neither is intended for transactional data (A) — custom metadata records are deployed, not created by end users in the flow of business.

Exam section: Data Modeling & Database Design  ·  Difficulty: Medium

Correct answer: C. Enabling Person Accounts is irreversible and changes the Account/Contact model, record type strategy, and integration contracts

Enabling Person Accounts is a one-way, irreversible org change. A Person Account is a single record surfaced through both the Account and Contact objects, which affects record types, page layouts, sharing, roll-ups, duplicate management, and every integration that assumes an Account always has separate Contacts. It must be validated in a sandbox and agreed with integration owners before enablement.

Person Accounts are fully API-accessible (B) and fully reportable (A), and Business and Person Accounts coexist in the same org via record types (D).

Exam section: Data Modeling & Database Design  ·  Difficulty: Hard

Correct answer: D. Mark the field as Unique (and External Id where appropriate) so the platform enforces a database unique index

Setting the field to Unique creates a database-level unique index enforced on every insert and update, regardless of the entry point — UI, API, Apex, or Bulk API. Combining Unique with External Id additionally enables upserts keyed on that value, which is invaluable during migration.

A trigger (C) is not truly atomic under concurrency and does not scale to 6 million records efficiently. Validation rules (A) cannot query other records. Duplicate Management set to Report (B) only surfaces duplicates; it does not prevent them.

Exam section: Data Modeling & Database Design  ·  Difficulty: Medium

Correct answer: B. Salesforce Connect with the cross-org adapter to expose Org B data as external objects in Org A, combined with a data warehouse for historical trend reporting

The cross-org Salesforce Connect adapter surfaces Org B records as external objects in Org A in real time, with no data duplication, no additional storage, and no synchronisation lag. Because external objects have query and reporting constraints, pairing them with a data warehouse (fed by Bulk API or CDC from both orgs) covers cross-org historical trend analysis.

Nightly copying (A) doubles storage, adds latency, and creates a second system of record. Spreadsheets (C) are unsustainable and ungoverned. Divisions (D) partition data within one org and do nothing across orgs.

Exam section: Data Modeling & Database Design  ·  Difficulty: Hard

Correct answer: C. Expose ERP orders as external objects via Salesforce Connect and surface them on the Account page, replicating only the small set of aggregates users must filter and report on

The pragmatic single-view pattern is virtualise the detail, replicate the aggregates. External objects give on-demand access to the full order history with no storage cost and no synchronisation lag, while a small number of replicated summary fields (lifetime value, last order date, open order count) remain natively reportable and filterable.

Full hourly replication (B) consumes storage and API capacity for data most users never open. Direct database access (D) bypasses Salesforce security entirely. A text area (A) is not queryable or reportable.

Exam section: Salesforce Data Management  ·  Difficulty: Medium

Correct answer: A. Licence type constrains which standard objects are available, so object choice must be validated against the licences the affected user populations hold

Licence type materially constrains the data model. Salesforce Platform licences, for example, exclude standard CRM objects such as Opportunity, Lead, Case, Campaign, Forecast, and Contract, and Experience Cloud licences carry their own object and sharing constraints.

An architect must therefore map which user population touches which object before finalising the model — otherwise the design is only discovered to be unlicensable during build. Options D, B, and C each misstate how licensing works.

Exam section: Salesforce Data Management  ·  Difficulty: Medium

Correct answer: D. Archive the aged Cases to a Big Object (or an external archive with Salesforce Connect access), then delete them from the Case object under a documented retention policy

The requirement is retain but do not carry the operational cost. Big Objects store hundreds of millions of records outside standard data storage and remain queryable by their index; alternatively the records move to an external archive surfaced through Salesforce Connect. Either way the aged Cases leave the Case object, shrinking indexes and improving query and report performance.

Deleting with only a weekly export as the archive (B) is not a defensible compliance position and the export is retained for a limited window. Buying storage (C) treats the symptom and leaves the performance problem. Chatter (A) does not reduce storage and is not an archive.

Exam section: Salesforce Data Management  ·  Difficulty: Hard

Correct answer: B. An External Id field marked Unique, used with the upsert operation

An External Id field that is also Unique is the standard integration key. It is indexed, it prevents duplicates at the database level, and it allows integrations to call upsert keyed on the external value — inserting when absent and updating when present, idempotently and without a prior query.

A formula field (A) cannot be an external Id in this sense and is not writable. Using the Salesforce Id (C) makes the upstream system dependent on Salesforce-generated keys, which breaks on sandbox refreshes and re-migrations. A picklist (D) is not a key.

Exam section: Salesforce Data Management  ·  Difficulty: Medium

Correct answer: D. Set Account org-wide default to Private, model the business units in the role hierarchy, and use criteria-based sharing rules or a public group for the central team

Private org-wide defaults plus a role hierarchy that mirrors the business units is the standard segmentation pattern; sharing rules or a public group then grant the central team access without flattening the model, and executives sit high enough in the hierarchy for consolidated reporting.

Splitting into two orgs (C) is a very expensive answer to a sharing requirement and destroys consolidated reporting. Page layouts (A) control field and layout visibility, never record visibility. View All Data (B) removes segmentation entirely.

Exam section: Salesforce Data Management  ·  Difficulty: Medium

Correct answer: C. A custom object synchronised from the external master, with an External Id key and an upsert-based delta integration

The distinguishing requirement is reporting and validation logic. External objects (B) have real limitations for reporting, roll-ups, and use in declarative automation, and callout latency on every access is poor for reference data that barely changes. A replicated custom object with an external Id and delta upserts gives full native reporting, relationships, and formula access at trivial storage cost for 12,000 records.

Custom metadata (D) is for configuration deployed by release, not for a dataset that changes on the source system's schedule and is far too large to redeploy. Manual picklist maintenance (A) does not scale and drifts from the master.

Exam section: Salesforce Data Management  ·  Difficulty: Hard

Correct answer: A. It extends field history retention beyond the standard period and raises the number of trackable fields per object, storing history in a Big Object queryable via SOQL

Field Audit Trail (part of Salesforce Shield) extends field history retention up to ten years, raises the tracked-field ceiling per object well above the standard 20, and persists history in the FieldHistoryArchive Big Object, queryable with SOQL and governed by a retention policy set through the Metadata API.

Encryption at rest (D) is Shield Platform Encryption, a separate feature. It does not filter by user type (B), and it addresses field-level history only — not record archiving (C).

Exam section: Salesforce Data Management  ·  Difficulty: Medium

Correct answer: D. Duplicate Management: matching rules paired with duplicate rules, set to block or alert on create and edit

Salesforce Duplicate Management is purpose-built for this. Matching rules define fuzzy comparison logic (exact, fuzzy first name, fuzzy company name, normalised address); duplicate rules then decide whether to allow with an alert, block, or simply report, and on which entry points.

A validation rule (A) cannot compare against other records. Encryption (B) actually interferes with matching on the encrypted field. Field History (C) records changes after the fact and prevents nothing.

Exam section: Salesforce Data Management  ·  Difficulty: Medium

Correct answer: B. Salesforce DML operates within a transaction that is committed or rolled back atomically, so the update logic should be centralised in a single service (for example an Apex service class or Flow) invoked by all callers

Consistency comes from one write path, not from each caller implementing its own. Salesforce commits a request's DML atomically, so centralising the calculation and the write in a single invocable service means every caller — UI, Flow, and each integration — applies identical rules within one transaction that either fully commits or fully rolls back.

Independent read-then-write loops (A) are exactly the race condition to avoid. Uniqueness (C) is about duplicate values, not write consistency. Field History (D) is an audit feature.

Exam section: Salesforce Data Management  ·  Difficulty: Hard

Correct answer: A. Divisions

Divisions partition records into logical subsets so that searches, reports, and list views can be scoped to one division, which reduces the working set in very large orgs. Divisions must be enabled by Salesforce Support and are a legacy feature to apply deliberately.

Record types (D) drive picklist values, layouts, and business process — not scope reduction. Public groups (B) and queues (C) are sharing and assignment constructs.

Exam section: Salesforce Data Management  ·  Difficulty: Easy

Correct answer: C. Big Object with a well-chosen index, queried with Async SOQL and surfaced through summary custom objects

200 million immutable, bulk-analysed rows is the canonical Big Object use case: capacity far beyond standard objects, no data-storage consumption, and Async SOQL for long-running aggregate queries whose results are written into a small custom object that users can report on normally.

Skinny tables (B) improve read performance on standard/custom objects but do not solve the volume problem at this scale. Attachments (D) are unqueryable as data. Custom metadata (A) is configuration, capped far below this volume.

Exam section: Salesforce Data Management  ·  Difficulty: Medium

Correct answer: B. The retention period, legal hold requirements, and the definition of "archived" determine what may be deleted, what must remain accessible, and therefore which archive mechanism is viable

Archiving is a consequence of retention policy, not a substitute for it. Whether records may be deleted at all, how long they must stay retrievable, in what timeframe they must be produced for an audit or legal hold, and who may read them jointly decide whether a Big Object, an external archive, or simple deletion is acceptable.

Options A, C, and D describe platform behaviours that do not exist.

Exam section: Salesforce Data Management  ·  Difficulty: Medium

Correct answer: C. Make the filters more selective — add an indexed, selective filter such as a date range on an indexed field and reduce the returned field set — and consider a skinny table for the frequently reported columns

Large-volume query performance is driven by filter selectivity against indexed fields. Checkbox fields are poor filters because they are inherently non-selective (roughly half the rows). Adding a selective, indexed filter (standard indexed fields include Id, Name, OwnerId, CreatedDate, SystemModstamp, RecordTypeId, and any External Id or Unique field), narrowing the date range, and trimming returned columns lets the optimiser use an index instead of a full table scan.

Where a small, stable set of fields is reported repeatedly, a skinny table requested through Salesforce Support removes the join between the base and custom-field tables. Raising the row limit (B) makes it worse; a joined report (D) adds work; Big Objects (A) are not a reporting substitute for a live transactional object.

Exam section: Large Data Volume Considerations  ·  Difficulty: Hard

Correct answer: D. A custom checkbox field

Standard indexes exist on Id, Name, OwnerId, CreatedDate, SystemModstamp, RecordTypeId, master-detail and lookup relationship fields, and any field marked Unique or External Id.

An ordinary custom checkbox is not indexed. Even if a custom index were added, a boolean is rarely selective enough for the query optimiser to use it, since it typically matches a large share of the table.

Exam section: Large Data Volume Considerations  ·  Difficulty: Medium

Correct answer: A. Sort the input file by parent Order Id, use serial mode rather than parallel mode where contention persists, and defer sharing calculation for the duration of the load

Lock contention on a shared parent is addressed by ensuring that a given parent is only ever touched by one batch at a time. Sorting the file by parent Id groups children of the same Order into the same batch; serial mode eliminates parallel batches competing for the same parent lock; and Defer Sharing Calculation suspends sharing recalculation during the load window.

Row-by-row loading (D) is orders of magnitude slower. Larger batches (B) increase the number of parents touched per batch and worsen contention. Retrying inside a trigger (C) does not remove the contention and burns governor limits.

Exam section: Large Data Volume Considerations  ·  Difficulty: Hard

Correct answer: C. It is a Salesforce-maintained table containing a frequently used subset of fields, avoiding joins between the base and custom-field tables and staying in sync with the source object

A skinny table is created by Salesforce Support and holds a narrow, frequently accessed subset of an object's fields (up to 100), avoiding the join between the base table and the custom-field table. Salesforce keeps it synchronised automatically, so reports and list views over those fields get materially faster on large objects.

Skinny tables do not archive (B), do not move data off-platform (D), and do not raise field limits (A). Note that they do not carry across a sandbox copy or org migration without being re-requested.

Exam section: Large Data Volume Considerations  ·  Difficulty: Medium

Correct answer: B. Filter on SystemModstamp, which is updated by both user and system changes and is indexed

SystemModstamp is the correct high-water mark. It is indexed and it is updated by system-driven changes that do not always touch LastModifiedDate — for example some platform-internal updates — so bookmarking on it avoids silently missing records.

Delta extraction should also handle deletions, using the queryAll / getDeleted capabilities or Change Data Capture. Full extraction every run (D) is the pattern to eliminate, and CreatedDate (C) misses updates entirely.

Exam section: Large Data Volume Considerations  ·  Difficulty: Medium

Correct answer: D. Defer sharing calculation, disable or bypass non-essential triggers, workflow rules, and validation rules, load with the Bulk API in parallel mode with a granular public group model, then re-enable and recalculate sharing once

The established LDV migration pattern is to reduce per-record work during the load and do the expensive recalculation once at the end: enable Defer Sharing Calculation, temporarily suspend non-essential automation (with a documented reactivation plan and a data-quality gate to compensate), load via Bulk API, then resume sharing calculation in a single controlled pass.

Leaving everything enabled (C) multiplies work per record. UI loading (A) is not viable at this volume. Permanently relaxing the sharing model (B) trades a security requirement for a performance shortcut and is not acceptable.

Exam section: Large Data Volume Considerations  ·  Difficulty: Hard

Correct answer: A. The data is large, changes frequently, and is only viewed occasionally in record context rather than reported on in aggregate

Virtualisation is strongest when the dataset is large, volatile, and read in context — a customer's full invoice history opened from the Account page, for example. Nothing is stored, so there is no storage cost and no synchronisation lag.

The other options describe exactly where virtualisation struggles: external objects cannot back roll-up summaries (D), have real search limitations (B), and impose callout latency and governor considerations in Apex (C). Those requirements point toward replication.

Exam section: Large Data Volume Considerations  ·  Difficulty: Medium

Correct answer: C. It uses an index only when the filter is selective enough — that is, when the filter matches below a threshold share of the object's records

The optimiser is selectivity-driven. It estimates how many rows a filter will return and uses an index only below a threshold (commonly cited as roughly 30% of the first million rows and about 15% thereafter, subject to change and lower for standard indexes). A non-selective filter falls back to a full scan even with an index present.

This is why indexing a checkbox or a status field with two common values rarely helps, and why !=, leading-wildcard LIKE, and NOT filters are index-defeating. The optimiser applies to SOQL, reports, and list views alike (A).

Exam section: Large Data Volume Considerations  ·  Difficulty: Easy

Correct answer: D. Run a scheduled hard delete via the Bulk API in off-peak windows, in controlled batches, after confirming the records are captured in the archive and no legal hold applies

Bulk API hard delete bypasses the Recycle Bin, which matters because 30 million soft-deleted records would otherwise sit in the Recycle Bin and keep consuming storage and index space. Running it off-peak in controlled batches limits contention, and confirming the archive and legal-hold status first is the governance precondition.

UI deletion (C) is impractical at this volume. Object truncation (A) removes all records, not a subset, and is a sandbox-oriented tool. Flagging records inactive (B) leaves the volume — and the performance problem — exactly where it was.

Exam section: Large Data Volume Considerations  ·  Difficulty: Medium

Correct answer: B. The filter is not selective — each value matches roughly 7.5 million records, above the optimiser's selectivity threshold — so the index is not used

An index only helps when the filter is selective. Four evenly distributed values over 30 million records means each value returns roughly a quarter of the table — far above the optimiser's threshold — so it correctly declines the index and performs a scan.

The remedy is to add a genuinely selective filter alongside Region (an indexed date range, an owner, or an external Id), pre-aggregate into a summary object, or use a skinny table. Custom indexes are supported on picklists (A), and no text conversion is required (D).

Exam section: Large Data Volume Considerations  ·  Difficulty: Hard

Correct answer: A. Populate an External Id on the parent, load parents first, then load children referencing the parent by that External Id in the relationship column

Salesforce supports referencing a parent record by an External Id in the relationship column of a child load (Parent__r.Legacy_Id__c), so the child resolves its parent at insert time. Loading parents first, then children, removes the need for an Id-mapping pass entirely.

Reversing the order (D) leaves orphans and name matching is unreliable. A single mixed file (B) does not control ordering. Manual Id mapping (C) is exactly the error-prone step this technique eliminates.

Exam section: Data Migration  ·  Difficulty: Medium

Correct answer: D. Use the Bulk API 2.0, disable non-essential triggers, workflow rules, validation rules, and duplicate rules for the load, defer sharing calculation, and load in parallel where no parent contention exists

Bulk API 2.0 is designed for high-volume asynchronous loads. The dominant cost per record is synchronous automation — triggers, flows, workflow rules, validation rules, duplicate rules — and sharing recalculation. Suppressing those for the load window and running parallel batches where parent contention allows is the established throughput recipe.

Crucially, suppressing validation and duplicate rules shifts the data-quality burden to pre-load cleansing and post-load verification, which must be planned. Option A is the low-throughput path, the Import Wizard (B) caps at 50,000 records, and extra users (C) does not increase throughput.

Exam section: Data Migration  ·  Difficulty: Hard

Correct answer: C. Profile and cleanse in a staging layer before load — deduplicate, standardise formats, validate picklist and reference values against the target, and run a full trial load in a sandbox with reconciliation counts

Quality is engineered upstream of the load. Profiling the source reveals nulls, duplicates, and format drift; cleansing in staging fixes them once; validating picklist and reference values against the target org prevents mass row failures; and a full sandbox trial load with row-count and control-total reconciliation proves the process before production.

Cleaning up in production (B) is far more expensive and risks user-visible bad data. Relying on validation rules (D) is fragile — and those rules are frequently disabled for throughput. Manual review after go-live (A) does not scale.

Exam section: Data Migration  ·  Difficulty: Medium

Correct answer: B. Bulk API 2.0 query jobs with PK chunking enabled

Bulk API 2.0 query jobs with PK chunking split the extract into sequential Id ranges, which keeps each chunk selective and avoids the query timeouts that a single 50-million-row query would hit. It is the supported mechanism for very large extracts.

Weekly Export (A) is a backup convenience with limited scheduling and format control. Report exports (C) are row-limited. The Developer Console (D) is a development tool with query row limits far below this volume.

Exam section: Data Migration  ·  Difficulty: Medium

Correct answer: A. CreatedDate can be set if the "Set Audit Fields upon Record Creation" permission is enabled, and OwnerId can be set directly on insert

Salesforce supports Set Audit Fields upon Record Creation, which — once enabled for the org and granted via permission set — allows CreatedDate, CreatedById, LastModifiedDate, and LastModifiedById to be supplied on insert. OwnerId is a normal writable field on insert.

The important nuance is that audit fields are settable only at insert, not afterwards (B) — so if they are missed on the first pass, the records must be deleted and reloaded. Option D is outdated and Option C is simply incorrect.

Exam section: Data Migration  ·  Difficulty: Hard

Correct answer: C. Row counts per object, control totals on key numeric fields, referential integrity checks on parent-child links, sampled field-level comparison against source, and a business sign-off on representative records

Reconciliation must prove completeness, integrity, and accuracy. Row counts prove nothing was dropped; control totals on amounts catch truncation and transformation errors; referential integrity checks catch orphaned children; sampled field-level comparison catches mapping mistakes; and business sign-off catches the semantic errors no automated check will find.

Zero reported errors (B) says nothing about rows silently filtered before the load. A higher target count (D) indicates duplication, not success. Ten records (A) is not a defensible sample.

Exam section: Data Migration  ·  Difficulty: Medium

Correct answer: A. Populating a heavily concentrated lookup during the insert causes parent-record lock contention; deferring it lets the inserts run cleanly and the links be applied afterwards in a controlled, parent-sorted update

Every insert that populates a lookup briefly locks the referenced parent. When many children point at the same parent, parallel batches contend for that lock and fail. Deferring the lookup lets the bulk insert run without contention, after which the links are applied in a second pass sorted by parent Id — or in serial mode — where contention is controllable.

Options D and C are false; the Bulk API populates lookups normally. Lookups do not carry meaningful additional storage (B).

Exam section: Data Migration  ·  Difficulty: Medium

Correct answer: D. Data Classification metadata on fields, Shield Platform Encryption for sensitive attributes, Field Audit Trail for retention, Consent Management objects for lawful basis, and a documented deletion or anonymisation process using hard delete

GDPR compliance is a composite of capabilities. Data Classification identifies and labels personal and sensitive fields so they can be governed; Shield Platform Encryption protects sensitive attributes at rest; Field Audit Trail enforces defined retention; the standard Consent Management model (Individual, ContactPointConsent, and related objects) records lawful basis and preferences; and a documented erasure process — hard delete or irreversible anonymisation, including in sandboxes, archives, and backups — satisfies the right to erasure.

Private OWDs (A) and MFA (B) are useful controls but address access, not lawful basis, retention, or erasure. Concentrating personal data in one object (C) does not by itself make processing lawful.

Exam section: Data Governance  ·  Difficulty: Hard

Correct answer: B. They record governance metadata about each field so stewards can inventory, classify, and report on sensitive data across the org

These are governance metadata attributes. They let an organisation build and maintain a data inventory — who owns a field, whether it is actively used, how sensitive it is, and which regulations it falls under — and they are retrievable through the Metadata and Tooling APIs so the inventory can be exported and audited.

They are descriptive only: they neither encrypt (A) nor enforce access (C) nor affect reporting availability (D). Enforcement still comes from FLS, sharing, and encryption.

Exam section: Data Governance  ·  Difficulty: Medium

Correct answer: A. Governance requires named data owners and stewards, agreed data quality metrics and thresholds, a change-control process for the data model, and a governance forum — with platform features enforcing the agreed policy

Effective governance is an operating model first: accountable owners and stewards per data domain, measurable quality metrics with agreed thresholds (completeness, duplication rate, validity), change control over the data model so it does not sprawl, and a forum that arbitrates conflicts. Salesforce features then enforce the agreed policy.

Treating it as purely technical (D) produces controls nobody owns. Deferring it (B) guarantees remediation cost later. Locking down write access (C) is one control, not a programme.

Exam section: Data Governance  ·  Difficulty: Medium

Correct answer: D. Retrieve object and field metadata via the Metadata or Tooling API, cross-reference the Data Classification attributes, and produce a reviewed inventory that stewards sign off and maintain under change control

Pulling field metadata programmatically produces a complete, repeatable, reviewable inventory that can be re-run after every release to detect drift. Cross-referencing the Data Classification attributes turns it into a governance artefact rather than a one-off spreadsheet, and steward sign-off makes it defensible to an auditor.

Manual Setup review (C) across 60 objects is slow and will not stay current. Option A is not a supported reporting path for this purpose. Exporting and scanning the data (B) creates a new copy of the very personal data you are trying to govern.

Exam section: Data Governance  ·  Difficulty: Medium

Correct answer: B. A documented legal hold: exclude the affected records from archiving and purging jobs, restrict edit and delete permissions on them, and record the hold and its release criteria in the governance register

A legal hold overrides normal retention. Practically it means the purge and archive jobs must filter the held records out, edit and delete rights on them must be constrained (record-level access, a validation rule keyed on a hold flag, or ownership transfer to a controlled queue), and the hold's scope, owner, and release criteria must be documented and reviewed.

Deleting and hoping to restore (A) fails the preservation requirement outright. Sharing defaults (C) control visibility, not mutability or retention. Field History (D) tracks changes but does not prevent purging.

Exam section: Data Governance  ·  Difficulty: Hard

Correct answer: C. Data survivorship rules — source system trust rankings, recency, completeness, and validation status combined into agreed weightings and thresholds

Survivorship rules decide attribute-level winners. They typically combine a trust ranking per source (the ERP may be authoritative for billing address while the marketing platform is authoritative for email preference), plus recency, completeness, and whether the value passed validation such as address standardisation.

Recency alone (B) lets a stale bulk import overwrite a verified value. Declaring one system universally authoritative (D) ignores that authority is attribute-specific. Majority voting (A) is unreliable when systems copy from one another.

Exam section: Master Data Management  ·  Difficulty: Hard

Correct answer: A. Centralised (transaction) style

In the centralised (transaction) style, the MDM hub is the authoritative system of record: data is authored or mastered there and distributed to consuming systems. It gives the strongest consistency but demands the most change from existing applications.

Registry style stores only keys and cross-references, resolving records on the fly. Consolidation style aggregates copies into a hub for reporting without writing back. Coexistence style masters data in the hub while allowing sources to keep authoring, with bidirectional synchronisation.

Exam section: Master Data Management  ·  Difficulty: Medium

Correct answer: D. It preserves traceability so any consolidated attribute can be traced back to its originating system, which is essential for troubleshooting, audit, and re-processing

Retaining the source system identifier (and often a source system name and last-synchronised timestamp) preserves lineage. When a golden-record value is disputed, you can show which system supplied it and when; when survivorship rules change, you can reprocess; and integrations can upsert reliably against the stored key.

It adds storage rather than reducing it (C), it is not a prerequisite for duplicate rules (A), and while it supports deterministic matching it does not by itself improve fuzzy matching accuracy (B).

Exam section: Master Data Management  ·  Difficulty: Medium