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

Explanation:

B. Create a PushTopic update event on the Opportunity object:
Correct. The requirement is for the affiliate company to receive immediate or near-real-time notifications when Opportunities change in the NTO Salesforce org. Since the affiliate already has a CometD client, Salesforce Streaming API is the appropriate integration mechanism.

A PushTopic defines a Streaming API channel based on a SOQL query. When an Opportunity record matches the PushTopic criteria and is updated, Salesforce generates a notification that the external CometD client can receive.

Streaming API uses CometD and the Bayeux protocol, allowing external clients to subscribe to Salesforce event channels and receive notifications without repeatedly polling Salesforce.

For example, the PushTopic could be configured around an Opportunity query such as:

SELECT Id, Name, StageName, Amount
FROM Opportunity

The affiliate's CometD client would then subscribe to the corresponding /topic/... channel and process the notifications.

Why the other options are incorrect

A. Poll the SOAP API getUpdated method:
Incorrect. getUpdated() follows a polling approach. The affiliate client would have to repeatedly call Salesforce to determine whether records have changed.

That does not satisfy the requirement as effectively as a push-based Streaming API solution. Salesforce describes Streaming API as a way to reduce unnecessary API requests associated with constant polling and to provide near-real-time notifications.

C. Create a connected app in the affiliate org and select "Accept CometD API Requests":
Incorrect. The CometD client needs to connect to the NTO Salesforce org because that is where the Opportunity records and event source reside. Creating a connected app in the affiliate org does not create a mechanism for NTO Opportunity changes to be published to the affiliate.

The key requirement is to configure the event source in NTO and have the external CometD client subscribe to it.

Exam takeaway

When you see:

External system or client
Immediate or near-real-time Salesforce record-change notifications
CometD client
Salesforce record such as Opportunity

Think Streaming API + PushTopic for this legacy exam scenario. Salesforce now classifies PushTopic as a legacy technology and recommends Change Data Capture for newer implementations, but B is the expected answer among these choices.

Explanation:

Why A is correct:
Lightning Web Components (LWCs) execute client-side code directly inside the user's browser. By default, Salesforce enforces a strict Content Security Policy (CSP) to help prevent cross-site scripting (XSS) and code injection attacks. This policy blocks outbound client-side HTTP or Fetch requests and WebSocket connections to third-party endpoints unless the target domain is explicitly registered under CSP Trusted Sites, also known as Trusted URLs, in Salesforce Setup with the appropriate directives enabled, such as connect-src.

Why B is incorrect:
Cross-Origin Resource Sharing (CORS) is a browser-level security mechanism enforced by the external server receiving the request. It determines whether that server allows responses to be read by a different origin, such as Salesforce. While CORS configuration issues can cause callouts to fail, configuring CORS within Salesforce whitelist settings is used for incoming requests to Salesforce APIs from external applications, not for outbound requests originating from an LWC.

Why C is incorrect:
Remote Site Settings are required for server-side callouts originating from Apex, such as requests made using the Http class. They do not govern client-side JavaScript or Lightning Web Component execution.

Reference/;
Salesforce Pattern: Client-Side Integration Security / Lightning Security Architecture
Salesforce Documentation: Call APIs from JavaScript (LWC Developer Guide)

Explanation:

Apex requires unit tests for callout logic, and Salesforce does not allow real HTTP callouts during test execution. Developers must use the HttpCalloutMock interface to simulate the external endpoint's response. The key requirement here is that the unit tests must confirm adherence to the RAML specification, meaning the mock responses need to be built directly from the field-level request and response payload definitions in the RAML contract.

By implementing HttpCalloutMock so that it returns responses that precisely match the structure, fields, and data types defined in the RAML specification, the architect ensures that:

The Apex client code is tested against a realistic, contract-accurate response.
Any mismatch between what the Apex code expects and what the actual API contract defines, such as missing fields, incorrect data types, or unexpected null values, will surface as test failures.
The tests validate actual adherence to the interface contract, rather than simply confirming that a callout occurred without throwing an exception.

This makes the mock the actual mechanism for validating conformance to the RAML specification. It is not enough to simply use a mock or invoke it; the mock's content must be driven by the specification for the tests to provide meaningful contract validation.

Why not the others:

A. Require Clients to implement HttpCalloutMock:
This only states that mocking must be used. It is a necessary but insufficient design specification because it says nothing about validating adherence to the RAML contract itself. Any mock implementation, including one returning arbitrary or incorrect data, would satisfy this requirement, defeating the purpose of the validation.

B. Call the HttpCalloutMock implementation from the clients:
This describes basic test setup mechanics, such as using Test.setMock() to inject the mock, but it does not address the actual goal of confirming that payloads conform to RAML. Implementing and invoking a mock without RAML-based content does not prove specification adherence.

Key exam takeaway
The differentiator is what the mock returns, not simply that a mock exists or is invoked. To validate a contract, test doubles should be built from that contract.

Reference
Apex Developer Guide - Testing HTTP Callouts (HttpCalloutMock interface, Test.setMock())

Explanation:

The requirement is to update Account, Contact, and other related information in bulk while using the REST API to reduce API call consumption. The key constraint is handling related records, including parent-child relationships, efficiently in a single call.

Why SObject Tree is the correct answer:

Parent-child relationship support:
The SObject Tree resource is specifically designed to create up to 200 records with parent-child relationships in a single API request. This directly matches the scenario where Account and Contact records are related and need to be created together.

Reduces API calls:
By allowing nested records, such as an Account with its associated Contacts, to be submitted in one call, it eliminates multiple round trips that would otherwise be required to create the parent first, retrieve its ID, and then create the child records.

Meets the 200-record limit:
The SObject Tree resource supports up to 200 total records across all trees, with a maximum depth of 5 levels.

Why Other Options Are Incorrect

A. Batch:
The Composite Batch resource allows multiple independent requests to be submitted in a single call, but each subrequest counts separately against API limits. It does not provide a mechanism for handling parent-child relationships within the batch, and it does not reduce API call consumption. It primarily reduces network round trips.

C. Composite:
While the general Composite resource, such as /composite, allows you to combine multiple subrequests into a single API call, it is not optimized for bulk data operations involving related records. The SObject Tree resource is the specialized tool for hierarchical record creation within the Composite API family.

Explanation:

When securing a Salesforce integration with an external system such as a Microsoft Azure API Gateway, the recommended mechanism, especially for server-to-server or high-security scenarios, is mutual authentication, also called two-way SSL, mutual TLS, or mTLS.

In this model:

Both parties, Salesforce and the Azure API Gateway, present and validate each other’s certificates during the TLS handshake.

Certificates must be issued by a trusted Certification Authority (CA-signed). Self-signed certificates are generally not accepted for mutual authentication in Salesforce for this use case.

This provides strong authentication of both the client and the server at the transport layer, without relying solely on application-level credentials.

Salesforce supports this pattern for both inbound and outbound integrations. For outbound callouts from Salesforce to Azure, you configure a CA-signed certificate in Certificate and Key Management and present it on the callout. Azure API Management or API Gateway also supports client-certificate authentication through mutual TLS.

Why the other options are incorrect

A. Use an API-only user profile and implement an external identity provider with federated API access

This is more relevant for user-context or identity-federation scenarios, such as SSO, SAML, or federated identity. It does not provide the transport-level mutual certificate authentication typically required for securing an API Gateway integration.

B. Configure a connected app with an authorization endpoint of the API Gateway and configure OAuth settings

Connected Apps and OAuth are excellent for delegated authorization and user-context or client-credentials flows. However, the question focuses on securing the integration with an external API Gateway, where mutual TLS provides strong transport-level authentication, particularly when the gateway expects or supports client certificates.

Key Exam Point
For high-security Salesforce server-to-server integrations where both systems must authenticate each other at the TLS layer, mutual TLS (mTLS) using CA-signed certificates is the relevant security mechanism.

Explanation:

Northern Trail Outfitters is distributing a Salesforce managed package that needs to call a Custom Apex REST endpoint in the central org. The security team requires that a specific integration account be used, which they will authorize after installation.

Authentication Provider + Connected App

The package can include an authentication provider configuration.

The consumer key and consumer secret of the connected app in the central org are used to establish secure OAuth flows.

This ensures that the integration account in the central org is explicitly authorized by the security team.

This approach provides a scalable and secure way to handle authentication across distributed packages.

Why not the other options?

A. Contact Salesforce Support to enable API access for managed packages

Incorrect. API access is already supported for managed packages. No special support case is required for this purpose.

B. Use an encrypted field to store the password

Incorrect. Storing passwords in encrypted fields is insecure and does not align with Salesforce best practices. OAuth and connected apps provide the recommended approach for secure authentication.

Key Exam Point

For a managed package that needs to securely authenticate to a central Salesforce org, an Authentication Provider combined with a Connected App can provide an OAuth-based authentication mechanism while allowing the central security team to authorize the required integration account.

Reference
Salesforce Documentation: Connected Apps and OAuth
Salesforce Documentation: Authentication Providers

Explanation:

A. Salesforce B2C Commerce to Service Cloud Connector — Correct
The requirement is specifically for Service Cloud agents to see B2C Commerce order history while working with customer cases. The Salesforce B2C Commerce to Service Cloud integration/connector is designed for this type of commerce-to-service integration.

The connector provides a prebuilt integration between B2C Commerce and Service Cloud, avoiding the need to develop and maintain a custom integration. Salesforce's commerce documentation describes the service experience as allowing agents to access customer and order information while handling service interactions.

The key architectural clue is that the requirement is a standard B2C Commerce and Service Cloud use case, so a Salesforce-provided connector should be preferred over developing a custom API integration or introducing a general-purpose integration platform.

Why the other options are incorrect

B. REST API offered by Commerce Platforms — Incorrect

A REST API could technically be used to retrieve B2C Commerce order information, but it would require a custom integration to retrieve, transform, and expose the order history to Service Cloud agents.

When Salesforce provides a purpose-built connector for the required Salesforce Commerce and Service integration, using the standard connector avoids unnecessary custom development and maintenance.

C. MuleSoft Anypoint Platform — Incorrect

MuleSoft Anypoint Platform is a powerful choice when an organization needs a broader integration layer, orchestration, transformation, API management, or connectivity across many systems.

However, this requirement is narrowly defined: Service Cloud agents need B2C Commerce order history. Introducing a general-purpose integration platform would add unnecessary architectural complexity when a purpose-built Salesforce integration is available.

Exam Takeaway
For Salesforce Integration Architect questions, watch for this pattern:
Standard Salesforce product-to-product integration requirement → use the Salesforce-provided connector before building a custom API or introducing middleware.

Here, the requirement is specifically B2C Commerce → Service Cloud → service-agent order history, making Option A the expected answer.

Answer
A. Salesforce B2C Commerce to Service Cloud Connector

Explanation:

Why B is correct:
Platform Events are modeled similarly to standard and custom objects in Salesforce, with event objects ending in __e. To successfully listen to or consume, or subscribe to, a Platform Event channel using an integration user, that user's profile or permission set must be provisioned with Read access to the specific event object or entity. Similarly, publishing requires Create permission.

Why A is incorrect:
Platform Events use an event bus that temporarily stores and buffers messages, typically for up to 24 hours for high-volume events. The external system does not need identical uptime to keep up. If the external system goes offline temporarily, messages can remain available in the event bus, and the client can resume consumption and replay events from where it left off once it reconnects.

Why C is incorrect:
Salesforce handles event routing and publishing natively through the event bus. Salesforce does not need to store explicit state configurations or records tracking individual external consuming systems to know when or what to broadcast. It publishes events onto the event bus for authorized subscribers listening to the relevant channel.

Reference
Salesforce Pattern: Event-Driven Architecture / Platform Events Security & Management
Salesforce Documentation: Platform Event Permissions & Considerations