Salesforce Certified Platform Integration Architect Plat-Arch-204 Exam Questions

Answer : C

When comparing Platform Events and Outbound Messaging for a near-real-time architecture, a Salesforce Platform Integration Architect must evaluate fundamental differences in their delivery models and governance. While both provide declarative, asynchronous 'Fire-and-Forget' capabilities, their technical constraints differ significantly, particularly regarding scalability and platform limits.

The key architectural highlight in this scenario is that Platform Events operate on a specialized event bus with specific Event Publishing and Event Delivery limits. Unlike Outbound Messaging, which is governed by more general daily outbound call limits (often tied to user licenses), Platform Events have a dedicated allocation for the number of events that can be published per hour and delivered in a 24-hour period to external clients via the Pub/Sub API or CometD. For example, the number of concurrent subscribers to a Platform Event channel is typically capped at 2,000 for standard configurations. Since the customer expects 3,000 customers to view these messages, this limit is a critical evaluation point; the architecture would need to account for this gap, perhaps by using middleware to fan out messages to the larger audience.

In contrast, Outbound Messaging does not have an 'Event Delivery' limit in the same sense. It is a point-to-point SOAP-based push mechanism where Salesforce manages retries for up to 24 hours if the receiving endpoint is unavailable. However, it is less flexible for multi-consumer scenarios because it requires a separate configuration for every unique destination.

Regarding the other options: Option A is incorrect because neither system strictly guarantees 'exactly-once' delivery without the possibility of duplicates; in fact, Outbound Messaging may deliver a message more than once if it doesn't receive a timely acknowledgment. Option B is incorrect because Platform Events do not have built-in 'fault recovery' handled by Salesforce in the same way as Outbound Messaging's automatic retry queue; with Platform Events, it is the subscriber's responsibility to use a Replay ID to retrieve missed events within the 72-hour retention window. Therefore, highlighting the unique delivery and publishing limits is the most vital step for the architect.

Answer : C

Salesforce is a highly capable CRM platform, but it is not a dedicated messaging or orchestration engine. When requirements include complex message queuing, process choreography, and guaranteed quality of service (QoS), the Integration Architect must recommend a middleware solution (ESB or iPaaS).

'True message queuing' involves holding messages in a persistent state until the target system is ready to receive them, handling sophisticated retry logic (such as exponential backoff), and providing dead-letter queues for failed messages. While Salesforce has basic asynchronous tools like Outbound Messaging or Platform Events, they lack the granular control over queuing and orchestration that enterprise middleware provides.

Option A is incorrect because performing heavy transformation and protocol translation (like XML to JSON or SOAP to REST) within Salesforce consumes excessive Apex CPU time and is better handled by middleware designed for that purpose. Option B is conceptually backward; usually, architects move away from synchronous Request-Reply toward asynchronous Fire-and-Forget to improve scalability. By recommending a middleware solution to handle these infrastructure-level concerns, the architect ensures that Salesforce remains performant for its users while the middleware manages the technical complexities of reliably connecting the enterprise.

Answer : A

In an org merger scenario, a Salesforce Platform Integration Architect must often design interim solutions that balance speed of delivery with minimal development overhead. The requirement here is for leads to be synced within a 30-minute window. This is a relatively low-latency requirement that does not strictly necessitate a real-time, event-driven architecture, which typically requires more complex infrastructure like Platform Events or middleware.

Option A, calling the Salesforce REST API to insert leads into the target system, represents the standard, most straightforward approach. Since both systems are Salesforce orgs, the retiring org can be configured to make an outbound REST call to the new org's standard Lead endpoint. This can be achieved with a small amount of Apex code (such as a trigger or an invocable method called by a Flow). This approach is considered the 'least development effort' because it leverages the standard REST API, which is already enabled and authenticated via a Connected App in the target org. It requires no custom API development in the target system and uses standard JSON payloads.

Option B is incorrect because the Tooling API is intended for managing metadata, system settings, and developer tools, not for standard transactional data movement like Lead insertion. Option C, using the Composite REST API, is an optimization technique designed to group multiple requests into a single call to save on API limits. While efficient for high-volume scenarios, it introduces additional development complexity regarding payload construction and bulk error handling that exceeds the 'least effort' requirement for a simple Lead sync. Therefore, a standard REST call is the most direct path to meeting the 30-minute SLA with minimal coding.

Answer : A

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.

Answer : B

To provide 'instant access' for new customers via an external IAM system using SAML, Salesforce provides a declarative feature called Just-in-Time (JIT) provisioning.

When a customer attempts to log in to the Community (Experience Cloud) through the IAM system, the IAM system (acting as the Identity Provider) sends a SAML assertion to Salesforce. If JIT provisioning is enabled, Salesforce parses the user information contained in that assertion---such as name, email, and federation ID. If a corresponding User record does not exist, Salesforce automatically creates one on-the-fly and then logs the user in. This eliminates the need for a manual registration step or pre-provisioning accounts.

Option A is slightly incorrect because Registration Handlers are specifically associated with Authentication Providers (which use OpenID Connect/OAuth), not SAML SSO. Option C is incorrect because JIT provisioning is a feature of SAML, while Authentication Providers use the Registration Handler class to achieve the same result. For a 'self-service' scenario where speed to market and standard protocols are key, SAML SSO with JIT provisioning is the architect's primary choice for automating user management and providing a seamless single-entry point for subscribers.

Answer : B

To translate abstract business needs into a functional Integration Architecture, an architect must move beyond 'what' the business wants to 'how' the data will technically flow. The details in Option B represent the fundamental building blocks of any integration design.

Source and Target Systems: Determining which systems are involved dictates the available APIs (REST, SOAP, Bulk) and required security protocols (OAuth, Mutual SSL).

Directionality: Knowing if the update is unidirectional or bidirectional is critical for record mastering, identifying the 'System of Record,' and preventing infinite data loops.

Data Volume: This is a primary driver for selecting the Integration Pattern. High volumes (millions of records) require the Bulk API, while low-volume, real-time updates are better suited for Streaming or REST APIs.

Transformation Complexity: If data must be heavily massaged or merged from multiple sources, it justifies the need for Middleware (ESB/iPaaS).

Option A focuses on user interface and licensing, which are implementation details rather than architectural integration requirements. Option C deals with project management and resource allocation. While these are important for the project's success, they do not help the architect decide between a Request-Reply or Fire-and-Forget pattern. By focusing on systems, data direction, and volume, the architect ensures that the proposed solution is technically viable, scalable, and adheres to Salesforce platform governor limits.

Answer : A

In a contract-first integration approach using RAML, the specification acts as the single source of truth for request and response structures. Since Salesforce unit tests are prohibited from performing actual network callouts, the HttpCalloutMock interface must be used to simulate external API behavior.

To ensure unit tests truly confirm adherence to the RAML contract, the architect must mandate that the mock implementation specifically returns responses formatted per the RAML specification. This means the mock's JSON or XML body, headers, and HTTP status codes (e.g., 200 OK, 400 Bad Request) must exactly match the 'interface contract' defined in the RAML file.

By strictly aligning the mock with the RAML spec, developers ensure that the Apex client's parsing logic (e.g., JSON.deserialize()) is tested against the agreed-upon data model. If the external service later changes its schema in a way that deviates from the RAML, the unit tests---which are based on that contract---will help identify where the Apex code might fail. Options B and C are technically incorrect: the client does not 'call' or 'implement' the mock; rather, the test runtime provides the mock instance to the client via Test.setMock().