Free Salesforce-Platform-Development-Lifecycle-and-Deployment-Architect Practice Test Questions (2026)

Explanation

Universal Containers has 80% code coverage yet a high defect count. This signals that coverage exists but is not meaningful — tests aren't validating real business scenarios, and requirements are ambiguous.

A is correct because test classes should be derived from the test scripts in the test plan. Test scripts define the actual business scenarios, positive/negative paths, and edge cases. When developers build test classes from these scripts, tests validate real behavior rather than merely executing lines of code to hit a coverage number. This catches defects earlier and improves test quality — not just quantity.

C is correct because vague acceptance criteria are a primary root cause of defects. When criteria lack specifics (validation rules, required fields, error handling, boundary conditions), developers and testers interpret requirements differently, producing mismatched implementations and missed scenarios. Detailed, testable acceptance criteria align everyone and reduce ambiguity-driven rework.

Together, A and C attack the root causes: poor requirements and weak test design — not the symptom (coverage percentage).

Why Other Options Are Incorrect

B (increase coverage to 95%)
— Salesforce requires only 75% coverage for production deployment. Chasing 95% encourages low-value "coverage-padding" tests that assert nothing meaningful, inflating numbers without reducing defects.

B (test analyst must create test classes)
— This role constraint isn't a recognized best practice. Developers typically own Apex test classes (they know the code); test analysts own the test plan. Merging roles creates bottlenecks and doesn't inherently improve quality.

References

* Salesforce Developer Docs – Apex Testing: "Testing Best Practices" (test positive/negative cases, bulk testing, use TestDataFactory).

Explanation

During Apex testing, developers often hit governor limits because test methods execute in the same transaction context as setup data creation and assertions. Salesforce provides Test.startTest() and Test.stopTest() to address this.

When a test method calls Test.startTest(), Salesforce resets the governor limits for the code that follows, giving that block a fresh set of limits. This isolates the actual code being tested from the setup work (data creation) that ran before it. Test.stopTest() marks the end of that block and also forces any asynchronous jobs (future methods, batch, queueable) to execute synchronously so they can be asserted.

This is the official, recommended Salesforce pattern to avoid governor limit failures in tests and to properly test code.

Why Other Options Are Incorrect

B. AppExchange product to increase governor limits
— No AppExchange product can raise Salesforce governor limits. These limits are enforced by the platform and cannot be temporarily increased by third-party tools.

C. Auto reset property during off-hours
— There is no such feature. Governor limits reset per transaction, not on a time-based schedule.

D. Test.setLimit() and Test.resetLimit()
— These methods do not exist in Apex. This is a fabricated option.

References

* Salesforce Developer Docs – Apex Testing: Using Test.startTest() and Test.stopTest() — "Using startTest and stopTest to Test Governor Limits."

* Apex Developer Guide – Execution Governors and Limits: Limits are per-transaction and reset with Test.startTest().

Explanation

Mock objects in Apex testing serve two core purposes: isolating external dependencies and avoiding real callouts during tests.

A is correct because Apex tests cannot make real HTTP callouts by default. Salesforce blocks external callouts in test context to keep tests deterministic and fast. Developers must implement the HttpCalloutMock interface and register it using Test.setMock() so the code under test receives a simulated response instead of making an actual external call. Without a mock, any test hitting a callout fails with a "callout not allowed" error.

D is correct because the fundamental purpose of mocking is dependency isolation. By replacing real dependencies (external services, other classes, stateful objects) with controlled mock implementations, the developer eliminates variables outside their control and can test their own logic in isolation. This produces deterministic, repeatable, and focused unit tests — the developer controls inputs and outputs precisely.

Together, A and D capture the two legitimate reasons for mocking: callout simulation and dependency isolation.

Why Other Options Are Incorrect

B. Using Mock as a shortcut to bypass long-running processes
— Mocking is not a shortcut to skip slow code. Tests should validate actual logic; bypassing long-running processes via mocks to save time is not the purpose of mocking and can hide defects. Long-running logic should be tested separately or with Test.startTest()/Test.stopTest().

C. Mock can bypass batch jobs on classes extending Batchable
— This is incorrect. Batchable classes are tested by calling Database.executeBatch() within Test.startTest()/Test.stopTest(), which forces synchronous execution. There is no standard Mock mechanism to "bypass" batch jobs; batch Apex must actually run in tests to be validated.

References

Apex Developer Guide – Testing HTTP Callouts: Implementing HttpCalloutMock and Test.setMock() — "You can't make callouts to external services from a test method unless you use a mock."

Explanation

Salesforce recommends creating test data in ways that are deterministic, isolated, and self-contained within the test class, so tests never depend on live external systems or org state.

D is correct because loading a CSV as a Static Resource and parsing it in a test class is a documented, repeatable method for supplying sample records. The data is version-controlled, portable across sandboxes, and requires no live callout — making tests reliable and independent of org data.

C is correct because hosting a mock endpoint (or using HttpCalloutMock/Test.setMock() to simulate one) lets the test class supply sample response data for HTTP callout logic without hitting a real external service. This keeps tests self-contained and satisfies the platform rule that Apex tests cannot make real callouts.

Both methods provide controlled, reusable test data that doesn't rely on live dependencies.

Why Other Options Are Incorrect

A. Heroku Connect
— This is a real-time data synchronization tool between Salesforce and Heroku Postgres. It is not a test data creation method, and tests must never depend on live external sync services — this would make tests non-deterministic and slow.

B. Reference data from middleware directly
— Apex tests cannot make real callouts, so pulling data directly from middleware violates the callout restriction and introduces external dependencies. Test data must be created or mocked within the test, not fetched live.

References

Apex Developer Guide – Testing Best Practices: "Create test data for each test" and "Use Static Resources to load test data."

Apex Developer Guide – Test.loadData(): Loading CSV test data from a Static Resource.

Explanation

The correct answer is A. Automated tests should be run when branches are merged. In a Salesforce development and deployment process, automated testing should be integrated into the version-control workflow so that changes are validated before they are merged into the shared branch. Running tests at merge points helps identify defects, integration issues, and breaking changes before they are promoted to other environments. This provides a consistent quality gate without requiring unnecessary daily test runs across every Developer Org.

Why the other options are incorrect

B. Automated tests should be run daily in all Developer Orgs.
– Running automated tests every day in all Developer Orgs is not required as a standard deployment practice. Developer Orgs can contain work in progress, and daily testing across all of them can consume resources without providing the same quality gate as testing changes when they are merged.

C. Automated tests should be run only when merging into Full or Partial Copy sandboxes.
– Automated testing should not be limited to merges into Full or Partial Copy sandboxes. Testing should occur as part of the source-control and integration process before changes are merged, regardless of whether the destination environment is a Full or Partial Copy sandbox.

D. Automated tests should be run daily in all Developer Orgs, and when branches are merged.
– This option adds an unnecessary requirement to run automated tests daily in every Developer Org. The key recommendation is to integrate automated testing with the branch merge process, where changes are validated before becoming part of the shared codebase.

Reference

Salesforce Developer Guide: Salesforce DX Development Lifecycle — source-driven development, version control, and automated testing. Salesforce DevOps Center documentation: Development workflows and validating changes before deployment. Salesforce Trailhead: Salesforce Development Lifecycle and Source Control.

Explanation

When migrating large volumes of Accounts, Contacts, and Leads into Salesforce, the areas that must be tested are those that validate data integrity, relationships, and transformation correctness — the core risks in any data migration.

C is correct because ownership (Account Owner, Lead Owner) must be tested. Ownership drives record visibility, sharing, reporting, and assignment rules. If ownership is migrated incorrectly, users may lose access to records or see incorrect data. Verifying owner mapping from the legacy system is a critical migration test.

D is correct because data transformation must be validated against the source system. Migration rarely moves data 1:1 — fields are mapped, reformatted, combined, or converted (e.g., legacy picklist values to Salesforce picklist values, date formats, address standardization). Testing transformation ensures the target values accurately reflect the source, catching mapping errors before go-live.

E is correct because Contact-to-Account association is a key relationship that must be tested. Contacts are typically related to Accounts via AccountId, and mislinked or orphaned Contacts break reporting, sharing, and business processes. Verifying that each Contact links to the correct Account is essential for relational data integrity.

Together, these three cover the critical dimensions of a data migration test: ownership (access/visibility), transformation (data accuracy), and relationships (referential integrity).

Why Other Options Are Incorrect

A. Page layout assignments
— Page layouts are a UI configuration concern, not a data migration concern. They affect how records display but are unrelated to migrating Accounts, Contacts, and Leads. Layouts should be tested during configuration/UAT, not as part of data migration validation.

B. Lead assignment
— While lead assignment rules exist, this is a functional/business process test, not a core data migration test. The question asks about data migration specifically, and lead ownership (C) is the data-integrity concern, not assignment rule execution.

References

Salesforce Trailhead – Data Migration: Planning, mapping, transformation, and validation of migrated data.

Salesforce Well-Architected Framework – Reliability: Data integrity, referential integrity, and validation during migrations.

Explanation

Automated browser tests (UI tests using tools like Selenium, Provar, or Copado Robotic Testing) interact with a web page through its DOM (Document Object Model) — the HTML structure of elements like buttons, fields, and links. These tests locate elements using selectors (IDs, CSS classes, XPaths).

When Salesforce releases a new version, it may update the Lightning UI markup, changing element IDs, class names, or DOM structure. Even a minor DOM change can break element selectors, causing automated browser tests to fail — even though the underlying functionality still works. This is why UI-based tests are brittle and require frequent maintenance after releases.

Why Other Options Are Incorrect

A. New Apex methods
— Apex is server-side logic. New methods don't affect browser test selectors. Apex changes would only impact unit tests or API-level tests, not UI browser tests.

B. Metadata schema changes
— Schema changes (e.g., new fields, objects) affect data structure and configuration, not the DOM structure itself. Browser tests would only be impacted if the schema change alters the UI layout — and that's still a DOM concern, not the schema itself.

D. New standard fields
— Adding standard fields changes data model configuration but doesn't inherently alter the DOM in a way that breaks selectors. Fields appear in UI only if added to layouts, and the impact would again be a DOM/layout concern, not the field itself.

References

 Salesforce Release Notes / Lightning Experience: UI updates and markup changes each release.

 Salesforce Trailhead – Application Lifecycle Management: Maintaining automated UI tests across releases.

Explanation

Salesforce treats performance testing as a controlled activity because aggressive load tests can impact shared infrastructure and other tenants. To protect the platform, Salesforce requires customers to follow a formal process before running performance tests.

A is correct because Salesforce requires advance notice — at least 7 days — before performance testing begins. This allows Salesforce to prepare, schedule, and coordinate the test window so it doesn't disrupt production services. Running tests without notice can result in throttling or blocked traffic.

B is correct because Salesforce actively monitors performance test activity. This monitoring ensures the tests don't cause issues with Salesforce services (for the customer or other tenants) and allows Salesforce to intervene if problems arise.

D is correct because a business justification must be provided to Salesforce before performance testing is approved. Salesforce uses this to evaluate whether the test is legitimate and to determine appropriate safeguards. Without a valid justification, performance testing is not permitted.

Together, these three describe Salesforce's official performance testing policy: notify in advance (A), accept monitoring (B), and justify the need (D).

Why Other Options Are Incorrect

C. Performance tests must be run in a sandbox
— This is incorrect. Salesforce does not allow performance/load testing in sandboxes because sandboxes share the same infrastructure as production and could impact other orgs. Performance testing is conducted under Salesforce's supervision, typically in coordination with Salesforce, not simply "in a sandbox."

E. Tests may run without notice, but logs won't be stored
— This is false. Running performance tests without advanced notice is not permitted. Salesforce requires notification and can block or throttle unannounced load testing. This option contradicts the actual policy.

References

Salesforce Help – Performance Testing: "Salesforce Performance Testing Policy" — requires advance notice (7 days), business justification, and Salesforce monitoring.
Salesforce Trust & Compliance: Acceptable Use Policy regarding load/performance testing.

Explanation

Cloud Kicks needs thorough batch data testing before Go-Live. The key requirement here is data volume and realistic data — batch testing must validate performance and logic against large datasets that resemble production. Only sandbox types that include sampled or full production data can support this.

C is correct because a Partial Copy sandbox includes a subset of production data (based on a sandbox template you define). This makes it well-suited for batch data testing, integration testing, and UAT where realistic data volume and record relationships matter, without the full storage cost of a Full sandbox.

D is correct because a Full sandbox is an exact replica of production, including all data, metadata, and configuration. It is the only sandbox type that supports true full-volume load and performance testing. For a major Go-Live with thorough batch testing, a Full sandbox provides the most accurate environment to validate batch jobs at production scale.

Together, C and D are the only sandbox types that carry production data, which is essential for meaningful batch data testing.

Why Other Options Are Incorrect

A. Developer sandbox
— Contains metadata only (no production data), with a small 200 MB storage limit. It's designed for isolated development and unit testing, not batch data testing at scale.

B. Developer Pro sandbox
— Also metadata only, with more storage (1 GB) than Developer but still no production data. It supports development and integration work but cannot support realistic batch data testing.

Neither Developer nor Developer Pro includes production data, so they cannot validate batch jobs against realistic datasets.

References

Salesforce Help – Sandbox Types and Templates: Developer, Developer Pro, Partial Copy, and Full sandbox capabilities and data inclusion.

Salesforce Trailhead – Sandboxes: Choosing the right sandbox for testing needs.

Explanation

Universal Containers needs data volume testing early in the lifecycle to catch performance defects, but regulations prohibit production data in non-production environments. The architect must recommend options that provide realistic data volume and shape without violating the data privacy constraint.

A is correct because a Full sandbox is refreshed with production data, and data masking (using tools like Salesforce Data Mask, or third-party apps) anonymizes/scrambles sensitive fields after the refresh. This satisfies the regulatory requirement while preserving realistic data volume, relationships, and distribution — ideal for data volume and performance testing.

B is correct because generating mock/synthetic data that mimics production shape (fields, relationships, distributions) and volume (record counts) provides a compliant way to run data volume testing. Tools like Salesforce's own data generation utilities or third-party tools can create large datasets without exposing real production data. This is a common, regulation-safe approach.

Together, A and B are the two viable options: mask real data (A) or synthesize realistic data (B) — both enable data volume testing without violating privacy regulations.

Why Other Options Are Incorrect

D. Use Query Analyzer in production
— Query Analyzer is a read-only diagnostic tool used to analyze query performance in production. It does not support data volume testing in non-production environments and doesn't help resolve performance defects earlier in the lifecycle. It also doesn't address the regulatory constraint.

E. Request a Partial Sandbox copy after the next Salesforce release
— A Partial Copy sandbox includes only a subset of production data (up to 5 GB by default) and still contains real production data, which violates the regulation prohibiting production data in non-production environments. Additionally, timing it to a Salesforce release is irrelevant to the data privacy issue.

References

 Salesforce Help – Sandbox Types and Templates: Full sandbox includes production data; Partial Copy uses a data subset.
Salesforce Help – Data Mask: Anonymizing/masking sensitive data in sandboxes.