Free Salesforce Platform Development Lifecycle and Deployment Architect Practice Test Questions

Explanation

The key phrase in the question is: "the feature release artifact file has been tested." This tells us the deployment is using a release artifact — a single, pre-built metadata package (a `.zip` file), not source-format files.

The Metadata API (`mdapi`) commands work with metadata format (zip files). The Source (`source`) commands work with source format (individual files/directories). Since UC is deploying a release artifact (a packaged zip), the correct commands are the `mdapi` variants.

Why Other Options Are Incorrect

A. Authorize; Validate with `sfdx:source:deploy`; Deploy with `sfdx:mdapi:deploy` — This mixes command types. `source:deploy` works with source format, but the artifact is a metadata zip. You can't validate source format and then deploy metadata format for the same artifact — the formats don't match. Inconsistent and incorrect.

C. Authorize; Validate with `sfdx:source:deploy`; Deploy with `sfdx:source:deploy` — This uses `source:deploy` for both steps, which is for source-format deployments, not for a release artifact zip. Since the artifact is metadata format, `source:deploy` is the wrong command.

D. Authorize; Validate with `sfdx:mdapi:deploy`; Deploy with `sfdx:source:deploy` — This validates with the right command (`mdapi:deploy`) but then deploys with the wrong one (`source:deploy`). Again, a format mismatch — you can't validate a metadata zip and then deploy it as source format.

References

* Salesforce CLI Command Reference – `sfdx force:mdapi:deploy`: Deploy/validate metadata-format (zip) artifacts; `--checkOnly` for validation-only.
* Salesforce CLI Command Reference – `sfdx force:source:deploy`: Deploy source-format files/directories.

Explanation

Custom Metadata Types in Salesforce consist of two distinct metadata components that must both be included when deploying via the Metadata API:

A. `CustomMetadataType` — This represents the definition/schema of the custom metadata type: its fields, relationships, and structure. It's analogous to the "object definition." Without it, the type itself doesn't exist in the target org.

B. `CustomMetadata` — This represents the records (data) of the custom metadata type. Custom metadata records are metadata, not data, so they are deployed as part of the metadata package — unlike regular object records, which are data and are not deployed via Metadata API.

When deploying custom metadata types to production, UC must include both the type definition (`CustomMetadataType`) and its records (`CustomMetadata`) in the deployment package. If only the type is deployed, the records are missing; if only records are deployed, the type won't exist to hold them.

Why Other Options Are Incorrect

C. `CustomObject` — Custom metadata types are not custom objects. They are a separate metadata component (`CustomMetadataType`), and they don't behave like custom objects (no page layouts, no standard DML in the same way, records are metadata). Deploying `CustomObject` is unrelated to custom metadata types.

D. Custom Field — While custom metadata types have fields, the field metadata is included within the `CustomMetadataType` definition itself — you don't deploy a separate "Custom Field" component for custom metadata types. Fields of a custom metadata type are part of its type definition, not standalone custom fields on an object. So this isn't a separate required component.

References

Salesforce Metadata API Developer Guide – CustomMetadataType: Definition/schema of a custom metadata type.

Explanation

Change Sets are a declarative, point-and-click deployment tool in Salesforce. They have well-known limitations that an architect must consider.

A is correct because Change Sets are inherently manual — they are built and deployed through the Setup UI by selecting components and clicking "Deploy." They cannot be scripted, scheduled, or integrated into a CI/CD pipeline. This makes them unsuitable for automated, source-driven deployment workflows, which is a major consideration when choosing a deployment strategy.

D is correct because Change Sets cannot be rolled back. Once deployed, there is no built-in undo. To reverse a Change Set, you must manually recreate and deploy a new Change Set containing the previous versions of the components (or use another tool like the Metadata API with a backup). This lack of rollback is a significant risk consideration.

E is correct because Change Sets can only be used between orgs that are affiliated with the same production org (i.e., a production org and its sandboxes, or sandbox-to-sandbox within the same org family). They cannot be reused between unrelated Production Salesforce orgs — you can't deploy a Change Set from one company's production to another's. This limits their use for distributing changes across independent orgs.

Together, A, D, and E capture the core limitations: no automation, no rollback, and restricted to affiliated orgs.

Why Other Options Are Incorrect

B. Change Sets cannot be validated before deployment — This is false. Change Sets can be validated before deployment — Salesforce provides a "Validate" option that performs a dry run (deploy without committing), running tests and checking for errors. So this is not a limitation.

C. Change Sets cannot be used for orgs affiliated with the same production org — This is false and backwards. Change Sets are specifically designed to work between orgs affiliated with the same production org (production ↔ sandboxes). This is exactly the scenario they do support.

References

* Salesforce Help – Change Sets: Manual creation/deployment; only between affiliated orgs; no rollback.

Explanation

When loading data into Salesforce, the correct order is determined by object dependencies (lookup and master-detail relationships). Parent objects must be loaded before their children so that lookup/master-detail relationships can be established.

The dependency chain here is:

1. Accounts — A foundational parent object. Contacts and Opportunities both reference Accounts. Load first.

2. Contacts — Contacts have a lookup to Account (via `AccountId`), so Accounts must exist first.

3. Leads — Leads are standalone (no lookup to Account/Contact required), so they can be loaded independently — placing them here is fine since they have no dependency on the other objects.

4. Products — Products (`Product2`) are parents of `PricebookEntry` and `OpportunityLineItem`. Opportunities reference Pricebook/Products via `OpportunityLineItem`, so Products must exist before Opportunities' line items.

5. Opportunities — Opportunities reference Accounts (`AccountId`), so Accounts must be loaded first. They're loaded before their line items.

6. Opportunity Line Items — These are children of both Opportunity and Product (via `PricebookEntry`). They require both Opportunities and Products to exist first — so they must be loaded last.

This order respects all parent-before-child dependencies, making it the correct optimized sequence.

Why Other Options Are Incorrect

B. Leads, Contacts, Accounts, Opportunities, Products, Opportunity Line Items — This loads Contacts before Accounts. Contacts have a lookup to Account (`AccountId`), so loading Contacts before Accounts would fail or leave the relationship unpopulated. Wrong order.

C. Leads, Accounts, Contacts, Products, Opportunities, Opportunity Line Items — This order is actually functionally valid (Leads first is fine since they're standalone). However, the question asks for the optimized order, and option A places the foundational Account object first, which is the standard recommended starting point. Option C starts with Leads, which is acceptable but less optimal as a convention — Accounts-first is the preferred, dependency-anchored sequence. (Note: If both A and C were presented, A is the better "optimized" answer because it anchors on the primary parent, Accounts.)

D. Accounts, Contacts, Opportunities, Products, Opportunity Line Items, Leads — This loads Opportunities before Products. Opportunity Line Items depend on Products (via PricebookEntry), and while Opportunities themselves don't directly require Products, the line items do. More importantly, this order is illogical — Leads (standalone) are placed last for no reason, and it disrupts the natural dependency flow. Not optimized.

References

Salesforce Data Loader Guide – Loading Data: Load order and object dependencies.

Explanation

The project is large, has been in progress for 6 months, and must go live by end of month. The architect must ensure all metadata changes deploy smoothly and on time — this calls for verification and traceability practices.

B is correct because checking all deployed code into source control is fundamental to a smooth deployment. It:

* Provides a single source of truth for exactly what's being deployed.
* Prevents missing or untracked components (a common cause of failed deployments).
* Enables traceability, rollback, and auditability.
* Ensures nothing is accidentally left out of the deployment package.

With a large, 6-month project involving many contributors, source control is essential to guarantee completeness and correctness.

D is correct because validating the final deployment package against production before go-live is the critical pre-flight check. A validate-only (dry run) deployment to production:

* Confirms the package will deploy successfully (no missing dependencies, no compile errors).
* Runs all Apex tests in the production context, verifying the org will pass the 75% coverage requirement.
* Catches problems before the real deployment, so they can be fixed while there's still time before the deadline.

This is the standard "validate before deploy" best practice — especially critical for a large, deadline-driven release.

Together, B and D ensure the deployment is complete (B) and verified (D) — the two keys to a smooth, on-time go-live.

Why Other Options Are Incorrect

A. Create a new sandbox and perform a test deployment to that environment — This is unnecessary and time-consuming, especially with a tight end-of-month deadline. Creating and populating a new sandbox (and then deploying to it) adds overhead without the benefit of validating against the actual production environment. The better approach is to validate directly against production (D) — a dry run that tests the real target. A new sandbox doesn't validate production-specific issues.

C. Upload a Change Set from sandbox to production as early as possible — Deploying (uploading) a Change Set to production as early as possible is risky and ill-advised. You don't want to push incomplete or unverified changes into production prematurely. The correct practice is to validate first (D) and deploy only when ready — not to push a Change Set early just to "get it in."

References

Salesforce Trailhead – Application Lifecycle Management: Source control and validate-before-deploy.