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

Explanation

A. An API Gateway component is deployable behind a DMZ or perimeter network — Correct

The key requirement is that cloud applications must pass through a secure firewall before accessing on-premise resources.

This is primarily a network architecture and perimeter-security requirement, not simply an authentication requirement.

An API Gateway can be positioned in a DMZ/perimeter network, creating a controlled boundary between cloud-facing integrations and the internal on-premise network:

Cloud Applications → API Gateway in DMZ → Firewall → On-Premise Resources

This allows NTO to expose only the required integration endpoints while keeping internal resources behind the corporate firewall.

Salesforce architecture guidance emphasizes that remote/on-premise systems should be protected with appropriate firewall mechanisms and discusses gateways/reverse proxies as security components for controlling traffic between cloud and on-premise environments.

Why the other options are incorrect

B. Middleware can interface directly with databases via an ODBC connection string — Incorrect

Direct database connectivity may be a useful technical capability, but it does not address the stated security requirement.

The question specifically says that all cloud applications must pass through a secure firewall before accessing on-premise resources. Direct database connectivity does not inherently provide the required network boundary or DMZ architecture.

Therefore, database/ODBC support is not the primary consideration for this requirement.

C. Middleware enforces OAuth — Incorrect

OAuth is important for authentication/authorization, particularly for API-based integrations. Salesforce architecture guidance recommends OAuth 2.0 for authorization when integrating with external systems.

However, OAuth does not determine where the middleware is deployed in relation to the firewall.

The requirement is specifically about ensuring that cloud-to-on-premise traffic crosses a controlled security boundary. That makes the middleware's ability to support a DMZ/perimeter deployment the relevant consideration.

Explanation:

The scenario describes a broad set of enterprise integration concerns: caching, queuing, error handling, alerts, retries, event handling, etc. These are all classic middleware/integration platform responsibilities — capabilities that Salesforce, as a CRM/application platform, is not designed to natively provide at an enterprise-grade level.

Salesforce has some native integration capabilities (Platform Events, Change Data Capture, Apex callouts, etc.), but it is not a full enterprise service bus (ESB) or integration platform. It lacks robust, purpose-built infrastructure for things like:

True message queuing with guaranteed delivery, ordering, and persistence
Sophisticated retry/error-handling frameworks with configurable backoff, dead-letter queues, etc.
Centralized alerting/monitoring across multiple integrated systems
Protocol translation and complex message transformation at scale

The correct architectural recommendation is to introduce a dedicated middleware solution (like MuleSoft or similar iPaaS/ESB platform) that is purpose-built to handle these cross-cutting integration concerns. Middleware platforms provide true message queuing (durable, reliable, FIFO or priority-based delivery with persistence) along with the other capabilities (caching, retries, error handling, alerting) as core platform features — this is exactly what they're designed for, and trying to replicate this natively within Salesforce would be inefficient, hard to maintain, and likely to hit platform limits (API limits, Apex governor limits, etc.).

Why not the others:

A (Message transformation and protocol translation within Salesforce) — This goes against integration best practices.
Salesforce is not designed to be a transformation/protocol-translation engine; doing so would consume Apex governor limits, create tight coupling, and add unnecessary complexity/maintenance burden to the Salesforce org. This type of heavy-lifting integration logic belongs in a middleware layer, not within Salesforce itself.

B (Transform Fire and Forget to Request and Reply, handled by middleware) — This is a specific messaging pattern change that isn't relevant to or requested by the scenario.
The question doesn't indicate an existing Fire-and-Forget pattern needing conversion to Request-Reply; it's a narrow, unrelated recommendation that doesn't address the broad set of stated requirements (caching, queuing, error handling, alerts, retries, event handling). This is a distractor introducing an unrelated specific pattern.

Key exam takeaway:
When a scenario lists broad enterprise integration infrastructure needs (caching, queuing, retries, error handling, alerting, event handling) that go beyond simple point-to-point callouts, the correct recommendation is almost always to introduce a dedicated middleware/integration platform — because Salesforce is an application platform, not an enterprise integration/message-queuing platform. Recognize when a scenario is signaling "you need middleware" versus "you can handle this natively in Salesforce."

Reference:
Salesforce Integration Patterns and Practices — "When to Use Middleware" / Enterprise Integration Architecture principles.

Explanation:

When a callout from a Lightning Web Component (LWC) to an external endpoint is failing, the first thing an integration architect should validate is whether the endpoint URL has been added to Content Security Policy (CSP) Trusted Sites in Salesforce Setup.

Why CSP is the priority for LWC callouts:

LWC JavaScript runs in the browser: Unlike Apex (server-side), LWC code executes client-side. Salesforce enforces a strict CSP that blocks all outbound API calls to external domains by default to prevent cross-site scripting (XSS) and code injection attacks.

Immediate failure point: If the endpoint domain is not added to CSP Trusted Sites (with the connect-src directive checked), any fetch() call from the LWC will fail immediately with a "Failed to fetch" error, and the browser console will show a CSP violation.

Configuration location: This is configured in Setup → CSP Trusted Sites (formerly Trusted URLs). The connect-src directive must be enabled for API callouts to work.

Why Other Options Are Incorrect

A. The endpoint domain has been added to Cross-Origin Resource Sharing (CORS):
CORS is enforced by the external server, not Salesforce. While CORS can cause failures, you cannot "add" a domain to CORS in Salesforce—that configuration must be done on the third-party endpoint itself. CORS controls whether the browser allows JavaScript to read the response, but it does not control whether the request is sent in the first place.

B. The endpoint URL has been added to Remote Site Settings:
Remote Site Settings authorize Apex callouts (server-side), not LWC JavaScript callouts (client-side). If the integration used an Apex controller to make the callout, Remote Site Settings would be the correct answer. However, the question explicitly specifies the callout originates from a Lightning Web Component.

Key Distinction for the Exam

Callout Origin → Required Salesforce Configuration
LWC / Aura (client-side JavaScript) → CSP Trusted Sites / Trusted URLs
Apex (server-side) → Remote Site Settings (or Named Credentials)

The presence of "Lightning Web Component" in the question is the critical clue pointing to CSP Trusted Sites. This distinction is a frequent exam topic.

Explanation:

The enterprise architect’s requirements (caching, queuing, error handling, alerts, retries, event handling, etc.) are classic middleware capabilities. Salesforce has limited native support for these concerns (Outbound Messaging provides basic retries for one endpoint; Platform Events provide a durable event bus). For full enterprise-grade support—especially true message queuing, sophisticated error handling, alerts, retries, and event routing—a middleware solution is required.

In a publish/subscribe pattern, middleware is the natural place to:

Receive events from publishers (including Salesforce Platform Events or Change Data Capture).
Route / fan-out those events to the appropriate active subscribers.
Apply transformation, protocol conversion, retries, dead-letter queues, logging, and alerting.

This is exactly the recommendation documented in Salesforce’s Integration Patterns and Practices guide and is one of the standard correct answers for this exam question family.

Why the other options are incorrect

A. Transform a Fire and Forget mechanism to Request and Reply…
Changing the interaction style is a design decision driven by the specific use case, not a general recommendation for fulfilling caching/queuing/error-handling requirements. Middleware can support either pattern; forcing everything to Request-and-Reply is not required or always desirable.

C. Message transformation and protocol translation should be done within Salesforce.
Transformation and protocol conversion are core middleware responsibilities. Performing them inside Salesforce increases governor-limit pressure, couples systems more tightly, and contradicts Salesforce best practice.

Summary
When the requirements include robust event handling, queuing, retries, and related quality-of-service features, the integration architect should recommend middleware that can act as the event router in publish/subscribe scenarios (and provide true message queuing).

Explanation:

When using Bulk API for nightly batch loads, monitoring is essential to ensure jobs complete successfully and errors are addressed. The recommended approach is:

Bulk Data Load Jobs UI (Setup Menu):

Provides a native monitoring interface in Salesforce.

Administrators can view job status, batch progress, success/failure counts, and error details.

No custom development is required, making it the most straightforward and reliable monitoring method.

Why not the other options?

B. Write error response to a custom error logging object with Apex trigger → Incorrect.
Bulk API jobs are asynchronous and external; Apex triggers cannot intercept Bulk API responses directly. This would require unnecessary custom development and is not scalable.

C. Set debug logs to “finest” for the job user → Incorrect.
Debug logs are intended for troubleshooting Apex code execution, not monitoring Bulk API jobs. They would generate excessive log volume and are not practical for nightly monitoring.

Thus, the best recommendation is to use the Salesforce UI “Bulk Data Load Jobs” page for monitoring.

Reference

Salesforce Docs: Monitor Bulk Data Load Jobs
Salesforce Help: Bulk API Monitoring

Explanation:

The question gives two important architectural clues:

The legacy application only supports SOAP.
The integration pattern is Fire and Forget, with a response coming back in a strongly typed format.

For the Salesforce-to-legacy direction, Outbound Messaging is appropriate for a Fire and Forget pattern. Salesforce can send a SOAP-based outbound message to an external listener when the configured record change occurs. The sender does not need to wait synchronously for the receiving application to complete its processing.

For the reverse direction, the legacy system needs to call Salesforce using the Salesforce SOAP API. The Enterprise WSDL is strongly typed and is generated for a specific Salesforce organization. It contains the organization's objects and fields, making it appropriate when the integration requires a strongly typed representation of Salesforce data.

Therefore:

Salesforce → Legacy: Outbound Messaging
Legacy → Salesforce: SOAP API + Enterprise WSDL

Why the other options are incorrect

A. Platform Events + Enterprise WSDL — Incorrect

Platform Events provide an event-driven mechanism and are asynchronous, but the scenario specifically identifies a legacy application that only supports SOAP and asks for the appropriate capability for the Fire and Forget pattern.

Outbound Messaging is the Salesforce capability specifically designed for sending SOAP-based notifications to an external system.

Platform Events would be more appropriate when the external application can consume Salesforce event channels, rather than when the stated legacy integration requirement is based on SOAP.

B. Outbound Messaging + Partner WSDL — Incorrect

The Partner WSDL is designed to be more generic and loosely typed. It uses generic representations that allow the same integration code to work across different Salesforce organizations.

The question explicitly requires the response to be in a strongly typed format. The Enterprise WSDL is strongly typed and organization-specific, making it the appropriate choice.

Enterprise vs. Partner WSDL

WSDL → Characteristics
Enterprise WSDL → Strongly typed, organization-specific, suited to tightly coupled integrations
Partner WSDL → Loosely typed, generic, suited to integrations that need to work across multiple Salesforce organizations

Exam takeaway

Remember this combination:

Fire and Forget + SOAP legacy system → Outbound Messaging

And when the Salesforce SOAP API must provide a strongly typed interface:

Enterprise WSDL

Therefore:

Answer: C. Outbound Messaging + SOAP API using Enterprise WSDL.

Explanation:

Why C is correct:
Salesforce enforces strict storage limits and maximum file size caps per file upload (typically 2GB for Salesforce Files). Storing massive 2.5 GB design files directly inside Salesforce is highly inefficient, cost-prohibitive, and technically restricted by file size limits. The architectural best practice for managing large binaries or files residing in an external system is Data Virtualization or Reference Storage. By storing lightweight metadata (such as a file reference URL) in Salesforce or a custom object, community users can view the link and securely access or download the heavy files directly from the on-premise file store without bloating Salesforce storage.

Why A is incorrect:
Building a custom Request and Reply integration pattern through a Lightning component to stream a 2.5 GB file through Salesforce buffers and synchronous callout limits will inevitably trigger timeout errors, heap size limits, and severe browser performance degradation. Large binaries should never be proxied directly through Salesforce synchronous Apex transactions.

Why B is incorrect:
Uploading and linking 2.5 GB files directly via Salesforce Files exceeds individual file size limits and rapidly consumes valuable, expensive file storage allocation in your Salesforce organization.

Reference:
Salesforce Pattern: Data Virtualization / Large Data Volume (LDV) / File Management Patterns
Salesforce Documentation: Salesforce Files Limits, Sizes, and Sharing Overview

Explanation:

The core requirement is to protect secrets (usernames, passwords, OAuth tokens) used in callouts from being exposed in plain text or accessible by unauthorized users/packages. The correct combination of Salesforce mechanisms for this is:

Named Credentials
This is the purpose-built Salesforce feature for securely storing authentication credentials (username/password, OAuth tokens, certificates) used in callouts. When you use Named Credentials, Salesforce encrypts and stores the credentials securely, and critically, Apex code and declarative tools never need to see or handle the actual credential values — you simply reference the Named Credential by name in your callout (callout:My_Named_Credential), and Salesforce injects the authentication automatically at runtime. This means credentials are never exposed in code, logs, or debug output, directly solving the "plain text secrets" vulnerability. Named Credentials also handle OAuth token refresh automatically, adding another layer of security/convenience.

Protected Custom Metadata Types
When secrets or configuration values need to be stored as metadata (e.g., supplementary configuration used alongside Named Credentials, or values referenced by managed/unmanaged package logic), marking the Custom Metadata Type as Protected ensures that subscriber orgs and other packages cannot directly query, view, or access the metadata records via SOQL or API — protecting it from being read or exposed by unauthorized package components. This is specifically relevant to the question's context of unmanaged package vulnerabilities, since "Protected" visibility controls access at the package boundary.

Together, these two mechanisms directly address the stated vulnerability: secrets are encrypted/hidden (Named Credentials) and configuration/metadata is shielded from unauthorized package-level access (Protected Custom Metadata Types).

Why not the others:

B (Encrypted Custom Fields and Protected Custom Settings)
Custom Settings are deprecated in favor of Custom Metadata Types for this kind of use case, and importantly, Custom Settings do NOT support a "Protected" visibility option the way Custom Metadata Types do — Custom Settings are generally accessible via Apex across the org without the same package-level protection mechanism. Additionally, Encrypted Custom Fields (Shield Platform Encryption) protect field-level data at rest but are not the purpose-built mechanism for storing callout authentication credentials — Named Credentials remains the correct, dedicated tool for that specific use case.

C (Named Credentials and Protected Custom Settings)
Named Credentials is correct here, but pairing it with Protected Custom Settings is problematic because, as noted above, Custom Settings don't support "Protected" status in the same robust way Custom Metadata Types do for package visibility protection. This makes the combination technically inconsistent with Salesforce's actual security model.

Key exam takeaway:
For protecting callout credentials/secrets, the answer almost always centers on Named Credentials (purpose-built, encrypted, hides secrets from Apex/logs). For protecting configuration data from unauthorized package/org access, use Protected Custom Metadata Types (not Custom Settings, which lack this protection mechanism). Remember: Custom Metadata Types support "Protected" visibility; Custom Settings do not.

Reference:
Salesforce Security Implementation Guide — "Named Credentials" and "Protect Custom Metadata Types."

Explanation:

The scenario involves a large enterprise (10+ million customers) that must give Customer Support seamless, contextual access to sensitive billing data in the Enterprise Billing System (EBS) and generated bills in the Document Management System (DMS) while working inside Salesforce CRM.

When designing the integration, the integration consultant’s primary authorization/authentication consideration is to align with the enterprise’s overall security policies and requirements for those backend systems. This includes:

Compliance with corporate identity, access-control, encryption, auditing, logging, and monitoring standards.
Ensuring that only authorized users (and only for the customers they are servicing) can retrieve billing information and documents.
Choosing appropriate authentication mechanisms (SSO/SAML/OAuth, mutual TLS, Named Credentials, etc.) that satisfy the enterprise security posture rather than inventing Salesforce-specific workarounds that violate enterprise policy.

This is the foundational need that drives all subsequent design decisions.

Why the other options are incorrect

A. Identify options to maintain DMS and EBS authentication and authorization details in Salesforce.
While credential management (e.g., Named Credentials / External Credentials) is an implementation detail that must be addressed, it is secondary to first understanding and complying with the enterprise’s security requirements. Storing or managing external credentials inside Salesforce must still conform to those enterprise rules.

C. Consider options to migrate DMS and EBS into Salesforce.
Migrating entire enterprise systems into Salesforce is neither an authorization/authentication consideration nor a realistic or recommended approach for systems of this scale and specialization. The requirement is integration, not migration.

Explanation:

Northern Trail Outfitters wants to integrate Salesforce test results and code coverage into their custom Java application. The correct API to use is the Tooling API:

Tooling API:

Provides access to Apex code coverage results, test execution results, and metadata about Apex classes and triggers.

Specifically designed for developer tools and integrations that need to query unit test outcomes and coverage metrics.

Ideal for external applications that consolidate test results across multiple enterprise systems.

Why not the other options?

A. Analytics REST API → Used for querying reports and dashboards, not for Apex test results or code coverage.

B. Metadata API → Used for deploying and retrieving metadata (e.g., custom objects, fields, page layouts). It does not provide test execution or coverage data.

Thus, the Tooling API is the only API that meets the requirement of retrieving code coverage and test results.

Reference
Salesforce Docs: Tooling API Overview
Salesforce Docs: Apex Test Results via Tooling API