Plat-Arch-201 Salesforce Certified Platform Data Architect Exam Topics and Questions

Data Modeling/Database Design carries the largest share of this exam, and it sets the foundation everything else depends on. The domain rewards candidates who can think in trade-offs: when a lookup beats a master-detail, when a big object is the right call, when a design that looks clean in a sandbox will collapse under production sharing rules. If your mental model of Salesforce data design is shallow, this topic is where the exam will expose it.

– Designing for the Customer 360 Platform

The exam expects you to move fluently between object types, field types, and relationship styles, choosing among them based on a described scenario rather than habit. Lookup versus master-detail is the classic decision, but the tested version is more nuanced: what happens to roll-up summary fields, what cascade-delete means for the customer's data, and whether a junction object is genuinely needed or just familiar. Object features such as record types, page layouts, and field history tracking are fair game when a scenario implies a business need they serve. The examinable move is matching a feature to a constraint in the scenario, not reciting what the feature does in isolation. Relationship limits also matter: a child object can have only one master-detail parent, and that constraint shapes valid design choices in ways the exam tests directly.

– Security, sharing, and scalable structure

A data model that breaks sharing calculations at scale is a failed design, and the exam tests exactly that failure mode. Ownership-based sharing, criteria-based sharing rules, and the interaction between role hierarchy depth and sharing recalculation are all in scope. When a scenario describes millions of records owned by a single user or a single account with tens of thousands of child records, the expected response is a redesign that distributes ownership or flattens the hierarchy, not a workaround. Scalability here means the model can grow without triggering governor limits on sharing recalculation or record locking. The exam will present a scenario where the naive design causes one of those problems and ask you to identify the better structure. Knowing that record locking occurs at the parent in a master-detail relationship, and that this affects concurrent DML, is the kind of detail that separates a passing answer from a failing one.

– Metadata, classification, and data lineage

Business and technical metadata management is less flashy than object design but consistently appears in scenario questions. A business dictionary defines agreed meanings for data elements across the organisation; data lineage tracks where a field's value came from and how it has been transformed; taxonomy and data classification determine how data is grouped and what sensitivity label it carries. The exam tests whether you can recommend the right metadata approach for a described need. A customer asking how to prove that a field value in Salesforce originated from a specific upstream system is asking a lineage question, and the answer involves documenting transformation rules, not just field mappings. Classification matters when a scenario involves regulatory exposure: knowing which records contain personally identifiable information is a prerequisite for protecting them.

– Big objects and data skew

Big objects exist for a specific purpose: storing very large volumes of records that do not need the full feature set of standard or custom objects. They cannot be used in standard reports, do not support triggers in the same way, and cannot participate in most standard relationships. The exam tests whether you know when that trade-off is acceptable and when it disqualifies the option entirely. A scenario where the customer needs reporting on the data rules out big objects; a scenario where the customer needs to retain billions of historical event records with no reporting requirement makes them a strong candidate. Data skew is the other high-stakes sub-topic. Account skew, where a single account owns an outsized share of child records, causes sharing recalculation delays and lock contention. The fix is architectural: redistributing ownership, introducing an intermediate object, or restructuring the hierarchy. The exam rewards recognising which skew pattern a scenario describes and matching it to the structural remedy.

How Data Modeling/Database Design is tested

At 25%, this is the topic where the exam spends the most time, and the items are almost entirely scenario-based. You will be given a business situation with implied constraints, such as a sharing requirement, a volume figure, or a compliance need, and asked to choose a data model approach. Items reward the candidate who reads the constraint first and eliminates options that violate it, rather than picking the most feature-rich design. The most common trap is selecting a design that works functionally but breaks under the stated scale or sharing model. A master-detail relationship that triggers excessive roll-up recalculation, or an account hierarchy so deep it slows sharing rule evaluation, will appear as the attractive wrong path. Big object questions tend to hinge on a feature the customer needs that big objects cannot provide. Metadata questions reward precision: lineage, classification, and dictionary are distinct tools, and conflating them costs marks. Work through as many scenario items as you can before the exam; pattern recognition across scenarios matters more here than memorising feature lists.

Where the previous topic was about structure, Master Data Management is about trust: which record is right when multiple systems disagree, and how you prove it. At 5%, this is a smaller slice of the exam, but the items are precise and unforgiving. Candidates who treat MDM as a vague concept around "data quality" tend to lose these marks. The exam wants specific knowledge of implementation styles, survivorship logic, and golden record methodology applied to a described customer scenario.

– MDM implementation styles and consolidation

The exam distinguishes between the main MDM implementation styles: registry, consolidation, coexistence, and centralised (sometimes called authoritative). Each style places the system of record differently and has different implications for latency, data ownership, and integration complexity. You need to match a style to a scenario based on the constraints given, not just name the styles. A customer with three legacy systems that cannot be retired is a different problem from one building a greenfield Salesforce org as the single system of record. Canonical data modeling is in scope here: the idea that a shared, system-neutral representation of a business entity lets disparate sources be compared and merged. Hierarchy management, such as account hierarchies that span legal entities across geographies, is also tested. The exam will describe a business structure and ask which approach handles the hierarchy correctly within a single Salesforce org.

– Golden records, survivorship, and attribute selection

Establishing a golden record means defining rules for which source wins when field values conflict, and the exam tests the mechanics of that decision. Survivorship rules assign weights or thresholds to sources: a CRM system might be trusted for contact information but not for financial data, while an ERP is trusted for billing addresses but not for marketing preferences. The exam expects you to recommend survivorship criteria for a described scenario and to explain the methodology for picking winning attributes, including recency, source reliability, and completeness scoring. Reference data enrichment, such as using an external address-validation service to fill gaps before merging records, is also in scope. Traceability is the other thread: once a golden record is assembled, the customer needs to know which source contributed each field value. That requirement shapes how you design the data model to preserve source identifiers alongside the merged output.

How Master Data Management is tested

At 5%, MDM produces a small number of items, but they are among the most concept-dense on the exam. Items tend to present a multi-source data problem and ask you to recommend an MDM style or a survivorship approach. The reward goes to candidates who apply the concept to the scenario rather than reciting a definition. The trap is choosing an MDM style that fits the general description of the customer's industry without checking whether the scenario's specific constraints, such as an inability to retire a legacy system or a requirement for real-time data access, rule it out. Attribute-selection questions reward methodical thinking: a source that is more recent is not automatically the winner if the scenario establishes that it has lower data quality. Golden record questions often include a traceability requirement that eliminates any design which discards source provenance. Read every constraint in the scenario before committing to an answer; MDM items are written to make the first plausible option wrong for a reason buried in the scenario details.

Salesforce Data Management matches Data Modeling at 25%, but the focus shifts from abstract design to operational decisions inside a real Salesforce environment. The questions here are grounded in licensing, data consistency, multi-org architecture, and the single-customer view. If you work daily in Salesforce, some of this will feel familiar, which is exactly when candidates get complacent and drop marks by choosing what they know over what the scenario specifies.

– License types and object strategy

Salesforce license types determine which objects a user can access, and the exam tests that constraint in the context of a business requirement. Sales Cloud, Service Cloud, and platform licenses each expose different standard objects and impose different limits on custom object access. A scenario might describe a partner community user who needs read access to a custom object that is not available under their license type, and ask you to recommend a compliant design. The key is reading the license constraint before evaluating the object design. Candidates who design the right object model for the wrong license type lose the mark even if the underlying schema is sound. The exam also tests combinations: a customer with both Sales Cloud and Service Cloud licenses has a different available feature set than one with only a platform license, and the recommended object strategy changes accordingly.

– Data consistency and the single customer view

Persisting data consistently across a Salesforce org means more than preventing duplicate records. It means designing validation rules, duplicate rules, and matching rules that enforce the business's definition of a valid record at the point of entry. The exam tests which mechanism is appropriate for a described consistency requirement: a validation rule enforces a field-level constraint; a duplicate rule prevents a new record from being saved when it matches an existing one; a matching rule defines what "match" means. These three are distinct and the exam treats them as such. The single-customer view question type describes a scenario with multiple interaction systems, such as a commerce platform, a service platform, and a CRM, and asks how to represent a unified customer record on the Salesforce Platform. The expected answer involves integration patterns, external IDs, and the role of a master object that aggregates identity across systems.

– Multi-org data consolidation

As organisations grow, they often end up with multiple Salesforce instances acquired through merger, regional expansion, or product line separation. The exam tests how to consolidate or share data across those instances without losing data integrity or violating the security model. Options range from full org merge to data federation via middleware, and the right choice depends on the constraints in the scenario: whether the orgs share a common data model, whether real-time access is required, and whether the customer can tolerate a migration cutover. External IDs are central to any cross-org consolidation strategy because they preserve the source system's record identifier through the merge, enabling upsert operations and preventing duplicate creation. The exam rewards candidates who can eliminate options that would cause data loss or break referential integrity during the consolidation process.

How Salesforce Data Management is tested

This topic's items are scenario-heavy and require you to hold multiple constraints in mind simultaneously. A single item might involve a license type, an object design, and a consistency requirement, and the options will be constructed so that each one satisfies two of the three constraints while violating the third. Items reward the candidate who checks all constraints before selecting. The most common place candidates lose marks is on license-type questions: the temptation is to pick the technically elegant object design and ignore the license implication. Multi-org questions are another loss point: candidates default to recommending a full migration when the scenario's timeline or data volume makes that impractical, or they recommend middleware federation when the scenario specifies a single-org requirement. Consistency questions reward knowing the difference between the three rule types precisely enough to choose the right one for a stated business rule. Practise reading scenarios for the constraint that eliminates options, rather than for the feature that sounds relevant.

Data Governance follows naturally from data management: once you know how data is stored and consolidated, the next question is who controls it and what rules apply. At 10%, this topic is weighted enough to matter but narrow enough that focused preparation pays off quickly. The two areas to own are GDPR compliance within a Salesforce data model, and enterprise governance programme design. Both are tested at the level of recommendation, not regulation recitation.

How Data Governance is tested

Data Governance items split between regulatory compliance and programme design. GDPR questions present a data model scenario and ask you to identify which design choice makes the model compliant: where personal data is stored, how it is classified, how a right-to-erasure request can be fulfilled without breaking referential integrity, and which Salesforce features support data identification and protection. Items reward candidates who know that compliance is a design constraint, not an afterthought. The trap is selecting an option that satisfies the business requirement while ignoring the regulatory one, or vice versa. Enterprise governance questions are broader: they ask you to compare approaches for establishing ownership, stewardship, and policy enforcement across an organisation. The exam is not testing knowledge of a specific governance framework by name; it is testing whether you can evaluate the trade-offs between centralised and federated governance models in a described organisational context. Candidates lose marks by recommending a governance structure that does not match the organisation's size, regulatory exposure, or data maturity level as described in the scenario.

Performance problems in Salesforce almost always trace back to decisions made at design time, and Large Data Volume Considerations is the topic that tests whether you would make the right calls before the data grows. At 20%, it is the third-largest area on the exam. The domain covers three distinct problems: designing a model that stays performant at scale, managing storage through archiving and purging, and knowing when to stop storing data in Salesforce altogether and use virtualisation instead.

– Scalable model design and LDV performance

A data model that performs well at ten thousand records may degrade significantly at ten million. The exam tests the design decisions that determine which outcome you get. Skinny tables, indexed fields, and selective SOQL queries are all in scope, but the examinable question is always which technique applies to the described scenario. An index on a field that has low selectivity, meaning most records share a small number of values, will not improve query performance and may make it worse. The exam tests that distinction. Sharing recalculation at scale is also in scope here: a role hierarchy with many levels, combined with a large record volume, creates sharing calculation overhead that can make the org unusable. The expected design response is to flatten the hierarchy, reduce the number of sharing rules, or restructure ownership, depending on what the scenario permits. Record locking under concurrent DML on a single parent record is another LDV-specific problem the exam expects you to diagnose from a described symptom.

– Archiving, purging, and data virtualisation

Storage management in Salesforce is not just a cost question; it is a performance question. The exam tests how to design an archiving and purging plan that meets a customer's retention requirements without degrading org performance or violating data governance obligations. Big objects are one archiving target for historical data that must be retained but does not need to be queried through standard reports. External storage with a reference record in Salesforce is another pattern. The exam expects you to match the archiving approach to the scenario's retention, access, and reporting requirements. Virtualised data is the option when the customer needs to access data that lives outside Salesforce without storing it inside the org. Salesforce Connect and external objects are the primary mechanism. The exam tests when virtualisation is appropriate: it works well for read-heavy, low-volume external data access; it is a poor fit when the customer needs to run complex SOQL queries, apply sharing rules to the external data, or write back to the source system in bulk.

How Large Data Volume Considerations is tested

At 20%, this topic generates a significant share of exam items, and they are almost all performance-diagnostic scenarios. You will be given a description of a problem, such as slow report generation, timeout errors on data loads, or sharing recalculation delays, and asked to identify the design change that resolves it. Items reward candidates who connect the symptom to the correct root cause before choosing a remedy. The trap is applying a valid LDV technique to the wrong problem: recommending a skinny table for a locking issue, or recommending an index for a sharing recalculation problem, will not be rewarded. Archiving questions hinge on the access and reporting requirements: an option that solves the storage problem but removes the customer's ability to report on the archived data is wrong if the scenario requires reporting. Virtualisation questions reward knowing the limits of Salesforce Connect precisely enough to rule it out when those limits apply. Build a clear mental map of which technique addresses which class of LDV problem, and use it to eliminate before you select.

Data Migration is where design decisions meet execution reality. At 15%, it is a meaningful share of the exam, and the items test practical knowledge of loading, exporting, and moving large data sets in and out of Salesforce. Candidates who have only designed data models but never managed a migration tend to underestimate this topic; the exam asks for specific technique choices under specific constraints, and general answers do not score.

– Data quality at load time

Loading data into Salesforce without a quality gate is how production orgs accumulate debt that takes years to clean. The exam tests which techniques enforce quality at the point of ingestion rather than after. Duplicate rules and matching rules can be configured to block or flag records during a data load, but their effectiveness depends on how the matching rule is configured and whether the loading tool respects them. Validation rules run on insert and update, so they apply during a migration load unless they are deliberately bypassed, which is sometimes necessary for legacy data that cannot meet current validation standards. The exam tests that trade-off: when bypassing a validation rule is acceptable during migration and what compensating controls you put in place. Pre-load data profiling, such as identifying null rates, format inconsistencies, and referential integrity violations in the source data before loading, is the recommended approach to catching quality issues before they enter the org.

– LDV migration performance and data export

Moving large data volumes into Salesforce efficiently requires specific techniques that the exam expects you to select by scenario. Parallel loading, bulk API versus REST API, and the use of external IDs for upsert operations are all in scope. The Bulk API is designed for large-volume operations and processes records in batches asynchronously; the REST API is better for smaller, real-time operations. Choosing the wrong one for a high-volume migration will produce timeouts or governor limit errors, and the exam tests that distinction. Order of load matters for referential integrity: parent records must exist before child records reference them, and the exam will present a scenario where the load order is wrong and ask you to correct it. Exporting data from Salesforce has its own set of considerations: Data Export, Data Loader, and third-party ETL tools each have different limits on volume, scheduling, and format. The exam tests which export mechanism fits a described requirement, including whether the customer needs a one-time extract or a recurring scheduled export.

How Data Migration is tested

Data Migration items are scenario-based and almost always include a constraint that eliminates the most obvious option. A question about loading a large volume of records will include a detail, such as a hard cutover window or a referential integrity requirement, that makes the straightforward bulk load approach insufficient. Items reward candidates who read for that eliminating constraint. The most common loss point is API selection: candidates default to the Bulk API for every large-volume scenario without checking whether the scenario's latency requirement or record-type mix makes it inappropriate. Export questions reward knowing the limitations of the native export tools well enough to recognise when a third-party tool is necessary. Data quality questions reward the candidate who recommends quality enforcement at the source rather than cleanup after load. The overall pattern across this topic's items is that the rewarded answer prevents a problem rather than reacting to one. Frame your thinking around what goes wrong if you do not apply the technique, and the right option becomes easier to identify.