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

When corporate guidelines mandate that all cloud-to-on-premise traffic must pass through a secure firewall, the architecture must support a Demilitarized Zone (DMZ) or "Perimeter Network" strategy. The Integration Architect must evaluate whether the middleware solution includes a robust API Gateway component.

A secure API Gateway acts as the single entry point for all external requests. It is typically deployed within the DMZ to terminate incoming TLS connections from the cloud (Salesforce) and perform deep packet inspection, IP whitelisting, and authentication before proxying the request to internal on-premise resources. This provides a critical layer of insulation, ensuring that internal services—such as an ERP or legacy database—are never exposed directly to the public internet.

While OAuth enforcement (Option B) is a common requirement for authorization, it does not fulfill the specific network-level firewall requirement described. Similarly, ODBC connectivity (Option C) is a low-level internal database protocol that should generally be avoided for cross-firewall communication due to its inherent security risks. By selecting a middleware solution with integrated API Gateway capabilities, Northern Trail Outfitters can provide the security team with centralized control over encryption, rate limiting, and threat protection, thereby strictly adhering to the new Corporate Security Guidelines while enabling seamless hybrid cloud integration.

In a synchronous Request-Reply integration—where a bank agent is waiting for a real-time credit check to open an account—the error handling strategy must balance user experience with system resilience. Handling these errors at the Middleware layer is the architecturally preferred solution for managing complex retry logic and providing a clean response to Salesforce.

If the external credit agency's service is momentarily unavailable, the middleware (such as an ESB or MuleSoft) can automatically retry the request multiple times using a pre-defined strategy (e.g., exponential backoff). This "self-healing" behavior can often resolve transient network issues before the Salesforce agent even realizes there was a problem. If the retries fail, the middleware then returns a structured error message to Salesforce, which is displayed to the agent via the UI.

Option B (Fire and Forget) is unsuitable for this use case because the agent needs the result immediately to proceed with the bank account opening; they cannot afford to wait for a background process to finish hours later. Option C (Mock Service) is a testing tool and has no place in a production environment where real financial decisions are being made. By delegating error management to the middleware, UC ensures that its Salesforce instance remains performant (avoiding long-running request timeo1112uts) while maximizing the chances of a successful credit check through automated, controlled retries.1314

For monitoring high-volume Bulk API jobs, the standard and most efficient architectural recommendation is to use the native Bulk Data Load Jobs page in Salesforce Setup.

This page provides a comprehensive, out-of-the-box view of all asynchronous API jobs, including their status (Queued, In Progress, Completed, Failed), the number of records processed, and any overall job errors. It allows administrators to download the result files for each batch to see record-level successes and failures without the overhead of custom code or data storage.

Option B is generally discouraged for high-volume nightly loads. Since the Bulk API is designed to bypass standard synchronous logic for performance, writing errors to a custom object for millions of records would consume significant data storage and could trigger additional governor limit issues during the load itself. Option C is ineffective for Bulk API monitoring; debug logs capture Apex execution but do not monitor the background processing of asynchronous Bulk API batches, and they would quickly become overwhelmed by the volume of data. For enterprise-grade monitoring9, the native UI provides the necessary visibility into job health with zero impact on platform performance or storage.

In the context of Salesforce Connect, securing the integration depends heavily on how the platform authenticates with the external system. The Identity Type configuration is the fundamental security setting for an External Data Source.

The architect must choose between two Identity Types:

Named Principal: Salesforce uses the same set of credentials for all users to access the external system. This is simple to manage but does not allow the external system to distinguish between individual Salesforce users for auditing or permission purposes.

Per User: Each Salesforce user must have their own credentials for the external system. This is the most secure option as it ensures that the data visible in Salesforce respects the specific permissions the user has in the source system.

By correctly configuring the Identity Type, the architect ensures that the requests coming from Salesforce are properly authorized at the target system. Option B (CSRF Protection) is a security measure to prevent cross-site request forgery but is not the primary mechanism for authenticating the Salesforce service itself. Option A is a technical compatibility setting for non-standard OData implementations and does not directly relate to security. Therefore, recommending the appropriate Identity Type—typically "Per User" for sensitive data—is the key step in securing the OData connection.

With a volume of 2 million records per day, this integration exceeds the practical limits of standard near-real-time patterns like Outbound Messaging or synchronous Apex Callouts. Sending 2 million individual REST requests would likely exhaust the daily API limit and could cause significant performance degradation in Salesforce due to transaction overhead.

An Integration Architect must recommend an Asynchronous Batch Data Synchronization pattern, typically facilitated by a third-party ETL/Middleware tool (e.g., MuleSoft, Informatica, or Boomi). Staging the records off-platform is essential for several reasons:

Throttling: The homegrown system behind a firewall may not be able to handle a massive, sudden burst of 2 million records. A middleware tool can ingest the data from Salesforce and "drip-feed" it into the target system at an acceptable rate.

Error Handling and Retries: Middleware provides sophisticated persistence and "Dead Letter Queues" to ensure that if the homegrown system goes offline, no data is lost.

API Efficiency: The middleware can use the Salesforce Bulk API 2.0 to extract the data in large chunks, which is significantly more efficient than individual REST calls and consumes far fewer API limits.

Option A is a valid concern but is a symptom of the wrong choice of tool (REST). Option B describes an inbound integration to Salesforce, whereas the requirement is outbound. By utilizing a third-party tool to stage and manage the 2 million record flow, the architect ensures that the integration is scalable, respects the corporate firewall constraints (via a secure agent or VPN), and maintains the performance of the Salesforce production environment.

When a target system experiences prolonged outages (lasting "several days"), point-to-point integrations built directly within Salesforce are prone to failure because they lack the persistence required for long-term retries. The architecturally sound recommendation is to utilize middleware queuing and buffering to "insulate" Salesforce from the target system's instability.

In this architecture, Salesforce sends the order to a middleware layer (such as an ESB or iPaaS). The middleware immediately acknowledges receipt of the message, freeing up Salesforce resources. If the manufacturing system is offline, the middleware stores the order in a persistent Message Queue. Unlike Salesforce Outbound Messaging (Option B), which only retries for up to 24 hours, enterprise middleware can be configured to hold messages for days or even weeks.

Middleware also provides sophisticated Quality of Service (QoS) features, such as "Dead Letter Queues" for manual intervention and customized retry schedules (e.g., retrying every hour instead of every few minutes). This decoupling ensures that Salesforce users can continue to create and "send" orders without seeing technical errors, even while the backend manufacturing system is down. Once the manufacturing service is restored, the middleware "drains" the queue, delivering all buffered orders in the correct sequence. This strategy provides the highest level of reliability and resilience for mission-critical business processes.

The timing of Platform Event publishing is a critical detail for an Integration Architect, as it affects data consistency and transaction integrity. In Salesforce, the default and most common behavior for publishing Platform Events from Apex is "Publish After Commit."

When an architect chooses the "Publish After Commit" setting (defined at the event level), the events are held in a buffer and are only released to the event bus after the Apex transaction completes successfully. This ensures that if the database transaction fails and rolls back, the event—which might trigger external actions—is never sent. This prevents "ghost" events where an external system is told to process data that was never actually saved to the Salesforce database.

The question implies a standard scenario where events are being "published" into the bus. In this state, the events have passed the transaction boundary. If the events were only "being published from Apex" (Option C), it doesn't describe the state of the delivery or the transaction. Option B is technically incorrect for standard event publishing logic, as Salesforce explicitly separates the event bus from the database commit to maintain atomicity.

Understanding this "After Commit" behavior is vital when designing synchronization patterns. If the architect requires the event to be sent regardless of whether the transaction succeeds (e.g., for logging a failure), they would need to configure the event as "Publish Immediately." However, in a standard synchronization use case where events are "only being published," it signifies that the source transaction has finalized, and the messages are now available for subscribers (like middleware or other Salesforce orgs) to consume.

---

When utilizing the Bulk API, the platform breaks large datasets into manageable "batches" for asynchronous processing. The "Max CPU time exceeded" error occurs when the synchronous logic triggered by the record save—such as Apex triggers, Flows, or complex sharing calculations—exceeds the 10,000ms limit within a single batch transaction.

Reducing the batch size is the standard technical remedy; it reduces the number of records processed in one transaction, thereby lowering the cumulative CPU time per batch. However, the Integration Architect must account for the latency impact on the end-to-end job completion.

As the batch size decreases, the total number of batches increases significantly. For example, moving from a batch size of 2,000 to 200 for a 1-million-record load increases the number of batches from 500 to 5,000. Each batch incurs a platform overhead for initialization, finalization, and queuing. Consequently, the total time required to execute the bulk job will increase because more time is spent on administrative platform overhead and queuing cycles rather than data processing.

The architect must also monitor the Daily Bulk Batch Limit (typically 15,000 batches per rolling 24-hour period). While a smaller batch size helps avoid CPU timeouts, it moves the system closer to this daily consumption limit. Option B is less relevant as "parallel mode" is designed to handle concurrency within its own defined limits, and Option C refers to synchronous REST/SOAP limits rather than the asynchronous Bulk API limits. Therefore, the primary trade-off is improved reliability (successfully processed records) at the cost of throughput/speed.

To minimize downtime when an external endpoint changes, an Integration Architect must ensure that the URL is not "hardcoded" within Apex code or configuration. The standard Salesforce mechanism for abstracting and managing external endpoints is Named Credentials.

Named Credentials specify the URL of a callout endpoint and its required authentication parameters in one definition. If the URL changes, an administrator simply updates the "URL" field in the Named Credential setup. This change takes effect immediately across all Apex callouts, Flows, and External Services that reference it, without requiring a code deployment or a sandbox-to-production migration.

Along with Named Credentials, Remote Site Settings (or the more modern External Website Configurations) are required. Salesforce blocks all outbound calls to URLs that are not explicitly whitelisted.

By having both in place, the remediation process is:

Update the URL in the Named Credential.

Update (or add) the new URL in the Remote Site Settings.

This approach follows the "Separation of Concerns" principle. Option B (ESB) could technically handle this, but it adds an extra layer of failure and complexity for a simple URL change. Option C (Content Security Policies) is used to control which resources (like scripts or images) a browser is allowed to load in the UI; it does not govern server-side Apex callouts. Therefore, the combination of Named Credentials and Remote Site whitelisting is the most efficient and standard way to provide architectural agility and minimize downtime.

Salesforc30e Platform Events are built on top of a highly scalable, event-driven messaging architecture designed to enable real-time communication between apps. To consume these events from outside Salesforce—such as from a legacy learning system—clients must use the Streaming API.

The Streaming API is the technical foundation for receiving event notifications in a Publish/Subscribe model. It utilizes the CometD protocol or the newer gRPC-based Pub/Sub API to maintain a persistent connection between the external client and Salesforce. When a student registers for a course in the Salesforce Community, a Platform Event is "published" to the event bus. The learning system, acting as a "subscriber," remains connected via the Streaming API and receives the event message instantly without needing to poll Salesforce for updates.

This architecture is ideal for "near real-time" requirements because it eliminates the overhead of traditional point-to-point integrations. While the REST and SOAP APIs (Options A and B) can be used to publish events into Salesforce, they are not designed to receive unsolicited notifications from the platform. By using the Streaming API, the integration architect ensures the solution is both responsive and efficient, as Salesforce only pushes data when a relevant event occurs. Furthermore, because Platform Events provide a retention window, the Streaming API allows the learning system to use a Replay ID to catch up on any registration events missed during a brief network outage.