Free Salesforce Platform Developer II Practice Test | 2026 Edurely

Salesforce Platform Developer II Practice Test

Students preparing for Salesforce Platform Developer II can View the complete practice-test library and use this guide to organize advanced study around Salesforce’s current official objectives. The credential focuses on designing, developing, testing, integrating, optimizing, and deploying complex programmatic solutions on the Salesforce Platform.

Platform Developer II, often shortened to PDII or PD2, is an advanced developer credential. It is intended for professionals who already understand Apex, Lightning Web Components, Flow, Salesforce data, security, testing, and deployment. The goal is not to repeat beginner syntax. Candidates must be able to evaluate several technically possible solutions and select the one that is secure, scalable, maintainable, and suitable for the requirement.

This page follows the current Salesforce Certified Platform Developer II Exam Guide. Older blogs may use incomplete domains, outdated prerequisite descriptions, or earlier product terminology. Students should always compare preparation material with Salesforce’s live guide before building a study schedule.

What Does Salesforce Platform Developer II Validate?

Salesforce describes Certified Platform Developer II professionals as experts in the advanced programmatic capabilities of the Salesforce Platform. They can use data modeling to create complex business logic and user interfaces. The credential goes beyond knowing individual features. It checks whether a developer can connect those features into a dependable application design.

A well-prepared learner should be able to:

• Design Apex that works for both small and large record volumes.
• Coordinate declarative automation and programmatic logic.
• Maintain transaction integrity and provide useful error handling.
• Select an appropriate asynchronous-processing pattern.
• Build inbound and outbound integrations.
• Create responsive, secure user interfaces.
• Test Apex and interface code with advanced techniques.
• Debug failures using evidence rather than guesses.
• Use source-driven development and suitable deployment tools.
• Find and correct performance problems.

The current Salesforce Platform Developer II credential page lists Salesforce Certified Platform Developer as the prerequisite. This makes sense because PDII assumes the learner already understands the foundation covered by the first developer credential. If Apex collections, bulk-safe triggers, SOQL, LWC communication, and unit testing are still unfamiliar, revise the Platform Developer material before moving into advanced preparation.

Current Salesforce Platform Developer II Topics

The official blueprint contains five domains totaling 100%.

The weights show why balanced preparation is important. Process Automation, Logic, and Integration is the largest area at 27%, but the other four domains make up almost three quarters of the blueprint. Advanced code that works correctly but performs poorly, exposes data, lacks useful tests, or cannot be deployed safely is not a strong solution.

1. Advanced Developer Fundamentals — 15%

This domain builds on the foundation of the first Platform Developer credential. It covers platform behavior and design choices that become important in larger, more varied implementations.

Localization and multicurrency

Applications may serve users in different countries, languages, time zones, and currencies. Developers need to understand how locale affects displayed dates, numbers, and currencies. A hard-coded display format that works for one user may be confusing or incorrect for another.

Review organization currency settings, corporate currency, conversion behavior, and how multicurrency can affect calculations and queries. The important lesson is to avoid assuming that every value is stored, calculated, or displayed in one universal format.

When building a component, use Salesforce-supported localization features rather than manually combining text. Test with users who have different locales, languages, currencies, and time zones.

Sharing and programmatic access

Advanced developers must understand the difference between record ownership, organization-wide defaults, role hierarchy, sharing rules, teams, manual sharing, and Apex-managed sharing. Code should extend access only when a real business requirement justifies it.

Study with sharing, without sharing, and inherited sharing. These keywords affect record-level access but do not automatically solve object- and field-level authorization. A solution may respect sharing and still expose a field the user should not see if other checks are missing.

Apex-managed sharing is useful when access must follow custom logic that standard sharing tools cannot express. However, it adds design and maintenance responsibility. A developer must select an appropriate access level, use the correct share object, consider recalculation, and understand what can happen when ownership changes.

Custom metadata and configuration

Code should not contain every business rule as a hard-coded value. Custom metadata types and custom settings can move suitable configuration outside the codebase. This makes some behavior easier to change, deploy, test, and reuse.

Learn how hierarchy custom settings differ from list settings and why custom metadata records are useful for deployable configuration. Decide whether a value is code, data, or configuration before choosing where to store it. Sensitive secrets do not belong in either source code or ordinary configuration records; use supported credential features.

Advanced Apex language features

Review interfaces, abstract and virtual classes, inheritance, dynamic Apex, schema describe information, annotations, and reusable service patterns. The blueprint expects candidates to recognize how advanced features solve real requirements rather than simply identify definitions.

Dynamic Apex can help when logic must inspect objects or fields at runtime. It also needs careful validation and security because flexible code can become difficult to understand or expose data unintentionally.

A useful exercise is to create a service that accepts an object type, checks whether the user can access the requested fields, builds a controlled query, and returns a limited result. Then compare that flexible design with a simpler typed implementation. Dynamic behavior is valuable only when its flexibility is actually required.

2. Process Automation, Logic, and Integration — 27%

This is the largest domain. It tests the ability to design complicated processing while keeping automation, transactions, integrations, and errors under control.

Interactions between automation tools

Salesforce records may be affected by validation rules, flows, Apex triggers, assignment rules, roll-up behavior, and other automation in one transaction. Candidates must understand that each process does not operate in isolation.

When reviewing a requirement, identify:

• What starts the transaction.
• Which automation runs before and after the save.
• Whether the same record can be updated again.
• Whether logic can become recursive.
• Which changes happen synchronously.
• What must move to asynchronous processing.
• How errors should affect the whole transaction.

The best design may combine Flow and Apex. Declarative automation can manage changeable business steps, while Apex handles reusable complex logic or processing that requires programmatic control. Avoid duplicating the same rule in several tools.

Trigger design and transaction integrity

PDII preparation should include advanced trigger practices. A trigger should process collections, query outside loops, minimize data operations, and delegate complex behavior to testable classes. A handler design can improve separation, but no named framework is automatically correct for every project.

Transaction integrity means that related work remains consistent. Review savepoints, rollback, partial processing through Database methods, exception types, and how failures cross method or integration boundaries.

If several records form one business unit, allowing only some to save may leave inconsistent data. In another use case, processing every valid record and logging failures may be the better result. The requirement determines whether all-or-none behavior is appropriate.

Advanced queries and dynamic Apex

Review relationship queries, aggregate queries, query-for loops, binding, selective filters, dynamic SOQL, SOSL, and methods for safely building a query at runtime. Never place untrusted input directly into a dynamic query. Use binding, escaping where applicable, field allowlists, and authorization checks.

Candidates should also understand how query structure affects large-volume processing. A syntactically correct query can still be slow or nonselective. Performance is a separate domain, but it is closely connected to logic and integration design.

Asynchronous processing

Compare future methods, queueable Apex, batch Apex, scheduled Apex, and event-based approaches. A learner should be able to choose based on volume, chaining, monitoring, retry needs, callouts, transaction separation, and timing.

• Queueable Apex is often suitable for controlled background work and chaining.
• Batch Apex processes large record sets in separate groups.
• Scheduled Apex starts work at planned times.
• Future methods support simpler background operations but provide less control than queueable work.
• Platform events can separate publishers from subscribers and support event-driven processing.

Do not move inefficient code to the background and call it optimized. Asynchronous jobs still have platform limits and operational costs.

Event-driven development

Platform events allow a publisher to announce that something happened without tightly coupling it to every subscriber. Study publishing, subscribing, transaction behavior, replay concepts, and error handling.

Event-driven architecture is useful when systems need loose coupling or work can occur after an event. It is less suitable when the initiating transaction requires an immediate, guaranteed response before it can continue.

Programmatic integrations

PDII learners should understand inbound and outbound communication, REST and SOAP concepts, Apex REST, callouts, named credentials, authentication, JSON or XML processing, error handling, and callout testing.

For each integration, consider:

1. Which system initiates the request?
2. Is the interaction synchronous or asynchronous?
3. How are users or systems authenticated?
4. What is the expected data volume?
5. How are timeouts, duplicates, and retries handled?
6. How is the transaction kept consistent?
7. What information is safe to log?

An integration that works only when every service responds immediately is fragile. Design for expected failures and give operations teams enough information to diagnose them.

3. User Interface — 20%

The User Interface domain covers advanced work with Lightning Web Components, Aura components, Visualforce, Apex controllers, responsive behavior, events, errors, and reusable resources.

Selecting an interface technology

Lightning Web Components are normally the preferred choice for new Lightning development. Aura components can remain part of existing applications or provide capabilities needed in a particular context. Visualforce is still important for older solutions and certain page-based requirements.

The skill is not simply knowing which technology is newest. Candidates must compare the requirement, runtime context, existing architecture, maintainability, team skills, and integration needs.

Lightning Web Components and Apex controllers

Review component lifecycle, reactive state, public properties, wire adapters, imperative Apex calls, cacheable methods, events, Lightning Message Service, error handling, and component composition.

When a scenario includes an LWC and Apex controller, inspect both sides:

• Are the Apex methods exposed correctly?
• Is data retrieved in the correct user context?
• Is the method safe to cache?
• Does the component handle loading, empty, success, and error states?
• Are server calls repeated unnecessarily?
• Is the response limited to the data the component needs?

Do not expose broad sObject data when a small, controlled data-transfer structure would be clearer and safer.

Aura and Visualforce knowledge

For Aura, understand component attributes, events, server actions, lifecycle behavior, and communication. For Visualforce, review standard and custom controllers, extensions, action methods, partial-page refreshes, asynchronous techniques, view state, and page security.

Students do not need to treat every older technology as the best choice for new development. They should be able to maintain it, debug it, and choose a migration or integration approach when appropriate.

Responsive design and static resources

Interfaces must work on different form factors. Study Salesforce Lightning Design System guidance, responsive layout, conditional presentation, device-aware behavior, and accessible markup.

Static resources package images, scripts, styles, and other files for controlled use by platform applications. Learn when they are appropriate and how resource loading affects performance, security, and caching.

Clear error communication

A user should receive a useful message without being shown a raw stack trace or sensitive system detail. Capture technical information for support while giving the user a clear next step.

Students can Find practice questions for your Salesforce exam after building and testing small components. Mixed scenarios are especially valuable because an interface problem may actually begin in Apex security, caching, automation, or query design.

4. Testing, Debugging, and Deployment — 20%

Advanced development requires more than reaching a code-coverage threshold. This domain checks whether candidates can design meaningful tests, isolate failures, verify interfaces, and move source safely through a development lifecycle.

Advanced Apex testing

Use positive, negative, bulk, permission, and integration-related tests where relevant. Create controlled test data and make assertions about business behavior.

Review:

• Test-data factories and builders.
• Test.startTest() and Test.stopTest().
• HTTP callout mocks.
• Stub API and dependency isolation.
• Testing asynchronous Apex.
• Testing event publication or handling.
• Verifying expected exceptions.
• Running tests under a chosen user context.
• Avoiding dependencies on organization data.

Mocks and stubs help isolate the code under test. They should make tests clearer, faster, and more predictable—not create a second complicated application inside the test suite.

Testing interface code

Salesforce’s guide includes Lightning Web Components, Aura, Visualforce controllers, extensions, and JavaScript. For LWC, learn Jest testing concepts such as rendering a component, setting public properties, simulating events, mocking wire adapters or Apex, and verifying the displayed result.

Interface tests should cover more than a success screen. Include missing data, server errors, different user actions, and important accessibility or state changes.

Root-cause debugging

A developer should locate the first incorrect behavior rather than patch the last visible symptom. Use debug logs, stack traces, checkpoints, browser developer tools, network information, test failures, and component debugging tools.

A clear process is:

1. Reproduce the problem with known data and a known user.
2. Record the expected result.
3. Identify the first place where actual behavior differs.
4. Check limits, queries, data changes, automation order, events, and permissions.
5. Reduce the case until the failure is understandable.
6. Fix the cause and add a regression test.

If a component displays stale data, the root cause might be client caching, server caching, a cacheable Apex response, an event that did not fire, or data that was never committed. Checking every layer in order avoids random changes.

Source-driven development and deployment

Review version control, Salesforce CLI, project structure, scratch orgs, sandboxes, packages, metadata dependencies, validation, continuous integration, and rollback planning. The exact tool depends on the team, but the principles remain consistent:

• Source control should be the reliable record of intended changes.
• Automated checks should run before deployment.
• Permissions and dependencies must travel with the solution.
• Environment-specific configuration must be managed safely.
• Production changes require validation and monitoring.

Deployment is not only a command. It is a process for moving a tested and approved change while reducing risk.

5. Performance — 18%

Performance is a major PDII topic because enterprise Salesforce applications must remain useful as data volume, automation, integrations, and users grow.

Large data volumes and selective queries

Review indexes, selective filters, query plans, data skew, sharing calculations, relationship choices, batch processing, and archiving strategies. A query that performs well with one thousand records may fail when an organization has millions.

Avoid retrieving fields or rows the process does not need. Use selective filters and inspect the query plan for important large-volume operations. Consider how null values, negative filters, leading wildcards, and sharing can affect selectivity.

Apex efficiency

Bulkification remains essential. Gather identifiers, query once, use maps for matching, perform controlled data operations, and avoid repeated describes or expensive work.

Common issues include:

• SOQL or DML inside loops.
• Nested loops over large collections.
• Repeated conversion or serialization.
• Unbounded result sets.
• Large heap use.
• Recursive automation.
• Synchronous work that can safely run later.
• Duplicate calculations across layers.

Measure before optimizing. A code change that looks faster can make maintainability worse without improving the actual bottleneck.

Interface performance

Reduce unnecessary server calls, return focused data, use caching where data freshness allows it, lazy-load secondary content, and avoid rendering huge collections at once. Use browser and Salesforce tools to identify whether delay comes from network time, Apex, queries, JavaScript, or rendering.

Do not cache sensitive or rapidly changing data without understanding the consequences. Fast but incorrect information is not a successful user experience.

Asynchronous callouts

An asynchronous callout can prevent a user transaction from waiting on an external service when an immediate response is not required. Candidates should understand when moving the callout improves responsiveness and when the business process still requires synchronous confirmation.

Reuse and maintainability

Code reuse can improve consistency and reduce duplicate work, but a highly generic utility may become hard to understand. Reuse stable behavior with a clear contract. Do not combine unrelated responsibilities only to reduce line count.

How to Use a Platform Developer II Practice Test

Use practice assessments after studying and building. Their purpose is to reveal weak decisions, not replace advanced hands-on experience.

Work in three stages:

• Focused sets: Practice one official domain and review every explanation.
• Connected scenarios: Mix automation, integration, interface, security, and performance.
• Timed mock assessments: Work without notes, then review mistakes and guesses.

For each item, write down:

• The domain being tested.
• The key requirement or constraint.
• Why the chosen solution fits or fails.
• Which Salesforce source verifies the rule.
• What hands-on task would strengthen the skill.

Do not count a lucky guess as mastery. Explain the decision in plain language before marking the topic complete.

Use independently written practice material. Avoid sources that claim to distribute confidential certification questions. Memorizing protected content is an ethical risk and does not prepare a developer to design real solutions.

What Advanced Preparation Adds to Your Developer Toolkit

Structured preparation helps learners turn separate technical topics into a consistent design method. The aim is to see how automation, code, security, UI, integration, testing, deployment, and performance affect one another.

When preparing with us, students can:

• Follow the five current official domains and weights.
• Start with focused practice before moving to mixed scenarios.
• Compare several valid-looking approaches using clear decision criteria.
• Review why each option is strong or weak.
• Track repeated mistakes by topic and cause.
• Verify explanations against current Salesforce documentation.
• Build confidence with fresh mock sets rather than repeated wording.
• Combine practice results with Trailhead and hands-on development.

No practice resource can replace real coding. Its value is showing where more learning or application is needed.

An Eight-Week PDII Study Plan

Week 1: Confirm the foundation

Review Platform Developer topics: bulk-safe Apex, SOQL, DML, triggers, LWC, sharing, tests, and deployment. Complete a mixed diagnostic set and record the weakest areas.

Week 2: Advanced fundamentals

Study localization, multicurrency, sharing, Apex-managed sharing, custom metadata, custom settings, and dynamic Apex. Build one small configurable service and test it with different users.

Week 3: Automation and transactions

Map the order of automation in a sample application. Build a trigger handler, add transaction-aware error handling, and compare the solution with a Flow-based alternative.

Week 4: Asynchronous and event-driven work

Build queueable and batch examples. Publish and process a platform event in a safe practice environment. Compare monitoring, retry, volume, and transaction behavior.

Week 5: Integrations

Build a small callout using named credentials, controlled request and response handling, and a mock test. Review inbound API design, idempotency, timeouts, and error logging.

Week 6: Advanced interfaces

Build an LWC that calls Apex, handles states and errors, and communicates with another component. Review Aura and Visualforce scenarios from the official guide. Add Jest or suitable interface tests.

Week 7: Performance and large data volumes

Inspect query plans, optimize a nonselective query, remove repeated work, and compare synchronous with asynchronous designs. Test with meaningful data volume instead of a single record.

Week 8: Deployment and mixed review

Review source-driven development, dependencies, validation, CI checks, and rollback planning. Complete fresh timed mock assessments and return to official resources for every uncertain area.

Learners can Find your next certification on Edurely when planning what to study after completing the Platform Developer II path.

Practical Activities That Strengthen PDII Skills

• Create a configurable Apex service using custom metadata.
• Add Apex-managed sharing for a justified custom access rule.
• Refactor a trigger into bulk-safe, testable logic.
• Use dynamic Apex with a strict field allowlist.
• Compare queueable and batch designs for one workload.
• Build and test an HTTP callout with a mock response.
• Publish a platform event and process it asynchronously.
• Create an LWC with loading, empty, success, and error states.
• Add Jest tests for component behavior.
• Diagnose a deliberately nonselective query.
• Test a service with large record collections.
• Move a safe sample project through a source-driven deployment flow.

After every activity, write one paragraph explaining the trade-offs. Advanced certification preparation is about reasoning, not only producing working code.

Common Preparation Mistakes

Moving on before Platform Developer skills are stable

PDII assumes comfort with Apex, LWC, SOQL, security, and testing. Advanced study becomes confusing when the foundation is incomplete.

Treating every problem as an Apex problem

Some requirements are better handled declaratively. Strong developers justify when code adds necessary value.

Ignoring transaction boundaries

Automation, callouts, events, and asynchronous jobs may run in different transactions. Understand what commits, what rolls back, and what can be retried.

Testing only the success path

Include failure, bulk, permission, asynchronous, integration, and user-interface states where relevant.

Optimizing without measurement

Use logs, query plans, browser tools, and realistic data. Do not add complexity to fix an assumed bottleneck.

Repeating one mock set

A memorized score is not a readiness signal. Use fresh, independently written scenarios and explain every decision.

Using outdated technology guidance

Salesforce products and recommended patterns change. Verify old Aura, Visualforce, integration, and deployment advice against the current guide and documentation.

Readiness Checklist

Before completing preparation, a learner should be able to confirm:

• I hold or have completed the required Salesforce Platform Developer credential path.
• I know all five current PDII domains and weights.
• I can explain localization and multicurrency effects on code.
• I can design secure sharing and justify Apex-managed sharing.
• I can use custom metadata for suitable configuration.
• I can manage interactions between Flow and Apex.
• I can protect transaction integrity and handle errors clearly.
• I can choose among asynchronous Apex options.
• I can design inbound, outbound, and event-driven integrations.
• I can evaluate LWC, Aura, and Visualforce approaches.
• I can test Apex with mocks, stubs, bulk inputs, and user contexts.
• I can test important interface behavior.
• I can isolate a root cause using logs and debugging tools.
• I can plan a source-driven deployment.
• I can identify selective-query and large-volume concerns.
• I can improve interface and Apex performance based on evidence.
• My scores are stable across fresh mixed and timed assessments.

Frequently Asked Questions

What are the current Salesforce Platform Developer II topics?

The official blueprint contains Advanced Developer Fundamentals at 15%, Process Automation, Logic, and Integration at 27%, User Interface at 20%, Testing, Debugging, and Deployment at 20%, and Performance at 18%.

Does Platform Developer II require another certification first?

Yes. The current Salesforce credential page lists Salesforce Certified Platform Developer as the prerequisite for Platform Developer II.

Is Platform Developer II active?

Yes. It appears as an active developer credential in the current Salesforce certification overview and is not listed among the certifications scheduled to retire in February 2027.

How is PDII different from Platform Developer?

Platform Developer validates foundational programmatic development. PDII moves into advanced automation interaction, integration, sharing, testing, user-interface analysis, large data volumes, and performance decisions.

Should students learn Aura and Visualforce?

Yes, at the level described by the official guide. LWC is central to modern development, but experienced developers may need to analyze, maintain, integrate, or migrate Aura and Visualforce solutions.

Why does the blueprint give Performance 18%?

Advanced solutions must work at realistic scale. Candidates need to recognize inefficient queries, large-data-volume risks, slow interfaces, repeated processing, and cases where asynchronous design improves responsiveness.

Are practice tests sufficient for PDII?

No. They help measure reasoning and find gaps. Advanced hands-on work, Salesforce documentation, Trailhead learning, and code review are essential.

Does Edurely provide live Salesforce certification questions?

No. Edurely provides independently written practice questions and mock assessments for educational preparation. It does not provide, request, or reproduce stolen, confidential, or leaked Salesforce certification content. Salesforce owns its certification names, trademarks, and protected assessment material.