Platform Developer I is best learned by writing code on the platform, not by memorising trivia about it. The exam is multiple-choice, but the questions assume you can read Apex, SOQL and Lightning Web Components fluently and reason about how the platform behaves - governor limits, the save order of execution, security enforcement - so this guide is built as a full self-study course. It walks through each of the four sections of the current outline, explains the concepts scenario questions are built on, and turns it all into a week-by-week plan and a description of exam day. It contains study guidance and original explanations only. There are no real or simulated exam questions, and you should always confirm current details against the official Salesforce exam guide before you book.
Chapter 1: Exam overview and how to use this guide
What Platform Developer I actually measures
Platform Developer I (PD1) measures whether you can build custom applications on the Lightning Platform by combining code with the platform’s declarative tools, and whether you understand what makes Salesforce development different from ordinary Java or C# work. The current outline has four weighted sections: Developer Fundamentals at 27%, Process Automation and Logic at 28%, User Interface at 25%, and Testing, Debugging, and Deployment at 20%. Questions align to the Summer ‘25 Release, which matters more than it sounds: Salesforce refreshes the exam guide with the platform’s three annual releases rather than using exam codes, and the current outline includes Agentforce (AI) topics that older study material never covers.
The exam is 60 scored multiple-choice questions plus up to five unscored ones in 105 minutes, with a passing score of 68% - about 41 of the 60 scored questions. There are no performance-based or live-coding tasks, and no reference materials are allowed. There is also no formal prerequisite, though Salesforce suggests one to two years of development experience and at least six months on the Lightning Platform. One more structural fact: PD1 is the formal prerequisite for Platform Developer II, so it is the gateway to the whole developer track.
Why reading fluency beats memorisation
Most PD1 questions describe a requirement or show a snippet and ask what happens, what is wrong, or which approach is best. Two options will often both look plausible, and the right one reflects platform judgement: respecting governor limits, choosing declarative tools where they fit, placing logic correctly in the save order, enforcing security in code that serves a UI. That judgement comes from writing real code in a free Developer Edition org, which is why every chapter here pairs concepts with hands-on practice. A note on integrity: every sitting begins with accepting the Salesforce Certification Program Agreement and Code of Conduct, and sites promising “real questions” breach it - build your skills from the official trail, the documentation and your own org instead.
How to use this course
Read the chapters in order. Chapter 2 establishes the platform model that everything else assumes; the Apex of Chapter 3 is the foundation for the UI work in Chapter 4 and the testing in Chapter 5. Treat the bold terms as a checklist you should be able to explain in a sentence, and implement each one in your practice org as you meet it. The final chapter turns the content into a schedule and walks through exam day.
Chapter 2: Developer Fundamentals (27%)
This section covers what makes the Salesforce platform distinctive. It rewards understanding why the platform works as it does, because those reasons drive every later design decision.
Multitenancy and governor limits
Salesforce is a multitenant platform: many customer orgs share the same infrastructure, and your customisations are stored as metadata that the platform interprets rather than as software you install on your own servers. The direct consequence is governor limits, runtime caps on queries, DML statements, CPU time and more, enforced per transaction so that no single org’s code can monopolise shared resources. Treat limits not as an obstacle but as the platform’s design language: they are the reason bulkification exists, the reason asynchronous Apex exists, and the reasoning behind a large share of exam questions. The platform’s architecture also follows MVC: objects and fields are the model, pages and components the view, and controllers and Apex the logic layer, with the Lightning Component Framework as the modern way to build the view.
Declarative versus programmatic
A signature PD1 skill is choosing between clicks and code. Formula fields calculate a value when read; roll-up summary fields aggregate detail records onto a master; validation rules block bad saves; Flow automates processes - all without code. Apex is for what those cannot express cleanly: complex branching, rich data transformation, work with collections across objects. The exam expects the professional default - reach for the declarative tool where it genuinely fits, write code where it does not - and it expects you to know the constraints that force the choice, such as roll-up summaries existing only on master-detail relationships.
Data modelling
Know the relationship types cold. A lookup relationship is a loose link: the child can exist without the parent. A master-detail relationship is ownership: the detail record requires its master, inherits its sharing, is deleted with it, and enables roll-up summary fields on the master. A junction object, a custom object with two master-detail relationships, models many-to-many. An external ID field lets integrations match records on an outside system’s key, which is what makes upsert operations idempotent. Expect scenario questions handing you a requirement and asking for the right structure.
Agentforce for developers
The newest fundamentals topic is Agentforce, Salesforce’s AI agent layer. At PD1 level you need its shape, not its internals: what use cases agents suit, what their limitations are, and the key developer fact that agent actions can invoke logic you build, including Apex. Study this from the current official material, since it simply does not exist in older courses.
Chapter 3: Process Automation and Logic (28%)
The largest section, and the core of the developer’s craft: Apex, queries, DML and triggers, plus the declarative automation they cooperate with.
Apex language fundamentals
Apex is Salesforce’s strongly typed, object-oriented language, close enough to Java that Java and C# developers read it quickly. Be fluent in classes, interfaces (method signatures a class commits to implement), control flow, and above all the three collections: List (ordered, allows duplicates), Set (unique values), and Map (key-value pairs, the workhorse of bulkified code). Exception handling with try-catch-finally matters both as syntax and as design: catching a DmlException and responding sensibly beats letting a whole transaction die.
SOQL, SOSL and DML
SOQL queries a single object and can traverse its relationships, parent fields in one query, child records in a subquery. SOSL text-searches across multiple objects at once, which is the discriminator the exam tests: one object with structure, use SOQL; a search term across many objects, use SOSL. DML covers insert, update, upsert (insert-or-update matched on ID or an external ID), delete, undelete and merge. Around all three sits bulkification: triggers receive up to 200 records per batch, so queries and DML must sit outside loops, records collected into collections and operated on once. A query or DML statement inside a loop is the classic exam wrong-answer, and the classic real-world limit breach.
Triggers and the save order of execution
An Apex trigger runs before or after records are inserted, updated, deleted or undeleted, and its context variables (Trigger.new, Trigger.old, Trigger.isInsert and friends) tell you what is happening. The design rule: before triggers modify the records being saved, no extra DML needed; after triggers see saved records with IDs, which is where related-record work belongs. Wrapping it all is the save order of execution, the fixed sequence a save follows - before triggers, then validation rules, then the save, then after triggers, then assignment rules and subsequent automation. Know it well enough to predict behaviour, including recursion: an update trigger that updates its own records fires again, and the standard guard is a static variable tracking that the logic already ran. Round out the section with with sharing versus without sharing, the class keywords deciding whether the running user’s record-sharing rules apply, and the main asynchronous options: future methods for fire-and-forget work like callouts, Queueable Apex for chained jobs with rich parameters, Batch Apex for very large volumes in chunks, and scheduled jobs to run on a timetable.
Declarative automation and combining it with code
Flow is a first-class automation citizen on the current exam. Know what a record-triggered flow can do, when it replaces a trigger, and when requirements - complex branching, heavy transformation, callouts - push you to Apex. The mature answer the exam rewards is architecture, not tribalism: declarative and programmatic automation coexist in one org, and you should be able to reason about how they interact during a save.
Chapter 4: User Interface (25%)
This section covers building UIs on the platform and, critically, keeping them secure.
Lightning Web Components
LWC is the modern default framework, built on web standards so the browser does natively what older frameworks did in JavaScript abstraction layers. Know the component model: HTML template plus JavaScript class, @wire for reactive data provisioning that re-runs when its parameters change, and imperative Apex calls when you need explicit control. Communication is a favourite topic: a child talks to its parent by dispatching a custom event; components in different hierarchies on the same page use the Lightning Message Service, which also reaches Aura and Visualforce. Aura components are the older Lightning framework, still supported and interoperable with LWC; Visualforce is the page-centric veteran, still examined but no longer the default for new work.
Apex behind components, and doing it securely
A component needing server data calls a static Apex method annotated @AuraEnabled. Simpler cases need no Apex at all: Lightning Data Service and the record form base components read and write single records with caching and sharing enforcement built in. The security topic is where easy marks hide: Apex runs in system mode by default, so code serving a UI must enforce object and field permissions itself, with WITH SECURITY_ENFORCED in SOQL or Security.stripInaccessible on results. Expect scenario questions where the flaw is a component happily showing users fields their profiles deny. Screen flows also count as UI: a wizard-style, multi-step input experience built declaratively. And Agentforce reappears here, since agent-driven experiences can sit in the UI and call the Apex you expose.
Chapter 5: Testing, Debugging, and Deployment (20%)
The smallest section, but dense with facts the exam checks precisely.
Apex testing
Test code lives in classes annotated @isTest, and by default tests see no org data - they must create their own, which keeps them repeatable (specific setup objects are the exception, and the seeAllData option exists but is a smell, not a habit). Test.startTest() and Test.stopTest() give the code under test a fresh set of governor limits and force asynchronous jobs to complete at stopTest, which is how you test future methods and queueables deterministically. System.runAs simulates another user’s record-sharing context, the tool for verifying access behaviour. The deployment gate is 75% overall coverage with every trigger touched, but the exam is explicit that coverage is not the point: assertions are what prove the code behaved, and a high-coverage test class with no assertions is a wrong answer waiting to be picked.
Debugging and deployment
For debugging, know the Developer Console (browser-based IDE with query editor and logs) and debug logs (the recorded trace of a transaction). For environments and deployment, know the ladder: Developer Edition orgs for learning, sandboxes as copies of production for building and testing, scratch orgs as short-lived source-driven environments in Salesforce DX workflows driven by the Salesforce CLI, and change sets as the point-and-click way to move customisations between related orgs. The exam expects you to match tool to situation - a solo admin-adjacent deployment suits a change set; a source-controlled team pipeline suits DX and the CLI.
Chapter 6: Study plan, practice and exam day
Allocate time by section weight
Process Automation and Logic (28%) and Developer Fundamentals (27%) are over half the exam and reward the same investment: daily hands-on Apex in a free Developer Edition org. User Interface (25%) needs real component-building time, not just reading about LWC. Testing, Debugging, and Deployment (20%) is the most factual section and the fastest to secure late in the plan. For most developers coming from Java, C# or JavaScript, eight weeks at eight to ten hours a week works: fundamentals in week one, Apex and queries in weeks two and three, triggers and automation in week four, UI in weeks five and six, testing and deployment in week seven, and a full review in week eight. People already working on the platform can compress to six weeks; those short on recent coding practice should stretch to twelve. To turn whichever timeline you pick into dated weeks from your own start date, use the free study-plan generator.
Practise deliberately
Build one small application and grow it as you study: a data model with both relationship types in week one, Apex classes against it in week two, a bulkified trigger and a record-triggered flow in week four, an LWC calling @AuraEnabled Apex in week five, and tests with real assertions in week seven. Drill concept questions steadily and review every miss until you can explain why the better option wins. In the final week, work through the four official certification-prep modules on Trailhead, which map one-to-one to the exam sections, and do timed reviews to calibrate pace - 105 minutes for around 65 questions is comfortable if you are fluent, punishing if you are translating syntax in your head.
Exam day and what follows
You book through your Trailhead account, which connects to Salesforce’s official scheduling system, and sit the proctored exam onsite at a testing center or online. Expect 60 scored questions plus up to five unscored ones in 105 minutes, a 68% passing score, no reference materials, and the certification agreement to accept before you start. Registration is US$200 with a US$100 retake, plus applicable taxes, published in USD and JPY. Afterwards, two habits: complete the free annual maintenance badge on Trailhead every year, because missing it expires the credential; and if you are continuing up the track, PD1 is your formal prerequisite for Platform Developer II.