Salesforce-Platform-Data-Architect Practice Test Questions

Use Big objects for cases older than 2 years, and use nightly batch to move them.

Use Heroku and external objects to display cases older than 2 years and bulk API to hard delete from Salesforce.

Explanation:

✅ C. Use Big objects for cases older than 2 years, and use nightly batch to move them.
Big Objects are designed to handle massive amounts of data that do not need to be accessed frequently, which makes them ideal for storing historical data like cases older than 2 years. They support standard querying via SOQL with some limitations and are cost-effective for long-term storage. A nightly batch job ensures that eligible data is moved regularly.

✅ D. Use Heroku and external objects to display cases older than 2 years and bulk API to hard delete from Salesforce.
Heroku with external objects (via Salesforce Connect) is a good strategy for providing on-demand access to historical data that is stored outside Salesforce. This method maintains Salesforce data volume limits and performance, and Bulk API can be used to delete old records after they’ve been archived externally.

❌ A. Use custom objects for cases older than 2 years and use nightly batch to move them.
This increases storage usage in Salesforce and does not significantly reduce org size. It also lacks the querying performance benefits of Big Objects or external systems.

❌ B. Sync cases older than 2 years to an external database, and provide access to Service agents to the database
While viable in concept, this lacks seamless integration within the Salesforce UI. Service agents would need to leave Salesforce to access case data, which hurts productivity.

📚 Reference:
Salesforce Help: Big Objects Overview
Salesforce Architect Guide: Data Archiving Strategies

Implement a workflow rule that sends Opportunity data through Outbound Messaging.

Explanation:

✅ B. Implement a workflow rule that sends Opportunity data through Outbound Messaging.
Outbound Messaging is a native point-and-click feature that supports real-time integration (or near real-time) without requiring Apex code. It’s ideal for one-way data transfers like copying Closed/Won Opportunities to a read-only ERP system.

❌ A. Implement a Master Data Management system
MDM is overkill for this use case. It adds unnecessary complexity when Salesforce is clearly the system of record for Opportunities.

❌ C. Have the ERP poll Salesforce nightly
Polling is not real-time and is resource inefficient. It can also miss near-term updates or cause synchronization delays.

❌ D. Implement an hourly integration
An hourly schedule is not considered "real-time". Outbound Messaging provides immediate updates, which is the core requirement here.

Reference:
Salesforce Help: Outbound Messaging Overview
Salesforce Integration Patterns and Practices

Change the master-detail relationship to a lookup relationship.

Explanation:

✅ D. Change the master-detail relationship to a lookup relationship.
Master-detail relationships require the detail record to have a parent. To allow creation of standalone discount requests, a lookup relationship is appropriate. It allows flexibility—linking to a custom product when applicable and remaining unlinked otherwise.

❌ A. Mandate the selection of a custom product
This violates the requirement for "generic" discount requests which must exist without a product.

❌ B. Create a placeholder product record
Workarounds like a fake “Generic Product” create messy data, skew reports, and complicate governance. Not sustainable.

❌ C. Remove the master-detail relationship and keep the objects separate
Removing the relationship entirely would break reporting and data integrity when a discount request does need to be tied to a product. Lookup gives optionality without losing relational structure.

📚 Reference:
Salesforce Help: Relationship Considerations
Salesforce Object Relationships Overview

Create a Dashboard using Analytics Cloud that will allow the user to create ad-hoc lenses and drill down.

Explanation:

This question tests the knowledge of the right analytics tool for the job, specifically focusing on advanced features like ad-hoc exploration and mobile usability.

Why D is Correct: Salesforce Analytics Cloud (Tableau CRM) is specifically designed for this purpose. It provides:

✔️ Advanced Data Exploration: Users can create ad-hoc "lenses" to explore data dynamically without a pre-built report.
✔️ Powerful Drill-Down: It allows users to start from a high-level dashboard and interactively drill down into the underlying details by clicking on data points.
✔️ Mobile-First Design: Analytics Cloud dashboards are built to be fully functional and interactive on mobile devices, perfectly matching the requirement for managers "on the move."
✔️ Smart Filtering: It supports adding and changing filters on the fly for true exploratory analysis.

Why A & B are Incorrect (External Dashboard): While external tools are powerful, they introduce complexity.
→ Exporting data to an external system creates a data silo, adds latency, and requires managing a separate security model.
→ Embedding an external dashboard (e.g., via Canvas) often results in a clunky user experience, especially on mobile, and may not provide the seamless, native integration required for the best mobile exploration.

Why C is Incorrect (Standard Salesforce Dashboard): Standard Salesforce dashboards are excellent for monitoring predefined KPIs based on standard reports. However, they are not designed for ad-hoc data exploration.
→ Users cannot create new filters or change the grouping of data on the fly from a mobile device; they can only interact with the filters that were pre-configured.
→ The drill-down capabilities are much more limited compared to Analytics Cloud.

Reference: The key differentiator is "ad-hoc filters while on the move." This is the core value proposition of Salesforce Analytics Cloud/Tableau CRM over standard reporting.

Implement shield platform encryption to encrypt and standard fields

Explanation:

This question evaluates the understanding of native, scalable encryption solutions on the Salesforce platform, particularly for sensitive data like health records.

Why C is Correct: Shield Platform Encryption is Salesforce's native, managed solution for encrypting data at rest. It provides:
➡️ Comprehensive Coverage: It can encrypt a wide range of standard and custom field types (text, number, email, etc.) without changing how users or apps interact with the data (it's transparent encryption).
➡️ Security and Compliance: It is specifically designed to help meet stringent compliance requirements like HIPAA for healthcare data, which is implied by "patient and health records."
➡️ Manageability: It is administered through point-and-click setup in the Salesforce UI, making it manageable for administrators without code.

Why A is Incorrect (Apex Crypto Class): The Apex Crypto class is used for encrypting data in transit (e.g., in a callout) or for storing encrypted data in a text field temporarily. It is not a solution for encrypting data at rest in standard and custom fields across an entire org. It would require a massive, custom-coded rewrite of all data access patterns and is not a feasible or secure solution for this requirement.

Why B is Incorrect (Classic Encryption): "Classic encryption" is not a defined Salesforce feature. This is a distractor term.

Why D is Incorrect (Export data and encrypt): Exporting sensitive data like health records to an external system to encrypt it is a major security risk and compliance violation. It exposes the data during the export process and breaks the security and audit trail within Salesforce. The encryption must happen within the secure confines of the Salesforce platform.

Reference: Shield Platform Encryption is the standard and recommended answer for any question about encrypting field data at rest in Salesforce, especially for regulated industries.

Put the business purpose in the Description of each field.

Maintain a data dictionary with the justification for each field.

Explanation:

This question addresses the principles of data governance, documentation, and maintaining clarity between business requirements and technical implementation over time.

Why B is Correct: Using the Description field on every object and field is a fundamental and easily accessible form of documentation. It is stored directly in the metadata, making it visible to any admin or developer working in the org's setup. This provides immediate context for what a field is for and why it exists, directly linking it to its business requirement.

Why C is Correct: A Data Dictionary is the comprehensive, single source of truth for an organization's data assets. It provides a detailed view that goes beyond the field description, including information like data owners, data sensitivity, approved values, and the specific business requirement that justified the field's creation. This is essential for tracing changes back to original requirements, especially during a long, phased project.

Why A is Incorrect (Setup Audit Trail): The Setup Audit Trail is a fantastic tool for tracking who made a change when and what the change was. However, it does not track the why. It will show that a field was created, but it cannot trace that action back to the detailed business requirement that justified it.

Why D is Incorrect (Save metadata in source control): Using source control (e.g., Git) is a development best practice for tracking changes to metadata over time and managing deployments. However, like the Setup Audit Trail, it tracks the what and the how of a change, not the business reason why the change was made. The requirement justification must be documented within the metadata itself (Description) or in a companion document (Data Dictionary).

Reference: A core responsibility of a Data Architect is to ensure data is well-documented and traceable. This is achieved by embedding documentation in the org (Descriptions) and maintaining external governance artifacts (Data Dictionary).

Use Accounts for dealers, and create record types for each of the dealer types.

Explanation:

Option A is the best and most scalable solution. A Record Type is specifically designed for this exact scenario. It allows you to use a single standard object, like the Account object, to represent different types of records that share a common purpose (being a "dealer" or "customer"). For each record type (Local dealer, Regional distributor, etc.), you can:

➡️ Display different fields by assigning different page layouts, ensuring users only see the attributes relevant to that dealer type.
➡️ Present different picklist values for the same field (e.g., different values for a "dealer status" picklist).
➡️ Implement different business processes or stages (e.g., a different sales process for a "regional distributor" vs. a "service dealer"). This is a fundamental best practice for data architecture on the Salesforce platform, enabling a streamlined user experience while centralizing data for reporting and analysis.

Option B is incorrect. Custom views only filter and display data that already exists; they cannot enforce different page layouts or business rules for data entry, nor can they hide fields.

Option C is incorrect. A custom picklist field to differentiate dealer types would not solve the problem of showing different attributes for each type. Users would still see all fields for all dealer types on a single page layout, leading to a cluttered interface and potential data entry errors.

Option D is incorrect. Creating a separate custom object for each dealer type is a poor data model choice. While it would allow for different fields and rules, it would create data silos. This would make reporting, automation, and overall data management across all dealers extremely difficult. For example, to find all dealers regardless of type, you would have to run a separate report for each object and combine them.

References:
Salesforce Help & Training: The official documentation on Record Types provides a clear definition and use cases that perfectly match this question's requirements.
Trailhead - Data Modeling: The "Record Types" module in Trailhead's Data Modeling trails explains how record types can be used to tailor the user experience and business processes on a single object.

Bulk API

Explanation:

✅ A. Bulk API
Designed for handling large data volumes. It allows batching, is optimized for speed, and minimizes governor limits, making it the best tool for exporting millions of records.

❌ B. REST API
REST API and SOAP API are typically used for real-time, smaller-scale transactions (e.g., creating a single record, retrieving a few records) and are not optimized for millions of records. Using them for this purpose would be slow, prone to timeouts, and would likely hit governor limits.

❌ C. Streaming API
Streaming API is designed for real-time, event-based data. It's used to receive notifications when changes are made to Salesforce data (e.g., a new record is created), not for exporting existing data in bulk.

❌ D. SOAP API
Slower and subject to strict limits. Not ideal for high-volume data operations.

References:
Salesforce Developer Documentation: The Salesforce API guide explicitly states that the Bulk API is the recommended tool for dealing with large data volumes (typically more than 2,000 records).
Trailhead - Integration Basics: The modules on Salesforce APIs and integration patterns define the specific use cases for each API, with the Bulk API clearly identified for large-scale data transfers.

Explanation:

The recommended approach is to refresh the full copy sandbox because it's the only method that reliably returns the sandbox to a clean, production-like state for a high-stakes, pre-go-live test.

A full copy sandbox is an exact replica of your production org, including all data, users, and metadata. This makes it the only environment suitable for a final, end-to-end performance and data migration test.

Refreshing the sandbox completely wipes all existing data and metadata and replaces it with a fresh copy of production. This ensures the testing environment is clean and ready for the new data load, replicating the conditions of the production migration as closely as possible. It eliminates any potential residual data, configuration changes, or sharing settings from previous tests that could skew the results of the final dry run.

Why other options are incorrect:

A and D (Truncate/Hard Delete):
While truncating and hard deleting data can clear out records, they do not reset the sandbox's metadata or configuration. This could lead to an inconsistent state where previous test configurations or other changes could interfere with the final migration test. More importantly, truncating or hard deleting 50 million records can be a time-consuming and resource-intensive process in itself, making it an inefficient solution.

C (Hard delete):
Similar to truncation, hard deleting the data manually is not a reliable way to reset the environment. It does not reset the configuration or metadata, and it's not a scalable or efficient way to clear millions of records.

References:
Salesforce Sandbox Guide: Salesforce documentation on sandboxes clearly states that full sandboxes are intended for "performance testing, load testing, and staging" and that refreshing a sandbox is the primary way to get a clean copy of production.
Salesforce Data Migration Best Practices: Standard data migration methodologies emphasize testing in a pristine environment that mirrors production as closely as possible, which is the core benefit of refreshing a full copy sandbox before a critical migration event.

Use the Account object with Person Accounts and a new B2C page layout.

Explanation:

Option A is the standard and recommended Salesforce solution for B2C data. Person Accounts are a special type of account designed for B2C use cases where each customer is an individual, not a company. They merge the Account and Contact objects into a single record to represent an individual person. Since UC is a B2C company now, Person Accounts provide a native, out-of-the-box data model that is scalable for the expected volume of 50 million consumers. A new page layout specific to B2C will ensure users see the correct fields and information for these individual customers.

Option B is incorrect. Using a standard Account record with a record type would still require a separate Contact record for each person. This duplicates data and creates a clunky, inefficient data model for a B2C business that doesn't need to track multiple contacts per account. It is a very poor fit for this business case.

Option C is incorrect. Creating a picklist value on the Account Type field doesn't change the underlying data model. You would still have to create separate Contact records, which is inefficient for B2C.

Option D is incorrect. This approach would be a massive breach of data integrity. Storing 1 million contacts under a single umbrella account is a terrible data model that would lead to severe performance issues, reporting limitations, and a complete lack of data governance. It would make it virtually impossible to find specific customer data.

References:
Salesforce Help & Training: The official documentation on Person Accounts provides a thorough explanation of their purpose and how they are the correct solution for B2C use cases.
Trailhead - Build a B2C Solution: Trailhead modules on B2C solutions and data models explicitly promote the use of Person Accounts as the best practice for consumer-centric businesses.