Integration-Architect Practice Test Questions

Leverage modular design by breaking up the web service into smaller pieces for a microservice architecture.

Explanation:

A tightly coupled, monolithic web service becomes a single point of failure and performance bottleneck. By decomposing it into a set of independently deployable microservices—each handling one integration use-case—you achieve fault isolation, independent scaling, and shorter development cycles. Each microservice can own a bounded context (e.g., “Billing sync”, “ERP orders”, “Data lake bridge”) and publish events or expose APIs for the rest of the ecosystem. This aligns with modern architecture principles that maximize decoupling, resiliency, and team autonomy while improving performance over a single on-premise endpoint.

The typical and worst-case historical response times.

How many concurrent service calls are being placed.

Explanation:

When designing real-time “available to promise” (ATP) callouts, you must dimension both performance and scale against Salesforce’s own limits and your external service’s SLAs. First, measure your external system’s typical and worst-case response times, since Salesforce enforces a 120 sec callout timeout (and will block the user UI until it returns). Second, track concurrent callout volume: Salesforce limits you to 100 HTTP callouts per Apex transaction, and long-running synchronous transactions (over 5 sec CPU) count toward your org’s 10 concurrent long-running transaction limit . Knowing both metrics lets you decide if you need middleware, caching layers, or a sync patterns to avoid hitting timeouts and concurrency governors under load.

Implement idempotent design and have Sales Representatives retry order(s) in
question.

Explanation:

When a network drop causes a lost acknowledgement, retries can inadvertently create a second order unless your integration is idempotent (“at most once” semantics). By assigning each order a unique message ID (or idempotency key) that your manufacturing system tracks, repeated submissions with the same key are recognized and ignored. Salesforce and many REST best-practices guides recommend this idempotent receiver pattern to guarantee single delivery even if clients retry. This allows reps to simply retry without fear of duplicates, and it builds robust fault-tolerance without custom polling or batch-reconciliation jobs.

Change Data Capture Events

High Volume Platform Events

Explanation:

To minimize data loss across days-long disconnects, you need durable, high-retention channels. Change Data Capture (CDC) and High-Volume Platform Events are both implemented on the High-Volume Streaming API, offering a 72-hour retention window and replay-ID-based durable subscriptions. In contrast, Generic or PushTopic events (standard-volume) expire after 24 hours and have lower throughput. Choosing CDC and high-volume Platform Events ensures that even if a client reconnects infrequently, it can reliably replay missed changes without data loss.

Platform Events

Explanation:

Of all event types, High-Volume Platform Events provide the longest built-in retention—up to 72 hours—so subscribers can reconnect within three days and still retrieve missed messages. Change Data Capture events are implemented as high-volume PEs behind the scenes, but the exam choice is explicitly “Platform Events.” Generic and standard-volume events only persist for 24 hours, and Apex callouts can’t buffer for days. By modeling your notifications as high-volume Platform Events, you get guaranteed at-least-once delivery with multi-day replay support.

Outbound Messaging, which will automatically handle error retries to the service.

Explanation:

Salesforce Outbound Messaging delivers a SOAP message to your finance endpoint and automatically retries on failure for up to 24 hours, giving you built-in delivery guarantees without custom Apex. Each message contains its own unique notification ID, and the service must acknowledge receipt with a 2xx HTTP response; otherwise, Salesforce queues and retries until it succeeds or drops after the retry window. This “fire-and-forget” pattern offloads retry logic to the platform and gives you near-exactly-once semantics as long as your endpoint is idempotent and acknowledges duplicates idempotently.

Impact of deleted records on system functionality.

Ability to delete personal data in every system.

Feasibility to restore deleted records when needed.

Explanation:

Under GDPR‐style data protection laws, “erasure” isn’t just a one-click delete—it requires careful coordination across every data store and backup to ensure compliance and operational continuity. First, you must be able to delete personal data in every system (CRM, Commerce Cloud, ERP, legacy mainframes, backups) so that a deletion request truly removes the subject’s information everywhere. Second, you need to assess the impact of deleted records on system functionality—for example, will orphaned orders, service cases, or analytic summaries break if the customer record is purged? This assessment drives exception handling and fallback designs. Third, you must evaluate the feasibility to restore deleted records to recover from accidental erasures or to comply with other legal holds—this includes designing audit logs or isolated recovery copies that respect data-minimization while still enabling rollback when legitimately needed.

Integrating Salesforce with Email Management System, Order Management System and Case Management System.

Explanation:

When Salesforce becomes the central case management platform, it must exchange data with:

→ Email Management System – to capture inbound customer emails as cases and push outbound responses back into users’ mailboxes.
→ Order Management System – so agents can reference order history, shipment details, and billing context when resolving order-related cases.
→ Existing Case Management System – to migrate legacy case records or synchronize ongoing cases, ensuring seamless continuity and archival access.

Other landscape elements like data warehouses are downstream analytics targets rather than part of transactional case workflows. Order Management and Email are mission-critical for day-to-day support operations, while the legacy Case Management system holds the historical data that agents still need. Choosing these three ensures you address both the operational inputs (emails, orders) and the data migration/synchronization requirements for cases.

SAML SSO and just-in-time provisioning

OpenId Connect Authentication Provider and just-in-time provisioning

Explanation:

To provide instant community access on first login, Salesforce must auto-provision users when they authenticate via SSO.

→ SAML SSO + JIT: You configure a SAML identity provider and enable Just-in-Time provisioning so that Salesforce consumes assertion attributes (e.g., Federation ID) to create the user, contact, and profile in one transaction.
→ OpenID Connect + JIT: You set up an OpenID Connect Authentication Provider in Setup and implement a Registration Handler class (Auth.RegistrationHandler) that Salesforce invokes on login, using the ID token claims to spin up the user record automatically.

Without JIT, you’d force users through a manual registration flow or pre-provisioning process, delaying access and complicating self-registration.

Build Batch Retry & Error Handling using BatchApexErrorEvent.

Explanation:

Salesforce’s BatchApexErrorEvent is a built-in platform event that fires whenever a batch Apex job fails or throws an unhandled exception. By subscribing to this event—either in Apex (trigger on the event) or via middleware—you can automatically detect failures in your daily invoice generation and implement retry logic or alerting without embedding complex error-handling inside the batch itself. This decouples your business logic from the resilience framework and leverages Salesforce’s event-driven model. A pure “in-job” retry loop risks hitting governor limits or masking systemic issues, and a simple report can’t react in real time. Events give you both visibility and automation around failure recovery for robust, scalable batch processing.