Salesforce-Platform-Data-Architect Practice Test Questions

Explanation:

“Unable to lock row” happens when multiple processes or users attempt to update the same record (or related records) at the same time. In Territory Management and Account Sharing, this is common because Salesforce by default locks entire account hierarchies or user groups during updates.

Granular locking changes the locking behavior: instead of locking entire hierarchies, Salesforce locks smaller record groups. This reduces contention and makes operations like moving users between territories or updating large sets of accounts less likely to fail. It’s specifically designed to address “row lock” issues in environments with large data volumes and complex sharing.

Why not the others?

A. Reduce number of users updated concurrently: Might lower the chance of conflicts, but it doesn’t eliminate the core issue. It also slows down business processes.

C. Analyze Splunk query: Monitoring tools may show errors but won’t fix the underlying Salesforce locking mechanism.

D. Increase CPU for the Salesforce org: Salesforce is a multi-tenant platform. Customers cannot allocate CPU; scaling is managed by Salesforce itself.

Reference:
Salesforce Help: Granular Locking Overview

Explanation:

While Salesforce offers multiple options for exporting data, restore is the tricky part. Simply extracting data into an EDW or flat files isn’t enough, because restoring requires handling parent-child relationships, metadata dependencies, and maintaining referential integrity.

AppExchange backup and restore solutions (like OwnBackup, Spanning, or Odaseva) are purpose-built for Salesforce. They provide:

→ Automated daily backups
→ Point-in-time recovery
→ Metadata and relationship-aware restores
→ Sandbox seeding and compliance features

This makes them the most reliable and least risky approach for backup and restore.

Why not the others?

B. ETL to/from EDW: Backups are possible, but restore is complex and error-prone. You’d need custom scripts to rebuild relationships.

C. Bulk API + REST API: Reinventing the wheel. Too much maintenance and still risky for restore accuracy.

D. Daily backup + custom restore: Same issue — costly, error-prone, and lacks the resilience of proven tools.

Reference:
Salesforce Help: Backup and Restore Solutions
AppExchange Backup & Restore Solutions

Explanation:

The Setup Audit Trail is Salesforce’s way of tracking administrative changes — such as creating, modifying, or deleting fields. It captures who made the change, what was changed, and when the change happened. The audit trail stores history for the last 6 months, which covers the request to look back 2 months. You can view the trail in Salesforce or export it as CSV for more detailed analysis.

🔴 Why not the others?

A. Remove "customize application": Prevents future changes but doesn’t provide history of past changes.

B. Export metadata: Shows the current state of fields, not the change history.

C. Field history report: Tracks data changes inside records, not configuration or metadata changes like field creation/deletion.

Reference:
Salesforce Help: Monitor Setup Changes with the Audit Trail

Explanation:

🟢 Option B is the correct and most efficient approach. This solution directly addresses both the CEO's requirement and the data storage issue.

✔️ "Annually aggregate order amount data to store in a custom object" directly meets the CEO's need for year-over-year customer revenue tracking. This new, smaller record holds the summarized data (total amount for all orders in a given year for a specific customer), which is all that's needed for the report.

✔️ "Delete those orders and order line items" is the key archiving step that frees up significant data storage. The original 1 million orders and 10 million line items per year are no longer needed for daily operations, and their summarized data is stored in the new custom object, which takes up a fraction of the storage space. This is a classic summary archiving strategy.

🔴 Option A and C are incorrect. While exporting and deleting data addresses the storage problem, simply storing the raw data in a zip file outside Salesforce doesn't meet the CEO's requirement for sales reps to "see how much money each customer generates year-over-year" within the Salesforce platform. The data would not be accessible for reporting.

🔴 Option D is incorrect. Deleting the records without retaining a summary in Salesforce or ensuring the sales reps have access to the information they need would fail to meet the business requirement. This approach focuses solely on the storage problem at the expense of functionality.

Explanation:

Why C is correct?
✅ Option C is the most critical recommendation for ensuring long-term scalability. With an expected 5 million invoices and 50 million invoice line items per year, the data volume will quickly exceed Salesforce's storage limits and degrade performance. A data architect's primary responsibility is to manage this volume. A sound data archiving strategy is a fundamental part of the product's architecture that a vendor must have to handle this volume.

Why Other Options are incorrect?

❌ Option A is incorrect. Referencing Opportunity Line Items is not relevant to the new accounting product's scalability. While it might be part of the product's data model, it doesn't solve the problem of managing the massive volume of new invoice and invoice line item records.

❌ Option B is incorrect. While Wave Analytics (now CRM Analytics) is a great tool for analyzing large datasets, it doesn't solve the underlying problem of data storage and platform performance. It is a reporting and analytics tool, not a data management or archiving solution.

❌ Option D is incorrect. Running 100% natively on the Salesforce platform is a common requirement for AppExchange products, but it doesn't inherently guarantee scalability for high-volume data. A native app can still cause performance and storage issues if it doesn't have a built-in archiving strategy to manage its growth. The data volume described is the key concern.

Implement a master data management (MDM) strategy for customer data.

Explanation:

✅ Option B is the correct solution. The problem describes a common scenario in large enterprises: multiple systems (often called a multi-system landscape) needing consistent and accurate customer information. Master Data Management (MDM) is the discipline and set of tools used to create a single, authoritative source of master data (in this case, customer data). An MDM solution would ensure that all connected systems are accessing a "golden record" of the customer, preventing data inconsistencies and ensuring everyone has the "same customer information."

❌ Option A is often part of an MDM strategy, but it's not the complete solution. Simply making Salesforce the system of record (SoR) doesn't solve the problem of propagating that data consistently to other systems or resolving data conflicts if other systems also create customer records. An MDM strategy would define the rules for this synchronization and data governance.

❌ Option C is incorrect. Loading customer data into all systems without a central management strategy would lead to massive data inconsistencies, as each system would likely have its own version of the customer data, leading to a fragmented and unreliable view.

❌ Option D is incorrect. Letting each system be the "owner of data it generates" is a recipe for data silos and inconsistencies. This is the very problem that an MDM strategy is designed to solve. It would lead to a fragmented customer view, where different departments or systems have conflicting information about the same customer.

RecordType

CustomField

Explanation:

Data architecture focuses on how data is structured, stored, related, and governed within an organization. Therefore, the documentation must include metadata types that define the core structure and behavior of data.

Why A is Correct (RecordType):
Record Types control the business processes, page layouts, and picklist values available to a user for a specific record. They are a crucial part of data architecture as they define how different data segments are presented and managed within the same object. Documenting which Record Types exist and their criteria is essential for understanding data flow and user interaction.

Why C is Correct (CustomField):
Custom Fields are the fundamental building blocks of custom data structures in Salesforce. They define the attributes and data points (e.g., text, number, date, relationship) stored for each record. Documenting all Custom Fields, their data types, and their relationships is the very core of data architecture documentation.

Why B is Incorrect (Document):
The "Document" metadata type refers to files stored in the Documents tab, which are used for branding (like images for email templates) or other static file storage. While important for an organization, these are content files, not structural elements of the data model, and are not a primary concern for data architecture documentation.

Why D is Incorrect (SecuritySettings):
While security is intrinsically linked to data (governing who can see what), Security Settings (e.g., password policies, network access) are part of the application's security and access architecture, not its data architecture. The data architecture document would reference security in the context of field-level security or sharing rules, not these org-wide settings.

Reference:
The core of the Data Architect exam revolves around data modeling, which is defined by objects (standard and custom), fields (standard and custom), and relationships. Record Types and Custom Fields are primary components of this model.

Explanation:

This question tests the knowledge of native Salesforce tools designed for auditing and monitoring user activity, particularly at the event level.

Why C is Correct (Event Monitoring):
Event Monitoring is a native Salesforce capability (part of Salesforce Shield) that is specifically designed to capture and log detailed information about user interactions. It generates event log files for exactly the types of actions listed:

✔️ Login and Logout are captured in the LoginEvent and LogoutEvent log files.
✔️ File Attachment Download is captured in the URI log file.
✔️ Package Install is captured in the PackageInstallRequest log file.
This is the standard, out-of-the-box solution for this security and compliance requirement.

Why A is Incorrect (Field Audit Trail):
Field Audit Trail is designed to track changes to field values on a record. It is excellent for knowing what data was changed, from what value to what value, and by whom. It does not track broader user events like logins, logouts, or file downloads.

Why B is Incorrect (Custom object and trigger):
While technically possible to build a custom auditing solution, it would be incredibly complex, fragile, and unsustainable. It would require writing triggers for every possible object and action, could not track system-level events like login/logout, and would not be a recommended "best practice" when a robust, scalable, native tool like Event Monitoring exists.

Why D is Incorrect (Third-party AppExchange app):
While an AppExchange app might leverage Event Monitoring APIs or provide a user interface for it, the question asks for the "recommended approach for defining a solution." The core, underlying technology that any robust solution would be built upon is Salesforce's native Event Monitoring. Recommending a third-party app before evaluating the native tool is not the best architectural practice.

Reference:
The Event Monitoring unit on Trailhead and the Salesforce Help documentation on "Event Monitoring Overview" detail the specific event types that are logged, which align perfectly with the actions listed in the question.

Einstein Analytics

AppExchange Apps

Explanation:

DreamHouse Realty has reached the limits of Salesforce’s native reports and dashboards, which are constrained by factors like the number of records, complexity of calculations, and visualization capabilities. They need advanced analytical insights in a multi-system ERP environment, suggesting a need for robust reporting and integration capabilities. Let’s evaluate each option:

Option A: Weekly Snapshots
Weekly snapshots allow capturing point-in-time data for reporting trends over time, but they are still part of Salesforce’s native reporting framework. They are limited in handling complex analytics, cross-system data integration, or advanced visualizations, and they consume storage space. This does not fully address the need for more analytical insights beyond native limits.

Option B: Einstein Analytics (now Tableau CRM)
Einstein Analytics is a powerful Salesforce-native analytics platform designed for advanced data analysis, visualization, and predictive insights. It can handle large datasets, integrate with external ERP systems via connectors (e.g., Salesforce Connect or middleware), and provide interactive dashboards and AI-driven insights. This makes it an ideal solution for overcoming the limitations of native reports and dashboards, aligning with the company’s need for advanced analytics.

Option C: Setup Audit Trails
Setup Audit Trails track changes to Salesforce configuration and metadata, such as user permissions or field modifications. They are unrelated to analytical reporting or dashboards and do not help with providing insights from sales, support, or marketing data.

Option D: AppExchange Apps
AppExchange offers a variety of third-party analytics and reporting tools (e.g., Domo, Power BI integrations) that can extend Salesforce’s native capabilities. These apps often provide advanced visualization, cross-system data integration, and customizable dashboards, making them a viable option for addressing the limitations of native reports in a multi-system ERP environment.

Why B and D are Optimal:
Einstein Analytics (B) is a Salesforce-native solution that provides advanced analytics and seamless integration with Salesforce data and external systems, directly addressing the need for enhanced insights. AppExchange Apps (D) offer flexible, third-party solutions that can be tailored to specific analytical needs, especially for integrating with ERP systems. Together, these approaches provide robust options for overcoming the limitations of native reports and dashboards.

References:
Salesforce Documentation: Tableau CRM (Einstein Analytics) Overview
Salesforce AppExchange: Analytics Apps
Salesforce Help: Reporting Snapshots

Use Batch Apex to archive old data on a rolling nightly basis.

Explanation:

The challenge is to improve the user experience for Sales Reps by ensuring searches return only relevant (recent) records, while preserving old data for Sales Managers’ historical reporting needs. The organization has sufficient storage, so the solution must focus on data visibility and performance rather than reducing storage usage. Let’s analyze each option:

Option A: Create a Permission Set to hide old data from Sales Reps.
Permission Sets control access to objects, fields, or features, but they cannot filter records based on criteria like age or relevance (e.g., created date). While you could use sharing rules or criteria-based sharing to limit access, this would require complex configurations and might not fully address search performance, as old records would still appear in searches unless explicitly filtered.

Option B: Use Batch Apex to archive old data on a rolling nightly basis.
This is the best approach. Batch Apex can be used to move old, irrelevant records (e.g., based on a date field) to a custom object, Big Object, or external system for archival purposes. This keeps the primary objects (e.g., Opportunities, Accounts) lean, improving search performance for Sales Reps. The archived data remains accessible for Sales Managers’ historical reporting via reports or integrations. A nightly batch process ensures the archive is updated regularly without manual intervention, balancing user experience and data retention needs.

Option C: Archive and purge old data from Salesforce on a monthly basis.
Purging (deleting) old data would make it unavailable for Sales Managers’ historical reporting, which conflicts with the requirement to retain the data. While archiving to an external system is viable, purging from Salesforce is not, as it would remove the data entirely. Additionally, a monthly cadence is less efficient than a nightly process for maintaining performance.

Option D: Set data access to Private to hide old data from Sales Reps.
Setting the organization-wide default (OWD) to Private restricts access to records based on ownership or sharing rules, but it doesn’t address the issue of old records cluttering searches. Old records would still appear in searches for users with access, and configuring sharing rules to hide old records based on age is impractical and doesn’t optimize search performance.

Why Option B is Optimal:
Using Batch Apex to archive old data on a nightly basis directly addresses the Sales Reps’ complaint by reducing the volume of records in active objects, improving search performance. It also ensures old data is preserved in an accessible format (e.g., Big Objects or external storage) for Sales Managers’ reporting needs. This aligns with Salesforce’s best practices for managing large data volumes (LDV) and optimizing user experience.

References:
Salesforce Documentation: Batch Apex
Salesforce Architect Guide: Large Data Volumes Best Practices
Salesforce Help: Archiving Data in Salesforce