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

Make an API inbound integration from an external Java client more secure.

Explanation

The question asks which use case can leverage an existing SAML integration (using a third-party Identity Provider) to connect Salesforce with internal systems.
The key context here is how the existing SAML setup can be reused for API authentication for a server-to-server or client-to-server integration:

SAML Assertion Flow for Inbound API Access:
Salesforce supports the SAML Assertion Flow (a variation of an OAuth flow) for inbound API integrations. In this scenario, the external system (the "external Java client") gets a SAML Assertion from the organization's central Identity Provider (the existing one). The Java client then sends this SAML Assertion to Salesforce's token endpoint to exchange it for an OAuth Access Token, which it then uses to call Salesforce APIs.

Leveraging Existing IDP:
This flow allows the external client to reuse the organization's existing SAML Identity Provider as the method of authentication to Salesforce, satisfying the requirement to leverage the existing infrastructure.

❌ Why the Other Options are Incorrect

A. Make formula fields with HYPERLINK() to external web servers more secure.
This typically involves Outbound SSO or linking to an external resource. While SAML can be used for Outbound SSO (where Salesforce acts as the Identity Provider), the question specifies the organization already has a third-party Identity Provider. For a simple HYPERLINK(), the primary need is to pass the authenticated user context to the external system, which is not what the SAML Assertion flow for API authentication is designed for.

B. Make Apex SOAP outbound integrations to external web services more secure.

C. Make Apex REST outbound integrations to external web services more secure.

These are Outbound integrations, where Salesforce calls an external system. For Apex callouts, the standard secure practice is using Named Credentials. Named Credentials simplify the callout process and often rely on protocols like OAuth 2.0 (e.g., JWT Bearer) or mTLS for authentication to the external endpoint. It is rare and unnecessarily complex to use a SAML Assertion from an external IDP for a Salesforce outbound callout, as Salesforce typically acts as the client, not the Service Provider validating a SAML assertion.

📚 Reference
Salesforce Integration Pattern: SAML Assertion Flow for API Access.
Concept: This flow allows a client application (the external Java client) that has already been authenticated by an external Identity Provider (the existing SAML IdP) to use the SAML assertion to securely gain access to the Salesforce API.
Source: Salesforce Help documentation on OAuth 2.0 flows, specifically the SAML Assertion Flow.

Develop custom APIs on the company's network that are invokable by Salesforce.

Deploy MuleSoft to the on-premise network and design externally facing APIs to expose the data.

Explanation

The core requirement is to expose data from on-premise applications to Salesforce in real-time. The on-premise systems are protected, so the solution must facilitate secure, external access without compromising the corporate network.

Let's evaluate why the correct answers work and why the others do not:

B. Develop custom APIs on the company's network that are invokable by Salesforce.
This is a foundational and correct approach. It involves creating custom REST or SOAP API endpoints within the corporate firewall that expose the specific data needed from the on-premise applications. Salesforce can then call these APIs directly (using Apex or a low-code tool) to retrieve data in real-time. This provides maximum control and is a direct implementation of the required integration pattern.

C. Deploy MuleSoft to the on-premise network and design externally facing APIs to expose the data.
This is also correct and is a more robust, enterprise-grade version of option B. MuleSoft, an integration platform owned by Salesforce, acts as an API-led connectivity layer. Deploying it on-premise allows it to connect securely to the backend systems. You then design and publish managed, well-documented APIs that Salesforce can call. This approach provides benefits like built-in security, transformation, orchestration, and reusability that pure custom code (option B) might lack.

Why the other options are incorrect:

A. Develop an application in Heroku that connects to the on-premise database via an ODBC string and VPC connection.
This is incorrect and architecturally risky. Directly connecting an external application to the production database via ODBC bypasses the application logic and data layer, which is a major security anti-pattern. It can lead to data corruption, performance issues, and schema lock-in. The correct approach is to integrate through APIs provided by the application, not directly with its database.

D. Run a batch job with an ETL tool from an on-premise server to move data to Salesforce.
This is incorrect because it violates the core requirement of real-time access. ETL (Extract, Transform, Load) jobs are batch-oriented; they run on a schedule (e.g., every hour or night). This would result in stale data within Salesforce, which does not fulfill the requirement for a "unified user experience" with current information.

Key Concept
The key concept tested here is the selection of the Real-Time Integration Pattern, specifically the API-led Connectivity approach for accessing data from secured, on-premise systems.
An Integration Architect must recognize that real-time access requires a synchronous, request-response mechanism. The solution must create a secure gateway (the API) that exposes the on-premise data without directly exposing the database itself, adhering to principles of loose coupling and security.

Reference
This aligns with the standard integration patterns documented by Salesforce and MuleSoft. The official Salesforce Integration Architecture documentation advocates for the "Virtual Data Integration" or "Direct Data Access" pattern for real-time scenarios to avoid data duplication and latency. Using MuleSoft as an integration layer is a canonical example of the API-led connectivity model, which is the recommended approach for creating a structured, reusable, and secure integration framework.

Users should be authorized to view information specific to the customer they are servicing without a need to search for customer.

Consider Enterprise security needs for access to DMS and EBS.

Users should be authenticated into DMS and EBS without having to enter username and password.

Explanation

This scenario focuses on providing seamless and secure contextual access to external systems (EBS for billing data and DMS for documents) for Customer Support agents who are already logged into Salesforce.

E. Users should be authenticated into DMS and EBS without having to enter username and password. (Single Sign-On - SSO)

Need:
The goal is a seamless experience. Agents shouldn't have to log in multiple times.
Solution:
The integration must employ a Single Sign-On (SSO) mechanism (like OAuth 2.0 with JWT Bearer or SAML) to delegate the Salesforce session to the external systems (DMS/EBS) or the intermediary integration layer. This eliminates the need for separate credentials for the external systems, improving agent efficiency and user experience.

A. Users should be authorized to view information specific to the customer they are servicing without a need to search for customer. (Contextual Authorization)

Need:
The data displayed must be specific to the customer the agent is currently viewing in Salesforce.
Solution:
The integration call must transmit the contextual data (e.g., the Customer ID from the Salesforce record) to the EBS/DMS. The external system or an integration layer must then authorize the request, ensuring the user (via the SSO token) has permission to see only the requested customer's data and not other customer data. This ensures row-level security for the external data.

C. Consider Enterprise security needs for access to DMS and EBS. (Security Compliance)

Need:
The prompt states "Only authorized users are allowed access to the EBS and the Enterprise DMS," and these are core enterprise systems.
Solution:
The integration design must adhere to the organization's governance, audit, and security policies (e.g., encryption of data in transit/at rest, logging, monitoring, and compliance with internal security standards). Ignoring overall enterprise security standards for convenience is an architectural anti-pattern.

❌ Why the Other Options are Incorrect

B. Identify options to maintain DMS and EBS authentication and authorization details in Salesforce.

Anti-Pattern:
Storing external system usernames and passwords directly in Salesforce is a security vulnerability and violates the principle of Single Sign-On. While Salesforce's Named Credentials securely store authentication details (like OAuth tokens or a service principal's password), the option phrasing suggests storing per-user credentials, which is what SSO is designed to avoid. The focus should be on secure delegation, not maintenance of redundant credentials.

D. Consider options to migrate DMS and EBS into Salesforce.

Scope Mismatch:
The task is to design an integration solution. Migrating entire enterprise systems (Billing and Document Management) is a massive, long-term project and is out of scope for an integration consultant focused on accessing the current systems. Integration patterns (like Data Virtualization via Salesforce Connect or Remote Process Invocation via API callouts) are used precisely to avoid unnecessary data migration.

Key Concepts:

Single Sign-On (SSO): User experience and security via delegated authentication (Option E).
Contextual Integration: Passing relevant record data (like Customer ID) to authorize and retrieve specific information (Option A).
Enterprise Security and Governance: Adherence to corporate security policies for sensitive systems (Option C).
Salesforce Tools for this Pattern: Named Credentials (for securely managing the connection endpoint and authentication) combined with Per-User Authentication (to ensure the call uses the individual agent's authorization) is the recommended implementation pattern for achieving Options A and E.

Insert and query using Bulk API 2.0.

Explanation

The scenario presents an extreme data volume challenge: loading 90 million records and then extracting 30 million records, all within a single day. The key to solving this is selecting an API designed for maximum throughput and asynchronous processing of massive datasets.

Let's evaluate why Bulk API 2.0 is the correct choice for both operations and why the other options are unsuitable:

Inserting 90 Million Records:
The Bulk API 2.0 is specifically engineered for this exact purpose. It processes large data sets asynchronously in the background, dividing the work into manageable batches that are processed in parallel. This prevents timeouts and efficiently handles the immense volume, which would be impossible for the synchronous REST API.

Querying 30 Million Records:
For data extraction of this magnitude, the Bulk API is again the only viable tool. The standard REST API has a hard limit of returning a maximum of 2,000 records in a single query response. While you can use pagination, it is not designed or efficient for extracting millions of records. The Bulk Query capability of Bulk API 2.0 allows you to execute a large query and receive the results (all 30 million records) as a set of downloadable files, which is precisely what the external auditing system requires.

Why the other options are incorrect:

A. Insert using Bulk API 2.0 and query using REST API:
This is incorrect because using the REST API to query 30 million records is not feasible due to its 2,000-record retrieval limit per call, making the process incredibly slow and complex.

B. Insert and query using Bulk API 1.0:
While Bulk API 1.0 is designed for high volume, it is a legacy API. Salesforce recommends using Bulk API 2.0 for all new development because it is more efficient and simpler to use, as it automatically manages batch sizing and job handling.

C. Insert using Bulk API 1.0 and query using REST API:
This is the least effective option. It combines the legacy version of the Bulk API for insertion with the entirely wrong tool (REST API) for the massive query operation.

Key Concept

The key concept tested here is the strategic selection of APIs based on data volume and processing.

An Integration Architect must understand the fundamental distinction between:

Synchronous APIs (like REST API): Best for real-time, interactive operations involving a few hundred or thousand records.
Asynchronous Bulk APIs (like Bulk API 2.0): Essential for non-real-time, high-throughput data loading and extraction jobs involving millions of records.
Choosing the wrong API pattern for the volume will lead to guaranteed failure, hitting governor limits and being unable to complete the job within the required timeframe.

Reference
This recommendation is based on the official Salesforce API documentation. The Bulk API Developer Guide explicitly states that Bulk API 2.0 "is optimized for loading or deleting large sets of data" and can be used to "query large sets of data." It is the designated tool for scenarios where the data volume is measured in millions of records, ensuring the job can be completed within a day.

Both Platform Events and Outbound Message offer declarative means for asynchronous near-real time needs. They aren't best suited for realtime integrations.

Number of concurrent subscribers to Platform Events is capped at 2,000. An Outbound Message configuration can pass only 100 notifications in a single messages to a SOAP end point.

Both Platform Events and Outbound Message are highly scalable. However, unlike Outbound Message, only Platform Events have Event Delivery and Event Publishing limits to be considered.

Explanation:

The customer wants to compare Platform Events vs Outbound Messages for real-time / near-real-time integration, and expects 3,000 subscribers. Key decision factors include scalability, reliability guarantees, delivery behavior, and platform limits.

Let’s evaluate each option:

✅ Correct Options

A. Both Platform Events and Outbound Message offer declarative means for asynchronous near-real time needs.
They aren't best suited for realtime integrations.
Correct: both are asynchronous, near-real-time solutions
Not recommended when strict sub-second response requirements exist
Both work well for event-driven notifications

D. Number of concurrent subscribers to Platform Events is capped at 2,000.
An Outbound Message configuration can pass only 100 notifications in a single messages to a SOAP end point.
Platform Events have enforced delivery & subscriber concurrency limits
Outbound Message batching = max 100 notifications per SOAP call
With 3,000 consumers, PE scalability limits become important

E. Both Platform Events and Outbound Message are highly scalable.
However, unlike Outbound Message, only Platform Events have Event Delivery and Event Publishing limits to be considered.
Platform Events require evaluating publish, delivery, and retention limits
OM does not have publishing limits but is limited to SOAP and endpoint reliability
PE provides more flexibility and modern architecture, but with quotas

❌ Incorrect Options

B. Incorrect — Salesforce does not guarantee once-only delivery or sequencing for either solution
Outbound Messages can be retried and may produce duplicates
Platform Events are at-least-once delivery, also possible duplicates

C. Incorrect — message ordering is not guaranteed for Outbound Messages or Platform Events
“Very high reliability” and fully Salesforce-handled fault recovery is not accurate

✅ Final Answer:
A, D, and E

Reference:
Salesforce Platform Events Limits & Considerations
Considerations for Defining and Publishing Platform Events
Outbound Messaging Limits
About SOAP API

User Interface API

Explanation

The core requirement is to create a native mobile app that has the look and feel of Salesforce's Lightning Experience. The User Interface (UI) API is specifically designed for this purpose.

UI Data and Metadata in One Call:
Unlike the standard REST API (which requires multiple calls to get record data, object metadata, layouts, and picklist values separately), the UI API returns all the data and metadata needed to render a Salesforce screen (like a Record Page or List View) in a single, efficient response.

Respects Lightning Experience:
The UI API automatically adheres to the Lightning Page Layouts, Field-Level Security (FLS), and Sharing Rules configured by the Salesforce administrator. This ensures that the native mobile app mirrors the experience of the Salesforce web/mobile app without the developer needing to replicate complex logic.

Efficiency for UI:
It is optimized for building user interfaces by fetching only the fields necessary based on the assigned page layouts and compact layouts, making it the most efficient choice for a front-end application like a native mobile app.

❌ Why the Other Options are Incorrect

A. Streaming API:
Used for real-time, event-driven communication (e.g., subscribing to Platform Events or Change Data Capture). It is not used for traditional CRUD (Create, Read, Update, Delete) or UI rendering.

B. REST API:
The standard REST API is used for general data access (CRUD, queries, etc.) but requires the developer to make multiple calls and manually handle layout, FLS, and dynamic picklist logic. It is less efficient and more work to replicate the Lightning UI experience.

C. Connect REST API:
Used for specialized functionality like Chatter feeds, files, notifications, and Experience Cloud (Community) data. While mobile apps use it for Chatter, the User Interface API is the primary choice for building the core record-and-list-view UI that mirrors Lightning Experience.

Configure Identity Type for OData connection.

Configure a Certificate for OData connection.

Configure CSRF Protection for OData connection.

Explanation

Salesforce Connect with OData allows external data to appear as External Objects. To secure outbound requests from Salesforce, the Integration Architect must configure authentication, encryption, and anti-forgery protections within Salesforce.

A. Configure Identity Type for OData connection
Correct

Defines how Salesforce authenticates to the OData service.
Options:
Per User (user-specific tokens)
Named Principal (integration user)
Required for secure, traceable access.


B. Configure a Certificate for OData connection
Correct

Enables mutual TLS (mTLS) — Salesforce presents a client certificate.
Ensures server trusts only authorized Salesforce instances.
Critical for high-security external systems.

D. Configure CSRF Protection for OData connection
Correct

Prevents cross-site request forgery in Canvas apps or Lightning components using the OData source.
Salesforce generates and validates CSRF tokens on callouts.
Must be enabled in the OData connection settings.

Why C and E are incorrect

C. Configure Special Compatibility for OData connection
→ Does not exist — distractor. No such setting in Salesforce Connect.
E. Configure CSRF Protection on External Data Source
→ Wrong scope. CSRF protection for Salesforce-initiated requests is configured in Salesforce, not the external system.
The external OData service may have its own CSRF, but that’s not managed via Salesforce Connect.

References
Salesforce Help:
Secure Salesforce Connect OData Adapters
Salesforce Connect Guide:
OData 2.0/4.0 — Identity Type, Certificate, CSRF settings Trailhead: Salesforce Connect Security

Exam Tip:
For Salesforce Connect (OData) security:
A (Auth) + B (mTLS) + D (CSRF in Salesforce) = Secure outbound access.

Use Salesforce external object and OData connector.

Explanation

This scenario presents a classic case for data virtualization rather than data replication. The requirements for real-time creation and viewing of up-to-date order information, combined with the constraints of minimal code and developer resources, make External Objects the most suitable solution.

Let's analyze why this is the correct choice and why the others are not:

A. Use Salesforce external object and OData connector. This is the correct approach. This solution allows you to:

View Real-Time Data (Requirement 3):
Sales reps can see order history and current order status directly in Salesforce as if the data were stored locally, but it's actually fetched in real-time from the external order system via the ESB.

Create Orders in Real-Time (Requirement 1):
By using an OData service exposed by the ESB, you can create an "External Data Source" in Salesforce. You can then define the order and line item tables as External Objects. Using the standard UI or quick actions, sales reps can create new orders, which will be sent in real-time to the external system via the OData connector.

Minimal Customization (Requirement 2):
This approach is largely declarative. It uses the standard Salesforce OData connector and point-and-click setup to define external objects, requiring little to no Apex code.

Run Reports (Requirement 4):
External Objects can be used in Salesforce Reports, allowing managers to run reports on daily/monthly order volumes and fulfillment timelines. The data is queried live from the external system.

Why the other options are incorrect:


B. Use Salesforce custom object, custom REST API and ETL.
This is incorrect. While a custom REST API on the ESB is a good practice, using ETL (Extract, Transform, Load) is a batch process, which violates the real-time requirement for both creating orders (Req 1) and viewing the most up-to-date status (Req 3). Storing the data in custom objects also means it can become stale, and it duplicates data, increasing storage costs.

C. Use Salesforce standard object, REST API and ETL.
This is incorrect for the same reasons as option B. Using standard objects like Opportunity or a custom standard object doesn't change the core problem: ETL is for batch synchronization�, not real-time interaction. It does not meet the real-time requirements.

D. Use Salesforce big object, SOAP API and Dataloader.
This is incorrect. Big Objects are designed for archiving and analyzing massive volumes of historical data (billions of records). They are not suitable for active, transactional processes like creating and viewing current orders. Using Data Loader is a manual, batch-oriented tool, which completely fails the real-time requirement.

Key Concept
The key concept here is Data Virtualization vs. Data Replication.
Data Replication (Options B, C, D):
This involves copying data from the external system and storing it within Salesforce. This leads to data duplication, potential staleness, and the overhead of managing ETL jobs to keep the data in sync.
Data Virtualization (Option A):
This leaves the data in its source system (the on-premise order management system) and provides a virtual "window" to it from within Salesforce using External Objects. This ensures data is always current, avoids data duplication, and is perfectly suited for real-time access scenarios with minimal code.

Reference
This approach is based on the official Salesforce integration pattern known as "Virtual Data Integration with External Objects." The Salesforce documentation for External Objects and the OData connector explicitly supports this use case, allowing for real-time read and write (create) operations on external data without storing it in Salesforce. This pattern is ideal when you need to access data in real-time from an external system that remains the system of record.

External gateway products in use

Explanation:

Northern Trail Outfitters wants to strengthen security and performance of outbound callouts from Salesforce to on-premise systems. When Salesforce communicates with internal servers, the integration must pass through secure network boundaries such as DMZs and firewalls.
Therefore, the most critical factor to evaluate is whether the company already uses an external integration gateway (e.g., Mulesoft, API Gateway, Reverse Proxy, VPN Tunnel, etc.), because this defines how Salesforce can securely reach the internal environment.

This directly impacts:

Secure protocol enforcement
Authentication policies
Traffic routing
Performance optimization
API management capabilities
Because of this, the primary architectural decision starts with existing network and gateway infrastructure.

✅ Correct Answer:

A. External gateway products in use

Incorrect Options

B. A Default gateway restrictions
This is too vague and not specifically relevant to Salesforce integration architecture evaluations.

C. Considerations for using Deterministic Encryption
Only relevant to encrypted data stored in Salesforce where searchability is needed — not related to outbound integration design.

D. Shield Platform Encryption Limitations
Shield protects data at rest inside Salesforce, not the secure routing and connectivity required for outbound integrations.

System types - APIs, File systems, Email

Error handling mechanisms

Data Volume and Processing volume

Explanation

When an Integration Architect chooses a pattern or mechanism, they must consider technical limitations and complexities imposed by the systems involved and the data itself.

A. System types - APIs, File systems, Email

Constraint:
The type of systems dictates the viable integration mechanisms. For example, systems that only expose file shares require a file-based pattern (like FTP/SFTP), while modern systems with APIs allow for real-time SOAP/REST integration. The architect needs a strategy to handle this heterogeneity (often by using a Middleware/Integration Platform to normalize the interfaces).

D. Error handling mechanisms

Pain-point:
A major challenge in integration is failure management. The architect must design a reliable pattern that addresses how errors are detected, logged, notified, and, most importantly, retried or compensated for. The complexity of error handling varies greatly depending on the chosen pattern (e.g., synchronous vs. asynchronous).

E. Data Volume and Processing volume

Constraint:
Volume determines the scalability and performance requirements. High volumes necessitate bulk APIs (like Salesforce Bulk API) and asynchronous patterns (like batch processing or Platform Events), as real-time synchronous integrations would quickly hit governor limits and performance bottlenecks.

❌ Why the Other Options are Incorrect

B. Reporting and usability requirements:
These are functional requirements primarily addressed by the Salesforce platform design (fields, reports, dashboards, UI/UX design) after the data is integrated, not core constraints that dictate the choice of the integration pattern itself.

C. Multi-language and multi-currency requirement:
These are data configuration requirements addressed by standard Salesforce platform features (Multi-Currency, Translation Workbench, Language settings). They are architectural considerations for the overall Salesforce design but do not directly constrain or influence the technical mechanism used for transferring data (API callout, File load, etc.).