• Cert++
  • Practice
  • Certle
  • Review
  • Tracks
  • Checklist
  • Guides
  • Upgrade
Cert++
  1. Home
  3. Platform Development Lifecycle and Deployment Architect

Platform Development Lifecycle and Deployment Architect

Checklist progress

0/133Learned

Platform Development Lifecycle and Deployment Architect

Study Checklist

  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Architect

Checklist progress

0/133Learned

  • Assessing ALM maturity of a customer organization — identifying signals of low, medium, and high maturity and the governance gaps each implies
  • Ad hoc and repeatable ALM maturity levels — characteristics and the tooling, process, or structural changes to advance
  • Defined and managed ALM maturity levels — characteristics and the tooling, process, or structural changes to advance
  • Optimizing ALM maturity level — characteristics and continuous improvement practices
  • Comparing waterfall vs. agile vs. hybrid development methodologies in the context of Salesforce ALM — when to recommend each based on project risk, team maturity, and delivery cadence constraints
  • Risk-based trade-offs between agile speed and governance control — recommending iterative delivery models while maintaining compliance and change management requirements
  • Governance strategy selection based on team size, project complexity, and regulatory requirements — choosing the appropriate level of process formality and oversight
  • The role of a Center of Excellence (CoE) in Salesforce ALM governance — when to recommend establishing one and what it should own
  • Release approval gates in a Salesforce deployment pipeline — purpose and appropriate use cases
  • Change advisory board (CAB) — purpose, composition, and appropriate use cases in a Salesforce deployment pipeline
  • Identifying ALM maturity gaps across people, process, and technology dimensions for a customer with ad-hoc deployments and no version control
  • Developer, QA, admin, and architect roles and handoffs in a mature Salesforce ALM team
  • Release manager role and responsibilities in a mature Salesforce ALM team
  • Source control and CI/CD tool evaluation for a Salesforce ALM pipeline
  • Static analysis and deployment tooling evaluation for a Salesforce ALM pipeline
  • Building a roadmap to improve ALM maturity for a customer currently using manual change sets — sequencing process, tooling, and training improvements
  • Risks introduced by direct production changes and the mitigation steps required to restore ALM integrity
  • Configuration drift and data leakage as environment risks — recommending mitigation strategies
  • Technical debt accumulation risk in long-lived orgs — identifying signals and recommending governance controls to prevent further drift
  • Mitigating the risk of conflicting parallel development streams sharing a single sandbox — recommended environment isolation strategies
  • Sandbox refresh lag as an environment risk — recommending mitigation strategies
  • Selecting a governance framework (ITIL, SAFe, Agile, custom hybrid) for a Salesforce program based on organizational culture and release cadence requirements
  • Defining approval gates and escalation paths within a Salesforce governance framework for an enterprise customer with multiple business units
  • Release coordination across vendor partners in multi-vendor Salesforce implementations
  • Change ownership and IP rights in multi-vendor Salesforce implementations
  • Strategies for assessing the impact of a Salesforce seasonal release on an existing org — sandbox preview, release notes analysis, and regression testing planning
  • Salesforce release preview sandbox window and opt-out mechanisms — understanding which sandbox types receive preview instances, the window duration, and how to opt an org out of a release window
  • Using sandbox preview instances to evaluate seasonal release impacts before production upgrade — timing, access, and testing scope considerations
  • Impact of a Salesforce seasonal release on an active CI/CD pipeline — identifying which automated tests, API versions, or deployment scripts may break and planning remediation before the upgrade window
  • Critical-update opt-in and auto-activation timelines — architectural implications of deferring or accepting critical updates in production
  • Communicating seasonal release changes to business stakeholders and coordinating UAT cycles around Salesforce's release schedule
  • Capabilities and benefits of agile project management tools (e.g., Jira, Azure Boards) in managing Salesforce sprint work, backlog grooming, and release planning
  • Integrating agile tracking tools with Salesforce source control and CI pipelines — traceability from story to deployment artifact
  • Single-org vs. multi-org architecture trade-offs — evaluating data isolation, licensing, complexity, and integration overhead given business unit separation requirements
  • Org strategy considerations for an acquisition scenario — deciding whether to merge into an existing org or maintain separate orgs based on business and technical constraints
  • Governor limits and platform capacity constraints as architectural drivers in org strategy — identifying when limits should influence org design decisions
  • Developer and Developer Pro sandbox types — capabilities, refresh frequency, and appropriate use cases
  • Partial Copy and Full Copy sandbox types — capabilities, data volume, refresh frequency, and appropriate use cases
  • Sandbox refresh strategy — when to refresh, impact on active development, and sequencing refreshes around release cycles and seasonal Salesforce releases
  • Designing a sandbox environment hierarchy for an org with multiple parallel development streams, a dedicated training environment, and a staging environment for UAT
  • Hotfix environment strategy — using a dedicated sandbox to isolate critical production fixes without contaminating ongoing development branches
  • Scratch org usage as part of a package-based development environment strategy — when scratch orgs replace or complement traditional sandboxes
  • Native deployment tools — Change Sets, Salesforce CLI (sf deploy), and ANT Migration Tool — strengths, weaknesses, and appropriate scenarios
  • Change Set limitations — no destructive changes in the same deployment, no version tracking, point-to-point topology only, manual dependency ordering
  • When Change Set limitations warrant migration to CLI or CI/CD tooling
  • Deployment validation vs. quick deploy — when to use quick deploy, the conditions that qualify a deployment for quick deploy, and the risks
  • CI/CD pipeline architecture for Salesforce — defining stages (build, validate, test, deploy) and the role of each tool in the pipeline
  • Salesforce DevOps Center — its role as a native release management layer, how it integrates with GitHub-based source control, and the scenarios where it is preferred over third-party tools
  • Third-party deployment tools (Copado, Gearset, Flosum) for Salesforce — strengths, weaknesses, and when to use
  • CI/CD platform selection for Salesforce — comparing GitHub Actions, Jenkins, Azure DevOps, and Bitbucket Pipelines for Salesforce pipeline orchestration based on team toolchain and pipeline complexity
  • Metadata API deployment order dependencies — understanding the order metadata components must be deployed to avoid dependency failures
  • Git branching strategies for Salesforce development — trunk-based development, Gitflow, and feature branching — trade-offs and recommended use cases for each
  • Branching strategy for a customer with a hotfix requirement alongside an active feature branch — coordinating the release of both without regression
  • Handling declarative changes (configuration) alongside programmatic changes (code) in the same source control repository — tracking flow and layout changes with metadata API
  • Managing merge conflicts in Salesforce XML metadata — strategies and tooling to detect, prevent, and resolve conflicts in metadata files
  • Semantic versioning and tagging strategies in Salesforce source control — aligning Git tags to production releases for rollback and audit purposes
  • Minimum Apex code coverage requirements for production deployment — understanding the 75% org-wide floor, the 1% per-trigger requirement, what counts toward coverage, and what does not
  • Positive path and negative path Apex unit test design — when each is required
  • Permission-based unit tests — testing record access, FLS, and profile/permission set assignments in Apex using System.runAs()
  • Test data isolation in Apex — @isTest(SeeAllData=false) as the default behavior, when SeeAllData=true is justified, and the risks of tests depending on org data
  • Test data factory patterns in Apex — building reusable test data factories vs. using @testSetup and when to prefer each approach
  • Apex mock frameworks for callout testing — implementing HttpCalloutMock and WebServiceMock (StubProvider) to isolate unit tests from external dependencies
  • Bulk and large data volume Apex unit test design — when required and how to implement
  • Large data volume testing in Apex — using Test.startTest/stopTest, governor limit resets, and test data volume to simulate production load conditions
  • Org-based development vs. package-based development — key differences in source tracking, deployment mechanism, and team collaboration model
  • Salesforce CLI source-tracking in org-based development — how sf project deploy/retrieve and source tracking differ from the traditional Metadata API pull/push model
  • Scratch org capabilities and limitations — shape, definition files, data seeding, and how scratch orgs enable consistent, reproducible development environments
  • Choosing between scratch orgs and developer sandboxes for a given team structure — factors including cost, lifecycle duration, concurrency, and team size
  • Scratch org expiry and lifecycle management — default 7-day expiry, maximum 30-day limit, implications for long-running feature branches, and strategies to avoid losing work
  • sfdx-project.json structure and packageDirectories configuration — how project definition files govern source format, package membership, and multi-package project layout
  • Unlocked packages as a migration path from org-based to package-based development — use case selection criteria and organizational prerequisites
  • Defining Salesforce Apex and LWC coding standards — naming conventions, trigger frameworks, bulkification requirements, and documentation standards
  • Pull request review process for Salesforce development — what reviewers should check, required approvals, and how PRs gate CI pipeline execution
  • PMD and Salesforce Code Analyzer for Apex static analysis — rules enforced and when to use each
  • Integrating static analysis into the CI pipeline — failing builds on critical violations vs. reporting-only gates and the governance tradeoff
  • Metadata API capabilities for deployment — supported metadata types, deployment size limits, and asynchronous deploy/retrieve lifecycle
  • Metadata API limitations — unsupported metadata types (e.g., some standard objects, reports in certain contexts), what must be migrated manually
  • Tooling API vs. Metadata API for deployment — when to use Tooling API (incremental Apex, real-time compile) vs. Metadata API (full deployments)
  • Deploying metadata with dependencies — managing the order and packaging of components when cross-component references would cause deployment failures
  • Destructive changes in Salesforce deployments — using destructiveChanges.xml and destructiveChangesPre.xml to delete metadata components, limitations when combined with additive changes in the same deployment
  • Deployment rollback strategies — Salesforce's lack of native rollback and the mitigation patterns (destructive changes, backup, version control revert) architects use
  • Deployment runbook design — documenting pre/post steps, rollback procedures, and validation steps for a production deployment
  • Pre-deployment checklist — disabling automation and preparing the target org before a deployment window
  • Managing user access before and during a deployment window
  • Post-deployment steps — re-enabling flows/workflows, assigning permission sets, and activating record types
  • Post-deployment data migrations and when they are required
  • Reports, dashboards, connected apps, and custom settings — Metadata API deployability limitations and manual deployment candidates
  • Distinguishing technical reference data (picklist values, custom settings, custom metadata) from transactional data — implications for deployment approach
  • Custom Metadata Types vs. Custom Settings for storing reference data — differences in deployability, access patterns, and packaging support
  • Managing environment-specific reference data (e.g., integration endpoints, feature flags) using Custom Metadata with deployment-time overrides vs. Custom Settings with manual updates
  • Deploying reference data using Salesforce CLI data commands, Data Loader scripts, or managed/unlocked package records — trade-offs in automation and reliability

Given a customer scenario, describe and recommend an appropriate testing methodology.

0/5

  • Testing pyramid for Salesforce — unit tests, integration tests, system tests, and UAT — scope, ownership, and tooling for each level
  • Shift-left testing strategy for Salesforce — integrating automated testing earlier in the development cycle to reduce late-stage defect cost
  • Recommending test methodology for an org with complex automation and integrations — balancing Apex unit tests, end-to-end testing, and manual regression
  • Regression test strategy for a high-volume, frequently-released Salesforce org — selecting what to automate, what to test manually, and what to deprioritize
  • Browser/UI automation testing for Salesforce Lightning using tools like Selenium, Provar, or Copado Robotic Testing — when to introduce automated UI tests

Given a customer testing strategy, describe the appropriate test execution methodology and coverage requirements.

0/6

Code coverage calculation in Salesforce — how org-wide coverage is computed, what triggers a coverage check, and how to interpret test coverage results

Learn this concept
Unseen

Apex test execution options — running local tests, all tests, or specified tests — and when each is appropriate for CI/CD validation vs. full regression

Learn this concept
Unseen

RunSpecifiedTests vs RunLocalTests vs RunAllTests — when to use each and coverage implications

Learn this concept
Unseen

When Salesforce requires RunLocalTests or higher for production deployments

Learn this concept
Unseen

Managing test execution time in large orgs — parallelism, test class isolation, and strategies to keep CI pipeline duration acceptable

Learn this concept
Unseen

Test coverage degradation risk in package-based development — ensuring dependent package tests run and cumulative coverage is maintained

Learn this concept
Unseen

Given a customer scenario, describe and recommend a unified test data strategy that utilizes representative data in a secure manner throughout the development lifecycle.

0/4

  • Unified test data strategy design — how to provide representative, consistent test data across all environments without exposing production PII
  • Partial Copy sandbox and test data seeding — using a Partial Copy sandbox as the source of representative data for lower environments
  • Data masking and anonymization strategies for Salesforce test environments — tools and approaches to protect sensitive data in sandboxes
  • Test data lifecycle management — refreshing and maintaining test data sets aligned to sandbox refresh cycles to prevent test data staleness
  • Managed package use cases — ISV distribution, IP protection, subscriber upgrade lifecycle, and limitations on post-release changes
  • Unlocked package use cases — internal modular deployment, dependency management, and source-driven development without ISV constraints
  • Choosing between managed, unmanaged, and unlocked packages for a given customer release scenario — evaluating IP protection, upgradeability, and deployment speed requirements
  • Package versioning — major vs. minor versions and semantics
  • Package dependencies — defining and managing dependencies between unlocked packages in a multi-package project
  • Namespace considerations for managed vs. unlocked packages — when a namespace is required, its impact on component naming, and implications for future package evolution
  • Deprecated components and subscriber impact during package upgrades
  • Mapping a sandbox environment strategy to a release plan with three parallel development streams and an upcoming major release
  • Staging sandbox role in the release plan — full copy sandbox as pre-production gate, UAT execution environment, and performance testing target
  • Hotfix stream integration into an ongoing release plan — resolving conflicts between a hotfix branch and in-flight feature branches before next release
  • Integrating a training environment into the release plan — when to refresh, how to isolate from development changes, and who owns data in the training sandbox
  • Release management process — change freeze periods, go/no-go criteria, release notes, and post-release monitoring
  • Release cadence selection — continuous delivery, sprint-based, or scheduled major release approaches and their fit for different customer contexts
  • Coordinating a release across multiple Salesforce orgs — sequencing deployments, managing shared reference data, and handling rollback across orgs
  • Feature flagging and dark launching in Salesforce — using custom metadata or permission sets to release code to production without activating features
  • Blue-green and canary release patterns applied to Salesforce — using permission sets, profiles, or custom metadata to control phased feature rollout to user populations
  • Implications of making configuration changes directly in production — impact on source of truth, configuration drift, and downstream environment sync
  • Urgent production change request under pressure — evaluating the risk of a direct production change vs. the risk of delay through a proper change management process
  • Emergency change process design — defining a sanctioned fast-track path for production changes that preserves auditability and rollback capability
  • Steps to integrate a direct production change back into the ALM pipeline — retrieve, commit to source control, back-propagate to lower sandboxes, and document
  • Detecting and reconciling configuration drift when production has diverged from source control — tools and processes to identify delta and re-synchronize
  • Governance controls to prevent unauthorized direct production changes — change approval workflows, production org lockdown strategies, and audit trail monitoring
  • Strategies for managing shared metadata components across multiple Salesforce orgs — packages, template repos, and manual synchronization compared
  • Using unlocked packages to share and version common components across multiple orgs — package subscriber model and update propagation process
  • Release artifact governance in a multi-org landscape — defining ownership, approval, and promotion of shared components to prevent fragmentation
  • Cross-org change management coordination — aligning release windows, dependency tracking, and regression testing when changes affect multiple connected orgs
  • Event logs and deployment history for post-release monitoring and diagnosis

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform Development Lifecycle and Deployment Architect studiers.

Go to Discord

Test coverage degradation risk in package-based development — ensuring dependent package tests run and cumulative coverage is maintained

Explainer

Learn More

Practice Question

Keep going

Next conceptUnified test data strategy design — how to provide representative, consistent test data across all environments without exposing production PII

Checklist progress

0/133 (0%)

0 of 133 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle
Back to track

Study Community

Ask questions and get the latest info from other Platform Development Lifecycle and Deployment Architect studiers.

Go to Discord

Explainer

Salesforce requires 75% code coverage for production deployments, but organization-wide coverage calculations typically exclude tests originating from installed packages. Developers must manage this risk because adding new code without tests dilutes the overall percentage, and relying on package tests to maintain coverage often fails because they are not counted in the org total unless specific deployment test levels are used.

Core information
  • Organization code coverage is calculated by dividing covered lines by total lines of code in the org, generally excluding coverage from package-related tests unless they fire local triggers.
More details and nuances
  • Code coverage numbers often differ between sandbox and production because data and metadata variations can cause tests to fail or execute different code paths in the destination environment.