Free Salesforce Integration-Architect Practice Exam with Questions & Answers | Set: 2

The requirement to view and update data in real-time while ens5uring the data only persists in the external system is the definition of a Data Virtualization pattern. In this architectural model, Salesforce does not store a local copy of the data (which would be Data Synchronization), but instead acts as a window into the external system of record.

An Integration Architect implements Data Virtualization primarily through Salesforce Connect. This tool allows the external system's order table to be represented as an External Object in Salesforce. Because the data is retrieved on-demand via a web service call (typically using the OData protocol), it is always "real-time." Furthermore, since Salesforce Connect supports writeable external objects, sales reps can update the order information directly from the Salesforce UI, and those changes are sent back to the external system immediately without being saved to the Salesforce database.

This approach is superior to Data Synchronization (Option A) in this specific use case because it eliminates the need for data storage costs and the complexity of keeping two databases in sync. It is also distinct from Process Orchestration (Option C), which focuses on the sequencing of tasks across multiple systems rather than the real-time presentation of external data. By utilizing Data Virtualization, NTO achieves a seamless user experience where external orders look and feel like native Salesforce records while strictly adhering to the "no persistence" constraint.

To securely integrate a distributed package with a central "Hub" org, the architect should utilize the OAuth 2.0 Web Server Flow. In this model, a Connected App is created in the central org to act as the identity and access provider.1

A critical component of this setup is the Callback URL (Redirect URI). When a user in the "Subscriber" org (where the packag2e is installed) initiates the connection, Salesforce redirects them to the central org to authorize the access. After successful authentication, the central org needs the correct callback URL to return the authorization code to the specific subscriber org.

Using this flow satisfies the security team's requirement for a specific integration account. The administrator in the central org can pre-authorize specific profiles or permission sets to use the Connected App, ensuring that only the designated integration user's credentials are used to fulfill requests. Option A is a security "anti-pattern" (storing passwords in fields), and Option C is unnecessary as API access is a standard feature. This OAuth-based approach provides a secure, revocable, and standardized way to manage cross-org communication in a multi-tenant environment.

In a Synchronous Request-Reply pattern, the user's experience is directly tied to the performance of the external service. For a mission-critical "Available-to-Promise" (ATP) service during checkout, the most vital scalability consideration is the typical and worst-case historical response times of the target system.

Salesforce imposes strict Governor Limits on synchronous callouts to protect platform health. Specifically, if an ATP callout takes longer than 120 seconds, the transaction will time out. More importantly, Salesforce limits the number of long-running requests (those lasting longer than 5 seconds). If multiple users are checking out simultaneously and the external inventory system begins to respond slowly (worst-case), those requests can quickly occupy all available slots in the concurrent request queue, leading to "Concurrent Request Limit Exceeded" errors for all users in the org.

By analyzing historical response times, the architect can determine if the service is reliable enough for a synchronous callout. If the worst-case response time frequently exceeds 5 seconds, the architect should consider a more resilient pattern, such as the Continuation pattern or an asynchronous approach, to prevent blocking the UI thread and hitting platform limits. Options A and C are irrelevant to synchronous checkout performance; query cursors relate to database state, and batch jobs are asynchronous background processes that do not impact real-time user checkout latency.

Implementing Shield Platform Encryption is a significant architectural change that requires careful planning before activation. The architect's first priority must be to Review Shield Platform Encryption configurations and understand the platform's functional limitations.

Encryption at rest affects how data interacts with other platform features. For example, encrypting a field can impact the ability to use that field in SOQL WHERE clauses, report filters, list views, or as a unique/external ID. Before encrypting Social Security Numbers, the architect must audit all existing integrations, Apex code, and reports that reference that field to ensure they will still function correctly.

Option A is incorrect because unnecessarily encrypting all data can negatively impact system performance and break standard functionality. Encryption should be applied selectively to sensitive fields based on a clear data classification policy. Option B is factually wrong; Shield is a data protection tool, not an authentication or authorization mechanism like OAuth or SSO. By reviewing the configurations first, the architect can identify potential "blockers"—such as a field being used in a formula or a criteria-based sharing rule—and address them before the encryption keys are generated and applied.

To secure outbound HTTP requests from Salesforce, architects must implement defense-in-depth measures at both the authentication and transport layers.

Named Credentials are the primary architectural recommendation for managing callout endpoints and authentication in a secure, declarative manner. They abstract the endpoint URL and authentication parameters (such as usernames, passwords, or OAuth tokens) away from Apex code. This prevents sensitive credentials from being hardcoded or exposed in metadata, significantly reducing the risk of accidental disclosure. By using Named Credentials, Salesforce handles the heavy lifting of authentication headers automatically, ensuring that the integration is both secure and maintainable.

Two-way SSL (Mutual Authentication) provides an additional layer of security at the transport layer. While standard SSL ensures that Salesforce trusts the external server, Two-way SSL requires the external server to also verify the identity of the Salesforce client. The architect first generates a certificate in Salesforce, which is then presented to the external system during the TLS handshake. This "mutual trust" ensures that the external service only accepts requests from an authorized Salesforce instance, protecting against man-in-the-middle attacks and unauthorized access attempts.

While an Authorization Provider (Option C) is essential for OAuth-based flows, it is typically used within the configuration of a Named Credential rather than as a standalone security method for a generic HTTP request. By combining Named Credentials with Two-way SSL, the architect ensures that the integration is secured at both the session/authentication level and the network/transport level, adhering to enterprise security best practices for cloud-to-on-premise or cloud-to-cloud communication.

To satisfy a requirement for near real-time REST updates with limited development resources, the architect should utilize Flow Builder. Flow Builder is Salesforce's primary low-code tool for automating complex business logic and outbound integrations.

The Remote Process Invocation—Fire and Forget pattern is the most efficient way to signal an external system (or middleware) that a record was created without blocking the user. Using a Record-Triggered Flow on the Order object, the architect can configure an Action (such as an External Service or a simple HTTP Callout) to send the order data to the middleware's REST endpoint.

Option A is slightly incorrect because creating a platform event is just one step in an event-driven flow; the "Fire and Forget" pattern more accurately describes the end-to-end intent. Option B (Change Data Capture) is a powerful tool, but it is considered a "pro-code" or high-configuration so12lution on the middleware side, requiring the middleware to manage Replay IDs and Bayeux subscriptions. Option C leverages the native strengths of Flow to fulfill the requirement declaratively, 13allowing the team to14 deliver a functional integration without writing Apex code while meeting the near-real-time performance expectations of the ERP.

For a requirement focused on synchronizing record updates from Salesforce to an external system in an event-driven and asynchronous manner, Change Data Capture (CDC) is the architecturally preferred solution over custom Platform Events.

CDC is designed specifically for data replication and synchronization. It automatically publishes change events for Salesforce records (Create, Update, Delete, and Undelete) to the event bus. Unlike Platform Events, which require manual publishing via Apex triggers or Flows, CDC is a low-code feature that requires only a simple activation for the Contact object in Setup. The external homegrown application can then act as a CometD subscriber, listening to the specialized /data/ContactChangeEvent channel to receive near real-time updates without the need for constant polling. Furthermore, CDC provides ordered, replayable events and an extended 72-hour retention window, ensuring that the homegrown application can recover missed updates using a Replay ID if it momentarily loses connection. This native broadcasting capability ensures data integrity across systems while breaking the tight coupling between Salesforce and the legacy application.

When data must reside on-premises due to security or compliance policies, but needs to be visible and actionable in Salesforce, the architect should recommend Data Virtualization via Salesforce Connect.

Salesforce Connect allows Salesforce to treat external data as if it were stored natively in the org without ever moving the data into the Salesforce cloud.28 This is achieved by creating External Objects that map to the on-premises data structures. For this to work seamlessly, the on-premises system or a middleware layer must expose the data through a compatible protocol, most commonly the Open Data Protocol (OData).

Option C is incorrect because Salesforce Connect does not natively support ODBC directly; ODBC is a low-level driver protocol, whereas OData is a web-based RESTful protocol designed for cross-platform data exchange. Option B is irrelevant as the data is stated to be on-premises, not in Heroku. By using Salesforce Connect with OData, the architect satisfies the "stay on-premises" policy while providing Salesforce users with real-time, bidirectional access to the data, supporting features like Global Search and related lists without the overhead of data synchronization.

In a synchronous Request-Reply scenario where a bank agent is waiting "on the spot" for a credit check, the error-handling strategy must balance immediate feedback with system resilience.

Option A is the recommended architectural approach for enterprise resiliency. By placing a Middleware layer (like MuleSoft) between Salesforce and the credit agencies, the architect can implement sophisticated error-handling patterns that are invisible to the user but critical for success. If a credit agency's API is momentarily unreachable, the middleware can perform automated retries (e.g., three attempts with 500ms intervals). If the retries still fail, the middleware sends a clean, structured error response back to Salesforce.

Option B (Fire and Forget) is fundamentally unsuitable for this use case because the agent needs the result immediately to open the account; they cannot wait for a callback that might arrive hours later. Option C (Mock service) is only a testing tool and provides no value in a production environment where real financial data is required. By delegating the retry logic to the middleware, the architect protects Salesforce's concurrent request limits (since the agent only occupies a thread for the duration of the final response) and ensures that transient network issues do not result in a "failed" bank account application for the customer.

In a Remote-Call-In or Batch Synchronization pattern where an external middleware initiates the connection to Salesforce, the external system must be authenticated. The standard Salesforce framework for this is the Connected App.

A Connected App provides a framework for external applications to integrate with Salesforce using APIs and standard protocols like OAuth 2.0. For a high-volume (100,000 records) batch process initiated by middleware every 6-12 hours, the architect would recommend a Connected App using a secure flow, such as the OAuth 2.0 JWT Bearer Flow. This allows the middleware to authenticate as a specific "Integration User" without storing clear-text passwords.

Option A (API Gateway) is used to manage and secure outbound calls from Salesforce or between external services; it does not handle inbound authentication to the Salesforce org itself. Option B (Remote Site Settings) is a whitelist configuration used purely to allow Salesforce to make outbound callouts to a specific URL; it provides no authentication mechanism for systems calling into Salesforce. By recommending a Connected App, the architect ensures that the middleware has the necessary permissions (scopes) to use the Bulk API—which is the appropriate mechanism for the 100,000 record volume—while maintaining a secure, auditable, and standard integration boundary.