Salesforce-Platform-Integration-Architect Practice Test Questions

Implement an Enterprise Service Bus for service orchestration, mediation, routing and decouple dependencies across systems.

Explanation:

The CIO’s concern is about scalability and maintainability. Let’s break down why the current approach is risky and why an Enterprise Service Bus (ESB) is the better choice:

Current Situation:

1. Each integration is a point-to-point asynchronous @future callout.
2. Point-to-point integrations do not scale well — adding new systems increases complexity exponentially (N×(N-1)/2 connections).
3. Tight coupling means any change in a target system requires changes in Salesforce code.
4. Hard to manage orchestration (sequence of calls) or mediation (data transformation).

Why ESB is the Right Solution:

An Enterprise Service Bus (e.g., MuleSoft, Dell Boomi) provides:

1. Decoupling — Salesforce only needs to integrate with the ESB, not each downstream system.
2. Centralized orchestration — Complex workflows can be handled outside of Salesforce.
3. Mediation and transformation — The ESB can transform messages for multiple systems without changing Salesforce code.
4. Scalability — Adding new systems doesn’t require new Apex callouts; you just connect them to the ESB.
5. Monitoring and error handling — Central place to track integration health.

Why Not the Other Options?

A. ETL Nightly Batch Loads
Nightly sync is not real-time and doesn’t address orchestration or service decoupling.
CIO’s concern is future scalability, not just traffic reduction.

B. Apex Class Catalog + Custom Metadata
Reduces code duplication but still point-to-point — doesn’t solve scaling issue or orchestration.

C. Enhanced External Services
Useful for declarative integration to REST APIs, but still requires direct connections to each system, leading to the same scaling problems.

Reference:

Salesforce Integration Patterns and Practices:

https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_intro.htm

Pattern: "Process Integration via an ESB" — Salesforce recommends using an ESB for high-scale, multi-system integrations.

The platform events are published after the Apex transaction completes.

Explanation:

Platform Events follow transactional boundaries, meaning:

Events are published only after the Apex transaction successfully completes (including all DML operations).
If the transaction fails (due to an exception or validation rule), no events are published.
This ensures data consistency between Salesforce and external systems.

Why Not the Other Options?

A) Incorrect – Platform Events are not published before the transaction completes.

C) Incorrect – While triggers can publish Platform Events, the question is about when they are published, not how.

D) Incorrect – The question is about when events are published, not where they originate (Apex, Flow, etc.).

Key Concept:

Event-Driven Architecture (EDA) relies on asynchronous event publishing after transaction success.

Order of Execution:
1. Apex transaction executes (DML, triggers, etc.).
2. If successful, Platform Events are published.
3. Subscribers (external systems, flows, triggers) consume the events.

Reference:

Salesforce Platform Events Documentation
Key Quote: "Platform events are published after the transaction completes successfully."

Enterprise Billing System (EBS) - All customer's monthly billing is generated by this system.

Salesforce CRM (CRM)- Customer information, Sales and Support information is maintained in CRM.

Explanation:

Enterprise Billing System (EBS) must be integrated because:
It generates all customer billing, meaning financial data must sync accurately with Salesforce.
Ensures invoices reflect the latest customer updates (e.g., address changes, pricing agreements).
Critical for revenue tracking and compliance.

Salesforce CRM (CRM) is the system of record for customer data, meaning:
All sales, support, and customer profile updates originate here.
Must feed accurate customer data to EBS to prevent billing errors.
Enables customer service agents to view billing history (via integration) without leaving Salesforce.

Why not the Document Management System (DMS)?

While DMS stores bill copies, it’s a downstream system that can be updated via EBS (not a direct integration priority).
Bills are typically generated in EBS first, then archived in DMS—so EBS integration supersedes DMS.

Key Integration Needs:

Bidirectional sync between CRM (customer updates) and EBS (billing records).
Real-time API calls for billing triggers (e.g., contract changes) or batch syncs for large data volumes.
Error handling to reconcile discrepancies across 10M+ records.

This approach ensures billing accuracy while maintaining a single customer view in Salesforce.

Require the Apex REST API Clients to implement the HttpCalloutMock.

Implement HttpCalloutMock to return responses per RAML specification.

Explanation:

Northern Trail Outfitters aims to ensure that Apex REST API clients adhere to RAML specifications, which define the structure and content of API request and response payloads. To confirm this adherence during unit testing, the integration architecture must include mechanisms to simulate API interactions and validate responses against the RAML contract. Let’s analyze the options:

A. Call the Apex REST API Clients in a test context to get the mock response.

This option is incorrect because simply calling the Apex REST API clients in a test context to retrieve a mock response does not inherently ensure adherence to RAML specifications. Without a specific mechanism to validate the response structure against RAML, this approach lacks the rigor needed to confirm compliance with the field-level definitions in the RAML contract.

B. Require the Apex REST API Clients to implement the HttpCalloutMock.

This is correct. The HttpCalloutMock interface in Salesforce allows developers to simulate external HTTP callouts during unit testing, which is essential for testing Apex REST API clients without making actual external calls. By requiring clients to implement HttpCalloutMock, the architecture ensures that tests can control and validate the mock responses, enabling verification that the client handles requests and responses as per the RAML specifications. This setup supports repeatable, isolated tests that align with the API contract.

C. Call the HttpCalloutMock implementation from the Apex REST API Clients.

This option is incorrect because Apex REST API clients do not directly call the HttpCalloutMock implementation. Instead, the Salesforce testing framework uses the Test.setMock() method to associate the HttpCalloutMock implementation with HTTP callouts made by the client during tests. The client code itself remains unaware of the mock implementation, making this option technically inaccurate.

D. Implement HttpCalloutMock to return responses per RAML specification.

This is correct. Implementing the HttpCalloutMock interface to return mock responses that conform to the RAML specifications ensures that unit tests validate the Apex REST API client’s behavior against the expected request and response payloads. By crafting mock responses that mirror the RAML-defined structure (e.g., specific fields, data types, and formats), the integration architect can confirm that the client correctly processes API responses as per the contract, catching any deviations during testing.

Why B and D?

B ensures the architecture mandates the use of HttpCalloutMock for testing, which is a Salesforce best practice for mocking external API calls.

D complements this by specifying that the mock implementation must align with RAML specifications, ensuring the client’s handling of requests/responses is tested against the API contract.

References:

Salesforce Developer Documentation: Testing HTTP Callouts – Explains the use of HttpCalloutMock for simulating HTTP callouts in unit tests.

Salesforce Trailhead: Test Apex Callouts – Covers best practices for mocking and testing REST API integrations.

RAML Official Documentation: RAML Specification – Details how RAML defines API contracts, including field-level request/response specifications, which can be used to structure mock responses.

SAML SSO and just-in-time provisioning

OpenId Connect Authentication Provider and just-in-time provisioning

Explanation:

The scenario involves a subscription-based media company implementing an Identity and Access Management (IAM) system that supports SAML and OpenID Connect to enable self-registration and Single Sign-On (SSO) for subscribers, integrating with Salesforce Community Cloud. The goal is to provide seamless access to new self-service customers. Salesforce Community Cloud (now called Experience Cloud) must support both self-registration and SSO while integrating with the IAM system. Let’s analyze the options:

A. SAML SSO and Registration Handler

This option is partially correct but not the best fit. SAML SSO is supported by Salesforce Community Cloud, allowing users to authenticate via the IAM system without re-entering credentials. However, a Registration Handler (a custom Apex class) is typically used for custom self-registration logic when users first sign up. While it can work with SAML, it’s not the most direct approach for enabling instant access for new users, as it requires custom development to map IAM attributes to Salesforce user records. Just-in-time (JIT) provisioning, which automatically creates or updates user records during SSO, is a more efficient standard approach.

B. OpenId Connect Authentication Provider and Registration Handler

This option is also partially correct but less optimal. Salesforce supports OpenID Connect as an Authentication Provider for SSO, allowing integration with the IAM system. A Registration Handler can be used for self-registration, but as with option A, it requires custom Apex to handle user creation, which is less streamlined than JIT provisioning for instant access. This makes it a less preferred choice compared to JIT provisioning with OpenID Connect.

C. SAML SSO and just-in-time provisioning

This is correct. SAML SSO enables subscribers to log in to Salesforce Community Cloud using their IAM credentials, providing a seamless SSO experience. Just-in-time (JIT) provisioning, supported with SAML, automatically creates or updates a Salesforce user record (e.g., a Community Cloud user) during the SSO process based on attributes sent by the IAM system. This ensures new self-service customers gain instant access without manual intervention or custom registration logic, aligning perfectly with the requirement for efficient self-registration and SSO.

D. OpenId Connect Authentication Provider and just-in-time provisioning

This is also correct. Salesforce supports OpenID Connect as an Authentication Provider, allowing SSO with the IAM system. Like SAML, OpenID Connect supports JIT provisioning, where user attributes from the IAM system (e.g., via ID tokens) are used to create or update Salesforce user records during login. This provides instant access for new self-service customers, meeting the requirement for self-registration and SSO in a scalable, standard way.

Why C and D?

Both SAML SSO (C) and OpenID Connect Authentication Provider (D) are supported by Salesforce Community Cloud and align with the IAM system’s capabilities (SAML and OpenID Connect). Just-in-time provisioning (in both C and D) is a standard Salesforce feature that streamlines self-registration by automatically provisioning user accounts during the SSO process, eliminating the need for custom Registration Handler logic. This is ideal for a large subscriber base requiring instant access.

Why not A and B?

While Registration Handler (in A and B) can be used for self-registration, it requires custom Apex development, which is less efficient than JIT provisioning for handling user creation/update during SSO. JIT provisioning is a declarative, out-of-the-box feature that better suits the scenario’s need for instant, scalable access.

References:

Salesforce Help: Set Up SAML for Single Sign-On – Details SAML SSO configuration and JIT provisioning in Salesforce.

Salesforce Help: OpenID Connect Authentication Providers – Explains OpenID Connect setup and JIT provisioning for SSO.

Salesforce Help: Just-in-Time Provisioning for SAML and OpenID Connect – Describes how JIT provisioning automates user creation during SSO.

Trailhead Module: Identity and Access Management – Covers SSO, self-registration, and JIT provisioning for Community Cloud.

Salesforce with relevant Marketing and ERP information.

Explanation:

The System of Record (SoR) for customers and prospects should be where users primarily interact with and manage that data.

In this scenario:

Salesforce will be the primary system for sales and service associates to view and log interactions.
Marketing and ERP are specialized systems:
. ERP handles invoicing and fulfillment — not prospect lifecycle.
. Marketing handles campaigns and leads — not the full customer view.

If Salesforce is going to be the central operational CRM, it should hold the golden record for customers and prospects, with relevant ERP (orders/invoices) and Marketing (campaign history) data integrated in.

This approach:

1. Makes Salesforce the single pane of glass for associates.
2. Avoids the complexity of constantly switching between multiple systems.
3. Fits Salesforce’s role as the engagement and relationship management hub.

Why not the others:

A. ERP with all prospect data from Marketing and Salesforce
ERP is not designed to manage prospect/customer relationship lifecycles — it’s for transactions, invoicing, and fulfillment.

B. Marketing with all customer data from Salesforce and ERP
Marketing systems focus on campaign execution, not operational service/sales workflows.

D. New Custom Database for Customers and Prospects
This adds unnecessary complexity and cost when Salesforce is already the CRM platform chosen.

Reference:

Salesforce Integration Patterns and Practices — System of Record considerations:

https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_sor_considerations.htm

Salesforce as CRM hub — Single Source of Truth pattern.

Tooling API

Explanation:

The Tooling API is specifically designed for interacting with Salesforce development and testing environments, making it the best choice for retrieving code coverage and test results.

Why Tooling API?

Provides access to Apex test execution results, including code coverage metrics.
Can query objects like ApexTestResult, ApexCodeCoverage, and ApexTestQueueItem.
Ideal for CI/CD integrations and custom monitoring tools (like the Java app in question).

Why Not the Other Options?

A) SOAP API – General-purpose but not optimized for accessing test results and coverage data.
B) Analytics REST API – Used for Einstein Analytics, not Apex testing metrics.
C) Metadata API – Used for deploying and retrieving metadata, not runtime test data.

Key Reference:
Salesforce Tooling API Documentation

Relevant Objects:
ApexTestResult – Test execution status.
ApexCodeCoverage – Code coverage percentages.
ApexTestQueueItem – Queued test runs.

Implementation Example (Tooling API Query for Test Results):

SELECT Id, Outcome, MethodName FROM ApexTestResult WHERE AsyncApexJobId = 'JobId'

SELECT NumLinesCovered, NumLinesUncovered FROM ApexCodeCoverage WHERE ApexClassOrTriggerId = 'ClassId'

This makes the Tooling API the clear choice for integrating test coverage reporting into a custom Java application.

Store unique identifiers in an External ID field in Salesforce and use this to update the proper records across systems.

Use Change Data Capture to update downstream systems accordingly when a record changes.

Explanation:

Universal Containers needs bidirectional synchronization between Salesforce (the system of record for Leads, Contacts, Accounts, Cases) and external systems (ERP, ticketing system, data lake), each with unique identifiers, using middleware.

B. Store unique identifiers in an External ID field in Salesforce and use this to update the proper records across systems.

Salesforce External ID fields store unique identifiers from external systems, allowing middleware to map and update records accurately in both directions (Salesforce ↔ external systems).

C. Use Change Data Capture to update downstream systems accordingly when a record changes.

Salesforce Change Data Capture (CDC) streams real-time record changes (create/update/delete) to middleware, which can propagate updates to external systems, ensuring near-real-time synchronization from Salesforce.

A is incorrect due to the complexity and risk of caching IDs in middleware. D is overkill, as an MDM solution is unnecessary when Salesforce is the system of record.

References:

Salesforce Help: External ID Fields
Salesforce Help: Change Data Capture

A Connected App for each external system integration.

Explanation: Key Requirements:

Principle of Least Privilege → Each external system should have only the permissions it needs.
Auditability → Activities must be traceable to individual systems for compliance.

Why Option D is Correct?

1. Unique Connected Apps per system allow:
. Fine-grained OAuth policies (scopes, IP restrictions, etc.).
. Distinct audit logs tied to each system (via ConnectedApp and AuthSession objects).
. Individual API usage tracking (monitoring per system).

2. Integration users (Option C) can also enforce least privilege but lack:
. Built-in OAuth security controls (e.g., refresh token policies).
. Native auditability of Connected Apps (e.g., LoginHistory ties to users, not systems).

Why Not the Other Options?

A) Shared integration user → Violates least privilege (all systems share one set of permissions) and muddies audit trails.
B) Shared Connected App → Same issues as Option A; no system-specific accountability.
C) Unique integration users → Works for least privilege but lacks the OAuth security and built-in auditing of Connected Apps.

Best Practice:

Use Connected Apps + Named Credentials for:
. Authentication security (certificate-based OAuth).
. Centralized credential management (no hardcoded secrets).
Supplement with Permission Sets to enforce least privilege at the user/license level.

Reference:

Connected Apps Documentation
Auditing Connected Apps

Provide true message queueing for integration scenarios (including
orchestration,process choreography, quality of service, etc.) given that a middleware solution is required.

Event handling processes such as writing to a log, sending an error or recovery process, or sending an extra message, can be assumed to be handled by middleware.

Event handling in a publish/subscribe scenario, the middleware can be used to route requests or messages to active data-event subscribers from active data event publishers.

Explanation:

The enterprise architect’s list — caching, queuing, error handling, alerts, retries, event handling — describes integration infrastructure capabilities that are best handled by middleware, not directly in Salesforce.

B. Provide true message queueing…

Middleware (ESB, iPaaS like MuleSoft) is designed for durable message queues, orchestration, and quality of service (QoS) guarantees.

Salesforce can publish events but does not provide enterprise-grade queuing like persistent retry queues, guaranteed delivery, or ordering — that’s the middleware’s role.

D. Event handling processes… handled by middleware

Error logging, triggering recovery processes, sending alerts — these are better done outside of Salesforce to avoid unnecessary processing overhead in the CRM and to centralize operational monitoring.

E. Event handling in a publish/subscribe scenario…

Middleware is well-suited to routing messages between multiple publishers and subscribers, applying transformations, and managing subscription lifecycles without overloading Salesforce with distribution logic.

Why not the others?

A. Transform a fire-and-forget mechanism to request-reply…
This transformation is not typically done to improve performance — in fact, adding request-reply can reduce throughput. The architectural pattern should be chosen based on business need, not performance tuning alone.

C. Message transformation and protocol translation should be done within Salesforce
Incorrect — Salesforce has limited transformation capabilities (e.g., Apex parsing, External Services), but middleware is designed for heavy transformations and protocol conversions (SOAP ↔ REST, JMS, FTP, etc.).

Reference:

Salesforce Integration Patterns and Practices:
https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_intro.htm

Pattern: Process Integration via Middleware — emphasizes middleware for queuing, orchestration, transformation, and event routing.