Free Salesforce Platform Development Lifecycle and Deployment Architect
Practice Questions

Question 1

Northern Trail Outfitters' Salesforce team has grown from 3 to 18 developers and admins in a year. They still deploy manually from source control, and regressions now reach UAT almost every week because nothing stops a broken change from being merged. Leadership wants a repeatable, gated process but is not subject to multi-org audit requirements. Which two practices should the DevOps engineer introduce first? Choose 2 answers.
A. Run automated builds and tests for every commit in a fresh environment before changes are promoted.
B. Require a change advisory board sign-off and an audit record for every change in every environment.
C. Protect the main branch so merges are blocked until the automated checks for the change have passed.
D. Let each developer deploy straight to UAT from a local machine so that feedback on changes is faster.
E. Add a progressive exposure stage that releases each change to a small group of production users first.

Accepted Answer

Correct answer: A. Run automated builds and tests for every commit in a fresh environment before changes are promoted. | C. Protect the main branch so merges are blocked until the automated checks for the change have passed.
The Well-Architected Operational Excellence pillar describes the next step beyond manual deployment as automated continuous integration: every commit builds and tests in a fresh environment and a protected main branch blocks merges until checks pass, catching regressions before merge. Change advisory board sign-off with audit records belongs to the governance-heavy enterprise profile and adds weight this team does not need yet. Deploying from local machines to UAT is the manual, discipline-dependent pattern causing the regressions. Progressive exposure in production is an enterprise release control layered on top of a working pipeline, not the first fix for regressions reaching UAT.

Question 2

Each of Northern Trail Outfitters' six developers set up their scratch orgs differently by hand, enabling features and loading sample records in their own way. Code that works for one developer often fails for another, and the CI job uses yet another setup. The architect is assessing what technology practice is missing. What should the architect recommend?
A. Give each developer a Developer Pro sandbox instead, since sandboxes copy production configuration and remove the need for any setup.
B. Ask the most experienced developer to set up every scratch org for the team, so that the configuration is at least consistent across all developers.
C. Standardize on a shared Partial Copy sandbox for all developers, so everyone always sees the same configuration and sample data.
D. Define environments in source: a scratch org definition file for edition, features and settings, plus versioned seed data that CI also uses.

Accepted Answer

Correct answer: D. Define environments in source: a scratch org definition file for edition, features and settings, plus versioned seed data that CI also uses.
The Operational Excellence guide describes environments defined from source: a scratch org definition file specifies the edition, enabled features and settings, so anyone, or a pipeline, can create an identical org, and setting values and reference records load from versioned seed data. That removes the drift between developers and CI. A Developer Pro sandbox is a refreshed copy of production configuration, not a definition in source, so it does not codify features or seed data and gives up disposable per-feature orgs. One person building every org adds a bottleneck without codifying anything. A shared Partial Copy sandbox brings back the shared-environment anti-pattern where developers overwrite each other's work.

Question 3

Northern Trail Outfitters' QA sandbox was on a preview instance, and the team planned to run regression tests on the upcoming Winter release there. Two days after the published sandbox preview cutoff date, a tester refreshed the QA sandbox to get fresh configuration. The sandbox is now on the current release while the team's other preview sandboxes have been upgraded. What is the most likely cause?
A. The tester's refresh used a sandbox template, and templated sandboxes are always placed on the current release.
B. Refreshing after the cutoff routed the sandbox to a non-preview instance, so it stays on the current release.
C. Preview upgrades apply only to Full sandboxes, so the refreshed QA sandbox was never eligible for the preview.
D. The production org has not yet been upgraded, and a sandbox can never run a newer release than its production org.

Accepted Answer

Correct answer: B. Refreshing after the cutoff routed the sandbox to a non-preview instance, so it stays on the current release.
A sandbox's upgrade status depends on its instance, and refreshing is the only way to move it; a preview sandbox refreshed after the cutoff is routed to a non-preview instance and reverts to the current release. Sandbox templates control which data a Partial Copy or Full sandbox copies, not which instance it lands on. The preview applies to every sandbox on a preview instance, not only Full sandboxes. The whole point of the sandbox preview is that preview sandboxes run the next release several weeks before production does.

Question 4

Cloud Kicks' operations director asks for a second production org in another region for disaster recovery. The business continuity plan's recovery targets are met by the platform's standard availability, and no regulation requires independence from a single region. What should the technical architect recommend?
A. An active-active pair of orgs with users split by region, so both orgs serve traffic and no capacity sits idle.
B. An active-passive pair of orgs, with the secondary org kept in sync and idle until the primary region fails.
C. A single org on platform-managed redundancy, with effort spent on application-layer reliability such as resilient integrations.
D. A single org copied each night into a Full sandbox that acts as the production failover org during an outage.

Accepted Answer

Correct answer: C. A single org on platform-managed redundancy, with effort spent on application-layer reliability such as resilient integrations.
Well-Architected says single-region deployment with platform-managed redundancy is sufficient for most solutions, and architects should focus on application-layer reliability; multi-org is reserved for needs such as recovery targets beyond platform capabilities or regulatory independence, neither of which applies. Active-active needs sophisticated data synchronization, user routing and conflict resolution that nothing here justifies. Active-passive still multiplies licensing and operational cost for an unneeded standby. A sandbox is not a production org, so it is not a failover target for live users.

Question 5

A state agency's Salesforce org runs on Government Cloud Plus. Its agile delivery lead wants Lifecycle Center (formerly DevOps Center) so that admins and developers can track work items and promote changes through one pipeline from a single interface. What should the architect advise?
A. Turn on Lifecycle Center from the App Launcher, because it's available in every org and needs no further review before the team uses it.
B. Install a partner DevOps tool from AgentExchange instead, because Security Review certifies every listed tool for use in Government Cloud Plus.
C. Use Lifecycle Center as planned, because the October 2026 rename from DevOps Center also made it available in Government Cloud Plus orgs.
D. Lifecycle Center isn't offered there; the DevOps Center managed package is, but it can send data outside the boundary, so review it first.

Accepted Answer

Correct answer: D. Lifecycle Center isn't offered there; the DevOps Center managed package is, but it can send data outside the boundary, so review it first.
Salesforce Help's Lifecycle Center overview says Lifecycle Center isn't available in Government Cloud Plus, while DevOps Center (Managed Package) is available there as interoperable and turning it on can send data outside the authorization boundary, so the agency needs a compliance review before relying on it. The overview's App Launcher note covers evaluation and doesn't override its edition list. The October 2026 note only renames DevOps Center to Lifecycle Center; it doesn't change where the product is available. The Well-Architected Trust guide says Security Review checks a listed package before it reaches AgentExchange, and that Salesforce certifies the platform while architects own what's built on it, so a listing isn't a Government Cloud Plus certification of the tool.

Question 6

Admins at Cumulus Financial prototype new page layouts and validation rules directly in production to see how they behave, then delete whatever they don't keep. The release manager wants a low-cost environment, refreshable as often as daily, where admins can try setup changes against production's current configuration without copying any records. Which environment should the release manager provide?
A. A Full sandbox, because it is a complete replica of production and lets admins see exactly how each change affects the existing records.
B. A Partial Copy sandbox, because its sandbox template copies a small sample of records that admins can use to evaluate each prototype.
C. A scratch org from the Dev Hub, because it copies production's current configuration automatically each time an admin creates one.
D. A Developer sandbox, because it copies production metadata only, can be refreshed every day, and is the most plentiful sandbox type.

Accepted Answer

Correct answer: D. A Developer sandbox, because it copies production metadata only, can be refreshed every day, and is the most plentiful sandbox type.
A Developer sandbox copies production's configuration without data, has a 1-day refresh interval, and Salesforce's best-practice article describes it as the most plentiful type for proofs of concept and setup playgrounds. A Full sandbox copies all data and can be refreshed only every 29 days, which is far more than prototyping needs. A Partial Copy sandbox copies records and refreshes only every 5 days, which breaks the no-records and daily requirements. A scratch org is built from source and a definition file, not copied from production, so it doesn't start with production's configuration.

Question 7

Get Cloudy Consulting's coding standard says every Apex class that calls an external system must have a name ending in Callout. Reviewers keep missing violations, and no built-in Salesforce Code Analyzer rule checks this convention. The technical architect wants violations caught automatically on every pull request and in developers' editors, using the same rule set in both places. Using the current Salesforce Code Analyzer (v5), what should the architect recommend?
A. Publish the naming convention on the team wiki and add it to the pull request checklist so reviewers confirm it on each change.
B. Write an Apex test class that queries ApexClass records and fails whenever a class that makes callouts lacks the required suffix.
C. Raise the severity of the closest built-in PMD naming rule to High so that each scan reports a wider range of naming problems.
D. Write a custom XPath PMD rule, reference it from code-analyzer.yml in the repository, and use that configuration in VS Code and CI.

Accepted Answer

Correct answer: D. Write a custom XPath PMD rule, reference it from code-analyzer.yml in the repository, and use that configuration in VS Code and CI.
PMD supports custom rules, including XPath rules defined in a ruleset file, and Code Analyzer runs them once the ruleset is referenced from code-analyzer.yml; keeping that file in the project root lets the CI pipeline use it, and the Code Analyzer VS Code extension reads a configuration file in the project root (or one named in its Config File setting), so both apply the same rules. A wiki page and checklist still depend on the reviewers who are already missing the violations. An Apex test can't reliably tell from ApexClass records which classes make callouts, and it runs only after the code is deployed. Changing a built-in rule's severity changes how its findings are ranked, not what the rule checks, so it still won't detect the missing suffix.

Question 8

Developers at Universal Containers edit the scratch org definition file by hand whenever production gains a feature or setting, and code that works in scratch orgs still fails in production because the features don't match. Working in a current org, the architect wants scratch orgs whose edition, features and settings mirror production without maintaining that list by hand. What should the architect recommend?
A. Create each developer's scratch org from a refreshed Developer sandbox so the org inherits production's features, metadata and records together.
B. Capture an org shape of production and create scratch orgs from it; the shape also carries production's custom metadata, so no deployment is needed.
C. Capture an org shape of production, create scratch orgs from it, then deploy the project's source and load test data, which the shape leaves out.
D. Set --edition enterprise on every create command, because the edition alone determines which features and settings a scratch org receives.

Accepted Answer

Correct answer: C. Capture an org shape of production, create scratch orgs from it, then deploy the project's source and load test data, which the shape leaves out.
Org Shape for Scratch Orgs captures the source org's features, Metadata API settings with Boolean fields, edition, limits and licenses so scratch orgs can be created from it without hand-building the definition; it doesn't include metadata types or data, so the team still deploys its source and loads test data. Saying the shape carries custom metadata is the trap, because metadata types are explicitly excluded. Scratch orgs aren't created from sandboxes, and org shape itself isn't available in sandboxes as a source org. Edition alone doesn't capture the individual features and settings that production has enabled, which is the drift the team keeps hitting.

Question 9

Northern Trail Outfitters' QA sandbox holds 2,000 evenly sized accounts with five contacts each, and every release passes its tests there. In production, one distributor account owns about 280,000 contacts. A release that recalculates contact rollups on the parent account failed in production with record lock errors on that account. What should the technical architect change in the test data strategy?
A. Add another 50,000 accounts with five contacts each to the QA sandbox, so the next release is tested against a larger total volume
B. Build test datasets that mirror production's shape, including the skewed distributor account, relationship depth and edge-case values
C. Leave the rollup logic out of QA testing and validate it in production after each release, where the real account data exists
D. Have the Apex unit tests insert 200 contacts under each test account, because trigger chunks of 200 reproduce the production failure

Accepted Answer

Correct answer: B. Build test datasets that mirror production's shape, including the skewed distributor account, relationship depth and edge-case values
Well-Architected lists inadequate test data, meaning sandbox data that doesn't represent production's volumes, relationships and edge cases, as an anti-pattern that hides production issues, and its reliability guidance notes that DML row locks fail when concurrent transactions collide and that queries exceed limits under data skew. The failure depended on one parent owning a huge number of children, so the test data must reproduce that shape. More uniform accounts raise the record count without reproducing the skewed parent. Validating only in production is how the failure happened in the first place. A unit test with 200 contacts per account checks bulk handling but never creates the concentration of children on one parent that caused the locks.

Question 10

Cloud Kicks' developers deploy to their sandboxes with sf project deploy start and rely on source tracking to push only local changes, using --ignore-conflicts when someone else has changed a component. The DevOps engineer wants the production pipeline to work the same way. What should the architect tell the engineer about production?
A. Production supports source tracking once it is enabled in Dev Hub settings, so the same commands work after an admin turns the feature on there
B. Production never allows source tracking, so the pipeline must name components with a manifest, source directory or metadata list
C. Production allows source tracking only for Apex classes and triggers, so declarative components must be deployed separately through change sets
D. Production supports source tracking only when --ignore-conflicts is set, because conflict detection is the reason tracking is off by default there

Accepted Answer

Correct answer: B. Production never allows source tracking, so the pipeline must name components with a manifest, source directory or metadata list
The CLI reference states that some orgs, such as production orgs, never allow source tracking, and that --ignore-conflicts applies only to orgs that allow source tracking and has no effect in production. A production pipeline therefore selects components explicitly with --manifest, --source-dir or --metadata. The Dev Hub setting in production turns on source tracking for the Developer and Developer Pro sandboxes created or refreshed from it, not for production itself; Enable Source Tracking in Sandboxes adds that Partial Copy sandboxes, Full sandboxes and Developer Edition orgs can't have source tracking at all. No partial tracking exists for Apex in production, and change sets aren't required for declarative components. Setting --ignore-conflicts doesn't turn tracking on.

Question 11

Cloud Kicks' Shipping_Option.Express custom metadata record had Max_Weight__c set to 30. The new release must leave that field blank for Express while other records keep their values, so the developer deleted the Max_Weight__c values block from Shipping_Option.Express.md-meta.xml and deployed. Production still shows 30. Refer to the remaining file: Express Carrier__c FastShip Which change makes the deployment clear the value? A. Delete the Max_Weight__c field from the Shipping_Option__mdt type definition in the same deployment, so the value is discarded. B. Redeploy the same file with the --purge-on-delete flag, so that field values missing from the file are removed from the record. C. Add a values block for Max_Weight__c whose value element is , so the deployment clears the old value. D. Retrieve the record from production first, so the next deployment compares the two versions and drops the missing value.

Accepted Answer

Correct answer: C. Add a values block for Max_Weight__c whose value element is <value xsi:nil="true"/>, so the deployment clears the old value.
The Metadata API CustomMetadata reference says that leaving out a field's values block means the field's value doesn't change: it stays at its previous value for updated records. Explicitly specifying the value with xsi:nil="true" sets the field to null, which clears the old value. Deleting the field from the type would remove it from every record, which the release must avoid. --purge-on-delete only controls whether components deleted through destructive changes skip the Recycle Bin. A deployment doesn't compare against previously retrieved files, so retrieving first changes nothing.

Question 12

Universal Containers' Visit_Note__c custom object holds 60,000 records in production. The release adds a new master-detail field on Visit_Note__c pointing to Care_Plan__c and deploys it with Metadata API. In the Full sandbox rehearsal, the deployment failed until the team soft-deleted the existing Visit_Note__c records. What should the architect put in the production runbook?
A. Nothing extra, because the deployment automatically assigns each existing Visit_Note__c record to a default Care_Plan__c master
B. Validate with checkOnly first, because a successful validation converts existing detail records into orphan-safe lookup records
C. Use purgeOnDelete in production so that the soft-deleted records are restored after the deployment adds the new field
D. Export the Visit_Note__c records before soft-deleting them, because the deployment permanently deletes them from the Recycle Bin

Accepted Answer

Correct answer: D. Export the Visit_Note__c records before soft-deleting them, because the deployment permanently deletes them from the Recycle Bin
For a Metadata API deployment that adds a new master-detail field, all existing detail records must be soft-deleted first or the deployment fails, and during the deployment those records are permanently deleted from the Recycle Bin and can't be recovered, so a pre-deployment export is essential if the data matters. Salesforce doesn't assign a default master to existing records. A checkOnly validation commits nothing and changes no records. purgeOnDelete doesn't work in production and controls Recycle Bin storage of deleted components; it never restores records.

Question 13

Cloud Kicks is replacing the pricing engine that every sales rep uses on every quote. The CTO wants the new engine validated in production with real data and real ERP integrations before all reps depend on it, and wants to be able to switch it off immediately if margins look wrong, without another deployment. What should the architect recommend?
A. Deploy the engine switched off behind a custom metadata type or custom setting flag, enable it for a small group of reps first, and widen or disable it by configuration
B. Deploy the engine active for everyone over a weekend, and roll back by redeploying the previous release if reps report wrong prices on Monday
C. Run the pricing engine's tests in production with RunAllTestsInOrg after the deployment, because tests that pass there prove it works with real data
D. Copy production data into a Developer sandbox and test only there, since any testing of a new feature in production exposes it to every user

Accepted Answer

Correct answer: A. Deploy the engine switched off behind a custom metadata type or custom setting flag, enable it for a small group of reps first, and widen or disable it by configuration
Well-Architected guidance describes deploying high-risk changes with features disabled behind custom metadata type or custom setting configuration, which enables testing in production without user exposure, gradual rollout to segments and instant rollback through a configuration change. Exposing every rep at once and relying on a redeployment is slower and riskier than flipping a flag. Apex tests create their own data and mock callouts, so a test run in production doesn't validate behaviour with real data and live integrations. A Developer sandbox holds no production records, and the claim that production testing must expose all users is exactly what a feature flag avoids.

Question 14

Ursa Major Solar is moving its sandbox masking to Data Mask & Seed in a current org and must build masking policies that cover about 60 objects. The technical architect wants the app's proactive PII detection to suggest a Mask With option for as many sensitive fields as possible, so the team doesn't have to review every field by hand. Which preparatory work should the architect prioritize?
A. Encrypt the sensitive fields with Shield Platform Encryption, so that the masking engine recognizes them as protected data
B. Turn on field history tracking for the sensitive fields, so that the app can see which field values change most often
C. Convert the sensitive text fields to the Encrypted Text field type, so that their values stay hidden in every sandbox copy
D. Populate data classification metadata, such as Data Sensitivity Level and Compliance Categorization, on the org's fields

Accepted Answer

Correct answer: D. Populate data classification metadata, such as Data Sensitivity Level and Compliance Categorization, on the org's fields
Data Mask & Seed's proactive PII detection evaluates each policy field's Sensitivity value and its Categories value to assign a suggested Mask With option, so completing field-level data classification (owner, usage, sensitivity and compliance categorization) gives the policies a head start. Shield Platform Encryption protects data at rest but isn't what the detection reads, and encryption is not masking. Field history tracking records value changes for auditing and plays no part in suggesting masking options. Converting fields to Encrypted Text changes how values display to users without the right permission; it neither masks the stored data in a sandbox nor feeds the PII detection.

Question 15

AW Computing releases Salesforce changes twice a year. Each release bundles six months of work from four teams, takes a whole weekend to deploy, and the last two caused weeks of follow-up fixes, so leadership now wants even fewer releases. The release manager instead proposes smaller releases every two weeks. Which two points support the release manager's proposal? Choose 2 answers.
A. Smaller, more frequent deployments carry less risk per release and give the teams faster feedback on each change.
B. Releasing rarely because deployments are painful makes each release larger and riskier, which feeds the same cycle.
C. Frequent releases remove the need for regression testing, because each release contains only a handful of changes.
D. Deploying every two weeks lets the team skip the staging sandbox and validate each release directly against production.
E. Fewer production deployments a year lower the change failure rate, because each release gets a longer period of testing.

Accepted Answer

Correct answer: A. Smaller, more frequent deployments carry less risk per release and give the teams faster feedback on each change. | B. Releasing rarely because deployments are painful makes each release larger and riskier, which feeds the same cycle.
The Well-Architected guide says frequent deployment enables rapid feedback and reduces deployment risk through smaller changes, while low deployment frequency signals deployment pain that teams avoid, creating a vicious cycle in which infrequent deployment makes each deployment riskier. Smaller releases still need regression testing, which the guide's CI practice runs automatically on every change. Release cadence doesn't replace staging, which the guide describes as the final production-like validation before deployment. The claim that fewer releases lower the change failure rate argues against the proposal and contradicts AW Computing's own experience of large releases needing weeks of fixes.

Question 16

Northern Trail Outfitters must train 150 warehouse supervisors on a new receiving process two weeks before it goes live. Trainers need realistic sample records from production, and the training org must show the new process exactly as it will be released. What should the release manager include in the release plan?
A. Refresh a Partial Copy training sandbox from production with a template, which brings the release candidate across because it's already in staging.
B. Refresh a Partial Copy training sandbox from production with a template, then deploy the release candidate to it before training starts.
C. Create a Developer sandbox for the training, because it copies a sample of production data and can be refreshed every day between classes.
D. Run the training in the Full staging sandbox while QA runs performance tests there, because only Full sandboxes can be used for training.

Accepted Answer

Correct answer: B. Refresh a Partial Copy training sandbox from production with a template, then deploy the release candidate to it before training starts.
A Partial Copy sandbox copies production metadata plus a template-defined sample of data, and Salesforce lists training among its uses, so it gives realistic records. A refresh copies from production, so a process that isn't live yet has to be deployed to the training sandbox as part of the release plan. The refresh doesn't pull anything from the staging sandbox, which is why the first Partial Copy option fails. Developer sandboxes copy metadata only, with no production data. Training isn't limited to Full sandboxes, and sharing staging with performance tests would disrupt both activities.

Question 17

An admin at Northern Trail Outfitters added a validation rule directly in production that requires a Region__c value on every Account. The rule never reached Git or the sandboxes. A week later, the production deployment of the next release fails because 14 Apex tests that insert Accounts without Region__c now fail. What should the team do?
A. Add the rule to Git and the sandboxes, update the test data factory to set Region__c, and rerun the tests in a sandbox before redeploying.
B. Deactivate the rule in production before every future deployment and reactivate it afterward, since tests can't satisfy validation rules.
C. Redeploy with --test-level NoTestRun, because tests that fail on validation rules don't count toward the production deployment requirements.
D. Mark the failing test classes @IsTest(SeeAllData=true), so that the tests read existing Accounts that already pass the new rule.

Accepted Answer

Correct answer: A. Add the rule to Git and the sandboxes, update the test data factory to set Region__c, and rerun the tests in a sandbox before redeploying.
The direct change left production different from the environments where the tests passed, and validation rules apply whatever the data source, so the fix is to bring the rule into Git and the sandboxes and update the test data so tests create valid records. Toggling the rule around every deployment removes its protection and adds manual risk; tests can satisfy validation rules by creating valid data. NoTestRun applies only to deployments to development environments such as sandboxes, not to production. Relying on existing org data makes tests fragile and doesn't fix the inserts that fail.

Question 18

Before releasing a new version of its Billing unlocked package, which depends on the Core unlocked package, Get Cloudy Consulting's client must confirm which of its six production orgs have Core installed at all, because two orgs were onboarded late. Using the current Salesforce CLI, which approach gives the release manager that answer?
A. Run sf package version list against the Dev Hub, which shows each package version and the production orgs it is installed in.
B. Retrieve each org's metadata with sf project retrieve start --package-name Core and compare the files to work out the version.
C. Query Setup Audit Trail in the Dev Hub org, which logs every installation of its packages in the subscriber orgs it supports.
D. Run sf package installed list against each production org, which lists the packages installed in that org.

Accepted Answer

Correct answer: D. Run sf package installed list against each production org, which lists the packages installed in that org.
The CLI command sf package installed list lists the org's installed packages and takes the target org as a flag, so running it against each of the six orgs shows which of them have Core before Billing goes out. sf package version list lists the package versions in the Dev Hub and isn't a per-org inventory of installations. Metadata retrieved with --package-name is for reference only, and comparing files is an unreliable way to tell whether a package is installed. Setup Audit Trail records package installs in the org where they happen, not in the Dev Hub for other orgs.

Free Salesforce Platform Development Lifecycle and Deployment Architect
Practice Questions

What is the Platform Development Lifecycle and Deployment Architect exam like?

Questions by exam section

Application Lifecycle Management

Question 1 · Harder · Choose 2

Planning

Question 2 · Medium

Question 3 · Medium

System Design

Question 4 · Medium

Question 5 · Medium

Question 6 · Easier

Building

Question 7 · Medium

Question 8 · Medium

Question 9 · Harder

Deploying

Question 10 · Medium

Question 11 · Medium

Question 12 · Harder

Testing

Question 13 · Harder

Question 14 · Medium

Releasing

Question 15 · Easier · Choose 2

Question 16 · Medium

Operating

Question 17 · Medium

Question 18 · Medium

Where to go after these 18 questions

Get Platform Development Lifecycle and Deployment Architect exam updates by email

Ready for a full Platform Development Lifecycle and Deployment Architect practice exam?

Free Salesforce Platform Development Lifecycle and Deployment ArchitectPractice Questions

What is the Platform Development Lifecycle and Deployment Architect exam like?

Questions by exam section

Application Lifecycle Management

Question 1 · Harder · Choose 2

Planning

Question 2 · Medium

Question 3 · Medium

System Design

Question 4 · Medium

Question 5 · Medium

Question 6 · Easier

Building

Question 7 · Medium

Question 8 · Medium

Question 9 · Harder

Deploying

Question 10 · Medium

Question 11 · Medium

Question 12 · Harder

Testing

Question 13 · Harder

Question 14 · Medium

Releasing

Question 15 · Easier · Choose 2

Question 16 · Medium

Operating

Question 17 · Medium

Question 18 · Medium

Where to go after these 18 questions

Get Platform Development Lifecycle and Deployment Architect exam updates by email

Free practice questions for other Salesforce Architect certifications

Ready for a full Platform Development Lifecycle and Deployment Architect practice exam?

Free Salesforce Platform Development Lifecycle and Deployment Architect
Practice Questions