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

Configure named credentials in the source org.

Call the Salesforce REST API to insert the lead into the target system.

Explanation

Two Salesforce orgs are merging; the old org stays active briefly for web-to-lead forms. New leads must appear in the new org within 30 minutes using minimal development. The solution should leverage out-of-box or low-code tools for real-time or near real-time sync without complex custom code or middleware.

✅ Correct Option: A. Configure named credentials in the source org
Named Credentials simplify secure callouts by bundling endpoint URL + auth (e.g., OAuth).
Set once in source org → reusable in Flow/Apex/Process Builder.
Zero code for auth management — reduces dev effort and maintenance.
Essential foundation for any REST-based sync (pairs perfectly with option D or B).

✅ Correct Option: D. Call the Salesforce REST API to insert the lead into the target system
Use REST API (/services/data/vXX.X/sobjects/Lead) from a Flow or Process Builder trigger on Lead insert.
Declarative callout via Flow’s “Apex Action” or “HTTP Callout” (with Named Credential).
Inserts lead instantly (<1 min) — well under 30-min SLA.
No scheduled jobs or batch code — pure low-code automation.

❌ Incorrect Option: B. Use the Composite REST API to aggregate multiple leads
Composite API batches up to 25 records — useful for volume, but not needed here.
Requires collecting leads first (custom staging or delay) → breaks real-time flow.
Adds complexity (parsing responses, error handling per record) → more dev effort, not less.

❌ Incorrect Option: C. Use the Tooling API with Process Builder
Tooling API is for metadata ops (e.g., creating fields), not record DML.
Cannot insert Leads — completely wrong API.
Even if misused via REST, it’s unsupported, complex, and high-effort — anti-pattern.

📚 Reference
Named Credentials
Flow HTTP Callout (Beta)
Introduction to REST API

The platform events are published after the Apex transaction completes.

Explanation:

Platform Events follow transactional boundaries, meaning:

Events are published only after the Apex transaction successfully completes (including all DML operations).
If the transaction fails (due to an exception or validation rule), no events are published.
This ensures data consistency between Salesforce and external systems.

Why Not the Other Options?

A) Incorrect – Platform Events are not published before the transaction completes.

C) Incorrect – While triggers can publish Platform Events, the question is about when they are published, not how.

D) Incorrect – The question is about when events are published, not where they originate (Apex, Flow, etc.).

Key Concept:

Event-Driven Architecture (EDA) relies on asynchronous event publishing after transaction success.

Order of Execution:
1. Apex transaction executes (DML, triggers, etc.).
2. If successful, Platform Events are published.
3. Subscribers (external systems, flows, triggers) consume the events.

Reference:

Salesforce Platform Events Documentation
Key Quote: "Platform events are published after the transaction completes successfully."

Leverage Middleware for all back office system integrations ensuring real time alerting, monitoring and reporting capabilities.

Explanation

For a large, regulated enterprise with critical business processes, the integration architecture must be robust, scalable, and centrally managed. The solution needs to handle integrations with multiple back-office systems reliably, provide a single pane of glass for monitoring, and offer built-in capabilities for error handling, alerting, and reporting without imposing a significant custom development burden on each system.

✅ Correct Option

D. Leverage Middleware for all back office system integrations ensuring real time alerting, monitoring and reporting capabilities.
A dedicated middleware platform (like MuleSoft) is the optimal choice. It is specifically designed for this scenario, providing a centralized enterprise service bus to decouple Salesforce from multiple back-end systems. These platforms offer out-of-the-box features for reliability, monitoring, alerting, and transaction reporting, which is crucial for a regulated industry. This avoids the cost and complexity of building and maintaining these capabilities from scratch.

❌ Incorrect Options

A. Architect Services in back office systems to support callouts from Salesforce and build reliability, monitoring and reporting capabilities.
This approach is highly fragmented and inefficient. Building reliability and monitoring individually into each back-office service creates inconsistency, increases development and maintenance costs, and fails to provide a unified view of integration health, which is critical for support associates.

B. Decouple back office system callouts into separate distinct services that have inbuilt error logging and monitoring frameworks.
While decoupling is a good practice, this option still suggests building custom frameworks for each service. This leads to the same drawbacks as option A: lack of standardization, high total cost of ownership, and no centralized monitoring hub, making it unsuitable for an enterprise with multiple critical integrations.

C. Build a custom integration gateway to support back office system integrations and ensure reliability and monitoring capabilities.
Building a custom gateway is a "re-inventing the wheel" approach. It requires massive initial development effort and ongoing maintenance to achieve what enterprise middleware platforms already provide as standardized, proven, and supported features. This introduces unnecessary risk and cost for the business.

📚 Reference
The recommended approach aligns with the Enterprise Service Bus (ESB) pattern and the capabilities of integration platforms like MuleSoft, which is part of the Salesforce ecosystem. For official guidance, refer to the Salesforce Integration Patterns & Practices documentation on the Salesforce Developer site, which advocates for using a middleware layer to simplify connectivity and centralize management for complex, multi-system enterprise landscapes.

Require the Apex REST API Clients to implement the HttpCalloutMock.

Implement HttpCalloutMock to return responses per RAML specification.

Explanation:

Northern Trail Outfitters aims to ensure that Apex REST API clients adhere to RAML specifications, which define the structure and content of API request and response payloads. To confirm this adherence during unit testing, the integration architecture must include mechanisms to simulate API interactions and validate responses against the RAML contract. Let’s analyze the options:

A. Call the Apex REST API Clients in a test context to get the mock response.

This option is incorrect because simply calling the Apex REST API clients in a test context to retrieve a mock response does not inherently ensure adherence to RAML specifications. Without a specific mechanism to validate the response structure against RAML, this approach lacks the rigor needed to confirm compliance with the field-level definitions in the RAML contract.

B. Require the Apex REST API Clients to implement the HttpCalloutMock.

This is correct. The HttpCalloutMock interface in Salesforce allows developers to simulate external HTTP callouts during unit testing, which is essential for testing Apex REST API clients without making actual external calls. By requiring clients to implement HttpCalloutMock, the architecture ensures that tests can control and validate the mock responses, enabling verification that the client handles requests and responses as per the RAML specifications. This setup supports repeatable, isolated tests that align with the API contract.

C. Call the HttpCalloutMock implementation from the Apex REST API Clients.

This option is incorrect because Apex REST API clients do not directly call the HttpCalloutMock implementation. Instead, the Salesforce testing framework uses the Test.setMock() method to associate the HttpCalloutMock implementation with HTTP callouts made by the client during tests. The client code itself remains unaware of the mock implementation, making this option technically inaccurate.

D. Implement HttpCalloutMock to return responses per RAML specification.

This is correct. Implementing the HttpCalloutMock interface to return mock responses that conform to the RAML specifications ensures that unit tests validate the Apex REST API client’s behavior against the expected request and response payloads. By crafting mock responses that mirror the RAML-defined structure (e.g., specific fields, data types, and formats), the integration architect can confirm that the client correctly processes API responses as per the contract, catching any deviations during testing.

Why B and D?

B ensures the architecture mandates the use of HttpCalloutMock for testing, which is a Salesforce best practice for mocking external API calls.

D complements this by specifying that the mock implementation must align with RAML specifications, ensuring the client’s handling of requests/responses is tested against the API contract.

References:

Salesforce Developer Documentation: Testing HTTP Callouts – Explains the use of HttpCalloutMock for simulating HTTP callouts in unit tests.

Salesforce Trailhead: Test Apex Callouts – Covers best practices for mocking and testing REST API integrations.

RAML Official Documentation: RAML Specification – Details how RAML defines API contracts, including field-level request/response specifications, which can be used to structure mock responses.

SAML SSO and just-in-time provisioning

OpenId Connect Authentication Provider and just-in-time provisioning

Explanation:

The scenario involves a subscription-based media company implementing an Identity and Access Management (IAM) system that supports SAML and OpenID Connect to enable self-registration and Single Sign-On (SSO) for subscribers, integrating with Salesforce Community Cloud. The goal is to provide seamless access to new self-service customers. Salesforce Community Cloud (now called Experience Cloud) must support both self-registration and SSO while integrating with the IAM system. Let’s analyze the options:

A. SAML SSO and Registration Handler

This option is partially correct but not the best fit. SAML SSO is supported by Salesforce Community Cloud, allowing users to authenticate via the IAM system without re-entering credentials. However, a Registration Handler (a custom Apex class) is typically used for custom self-registration logic when users first sign up. While it can work with SAML, it’s not the most direct approach for enabling instant access for new users, as it requires custom development to map IAM attributes to Salesforce user records. Just-in-time (JIT) provisioning, which automatically creates or updates user records during SSO, is a more efficient standard approach.

B. OpenId Connect Authentication Provider and Registration Handler

This option is also partially correct but less optimal. Salesforce supports OpenID Connect as an Authentication Provider for SSO, allowing integration with the IAM system. A Registration Handler can be used for self-registration, but as with option A, it requires custom Apex to handle user creation, which is less streamlined than JIT provisioning for instant access. This makes it a less preferred choice compared to JIT provisioning with OpenID Connect.

C. SAML SSO and just-in-time provisioning

This is correct. SAML SSO enables subscribers to log in to Salesforce Community Cloud using their IAM credentials, providing a seamless SSO experience. Just-in-time (JIT) provisioning, supported with SAML, automatically creates or updates a Salesforce user record (e.g., a Community Cloud user) during the SSO process based on attributes sent by the IAM system. This ensures new self-service customers gain instant access without manual intervention or custom registration logic, aligning perfectly with the requirement for efficient self-registration and SSO.

D. OpenId Connect Authentication Provider and just-in-time provisioning

This is also correct. Salesforce supports OpenID Connect as an Authentication Provider, allowing SSO with the IAM system. Like SAML, OpenID Connect supports JIT provisioning, where user attributes from the IAM system (e.g., via ID tokens) are used to create or update Salesforce user records during login. This provides instant access for new self-service customers, meeting the requirement for self-registration and SSO in a scalable, standard way.

Why C and D?

Both SAML SSO (C) and OpenID Connect Authentication Provider (D) are supported by Salesforce Community Cloud and align with the IAM system’s capabilities (SAML and OpenID Connect). Just-in-time provisioning (in both C and D) is a standard Salesforce feature that streamlines self-registration by automatically provisioning user accounts during the SSO process, eliminating the need for custom Registration Handler logic. This is ideal for a large subscriber base requiring instant access.

Why not A and B?

While Registration Handler (in A and B) can be used for self-registration, it requires custom Apex development, which is less efficient than JIT provisioning for handling user creation/update during SSO. JIT provisioning is a declarative, out-of-the-box feature that better suits the scenario’s need for instant, scalable access.

References:

Salesforce Help: Set Up SAML for Single Sign-On – Details SAML SSO configuration and JIT provisioning in Salesforce.

Salesforce Help: OpenID Connect Authentication Providers – Explains OpenID Connect setup and JIT provisioning for SSO.

Salesforce Help: Just-in-Time Provisioning for SAML and OpenID Connect – Describes how JIT provisioning automates user creation during SSO.

Trailhead Module: Identity and Access Management – Covers SSO, self-registration, and JIT provisioning for Community Cloud.

Use continuation to process payment to the payment gateway.

Explanation

The core requirements are:
The transaction is initiated by a student (Community user) and must feel synchronous (i.e., the student must wait for the result).
The processing time is more than 30 seconds.
The student needs the result in real-time to retry the payment if an error occurs.
Salesforce Apex has a standard synchronous callout timeout limit of 10 seconds. Since the payment gateway takes over 30 seconds, a standard synchronous callout will fail with a timeout exception.
Continuation is the specific Salesforce framework designed to handle long-running external web service requests that are initiated from a Visualforce Page or a Lightning Component (LWC), which is typically used in a Community.

The Continuation pattern splits the single transaction into two parts:
The Apex method calls the external service and immediately returns a Continuation object, releasing the user's thread so the transaction doesn't time out.
The external service processes the payment (taking >30 seconds).
When the response is received, a callback method is automatically executed to process the result and update the student's Community page with the real-time success or error status, allowing for a retry.
This approach preserves the synchronous user experience (the user waits on the page) while bypassing the strict 10-second synchronous governor limit.

❌ Why other options are incorrect:

A. Use platform event to process payment...:
Platform Events (a Publish/Subscribe pattern) are purely asynchronous. They would initiate the payment, but the student's screen would immediately refresh without a result. The student would need to wait for a separate mechanism (like a push topic or polling) to get the result, which fails the requirement for a real-time, immediate result allowing for a retry.

C. Use change data capture (CDC) to process payment...:
CDC is an asynchronous pattern used to notify external systems when a record in Salesforce is changed. It is the wrong tool for initiating a payment request from a Community user and expecting a real-time response.

D. Use request and reply to make an API call...:
This is the integration pattern (Remote Process Invocation—Request and Reply), but it doesn't specify the technical solution to overcome the 30-second timeout. A standard Apex API call would be a synchronous Request and Reply, which would fail due to the 10-second limit. The Continuation framework (Option B) is the specific technical implementation of the Request and Reply pattern for long-running transactions.

🌐 Reference
Salesforce Documentation: Make Long-Running Callouts with Continuations
Maximum Synchronous Timeout: Standard synchronous callouts timeout after 10 seconds.
Continuation Purpose: Continuations are designed to enable an Apex application to make long-running requests (up to 120 seconds) to an external Web service and integrate the results into the user interface (Lightning Components/Community) without exceeding the cumulative transaction timeout.

Tooling API

Explanation:

The Tooling API is specifically designed for interacting with Salesforce development and testing environments, making it the best choice for retrieving code coverage and test results.

Why Tooling API?

Provides access to Apex test execution results, including code coverage metrics.
Can query objects like ApexTestResult, ApexCodeCoverage, and ApexTestQueueItem.
Ideal for CI/CD integrations and custom monitoring tools (like the Java app in question).

Why Not the Other Options?

A) SOAP API – General-purpose but not optimized for accessing test results and coverage data.
B) Analytics REST API – Used for Einstein Analytics, not Apex testing metrics.
C) Metadata API – Used for deploying and retrieving metadata, not runtime test data.

Key Reference:
Salesforce Tooling API Documentation

Relevant Objects:
ApexTestResult – Test execution status.
ApexCodeCoverage – Code coverage percentages.
ApexTestQueueItem – Queued test runs.

Implementation Example (Tooling API Query for Test Results):

SELECT Id, Outcome, MethodName FROM ApexTestResult WHERE AsyncApexJobId = 'JobId'

SELECT NumLinesCovered, NumLinesUncovered FROM ApexCodeCoverage WHERE ApexClassOrTriggerId = 'ClassId'

This makes the Tooling API the clear choice for integrating test coverage reporting into a custom Java application.

Store unique identifiers in an External ID field in Salesforce and use this to update the proper records across systems.

Use Change Data Capture to update downstream systems accordingly when a record changes.

Explanation:

Universal Containers needs bidirectional synchronization between Salesforce (the system of record for Leads, Contacts, Accounts, Cases) and external systems (ERP, ticketing system, data lake), each with unique identifiers, using middleware.

B. Store unique identifiers in an External ID field in Salesforce and use this to update the proper records across systems.

Salesforce External ID fields store unique identifiers from external systems, allowing middleware to map and update records accurately in both directions (Salesforce ↔ external systems).

C. Use Change Data Capture to update downstream systems accordingly when a record changes.

Salesforce Change Data Capture (CDC) streams real-time record changes (create/update/delete) to middleware, which can propagate updates to external systems, ensuring near-real-time synchronization from Salesforce.

A is incorrect due to the complexity and risk of caching IDs in middleware. D is overkill, as an MDM solution is unnecessary when Salesforce is the system of record.

References:

Salesforce Help: External ID Fields
Salesforce Help: Change Data Capture

ConnectedApp configured in Salesforce to authenticate the middleware.

Explanation

In this scenario, the business wants to automate the classification of phone numbers (mobile vs. landline) for incoming calls, using an external service API. The system handles high daily volumes but is flexible with timing, meaning it’s not a real-time requirement — so patterns like Remote Call-In and Batch Synchronization are appropriate.
Because the middleware is on-premises, the main concern is secure communication between Salesforce (cloud) and the on-premises middleware (ETL/ESB) that connects to internal systems.
The most suitable approach is to use an API Gateway that sits in front of the middleware to handle authentication, traffic control, and security for inbound Salesforce requests.

✅ Correct Answer
✅ C. An API Gateway that authenticates requests from Salesforce into the Middleware (ETL/ESB)

An API Gateway acts as a secure intermediary between Salesforce and the internal middleware or ETL layer.
It manages:
Authentication of Salesforce requests (e.g., via OAuth or mutual SSL).
Traffic throttling and scaling, which is crucial for large volumes (up to 100,000 calls/day).
Request routing and monitoring, improving system resilience.
The API Gateway helps securely expose internal APIs to Salesforce without directly opening your internal network, aligning perfectly with the Remote Call-In and Batch Synchronization integration patterns.

Key Benefits:
Centralized authentication and authorization
Protects internal services from direct exposure
Scalable and fault-tolerant design for large call volumes
Enables audit logging and monitoring of API traffic

❌ Incorrect Options
A. Connected App configured in Salesforce to authenticate the middleware

Reason:
Connected Apps manage inbound integrations—they are used when external systems access Salesforce (e.g., calling Salesforce APIs). Here, Salesforce is calling into the middleware, not the other way around, so Connected App isn’t relevant.

B. Remote Site Settings in Salesforce to authenticate the middleware

Reason:
Remote Site Settings only whitelist outbound callout URLs from Salesforce; they do not handle authentication or security policy enforcement. While they may be required for callouts, they don’t fulfill the authentication or protection role of an API Gateway.

D. Firewall and reverse proxy are required to protect internal APIs and resources being exposed

Reason:
While firewalls and reverse proxies are indeed part of the overall network security setup, they are not Salesforce integration components. They control network access but do not handle API-level authentication, traffic routing, or transformation—functions an API Gateway provides.

Reference:
Salesforce Integration Patterns and Practices: Integration Patterns
Salesforce Architects Guide “Use an API Gateway to securely expose internal services to Salesforce via controlled and authenticated endpoints.”

Summary:
To implement secure and scalable integration between Salesforce and an on-premises middleware (for Remote Call-In and Batch Synchronization),
➡ Use an API Gateway (Option C) to authenticate and manage Salesforce requests into the middleware.

The maximum callouts in a single Apex transaction

📝 Explanation

When making callouts from Apex code to an external system, one of the most immediate and critical governor limits to consider is the limit on the number of callouts per Apex transaction.

Governor Limit:
Salesforce enforces a limit on the number of external calls (HTTP requests or web service calls) that can be made in a single Apex transaction. This limit is typically 100 callouts. If the external processing of an insurance quote requires making multiple, distinct HTTP requests, the architect must ensure that the total number of callouts does not exceed this limit within the scope of the Apex transaction (e.g., within a single trigger, batch execution, or execute method).

Impact:
Exceeding this limit results in a System.LimitException and the transaction is rolled back, preventing the quote process from completing.

❌ Why other options are less relevant:

B. The maximum number of parallel Apex callouts in a single continuation:
This option is specific to Continuation (an asynchronous pattern for long-running UI transactions), not general synchronous or simple asynchronous Apex callouts. It's a relevant detail if a Continuation pattern is used, but the primary concern for a generic Apex callout recommendation is the overall limit per transaction.

C. The limit on long-running requests (total execution time):
The total execution time (10 seconds for synchronous, 60 seconds for asynchronous) is a crucial limit, but it's a general governor limit for all Apex code execution. The callout limit (A) is the governor limit specific to external integration that is directly relevant to the decision to use Apex callouts for external processing.

D. The limit of pending operations in the same transaction:
This is too vague. Governor limits cover various resources (SOQL queries, DML statements, CPU time, etc.), but there is no specific limit called "pending operations." This phrasing does not point to a specific, critical integration-related limit like the number of callouts.

🌐 Reference
The primary reference for this is the Salesforce documentation on Apex Governor Limits.
Salesforce Documentation: Apex Governor Limits
Maximum number of callouts (HTTP requests or Web services calls) in a transaction: 100