Free Salesforce-Platform-Integration-Architect Practice Test Questions (2026)

Explanation:

For a synchronous Available-to-Promise (ATP) callout that queries product availability and reserves inventory during the customer checkout process, the integration runs in the same transaction as the user action. Salesforce imposes strict limits on synchronous callouts, including a maximum timeout of 120 seconds, while concurrent long-running transactions are also constrained.

To build a scalable solution, the architect must therefore evaluate:

Typical response times of the external ATP service under normal load
This helps determine whether the external service can consistently respond within an acceptable time during normal checkout activity.

Worst-case response times under peak load or degraded conditions
This helps identify whether the external service could approach or exceed Salesforce timeout limits during periods of high traffic or reduced performance.

These response-time figures determine whether the callout can reliably complete within the Salesforce timeout, whether the user experience remains acceptable, and whether additional patterns such as Continuations, asynchronous fallbacks, caching, circuit breakers, or capacity planning are required.

Why the other options are incorrect

A. The maximum query cursors open per user on the service
Incorrect. Query-cursor limits apply to Salesforce SOQL or certain external-data-source integrations. They are not a primary scalability concern for a standard synchronous HTTP callout to an external ATP service.

C. The number of batch jobs that can run concurrently
Incorrect. Batch Apex concurrency limits are irrelevant to this scenario. The requirement is a real-time, user-facing synchronous callout rather than an asynchronous batch process.

Key Exam Takeaway
For synchronous external-service integrations, response time is a critical scalability factor. Architects should evaluate both normal and worst-case response times to ensure the callout remains within Salesforce limits and provides an acceptable checkout experience.

Explanation:

Northern Trail Outfitters wants to integrate its new Identity and Access Management (IAM) system, which supports SAML and OpenID Connect, with Salesforce Community Cloud to provide self-registration and single sign-on (SSO) for subscribers.

OpenID Connect Authentication Provider

Salesforce supports OpenID Connect (OIDC) as an authentication provider.
OIDC is built on OAuth 2.0 and is well suited to modern IAM systems that support self-registration and federated identity.
It allows subscribers to authenticate through the IAM system and gain access to Salesforce Community Cloud without requiring multiple logins.

Just-in-Time (JIT) Provisioning

JIT provisioning automatically creates a Salesforce user record at the time of login if one does not already exist.
This provides immediate access for new self-service customers without requiring manual user creation.
This is particularly useful when thousands of subscribers may register themselves and require immediate access to the community.

Why not the other options?

B. OpenID Connect Authentication Provider and Registration Handler

Incorrect. Registration Handlers are associated with certain authentication-provider-based registration flows, while for the OIDC scenario described here, JIT provisioning is the appropriate mechanism for automatically creating users during authentication.

C. SAML SSO and Registration Handler

Incorrect. SAML can be used for SSO, but the scenario specifically requires self-registration and immediate user access. A SAML-based approach can require a Registration Handler Apex class to create users, adding development and maintenance requirements compared with an OIDC and JIT provisioning approach.

Key Exam Takeaway

When an external IAM system supports OpenID Connect and the requirement includes SSO with automatic user creation at login, consider an OpenID Connect Authentication Provider together with Just-in-Time (JIT) provisioning.

Reference
Salesforce Documentation: OpenID Connect Authentication Provider
Salesforce Documentation: Just-in-Time User Provisioning
Salesforce Documentation: SAML SSO and Registration Handler

Explanation:

Why A is correct:
When integrating Salesforce with multiple external systems, such as an ERP or ticketing system, where Salesforce is the system of record, establishing a robust data relationship is paramount.

Using an External ID field, configured as unique and enabled as an External ID, on Salesforce objects allows the system to store the primary key of the corresponding external-system record. This enables reliable upserts, helps prevent duplicate record creation, and provides the necessary cross-reference key for middleware to match and update the correct record across heterogeneous systems in both directions.

Why B is incorrect:
Relying on the middleware layer to locally cache external IDs and manage cross-system mapping logic without native Salesforce identifiers introduces a fragile, high-maintenance architecture. Caching state externally increases the risk of data drift, synchronization failures, and complex recovery states if the middleware cache becomes out of sync or restarts.

Why C is incorrect:
While Change Data Capture (CDC) is an effective mechanism for publishing Salesforce data changes downstream, Option C only addresses one direction of the integration, Salesforce to external systems.

It does not address how systems correlate records or handle bidirectional synchronization, particularly when matching inbound changes from the external system back into Salesforce. Furthermore, CDC does not replace the fundamental requirement to store external keys for reliable upsert operations.

Key Exam Takeaway
For bidirectional integrations involving Salesforce and multiple external systems, External ID fields provide a reliable cross-reference mechanism. They allow middleware and external systems to identify Salesforce records consistently and support dependable upsert operations while reducing duplicate records and synchronization issues.

Reference:
Salesforce Pattern: Data Integration Patterns / Remote Process Sync / Data Virtualization
Salesforce Documentation: Data Integration Strategies (Integration Patterns and Practices)

Explanation

A. Change Data Capture + CometD subscriber — Correct

The requirements are:

Changes made to Contact records in Salesforce must be sent to the legacy homegrown application.
The synchronization must be event-driven.
The integration must be asynchronous.

Change Data Capture (CDC) is specifically designed to publish Salesforce record changes as change events. When a Contact is created, updated, deleted, or undeleted, Salesforce publishes a corresponding change event.

The homegrown application can subscribe to these events using a CometD client. The subscriber receives the events asynchronously, so Salesforce does not need to wait for the homegrown application to process the change.

The architecture is therefore:

Salesforce Contact change → CDC event → Salesforce event channel → CometD subscriber → Homegrown application

This directly satisfies all three requirements.

Why B is less appropriate

B. Platform Events — Not the recommended choice

Platform Events are also asynchronous and event-driven, so they can certainly be used for integrations. However, Platform Events are intended for publishing custom business events.

In this scenario, the requirement is specifically to synchronize changes to the Contact object. CDC automatically captures and publishes those record changes without requiring custom Apex or other logic to construct a custom Platform Event containing the changed fields.

With Platform Events, UC would need to build logic that detects Contact changes and publishes the appropriate custom event. That introduces unnecessary custom development when CDC already provides the required record-change event capability.

Key distinction for the exam

Change Data Capture (CDC)
Use when the requirement is:

"Tell an external system whenever Salesforce records change."

Platform Events
Use when the requirement is:

"Publish a custom business event when something meaningful happens."

Here, the requirement is record synchronization based on Contact changes, so CDC is the better fit.

Exam takeaway

Look for these clues:

Salesforce record changes
Event-driven synchronization
Asynchronous integration
External/legacy application
CometD subscriber

These strongly indicate:

Change Data Capture + CometD

Answer: A. Leverage Change Data Capture to track changes to the Contact object and write a CometD subscriber on the homegrown application.

Explanation:

Why B is correct:

When designing security and deactivation integration patterns (especially around identity management and immediate access revocation), an integration architect must take a holistic view. You need to analyze:

Data access prevention requirements: What does "immediate" truly mean? Is deactivation alone enough, or do active sessions need to be immediately revoked (e.g., via OAuth token revocation)?

Integration requirements: How will the HR system communicate the deactivation (e.g., SCIM, REST API, middleware)?

System constraints: Salesforce API limits, license constraints, identity provider (IdP) timing delays, and replication intervals.

Evaluating all three dimensions ensures the proposed design handles edge cases like active user sessions or cached tokens remaining valid after the user record is flagged as inactive.

Why A is incorrect:

Focusing solely on inbound integration requirements and frequency ignores critical security controls, session management constraints, and authorization requirements inherent to access prevention.

Why C is incorrect:

While data access requirements are essential, skipping system constraints and integration mechanics ignores technical limitations (such as whether Salesforce can be updated in real-time via SCIM or if a middleware layer is required to handle token revocation).

Reference
Salesforce Pattern: Identity and Access Management / User Provisioning / Security Integration Patterns

Salesforce Documentation: Salesforce Identity and Access Management Guide

Explanation:

The core problem described is architectural: a monolithic web service handling multiple P2P integrations (Salesforce ↔ billing, Salesforce ↔ ERP, Salesforce ↔ data lake) has created tight interdependencies, meaning a failure or change in one integration point can cascade and impact the others. This is a classic symptom of monolithic, point-to-point integration architecture — lack of isolation, fragile coupling, and poor scalability/resilience.

The recommended fix is to decompose the monolith into smaller, independent, purpose-specific services (a microservices approach) — each service handling one integration concern (e.g., a Billing integration service, an ERP integration service, a Data Lake integration service). This achieves:

Decoupling: A failure in the billing integration no longer takes down the ERP or data lake integrations
Independent scalability: Each service can be scaled, deployed, and maintained on its own release cycle
Improved performance: Smaller, focused services are easier to optimize, troubleshoot, and don't compete for shared resources/threads within a single monolithic process
Better fault isolation: Failures are contained to the specific integration domain rather than cascading across the whole system

This directly addresses the stated problem — tight interdependencies causing failures — by breaking the tight coupling at the architectural level.

Why not the others:
A (Use Bulk API for integrating back into Salesforce) — The Bulk API is useful for high-volume data loads to improve throughput/performance for large datasets, but it doesn't address the root cause here: the tight coupling and interdependency between the three separate integrations within a single monolithic service. Switching an API type doesn't decouple the systems.

B (Move the service from on-premise to cloud) — This is an infrastructure/hosting change, not an architectural change. Moving a monolith to the cloud might improve availability, scalability of compute, or reduce on-prem maintenance burden, but the fundamental problem of tight coupling between the three integrations within the same codebase/service remains unchanged — a monolith in the cloud is still a monolith. This doesn't solve the stated issue of interdependency-caused failures.

Key exam takeaway:
When a question describes monolithic integration architecture causing cascading failures or tight coupling, the answer almost always points toward decomposition into microservices / modular services — this is a fundamental integration architecture principle (isolate concerns, reduce blast radius, enable independent scaling and deployment) tested repeatedly on this exam.

Reference:
Salesforce Integration Patterns and Practices — "Enterprise Integration Patterns" / Microservices Architecture principles.

Explanation:

Before (and as part of) implementing Shield Platform Encryption for sensitive fields such as Social Security Numbers, Salesforce best practice is to ensure that data is encrypted with the most current tenant secret / encryption key.

When a new tenant secret is generated:

Newly created or updated data is encrypted with the new key.
Existing data remains encrypted under the previous key(s).

Salesforce therefore strongly recommends re-encrypting existing sensitive data with the latest key (via the Background Encryption Service or equivalent process) so that all protected data is under the current key material. This is a critical preparatory / early-implementation step for an Integration Architect to plan and execute.

Why the other options are incorrect

A. Encrypt all the data so that it is secure.
This is not recommended. Shield Platform Encryption should be applied selectively to only the data that requires it (based on data classification and threat modeling). Encrypting everything unnecessarily degrades performance and breaks platform functionality (filters, sorting, formulas, unique constraints, etc.).

C. Use Shield Platform Encryption as a user authentication or authorization tool.
This is incorrect. Shield Platform Encryption protects data at rest. It is not a replacement for authentication, authorization, profiles, permission sets, or field-level security. Access control remains the responsibility of the Salesforce security model.

Explanation:

When using Bulk API with parallel mode and large batch sizes (e.g., 2,000 records), jobs may fail with “Max CPU time exceeded” because Salesforce must process too much logic per batch. Reducing the batch size helps avoid CPU limits, but it introduces trade-offs:

Smaller batch size → Each batch contains fewer records, so Salesforce spends less CPU time per batch. This reduces the likelihood of hitting Apex governor limits.

However, more batches are required to process the same total volume of data.

This increases the overall execution time of the bulk job, since Salesforce must handle more batch overhead (setup, commit, retries).

Why not the other options?

B. Smaller batch size can trigger “Too many concurrent batches” error → Incorrect. That error occurs when too many batches are submitted simultaneously, not because of smaller batch sizes.

C. Smaller batch size may exceed the concurrent API request limits → Incorrect. Bulk API jobs are still counted as a single job submission, regardless of batch size. Smaller batches do not increase API request limits directly.

Thus, the main consideration is that smaller batch sizes improve reliability but increase total job execution time.

Reference

Salesforce Docs: Bulk API Best Practices
Salesforce Help: Bulk API Limits and Performance

Explanation:

B. Salesforce B2C Commerce to Service Cloud Connector — Correct

The requirement is specifically to allow Salesforce Service Cloud agents to see customer order history from B2C Commerce while managing cases.

The Salesforce B2C Commerce-to-Service Cloud integration is designed for this type of commerce-to-service use case, providing a prebuilt integration rather than requiring UC to build and maintain a custom integration.

Salesforce's current documentation describes the broader Commerce/Service experience as providing service agents with a unified view of customer and order information. Salesforce Order Management can integrate with B2C Commerce and Service Cloud so agents can access order information from the service experience.

The important exam clue is that this is a standard Salesforce product integration requirement. When a purpose-built connector is available, an architect should generally prefer it over developing a custom API or introducing middleware.

Why the other options are incorrect

A. REST API offered by Commerce Platform — Incorrect

A REST API can technically retrieve B2C Commerce order information, but UC would have to build the integration logic required to:

authenticate to B2C Commerce,
retrieve the appropriate customer/order information,
map the data into Salesforce,
expose it to service agents, and
maintain the integration.

That is unnecessary when a Salesforce-provided connector addresses the Commerce-to-Service use case.

C. MuleSoft Anypoint Platform — Incorrect

MuleSoft Anypoint Platform is appropriate when UC needs a broader integration architecture involving multiple systems, orchestration, transformation, API management, or complex integration flows.

This question has a much narrower requirement: B2C Commerce order history needs to be available to Service Cloud agents. A purpose-built Salesforce connector is the more direct solution.

Explanation:

Why B is correct:
To give new self-service customers "instant access" via an external IAM system using SAML, Salesforce provides a declarative feature called Just-in-Time (JIT) provisioning. When a customer attempts to log in to the Experience Cloud (Community) site through the external IAM system acting as the Identity Provider (IdP), the IdP sends a SAML assertion to Salesforce. If JIT provisioning is enabled, Salesforce reads the user attributes contained in that assertion (such as username, email, and first/last name). If a matching user record doesn't already exist, Salesforce automatically creates the user on-the-fly and logs them in seamlessly during the initial login handshake.

Why A is incorrect:
Registration Handlers (Auth.RegistrationHandler) are specifically used with OpenID Connect or custom Auth Providers rather than native SAML SSO configurations to handle user provisioning and attribute mapping.

Why C is incorrect:
While OpenID Connect Auth Providers combined with JIT provisioning can also provision users dynamically, the scenario explicitly introduces an IAM system utilizing SAML standards alongside OpenID capabilities, where SAML JIT is the targeted out-of-the-box declarative framework for handling enterprise-scale assertions and auto-creation of contact/community user records.

Reference
Salesforce Pattern: Identity and Access Management / Single Sign-On (SSO) / Just-in-Time Provisioning
Salesforce Documentation: SAML Just-in-Time Provisioning Implementation Guide