Plat-Arch-202 Salesforce Certified Platform Development Lifecycle and Deployment Architect Exam Topics and Questions

Application Lifecycle Management sets the foundation for everything that follows in this exam. You are assessed on your ability to structure how changes move from idea to production, how teams coordinate across environments, and how governance scales without choking velocity. The weight is modest, but the conceptual ground it covers underpins the planning, building, and releasing topics that carry heavier percentages. Candidates who treat this as a warm-up section lose marks because the scenarios assume you already know why ALM exists and what breaks when it does not. The cost comes from vague answers that describe process in theory rather than solve a specific coordination problem.

How Application Lifecycle Management is tested

Eight percent translates to roughly six to eight items, and each one presents a scenario where something in the lifecycle is misaligned. You are asked to identify the consequence or recommend the fix. The traps are answers that sound like good practice in general but do not address the specific dysfunction described. For example, an item might describe a team making changes directly in production while another team works in a sandbox. The wrong answer will propose better documentation. The right answer will name the integration step that reconciles the two streams. You lose marks when you pick the response that feels safe rather than the one that closes the gap the scenario exposes. The demand is diagnostic, not definitional.

Planning is where you translate organisational reality into a workable release strategy. The exam shifts from lifecycle theory to the messy specifics of customer environments: immature ALM practices, competing project streams, seasonal release windows, and governance that either does not exist or exists in triplicate. Thirteen percent makes this a significant scoring area, and the sub-topics are tightly focused on assessment and risk mitigation rather than abstract best practice.

– Maturity, governance and the people layer

Assessing ALM maturity means identifying which capabilities are missing and which roles need to own them. The exam gives you a scenario with scattered responsibilities, no clear ownership of environments, or ad hoc release approval, and asks what comes first. You need to know the difference between a process gap and a tooling gap. Governance frameworks are tested through scenarios where multiple teams, geographies, or business units need coordination. The wrong answer imposes a centralised model where a federated one fits, or vice versa. The right answer reflects the customer's actual structure and risk appetite, not a template. Candidates lose marks by recommending governance that looks rigorous on paper but cannot be sustained by the people described in the scenario.

– Risk, environment strategy and release cycles

Environment risks include sandbox sprawl, production hotfixes bypassing lower environments, or a lack of staging between UAT and live. You are expected to spot the failure mode and recommend the mitigation that fits the constraint. Salesforce releases three times a year, and the exam tests your ability to plan for them without disrupting in-flight projects. The trap is treating the release as an event rather than integrating it into the environment refresh cycle. You need to know when to preview in a sandbox, when to regression test, and when to hold a deployment because a new feature changes behaviour your customisations depend on. The cost is in the detail: missing one step in the sequence turns a safe release into a production incident.

How Planning is tested

Thirteen percent means ten to twelve items, and they present multi-variable scenarios where several things are suboptimal at once. You are asked to prioritise, sequence, or choose the intervention with the highest return. The examiners favour items that force a trade-off: you cannot have perfect governance and zero process overhead, so which constraint do you relax first? The wrong answers are the ones that solve a problem the scenario does not have, or that assume unlimited budget and executive sponsorship. The right answer acknowledges the mess and picks the smallest change that reduces the highest risk. Candidates lose marks when they choose the most comprehensive option instead of the most appropriate one. The demand is judgement under constraint, and the trap is over-engineering.

System Design carries the highest weight so far and focuses on the architecture decisions that enable or constrain everything downstream. You move from planning into the concrete choices about environments, tooling, and deployment pipelines. The sub-topics assume you understand the trade-offs between sandbox types, the role of agile tooling in a distributed team, and how org strategy shapes the environment landscape. The cost is in the details that look interchangeable until you apply them to a specific customer constraint.

– Agile tooling and org strategy

Agile tools are tested through their role in coordination, not their feature lists. You need to know what breaks when work item tracking is disconnected from source control, or when acceptance criteria live in email threads instead of a shared backlog. The exam gives you a scenario with multiple teams, asynchronous communication, or distributed ownership, and asks which tool capability closes the gap. Org strategy appears in scenarios where you must decide between a single production org, multiple orgs for different regions or business units, or a hub-and-spoke model. The wrong answer optimises for technical elegance. The right answer fits the governance, data residency, and operational model the customer already has. You lose marks by recommending consolidation when federation is the only viable path.

– Environment strategy and deployment components

Sandbox strategy is heavily tested. You are given a scenario with multiple project streams, a training requirement, a need for staging, and occasional production hotfixes, then asked to map sandbox types and refresh cycles to those demands. The trap is using Developer Pro sandboxes for everything, or assuming Full Copy is always the right choice for UAT. You need to know when Partial Copy suffices, when you need data volume, and when a scratch org is faster than a long-lived sandbox. Deployment strategy covers the tools and components that move metadata: change sets, Metadata API, SFDX, unlocked packages, and manual steps. The exam presents a deployment with dependencies, pre-deployment configuration, and post-deployment validation, then asks which combination of tools handles it. The wrong answer picks one tool and forces the entire pipeline through it. The right answer uses the simplest tool for each step and acknowledges what must be done manually.

How System Design is tested

Fifteen percent means twelve to fourteen items, and they test your ability to match architecture to constraint. The scenarios are detailed: a customer with four project teams, two production orgs, quarterly releases, and a compliance requirement that data never leave the Full Copy sandbox. You are asked to design the environment strategy or choose the deployment tool that satisfies all the constraints. The traps are answers that solve for one constraint and violate another, or that assume the customer can re-architect their org model to fit the tooling. The right answer works within the landscape as described. Candidates lose marks by choosing the most modern tooling over the most appropriate, or by ignoring the operational cost of the solution they recommend. The demand is systems thinking, and the trap is optimising one variable in isolation.

Building is where design turns into working code, and the exam focuses on the practices that keep quality high and merges clean when multiple developers work in parallel. The weight is substantial, and the sub-topics cover source control, test strategy, development models, and code quality gates. This is the domain where candidates with strong development experience can lose marks by relying on habits from other platforms that do not translate directly to Salesforce.

– Source control and branching strategy

Source control is tested through scenarios where you must recommend a branching model that fits the release cadence and team structure. You need to know when feature branching works, when it creates merge hell, and when a trunk-based model is faster. The exam gives you a customer with overlapping releases, long-lived feature branches, or a need to hotfix production while development continues, then asks how to structure the repository and merge strategy. The trap is recommending the branching model you use at work without checking whether it fits the scenario. The right answer reflects the number of developers, the frequency of integration, and the tolerance for merge conflicts. You lose marks when the strategy you choose creates more coordination overhead than the problem it solves.

– Test data, development models and code quality

Test data strategy covers how you build datasets that are representative, secure, and available across scratch orgs and sandboxes. The exam asks how to handle volume, permissions, and negative cases without copying production data verbatim. You need to know when to use synthetic data, when to anonymise, and when a subset of real data is the only option that surfaces the defect. Development models are tested by comparing org-based development in sandboxes against package-based development in scratch orgs. The wrong answer assumes one model is always superior. The right answer weighs the customer's CI/CD maturity, the complexity of dependencies, and whether they are building for a single org or distributing a package. Code quality gates include pull requests, static analysis, and coding standards. You are asked which combination catches the defect the scenario describes, and the trap is recommending a gate that sounds rigorous but does not address the actual failure mode.

How Building is tested

Fourteen percent means eleven to thirteen items, and they present failures in the build process and ask you to identify the practice that would have prevented them. A common pattern is a scenario where untested code reaches UAT, or where a merge conflict destroys a feature another team built. You are asked what was missing from the workflow. The wrong answers are practices that improve quality in general but do not prevent the specific failure described. The right answer is the gate or the branching rule that closes the gap. Candidates lose marks when they choose the most comprehensive testing strategy instead of the one that catches the defect type in the scenario. The demand is precision, and the trap is answering the question you wish had been asked instead of the one in front of you.

Deploying is where the build leaves the development environment and moves toward production, and the exam tests your command of the tools, their limitations, and the manual steps that fill the gaps. Fourteen percent makes this a high-stakes area, and the sub-topics focus on API capabilities, pre- and post-deployment tasks, and the special case of reference data that lives as records rather than metadata.

– Metadata and Tooling APIs

The Metadata API and Tooling API are tested through their capabilities and their edges. You need to know what each can deploy, what requires manual intervention, and when the API call succeeds but the deployment fails validation. The exam gives you a scenario with a mix of components: some supported, some partially supported, some not supported at all. You are asked to design the deployment sequence or identify what must be done outside the API. The trap is assuming that because a component appears in the metadata coverage report, it deploys cleanly. The right answer accounts for dependencies, order of execution, and the components that require point-and-click setup before or after the API call. Candidates lose marks by proposing a fully automated pipeline for a deployment that includes features the APIs cannot touch.

– Pre- and post-deployment steps and reference data

Pre-deployment steps include enabling features, adjusting org limits, or configuring settings that are not metadata. Post-deployment steps include running scripts, updating permission sets, or validating integrations. The exam asks how you sequence these around the API deployment, and the wrong answer is the one that assumes everything happens in a single push. Reference data is configuration stored as records: picklist mappings, tax codes, territory hierarchies. You need to know when to deploy it as static data, when to use a data loader, when to version it in source control, and when it belongs in a package. The trap is treating it as metadata when it is not, or leaving it out of version control because it looks like transactional data. The right answer reflects how often it changes, who owns it, and whether it must stay in sync across environments.

How Deploying is tested

Fourteen percent means eleven to thirteen items, and they describe deployments that partially succeed, fail validation, or leave the target org in an inconsistent state. You are asked what went wrong or how to structure the deployment to avoid the failure. The scenarios include components with dependencies, features that require manual enablement, and reference data that must be loaded before the metadata. The wrong answers are the ones that propose a single-step deployment when the scenario requires sequencing, or that ignore the components the APIs cannot handle. The right answer breaks the deployment into phases and names the manual steps explicitly. Candidates lose marks when they over-rely on automation and miss the edges where human intervention is unavoidable. The demand is operational realism, and the trap is the elegant solution that does not work.

Testing focuses on the strategy and execution that prove a release is ready, and the exam assesses your ability to design test coverage that balances rigour with velocity. Thirteen percent makes this a significant domain, and the sub-topics cover methodology, execution, and test data. The cost comes from answers that describe testing in theory rather than solve the specific coverage or data problem the scenario presents.

– Methodology and execution

Test methodology is tested through scenarios where you must choose between manual, automated, or hybrid approaches based on the release frequency, team size, and complexity. The exam gives you a customer with a specific risk profile and asks which testing model fits. The trap is recommending full automation when the team lacks the tooling or skills to maintain it, or proposing manual regression when the release cadence makes that unsustainable. Execution and coverage ask how much testing is enough. You need to know when unit tests suffice, when integration tests are required, when user acceptance testing must involve the business, and when performance testing is the only way to surface the defect. The wrong answer is the one that tests everything equally. The right answer concentrates effort where the risk is highest and accepts lighter coverage where the consequence of failure is low.

– Test data strategy

A unified test data strategy ensures that data is representative, secure, and available across all environments without copying production verbatim. The exam asks how to build datasets that reflect real volume and complexity while protecting privacy and staying within sandbox limits. You need to know when to anonymise, when to synthesise, when to subset, and when a full copy is the only option that surfaces the performance issue. The trap is treating test data as an afterthought and discovering in UAT that the data does not trigger the validation rule or the governor limit the production workload will hit. The right answer versions the data generation scripts, refreshes datasets on a schedule, and ensures that every environment from scratch org to Full Copy has access to the data it needs. Candidates lose marks when the strategy they propose works in development but breaks in staging because the data does not scale.

How Testing is tested

Thirteen percent means ten to twelve items, and they present test failures or coverage gaps and ask you to identify the missing layer. A common pattern is a scenario where unit tests pass but the integration fails, or where UAT succeeds but production fails under load. You are asked what was not tested. The wrong answers are the ones that add more of the same testing rather than the different kind the scenario needs. The right answer names the test type that would have caught the specific failure mode. Candidates lose marks when they choose the most comprehensive test plan instead of the one that addresses the gap. The demand is diagnostic, and the trap is assuming more testing is always better when targeted testing is what the scenario requires.

Releasing is the final step before changes reach production, and the exam tests your understanding of packaging models, sandbox-to-release mapping, and release management strategy. Thirteen percent makes this another high-weight domain, and the sub-topics assume you can choose between managed, unmanaged, and unlocked packages based on the use case, and that you can map a sandbox strategy to a release plan that handles multiple streams, training, staging, and hotfixes simultaneously.

– Package types and their trade-offs

Managed, unmanaged, and unlocked packages are tested through scenarios where you must choose the model that fits the distribution, upgrade, and intellectual property requirements. You need to know when managed packages are the only option, when their limitations make unlocked packages a better choice, and when an unmanaged package or no package at all is appropriate. The exam gives you a customer building for AppExchange, or distributing internally across orgs, or simply trying to modularise a monolithic org. The trap is choosing managed packages because they sound enterprise-grade, when the scenario requires the flexibility that only unlocked packages provide. The right answer reflects whether the customer needs to push upgrades, whether they need to protect code, and whether they can tolerate the namespace and API limits that managed packages impose. Candidates lose marks by optimising for one benefit and ignoring the constraints the package model introduces.

– Sandbox mapping and release strategy

Mapping sandbox strategy to a release plan means assigning the right sandbox type to each stage: development, integration, UAT, training, staging, and hotfix. The exam presents a scenario with multiple project streams releasing on different schedules, a need to train users before go-live, and the occasional emergency fix that cannot wait for the next planned release. You are asked which sandboxes handle which workloads and how they refresh. The trap is a one-size-fits-all model that uses the same sandbox type for every purpose. The right answer uses Developer or Developer Pro for active development, Partial Copy for integration testing, Full Copy for staging and training, and reserves a separate sandbox for hotfixes so they do not collide with in-flight features. Release management strategy covers how you sequence, communicate, and validate releases. The wrong answer is a rigid plan that cannot adapt when a dependency slips or a critical defect appears in UAT. The right answer builds in contingency and defines the criteria for go or no-go at each gate.

How Releasing is tested

Thirteen percent means ten to twelve items, and they ask you to choose the package model, the sandbox allocation, or the release sequence that satisfies the constraints. The scenarios are detailed: a customer with three project teams, a quarterly release to production, monthly training cohorts, and a requirement that hotfixes deploy within four hours. You are asked how to structure the environments and the release calendar. The wrong answers solve for one constraint and break another, or assume unlimited sandboxes and refresh windows. The right answer works within the limits Salesforce imposes and prioritises the highest-value stream when resources are scarce. Candidates lose marks when they propose a release strategy that looks robust on paper but cannot be executed with the sandboxes and people the scenario provides. The demand is operational feasibility, and the trap is the plan that requires more than the customer has.

Operating closes the loop by addressing what happens after go-live: changes made directly in production, the integration of those changes back into the development lifecycle, and the coordination of release artifacts across multiple orgs. Ten percent makes this the lightest topic, but the scenarios are among the most realistic because every production org eventually faces the tension between process and urgency.

– Production changes and lifecycle integration

The exam tests your understanding of the risks and trade-offs when a change is made directly in production, bypassing the usual development and testing environments. You are given a scenario where a business-critical configuration must be adjusted immediately, and you must explain the implications for regression testing, source control, and the next planned release. The trap is answering that production changes should never happen. The right answer acknowledges that they do, names the specific risks, and describes how to integrate the change back into the lifecycle so it does not get overwritten by the next deployment. You need to know how to reverse-engineer the change from production, commit it to source control, and validate that lower environments are updated before the next release cycle begins. Candidates lose marks when they prescribe ideal process instead of describing how to recover from the deviation.

– Multi-org artifact management

Multi-org scenarios ask how you manage common release artifacts when the customer operates multiple production orgs: regional instances, business unit orgs, or a hub-and-spoke model. You need to know when to centralise the artifact repository and deploy to all orgs from a single source, when to maintain separate repositories and accept drift, and when to use packaging to distribute shared components. The exam presents a scenario where some customisations are global and some are org-specific, and asks how to structure source control and deployment pipelines so global changes propagate without overwriting local variations. The trap is forcing a single model across all orgs when a hybrid approach is the only one that fits. The right answer reflects the governance model, the degree of shared ownership, and the operational cost of keeping orgs in sync. You lose marks when the strategy you propose creates more coordination overhead than the drift it prevents.

How Operating is tested

Ten percent means eight to ten items, and they describe operational realities that stress the lifecycle: a production hotfix, a business user who edits a flow directly in live, or a multi-org customer where one region deploys ahead of the others. You are asked what breaks, what the risk is, or how to integrate the out-of-band change. The wrong answers treat the deviation as a process failure and recommend training or governance without addressing the immediate technical problem. The right answer explains the specific risk, names the integration step that prevents regression, and acknowledges the constraint that made the shortcut necessary. Candidates lose marks when they answer with policy instead of mechanics. The demand is pragmatism, and the trap is the answer that assumes perfect adherence to process when the scenario explicitly describes a departure from it.