Free Salesforce Platform Development Lifecycle and Deployment Architect Practice Test Questions

Explanation

UC wants to move to unlocked packages for better CI/CD integration, but the managed package contains objects and fields — and this is the critical constraint. Data lives in the objects/fields. If you uninstall the managed package, all data in its objects is deleted, which is catastrophic for a live org with integrations and local processes.

The correct migration strategy is a hybrid/separation approach:

1. Keep the managed package installed for its objects and fields — install a new version of the managed package that contains only the objects/fields (the data model). This preserves all existing data and relationships.

2. Migrate the code components — Apex classes, Visualforce pages, Lightning components — out of the managed package into unlocked packages. These components don't hold data, so moving them is safe.

3. Adopt unlocked packages for the code so UC gains the CI/CD benefits it wants (source-driven, version-controlled, pipeline-friendly) — while the data model remains protected inside the managed package.

This avoids data loss while achieving the CI/CD goal.

Why Other Options Are Incorrect

A. Export data, uninstall managed package, install unlocked package with the same namespace, restore data
— Uninstalling the managed package deletes the data, and you cannot reuse a managed package's namespace for an unlocked package (namespaces are tied to the package type/publisher). Even with export/restore, this is risky, complex, and may not fully restore relationships or references. It also breaks integrations during the migration window.

B. Export data, uninstall, install unlocked package without namespace, restore data
— Same core problem: uninstalling deletes the data, and dropping the namespace breaks all references from integrations, local processes, and code that expect the namespace. This is highly disruptive and error-prone.

C. Do not change to unlocked package; all CI/CD can be done with the managed package
— This ignores UC's explicit requirement to use unlocked packages for better CI/CD integration. While managed packages can participate in CI/CD to a degree, they are less flexible for source-driven pipelines. This option doesn't meet the business goal.

References

Salesforce Developer Docs – Unlocked Packages vs. Managed Packages: Differences in CI/CD support, namespaces, and data behavior.

Salesforce Developer Docs – Uninstalling a Package: Uninstalling deletes the package's data and components.

Explanation

The problem: administrators make permission set changes directly (likely in production or without tracking), and these changes cause SOQL statements to fail — almost certainly because permission sets control object and field-level access (CRUD/FLS). If a permission set removes access to an object or field that a SOQL query references, the query fails at runtime with an access-related error.

The root cause is that permission set changes are not tracked, reviewed, or tested before they affect code. The fix is to bring these changes into the source-driven, CI-monitored pipeline:

* Extract each permission set to source control so changes are versioned and visible.
* Commit and merge them through the normal branching process.
* Run CI checks — including Apex tests and static analysis — which will fail early if a permission change breaks a SOQL query or removes required field access.

This surfaces the problem earlier in the lifecycle (in CI, not production), which is exactly what the question asks for.

Why Other Options Are Incorrect

B. Ask administrators to only make changes to profiles instead
— Profiles have the same access-control impact as permission sets (they also grant/revoke object and field access). Switching to profiles doesn't solve the problem and actually goes against Salesforce's strategic direction (permission sets are preferred over profiles). It's a lateral move that doesn't improve early detection.

C. Create a sandbox refresh strategy to refresh every sandbox daily
— Daily sandbox refreshes are impractical, expensive, and slow, and they don't address the root cause. Refreshing a sandbox doesn't track permission changes or run CI checks — it just resets data. It won't bring the issue to the developer's attention earlier in a controlled way.

D. Advise developers to switch to SOSL queries
— SOSL doesn't bypass FLS/CRUD any more than SOQL does. Switching query languages doesn't fix permission-related failures and is a misguided workaround. The issue is access control, not query type.

References

Salesforce Trailhead – Application Lifecycle Management: Source-driven development and CI for metadata (including permission sets).

Salesforce Well-Architected Framework – Security & Operational Excellence: Tracking and reviewing access-control changes.

Explanation

UC is adopting an SFDX, source-driven, unlocked package development strategy. Two best practices are essential to make this successful.

B is correct because not all Salesforce metadata is supported by unlocked packages. Some metadata types cannot be included in packages (e.g., certain settings, standard object configurations, some CPQ or managed-package–related metadata). The Metadata Coverage Report (published by Salesforce) tells you which metadata types are supported by unlocked packages, source format, and other distribution methods. An architect must consult it before deciding what can go into packages — otherwise the package build will fail or silently omit components.

C is correct because packages must be installed and validated in test environments (e.g., scratch orgs, sandboxes) before production. This verifies:

* The package installs cleanly (no dependency or namespace conflicts).
* Apex tests pass in the install context.
* The installed components behave correctly with org-specific configuration.

Testing packages before production is a fundamental deployment safety practice, especially in source-driven CI/CD pipelines.

Together, B and C ensure UC knows what can be packaged (B) and verifies packages before production (C) — both critical to a healthy package strategy.

Why Other Options Are Incorrect

A. Version control does not need to be used, as packages manage all code and configuration
— This is fundamentally false. Unlocked packages are built from source in version control — Git is the backbone of source-driven development. Packages don't replace version control; they depend on it. Skipping version control breaks CI/CD, traceability, and rollback.

D. Move everything into a single monolithic package
— This is an anti-pattern. Best practice is modular, domain-aligned packages (e.g., by business capability), which improve deployability, reuse, and independence. A single monolithic package creates tight coupling, long build/deploy times, and deployment fragility — the opposite of what unlocked packages are meant to achieve.

References

* Salesforce Developer Docs – Metadata Coverage Report: Supported metadata types for unlocked packages, source format, and other distribution methods.

* Salesforce Developer Docs – Unlocked Packages: Best practices for modular package design and testing.

Explanation

The scenario: Sales and Service products are built by two separate teams, but the Sales team needs to use a specific function of the Service product, and the architect wants only the Sales team (no other team) to use those Service functions.

In second-generation managed packages (2GP), packages created under the same namespace can share code with each other using the `@namespaceAccessible` annotation. This annotation:

Exposes an Apex method or class so it can be called from another package in the same namespace.
Keeps it hidden from all other namespaces/orgs — so only the sibling package (Sales) can access it, and no external team can.

By creating two 2GP packages under the same namespace (one for Sales, one for Service) and annotating the shared Service methods with `@namespaceAccessible`, the architect achieves:

Controlled sharing — only the Sales package can call the exposed Service methods.
Encapsulation — other teams and external orgs cannot access those methods.
Clean separation — each team owns its own package.

This is precisely the mechanism Salesforce provides for cross-package code sharing within the same namespace in 2GP.

Why Other Options Are Incorrect

A. Create one managed package with both products; use a code review process with approvers from each team
— A single package couples the two teams' code, defeating the purpose of independent team ownership. A code review process is a human control, not a technical enforcement — it doesn't guarantee only Sales uses the Service functions. The requirement calls for technical access control, which this doesn't provide.

C. Create two managed packages; use an authentication token in the Service package
— This is over-engineered and not how Salesforce package access works. Building a custom token-based authorization mechanism to gate access is unnecessary complexity when the platform already provides `@namespaceAccessible` for exactly this purpose. It also doesn't leverage the namespace model.

D. Create two managed packages with Sales and Service namespaces; use `@salesAccessible` annotation
— The `@salesAccessible` annotation does not exist in Salesforce. This is a fabricated option. Additionally, different namespaces cannot access each other's code — packages in separate namespaces are isolated, so this approach would not even allow the sharing the requirement demands.

References

Salesforce Developer Docs – Second-Generation Managed Packages: Creating and versioning 2GP packages.

Salesforce Developer Docs – `@namespaceAccessible` Annotation: Sharing Apex classes/methods between packages in the same namespace.

Explanation

Salesforce's AppExchange Security Review enforces a set of security requirements that all partner applications must pass before listing. The single most common reason applications fail the review is failure to enforce CRUD (Create, Read, Update, Delete) and FLS (Field-Level Security) permissions.

In Apex, SOQL/DML operations run in system mode by default, which means they bypass object and field-level permissions. If a developer doesn't explicitly enforce CRUD/FLS — using constructs like:

* `Schema.sObjectType.Account.isAccessible()`
* `Schema.sObjectType.Account.fields.Name.isUpdateable()`
* `WITH SECURITY_ENFORCED` in SOQL
* `Security.stripInaccessible()`

...then users could read or modify records and fields they shouldn't. This is the most frequently flagged issue in security reviews because it's easy to overlook and affects nearly every app.

Why Other Options Are Incorrect

A. Session hacking — Session security is largely handled by the Salesforce platform itself (session settings, HTTPS, secure cookies). It is not the most common AppExchange security review failure — app developers have limited control over session management, so it's rarely the cause.

C. SOQL injection — While real and important, SOQL injection is less commonly the failing reason than CRUD/FLS. It occurs when user input is concatenated into queries; developers can prevent it with bind variables and `String.escapeSingleQuotes()`. It's a known issue but not the #1 failure cause.

D. Cross-site scripting (XSS) — XSS is a valid security concern (especially in Visualforce/LWC with unescaped output), but Salesforce provides built-in protections (e.g., automatic escaping in Visualforce with ``). It is not the most common reason for security review failure compared to CRUD/FLS.

References

Salesforce Partner Program – Security Review Requirements: CRUD/FLS enforcement is a core requirement.

Apex Developer Guide – Enforcing CRUD and FLS: `WITH SECURITY_ENFORCED`, `Security.stripInaccessible()`, and schema describe methods.