Plat-Dev-201 Salesforce Certified Platform Developer Exam Topics and Questions

This is the heaviest topic on the exam and the one that separates candidates who understand the platform from those who have memorised syntax. You need to know how Salesforce's multi-tenant architecture constrains what you can build, when to use clicks over code, and how to model data correctly under pressure.

– Multi-tenant architecture and frameworks

Multi-tenancy means shared infrastructure and hard limits on what your code can do. The exam expects you to recognise when a design will hit governor limits before it runs, and to choose patterns that stay within them. MVC architecture and the Lightning Component Framework are tested as concepts that shape how you structure applications, not as definitions to recite. You will be asked to identify which layer owns a piece of logic or where a controller fits in a component's lifecycle. The framework knowledge is applied, so if you have only read about it without building anything, you will struggle.

– Declarative versus programmatic choices

The platform gives you two ways to solve most problems, and the exam tests your judgment about which to use. Formula fields and roll-up summaries have limits: formulas cannot call external systems, roll-ups only work up certain relationship types, and both count against field limits. Governor limits apply differently depending on whether you use a Flow or write Apex, and knowing which approach consumes fewer resources is the decision point. Candidates lose marks when they choose code for something a formula could handle, or when they assume declarative tools have no performance cost. The scenario will include enough detail to make the trade-off clear, but only if you know what each tool can and cannot do.

– Data modelling and external IDs

Objects, fields, and relationships form the foundation, and the exam assumes you have built them under real constraints. You need to know when to use a lookup versus a master-detail, what happens to child records when a parent is deleted, and why external IDs matter for integration and upsert operations. The questions often involve a scenario where the wrong relationship type will break a requirement, or where an external ID is the only way to avoid duplicates. If you have only worked in orgs where someone else designed the schema, this topic will cost you. The exam also expects you to recognise when a custom object is unnecessary because a standard one already exists.

– Agentforce for Developers

Agentforce is new to the outline and tested lightly. The focus is on knowing what it can and cannot do, not on building agents from scratch. You need to recognise scenarios where Agentforce is appropriate and where it is not, and understand any limitations on how it integrates with custom code. The exam will not ask you to configure an agent in detail, but it will expect you to know when to recommend it and when to rule it out. If you have not seen it in action, read the documentation and understand the use cases.

How Developer Fundamentals is tested

At 27 percent, this topic appears in more than a quarter of the items, and the questions are scenario-heavy. You will be given a set of requirements and asked which data model, which relationship type, or which combination of declarative and programmatic tools fits best. The exam does not ask you to define MVC or recite the benefits of multi-tenancy. It describes a situation where governor limits are about to be exceeded, or where a roll-up summary cannot be used, and expects you to choose the alternative that works. Candidates fail this topic when they have only surface knowledge of the platform's constraints. If you cannot explain why a master-detail relationship behaves differently from a lookup when it comes to sharing and deletion, or if you do not know which declarative tools count against DML limits, you will lose marks. The questions move quickly from theory to application, and there is no time to work out the rules during the exam.

Where the first topic tested your judgment about when to write code, this one tests whether you can write it correctly. At 28 percent, it is the single largest area on the exam, and it spans everything from declarative automation to Apex transactions, governor limits, and exception handling.

– Declarative automation and when to combine it with code

Flow, Process Builder, and other declarative tools handle a large portion of automation, and the exam expects you to know their capabilities and limits. You need to recognise when a Flow can solve a requirement on its own and when it needs to call Apex. The questions often describe a scenario where declarative automation is almost enough but falls short on one requirement, and you have to decide whether to add code or redesign the Flow. Combining declarative and programmatic logic is tested explicitly, so if you have only used one or the other in isolation, you will miss the nuance. The exam also expects you to know which declarative features can invoke Apex and what gets passed between them.

– Apex syntax, control flow, and query languages

Variables, constants, methods, and modifiers are tested as building blocks, but the exam focuses on why you would use one over another. Control flow statements appear in scenarios where you have to predict what will execute and in what order. SOQL and SOSL are tested together, and you need to know when to use each, how they differ in syntax and performance, and what they return. DML statements are tested for correctness and for their position in a transaction, because issuing DML inside a loop is the classic mistake. The questions assume you have written enough Apex to recognise inefficient patterns on sight, and they will show you code that works but violates best practices.

– Apex classes, triggers, and best practices

Writing Apex classes and triggers is not the same as writing them well. The exam tests bulkification, trigger frameworks, and the one-trigger-per-object rule. You need to know when to use a trigger versus a Flow, how to structure a trigger to avoid recursion, and why putting logic in a handler class is better than putting it directly in the trigger body. Best practices are not optional background knowledge. They are the basis for wrong answers that look correct if you have only written code for single-record scenarios. If you have not dealt with bulk operations or tested your triggers with 200 records at once, this area will catch you out.

– Governor limits, transactions, and order of execution

Governor limits are not just a list to memorise. The exam gives you a scenario and asks whether the code will hit a limit, which limit it will hit, and how to rewrite it so it does not. You need to know how limits are counted within a transaction, what resets them, and how asynchronous code changes the budget. The order of execution is tested in detail: before triggers, after triggers, validation rules, workflow rules, and where each type of automation fires. Recursion and cascading are tested as risks you need to prevent, not as theoretical problems. Exception handling is tested both for syntax and for knowing when to catch an exception versus letting it bubble up. Custom exceptions appear in scenarios where a standard exception is not specific enough.

How Process Automation and Logic is tested

This topic makes up 28 percent of the exam, and the items are longer and more technical than those in Developer Fundamentals. You will see code snippets and be asked what they return, whether they will hit a governor limit, or how they will behave in a bulk context. The exam does not ask you to write code from scratch, but it expects you to read it quickly and spot the problem. A common item type shows a trigger or class that works for one record but fails at scale, and you have to identify the fix. Another type gives you a scenario and asks whether to use SOQL or SOSL, or whether to call Apex from a Flow or handle it declaratively. Candidates lose marks when they know the syntax but not the platform's execution model. If you do not understand how the order of execution affects when your code runs, or if you cannot calculate whether a transaction will exceed its DML or SOQL limits, you will struggle. The questions assume you have debugged real transactions and know what happens when things go wrong.

The exam now shifts from back-end logic to what the user sees and how you build it securely. At 25 percent, this topic is almost as heavy as the previous one, and it tests your ability to choose the right UI framework, prevent security holes, and connect Apex to components correctly.

– Security vulnerabilities in the UI and data access

Security is tested as a design responsibility, not a checklist. You need to recognise when a component exposes data that should be restricted, when user input is not sanitised, and when a query bypasses sharing rules. Cross-site scripting, SOQL injection, and failure to enforce field-level security are the common vulnerabilities, and the exam describes scenarios where each could occur. The questions assume you know how to prevent them, not just that they exist. If you have always relied on the platform's default protections without understanding when they do not apply, you will miss items. The exam also expects you to know when with sharing and without sharing matter, and what happens if you omit the keyword entirely.

– Custom UI components and framework choice

Lightning components, Lightning Web Components, Visualforce, and Flow can all build user interfaces, and the exam tests when to use each. Lightning Web Components are the current standard, and you need to know their benefits, how events work, and when to use them instead of Aura components. Visualforce still appears in scenarios involving legacy pages or PDF generation. Flow is tested as a UI tool for guided processes, and you need to know when a Flow screen is better than a custom component. The exam gives you a requirement and asks which framework fits, and the answer depends on performance, maintainability, and what the user needs to do. If you have only built in one framework, you will struggle to choose between them.

– Apex integration with page components

Components need data, and Apex is how you get it to them. The exam tests how to write Apex methods that Lightning Web Components can call, how to pass parameters, and how to handle errors that come back from the server. It also covers how Apex works with Flow and Agentforce, and what you can and cannot do when a component invokes your code. You need to know which methods must be annotated with @AuraEnabled, when to use cacheable=true, and what happens if your method throws an exception. The questions assume you have connected components to controllers in a real org and debugged the failures that occur when the contract between them is wrong.

How User Interface is tested

At 25 percent, this topic appears in a quarter of the exam, and the items focus on security and framework selection more than on syntax. You will be given a scenario where a component needs to display data, and you have to choose which framework to use, how to secure the data access, and how to connect it to Apex. The exam does not ask you to write a Lightning Web Component from scratch, but it expects you to read a controller method and know whether it will work. Security questions describe a situation where user input reaches a SOQL query or where a component displays fields the user should not see, and you have to identify the vulnerability and the fix. Candidates lose marks when they assume the platform will enforce security automatically, or when they choose a framework based on familiarity rather than fit. If you do not know when to use with sharing, or if you cannot explain why Lightning Web Components perform better than Aura, you will lose items. The questions move quickly, and you need to recognise the patterns without working them out from first principles.

The final topic tests whether you can prove your code works, find out why it does not, and move it to production without breaking anything. At 20 percent, it is the lightest of the four, but it still accounts for one in five items, and candidates often underestimate it.

– Writing and executing tests

Test coverage is mandatory, and the exam expects you to write tests that actually verify behaviour rather than inflate a percentage. You need to know how to set up test data, how to test triggers and controllers in bulk, and how to test Flows. The questions focus on what makes a test meaningful: whether it covers positive and negative cases, whether it uses the right assertions, and whether it will catch regressions. You also need to know how to use Test.startTest and Test.stopTest, when to use @testSetup, and how to create test data without relying on existing records in the org. If your tests only ever pass one record at a time, or if you have never tested a Flow, you will miss the nuance.

– Developer tools and when to use them

Salesforce DX, the Salesforce CLI, and Developer Console are tested as tools you choose based on what you need to do. The exam expects you to know when to use the CLI for scripting and deployment, when to use Developer Console for debugging, and when Salesforce DX is the right model for source-driven development. The questions describe a task and ask which tool fits, and the answer depends on whether you need version control, whether you are working in a scratch org, and whether you need to inspect logs in real time. If you have only used the UI or only used the CLI, you will not recognise when the other is better.

– Debugging and monitoring

Debugging is tested as a process, not a feature. You need to know how to read debug logs, how to set log levels, and how to monitor asynchronous and batch jobs. The exam describes a scenario where something is failing or performing poorly, and you have to choose the right approach to find the cause. Monitoring Flows, tracking batch job status, and checking governor limit consumption all appear as tasks you should be able to do without guidance. If you have never opened a debug log or checked the status of a queued job, this area will be unfamiliar.

– Deployment environments and process

Deployment is tested as a sequence of environments and a set of requirements you must meet before code moves forward. You need to know the difference between sandboxes, scratch orgs, and production, what must be deployed alongside your code, and what the deployment process checks. The exam expects you to recognise when a deployment will fail because a dependency is missing, or when you need to include metadata that is not part of the code itself. Change sets, Salesforce DX, and other deployment tools appear in scenarios where you have to choose the right one for the situation.

How Testing, Debugging, and Deployment is tested

This topic makes up 20 percent of the exam, and the items assume you have worked through the full development lifecycle. You will be asked how to structure a test class, what a failing test indicates, or which tool to use to investigate a performance problem. The exam does not ask you to write a complete test method, but it expects you to recognise when a test is insufficient or when it will not run in a deployment. Debugging questions describe symptoms and ask you to choose the diagnostic step that will find the cause, and you need to know which logs to check and what to look for. Deployment questions focus on process and dependencies: what needs to be deployed together, what order to deploy it in, and what will cause a validation failure. Candidates lose marks when they have only deployed code in one way, or when they have never debugged a batch job or monitored a Flow. The questions assume practical experience, and surface-level knowledge of the tools is not enough.