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

Explanation

UC is building a high-volume REST integration (100K+ orders/day, each with up to 10 line items). The concern is that users don't face platform slowdowns during peak business hours. This is fundamentally a question about how the system behaves under realistic and expected high-volume conditions — which is exactly what load and performance testing validate.

B is correct because Load Testing simulates the expected peak volume of concurrent requests to verify the system can handle the anticipated workload. With 100K+ orders per day arriving as individual REST requests, load testing confirms the web service, Apex logic, and database operations sustain that throughput without degradation. It directly answers: "Can the system handle the expected load?"

C is correct because Performance Testing measures response times, throughput, and resource utilization under that load. It verifies that business logic, validations, and DML operations complete within acceptable timeframes so users don't experience slowdowns. Load and performance testing are complementary — load tests generate the volume, performance tests measure whether behavior stays within acceptable thresholds.

Together, B and C ensure the integration scales to expected volume and maintains acceptable response times during peak hours — directly addressing the "no slowdowns" requirement.

Why Other Options Are Incorrect

A. Unit Testing
— Unit tests validate individual pieces of code in isolation (a single method or class). While essential for correctness, they cannot simulate 100K orders/day or reveal platform slowdowns under concurrent load. Unit testing doesn't address the performance concern.

D. Stress Testing
— Stress testing pushes the system beyond expected limits to find the breaking point and observe failure behavior. While valuable, it tests extreme/abnormal conditions, not the expected peak load described here. The question asks about ensuring no slowdowns during peak business hours (expected high load), which is load/performance testing — not breaking-point stress testing.

References

Salesforce Well-Architected Framework – Performance: Load and performance testing for high-volume integrations.

Salesforce Help – Performance Testing: Guidelines and the performance testing policy (advance notice required).

Explanation

The question asks which configuration item should be covered by executable tests. Among the options, Validation Rules are the configuration that can be directly and meaningfully verified through Apex test methods.

Validation rules are enforced at the database/DML level. When an Apex test performs a DML operation (insert/update) that violates a validation rule, Salesforce throws a DmlException. Developers can write test methods that:

* Attempt to insert/update a record that should fail → assert a DmlException is thrown.
* Attempt a valid record → assert it succeeds.

This makes validation rules testable via executable Apex tests, ensuring they behave correctly as part of the deployment pipeline.

Why Other Options Are Incorrect

A. Active Process Builders
— Process Builder was a declarative, point-and-click automation tool (now retired in favor of Flow). It cannot be directly invoked or asserted against in an Apex test method. You would test its effects indirectly (e.g., record updates), but the Process Builder itself is not "covered by executable tests."

C. Workflow Rules
— Workflow Rules are also declarative automation. Like Process Builder, they can't be directly executed or asserted in a test class. They're tested indirectly by verifying resulting field updates or actions, not as a testable configuration unit.

D. Case Assignment Rules
— Assignment rules route cases to users/queues. They run on case creation and are not directly testable via Apex assertions in a standard test method. Testing them requires verifying case ownership indirectly, and they aren't a configuration item covered by executable tests in the Apex sense.

References

Apex Developer Guide – Testing Best Practices: Use DmlException to test validation rules and other DML-level constraints.

Explanation

A Requirement Traceability Matrix (RTM) is a project artifact that maps each requirement to its associated test cases. It provides a clear, one-to-one (or one-to-many) linkage showing that every requirement has at least one test case covering it — and conversely, that every test case traces back to a requirement.

This directly meets the business need: ensuring no functionality is left untested. The RTM:

Confirms 100% coverage of requirements by test cases.
Highlights gaps where requirements lack test coverage.
Prevents scope creep by tracing tests back to approved requirements.
Is especially valuable during User Acceptance Testing (UAT) to demonstrate completeness.

Why Other Options Are Incorrect

A. User acceptance test scripts
— These are the actual step-by-step test procedures executed during UAT. They define how to test, but they don't by themselves guarantee that every requirement is covered. Without a traceability matrix, there's no way to verify completeness.

B. Testing strategy
— A high-level document describing the overall approach, scope, tools, and types of testing. It defines how testing will be conducted, not which specific requirements map to which test cases.

C. Test execution plan
— Describes when, where, and how tests will be run (schedules, environments, resources). It focuses on execution logistics, not requirement-to-test coverage.

References

Salesforce Trailhead – Application Lifecycle Management: Project artifacts and testing documentation.

PMI / PMBOK – Requirements Traceability Matrix: Standard project management artifact linking requirements to test cases.

Explanation

Automated test data loads use tools (e.g., Data Loader with command-line/scripting, DML via Apex, or CI/CD-integrated scripts) to populate test data consistently and repeatedly, unlike manual loads which depend on human effort.

A is correct because automated loads can run unattended — they can be scheduled or triggered by CI/CD pipelines without a person manually executing each load. This saves time and enables continuous testing.

B is correct because automated loads produce consistent, repeatable, and reliable results. The same script produces the same data every time, eliminating human error (typos, missed fields, inconsistent values) that plagues manual loads. Reliability is a core benefit of automation.

Why Other Options are Incorrect

C. Automated loads cannot be scripted by CI/CD tools
— This is false. Automated loads are precisely the type of task that can and should be scripted by CI/CD tools. This contradicts the very definition of automation.

D. Automated loads will increase costs
— This is generally false. Automation typically reduces long-term costs by eliminating repetitive manual effort and human error. It may have upfront setup cost, but the net effect is cost reduction, not increase.

References

Salesforce Trailhead – Application Lifecycle Management: Automated testing and CI/CD integration.

Salesforce Data Loader Guide – Command Line / Scripting: Automating data loads.

Explanation

UC wants to delete the day's test data nightly (~1 GB) in a Partial Copy sandbox, restoring it to a fresh state for the next day's testing. The best strategy must be automated, repeatable, and scalable to handle 1 GB of records without manual effort.

B is correct because a batch job (e.g., Batch Apex or a scheduled job) can:

Query and delete all records created during the day in chunks, staying within governor limits.
Run >unattended on a nightly schedule (via Scheduled Apex or a scheduler).
Handle ~1 GB of data efficiently through batch processing, which is designed exactly for large-volume DML.
Set the sandbox back to a consistent "fresh" state automatically, with no human intervention.

This is the most efficient, automated, and governor-limit-safe approach.

Why Other Options Are Incorrect

A. Manually delete all records individually
— Impractical for 1 GB of data. Manual deletion is slow, error-prone, and requires human oversight every night. It defeats the goal of an automated nightly reset.

C. Create a new Developer sandbox every night
— A Developer sandbox contains metadata only (no production data) and is a completely different sandbox type than the Partial Copy sandbox being used. Creating one nightly doesn't reset the Partial Copy sandbox, and Developer sandboxes lack the data needed for realistic testing.

D. Refresh the sandbox every night
— Sandbox refreshes are expensive, time-consuming, and limited (e.g., Full sandbox refresh is restricted to once every 29 days). Refreshing nightly is not feasible, would wipe all sandbox configuration/data, and is overkill for simply removing a day's test data.

References

Apex Developer Guide – Batch Apex: Processing large data volumes in chunks within governor limits.

Apex Developer Guide – Scheduling Apex: Running jobs on a nightly schedule.

Explanation

UC's problem: administrators make minor production changes that break dependent components, causing unit tests to fail only in production. The root cause is untracked, untested changes bypassing the deployment pipeline. The architect needs suggestions that surface these changes earlier.

C is correct because routing admin changes through a  dedicated sandbox and promoting them to production brings those changes into the  managed release process. Changes are then tested (unit tests run) before reaching production, and dependent components can be validated in a lower environment. This is a core ALM best practice — no direct production changes.

D is correct because committing a  daily metadata backup to version control and publishing a diff to the release team creates  visibility into what changed in production. The diff highlights unauthorized or unexpected changes, allowing the release team to detect and address them before they cause deployment failures. This is a detective control that catches untracked changes.

Together, C and D  prevent (C) and  detect (D) untracked production changes — directly addressing the root cause.

Why Other Options Are Incorrect

A. Stop administrators from making all changes
— This is too extreme and impractical. Administrators need to make legitimate changes. The problem isn't making changes — it's making them  without process or tracking. A blanket ban is not a realistic or recommended governance approach.

B. Ask administrators to run unit tests before every change
— This places the burden on administrators who may not understand or have access to run Apex unit tests, and it doesn't address  tracking or dependent components. It's an unreliable, unenforceable control compared to routing changes through a sandbox.

References

Salesforce Trailhead – Application Lifecycle Management: Governance, sandbox strategy, and change management.

Salesforce Well-Architected Framework – Operational Excellence: Change management and deployment governance.

Explanation

Salesforce provides built-in Aura accessibility testing through two test automation environments, which map directly to the two Aura testing frameworks: JSTEST (Aura's JavaScript test framework) and ACCTEST (accessibility test mode). These are the two environments where the UMS team can invoke Aura accessibility tests.

A. JSTEST
— The JavaScript Test (JSTEST) environment is Aura's native test framework for writing and running JavaScript tests on Aura components. It supports accessibility test assertions via the Aura testing API, allowing developers to check components for common accessibility issues programmatically.

B. ACCTEST
— The Accessibility Test (ACCTEST) environment is specifically designed to run accessibility checks on Aura components. It uses the same accessibility ruleset Salesforce applies in its own component testing, letting teams catch issues like missing labels, ARIA problems, and contrast/role violations.

Together, JSTEST and ACCTEST are the two documented Aura test environments that support accessibility testing.

Why Other Options Are Incorrect

C. WebDriver Test
— WebDriver is a browser automation framework (Selenium/WebDriver) used for end-to-end UI testing. It is not an Aura-native test environment and does not expose Aura's built-in accessibility test API. While WebDriver can test UI behavior, it isn't where Aura accessibility tests are "called" from the framework.

D. AuraDriver Test
— There is no such environment as "AuraDriver Test." This is a fabricated/distractor option that combines "Aura" and "WebDriver" to sound plausible. It does not exist in Salesforce's Aura testing tooling.

References

Salesforce Developer Docs – Aura Testing: Testing Aura Components — describes `$A.test` framework and the JSTEST environment.

Salesforce Developer Docs – Accessibility Testing for Aura Components: ACCTEST environment and `axe`-based accessibility rules.

Explanation

Universal Containers wants QA techniques to incorporate into its overall CI/CD pipeline to minimize defects. The key phrase is CI/CD pipeline — techniques that can be automated and triggered as part of the build/deploy process.

A is correct because Static Code Quality Analysis tools (e.g., PMD, Checkmarx, Salesforce Code Analyzer) scan source code without executing it to detect security vulnerabilities, code smells, governor-limit risks, and best-practice violations. These tools integrate directly into CI/CD pipelines (e.g., in a pull request or build step), giving fast, automated feedback on every commit. This catches defects before code is deployed.

B is correct because Automated Browser Testing (e.g., Selenium, Provar, Copado Robotic Testing) runs scripted UI tests automatically against a deployed environment. It integrates into CI/CD pipelines to validate that end-user functionality works after each build/deployment, catching regression and integration defects early and repeatedly.

Together, A and B are the two techniques specifically designed to be automated within a CI/CD pipeline — one at the code level (static) and one at the UI level (dynamic).

Why Other Options Are Incorrect

C. Stress testing — Stress testing pushes a system beyond expected limits to find breaking points. It is a performance/load activity typically run periodically (and with advance notice to Salesforce), not a per-build CI/CD pipeline step. It's too heavy and infrequent for continuous integration.

D. Business verification testing — This refers to UAT / business-level validation performed by end users or business stakeholders. It is manual and human-driven, occurring at the end of a release cycle — it cannot be automated into a CI/CD pipeline and is not a per-commit quality gate.

References

Salesforce Trailhead – Application Lifecycle Management: CI/CD pipeline quality gates.

Salesforce Well-Architected Framework – Operational Excellence: Static analysis and automated testing in CI/CD.

Explanation

The classic symptom here: tests pass in a sandbox but fail in production. This almost always happens because the tests depend on existing org data (e.g., a record created manually in the sandbox, or org-specific configuration) rather than creating their own data.

The Salesforce best practice is clear: test methods must create their own data and must not rely on `SeeAllData=true`. When tests generate their own data inside the test method, they are self-contained, deterministic, and portable — they behave identically in a sandbox and in production, because they don't depend on whatever records happen to exist in each org.

By setting `SeeAllData=false` (the default) and generating data in the test, the developer ensures:

Tests don't fail due to missing org-specific data in production.
Tests are isolated and repeatable.
Tests comply with Salesforce's recommended testing practices.

Why Other Options Are Incorrect

A. Create test data in production before deploying
— This is not allowed as a reliable practice and is dangerous. Production is not a test environment; manually creating test data there is error-prone, and tests would still break if that data changes. Tests must be self-sufficient, not dependent on manual production data.

B. Set `SeeAllData=true` to use production data
— This is the opposite of the recommended practice. Relying on real org data makes tests brittle, non-deterministic, and org-dependent — exactly the cause of the sandbox-vs-production failure. It's also discouraged by Salesforce best practices.

C. Explicitly set `SeeAllData=true` and generate data in the test methods
— Combining `SeeAllData=true` with data generation is contradictory and unnecessary. Enabling `SeeAllData=true` still exposes tests to unpredictable org data (and can cause failures from org-specific records or validation rules), while the generated data would be the only data actually needed. The correct approach is to not use `SeeAllData` at all.

References

Apex Developer Guide – Testing Best Practices: "Create test data for each test" and "Avoid `SeeAllData=true`."

Apex Developer Guide – `@isTest(SeeAllData=true)`: Why relying on org data makes tests unreliable.

Explanation

In Apex, test methods cannot make real HTTP callouts to external services. The platform blocks outbound callouts during test execution to keep tests deterministic, fast, and isolated. If a test method executes code that performs a web service callout without registering a mock via `Test.setMock()`, Salesforce throws a `System.CalloutException` with the exact message:

> "Methods defined as TestMethod do not support Web service callouts."

The developer must implement `HttpCalloutMock` (or another supported mock interface) and register it with `Test.setMock(HttpCalloutMock.class, mockInstance)` before the callout executes. Since the developer forgot that step, the test fails immediately with that error message — regardless of what the external service would have returned.

Why Other Options Are Incorrect

A. The test class fails without error message since it skips the callout
— False. The callout is not silently skipped; the platform throws a `CalloutException` with an explicit error message. Tests fail loudly, not silently.

C. The test class would make the callout and may or may not fail
— False. Apex tests cannot make real callouts at all. There's no "may or may not" scenario — the callout is blocked and the test fails with the callout exception.

D. The Developer Console will not let the developer save it
— False. The Developer Console and CLI will allow the test class to be saved. The error only surfaces at runtime when the test executes the callout without a mock. There is no compile-time or save-time check for missing `Test.setMock()`.

References

Apex Developer Guide – Testing HTTP Callouts: "Apex tests can't make callouts to external services unless you use a mock." `Test.setMock(HttpCalloutMock.class, mock)` is required.