Free Salesforce Platform Development Lifecycle and Deployment Architect Practice Test Questions
Topic: Testing
118 questionsUpdated 13-Nov-20268 topics
TopicTesting
Question 1Choose 2
Universal Containers has 80% code coverage. Despite the creation of a test plan for each sprint, the number of
defects is large.
What two items should the architect recommend to reduce defects? Choose 2 answers
Correct answer:
A. The test script should be used to define the test classes.
C. The acceptance criteria should have more details.
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).
Question 2Choose 1
Northern Trail Outfitter ' s development team has built new features for its sales team in the Asia-Pacific
region. While testing the Apex classes, the developers are constantly hitting the governor limits.
What should the architect recommend during the review to address this issue?
Correct answer:
A. Use test.startTest() and test.stopTest() methods to reset governor limits.
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().
Question 3Choose 2
Which two statements are accurate about why Mock objects are needed when writing test classes? Choose 2
answers
Correct answer:
A. Mock is needed whenever the code makes an HTTP callout.
D. Using a Mock allows the test class to bypass the dependencies of other objects, methods, state, or
behaviors. Therefore, the developer has total control of his own code.
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."
Question 4Choose 2
Which are two recommended methods of creating test data in Salesforce? Choose 2 answers
Correct answer:
C. Host a mock endpoint to produce sample information from an endpoint.
D. Load a CSV as a static resource and reference it in a test class.
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.
Question 5Choose 1
Cloud Kicks is considering using an automated testing tool to help manage deployments between
environments.
When should the architect recommend the use of an automated testing tool?
Correct answer:
A. Automated tests should be run when branches are merged.
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.
That's the last free question in Testing
You've seen the free 25% of this topic (5 of 22 questions). Get complete access for every question, explanation and the timed exam simulator.
Our timed 2026 Salesforce Platform Development Lifecycle and Deployment Architect practice test mirrors the format, number of questions and time limit of the official exam.
The #1 challenge isn't just knowing the material, it's managing the clock. The simulation builds your speed and stamina, so you walk in knowing exactly what to expect.
Build exam stamina: stay focused and accurate for the entire duration.
Master time management: learn to pace yourself so you never have to rush.
A new test every time: a randomised set from the Salesforce Certified Platform Development Lifecycle and Deployment Architect question pool on every attempt.
Unlimited attempts: practice until you're 100% confident, not just once.
