Configure mutual server authentication with two-way SSL using CA issued certificates.

Explanation

This scenario requires securing a server-to-server integration between Salesforce and an external Microsoft Azure API Gateway. The most appropriate mechanism is one that provides strong authentication and encryption for the communication channel itself.

Why A is Correct:
Mutual TLS (mTLS) is the industry standard for securing API-to-API communications. It ensures both parties (Salesforce and the Azure API Gateway) authenticate each other using X.509 certificates before establishing a secure, encrypted connection. This provides a high level of trust and is natively supported by Azure API Gateway for backend authentication. It is specifically designed for this exact use case.

❌ Why B is Incorrect:
A Connected App with OAuth is primarily designed for scenarios involving user context and delegated authorization, where a user grants an application access to their data. For a system-level, server-to-server integration where no user is involved, OAuth adds unnecessary complexity. mTLS is a more straightforward and secure fit.

❌ Why C is Incorrect:
Using an API-only user with a federated identity provider is an architecture for authenticating users via an external IdP (like Azure AD). It is not the standard or most direct method for securing the communication channel between two backend systems (Salesforce and the API Gateway).

❌ Why D is Incorrect:
Salesforce Shield with Encryption at Rest is designed to encrypt data stored in the Salesforce database. It does not secure the data in transit over the network between Salesforce and an external system. The requirement is to secure the integration path, not the storage of the data within Salesforce.

Reference & Key Concept
Mutual TLS (mTLS): This protocol requires both the client and the server to present and verify each other's certificates. This prevents impersonation and ensures that only trusted systems can communicate.
API-led Security: For system-level integrations, certificate-based authentication is often preferred over token-based systems as it provides a strong, persistent identity for the connecting client.
Azure API Gateway Capability: The Azure API Gateway v2 SKU has built-in support for validating client certificates, making this a directly implementable solution.

The mobile device makes a REST API inbound call.

Explanation

The core requirement is for the mobile application to send data (GPS coordinates) to Salesforce to be stored in a field. This is an inbound integration to Salesforce.

Why C is Correct:
The mobile application, acting as an external client, must call into Salesforce. The Salesforce REST API is the standard, modern, and efficient way for an external application to perform CRUD operations (like updating a record) on Salesforce data. It uses the oAuth authentication that is already in place, making it a seamless extension of the current architecture.

❌ Why A is Incorrect:
While the SOAP API is also an inbound call and could technically achieve this, it is overly complex and verbose for this simple task. The REST API is lighter, more performant for mobile networks, and the preferred choice for mobile applications.

❌ Why B is Incorrect:
This option is conceptually flawed. A "REST Apex callout" is an outbound call initiated by Salesforce to an external system. The mobile device cannot "receive" a callout from Salesforce. The direction of the data flow is wrong.

❌ Why D is Incorrect:
"REST Apex inbound call" refers to a custom Apex REST service. This is unnecessary for standard CRUD operations. Using the standard, pre-built Salesforce REST API to update a record is the simplest, most secure, and most maintainable approach. Building a custom Apex REST service would be over-engineering.

🔐 Reference & Key Concept
Inbound vs. Outbound: The mobile app is the client initiating the request to the Salesforce server. This is the definition of an inbound integration.
Standard REST API: The built-in Salesforce REST API provides direct, optimized access to standard operations.
Security Context: The operation will respect the user's oAuth session and all associated security controls, including Field Level Security (FLS).

Important Caveat:
To successfully update the field, the running user's Profile or Permission Set must grant Edit access to the custom geolocation field. The API honors FLS, so read-only access in the UI would prevent the update via the API as well.

Callouts to RESTful services

Encryption in transit and at rest

Explanation

The scenario demands strict PHI protection, fine-grained access, and compliance (e.g., HIPAA). The integration must never store identifiable data in Salesforce and must secure all interactions.

C. Callouts to RESTful services Correct

Community users (patients, nurses, doctors) must access prescriptions on-demand via real-time REST callouts from Salesforce to the secure system.
Use one-time identity tokens (passed in headers) for ephemeral, authorized access.
No data is stored in Salesforce — only temporary display in UI (e.g., Lightning component).
Enables policy #2 and #3: Only verified, token-holding users get data.

D. Encryption in transit and at rest Correct

In transit: All REST callouts must use HTTPS/TLS 1.2+.
At rest: Even though identifiable data is not stored, any cached responses or session data in Salesforce must be encrypted (Salesforce provides this by default).
Einstein Analytics: De-identified data is loaded — but encryption in transit (via secure API) is still required.
Meets policy #1 (no identifiable data at rest in Salesforce) and compliance standards.

Why A and B are incorrect

A. Identity token data storageWrong — Tokens are one-time, short-lived (minutes).
Storing them violates security best practices and policy #1.
Tokens must be used immediately in callouts and discarded.

B. Bulk load for Einstein AnalyticsWrong — Bulk load is for de-identified, analytical data only (allowed).
But the question is about Community portal + Einstein access to prescriptions — not bulk analytics.
Bulk load does not address authorization or encryption for live prescription access.

Official References
Salesforce Help:Callouts from Lightning Components
HIPAA Guidance: Salesforce supports encryption in transit/at rest — but PHI must not be stored.
https://compliance.salesforce.com/en/hipaa
Architect Guide: Secure External Service Integration

Exam Tip:
For PHI + external secure system:
Never store PII/PHI → Use real-time callouts (C)
Always encrypt → TLS + no at-rest PHI (D)

Write a trigger that invokes an Apex proxy class to make a REST callout to the Order Management System.

Explanation

NTO requires a synchronous callout from Salesforce to the OMS immediately when an Opportunity changes to "Closed/Won" with products. This ensures real-time order creation and prevents fulfillment delays. The solution must trigger automatically on record update, execute in real time, and use Apex for HTTP callouts—while respecting governor limits in a synchronous context.

✅ Correct Option: A – Write a trigger that invokes an Apex proxy class to make a REST callout to the Order Management System
Triggers fire synchronously on DML, ensuring immediate execution when status changes.
Apex proxy class encapsulates reusable, secure REST callout logic with @future(callout=true) if needed for async fallback.
Supports real-time integration; OMS receives order instantly upon Close/Won.
Allows error handling, retry logic, and logging within transaction scope.

❌ Incorrect Option: B – Use Process Builder to call an Apex proxy class to make a REST callout
Process Builder actions are asynchronous by design—even when invoking Apex.
Cannot guarantee synchronous callout; risks delay or out-of-order processing.
Violates the explicit requirement for synchronous behavior.

❌ Incorrect Option: C – Develop a batch Apex job that aggregates Closed Opportunities and makes a REST callout hourly
Batch jobs run asynchronously and on a schedule—not in real time.
Hourly delay means orders wait up to 60 minutes, breaking real-time fulfillment.
Aggregation may complicate error handling per Opportunity.

❌ Incorrect Option: D – Build a Lightning Component that makes a synchronous Apex REST callout when a button is clicked
Relies on user interaction (button click)—not automatic on status change.
Fails if Opportunity is closed via API, import, or automation without UI.
Adds unnecessary UI dependency and poor user experience.

📚 Reference:
Apex Triggers
Invoking HTTP Callouts
Process Limits

What latency is acceptable for orders to reach the fulfillment system?

Can the fulfillment system participate in idempotent design to avoid duplicate orders?

Explanation

When designing an integration from Salesforce to a fulfillment system for sending orders, an Integration Architect must analyze system constraints that directly affect data consistency, reliability, and performance. System constraints refer to technical limits or requirements that affect how two systems interact — such as latency, throughput, idempotency, and error handling. Among the given choices, two options stand out as system-level considerations that must be addressed early in the integration design.

✅ Correct Answers

✅ A. What latency is acceptable for orders to reach the fulfillment system?
Latency is a key system constraint in integration design — it defines how quickly Salesforce must deliver an order to the fulfillment system after it’s created or updated.
Knowing acceptable latency helps determine:
Whether to use synchronous (real-time) or asynchronous (batch or queued) integration patterns.
The appropriate integration technology, such as REST API (real-time) or Platform Events/ETL (asynchronous).
The impact on user experience and business SLAs.
Example:
If the business requires fulfillment updates in real-time, a low-latency REST callout might be required. If a few minutes’ delay is acceptable, middleware queueing or batch processing could be better.

✅ D. Can the fulfillment system participate in idempotent design to avoid duplicate orders?
Idempotency means that repeating the same request multiple times results in the same outcome — no duplicates, no inconsistencies. When integrating with external systems, duplicate message handling is a critical system constraint.
If the fulfillment system supports idempotent APIs or can handle unique order IDs gracefully, it prevents duplicate orders during:
Retry logic (due to transient failures)
Middleware replays
Salesforce reprocessing events
Example:
Salesforce might retry a failed order submission due to timeout; the fulfillment system must ensure duplicate prevention through idempotent behavior.

❌ Incorrect Options

B. Which system will validate order shipping addresses?
Reason:
While important for data governance and business logic, address validation is a functional design decision, not a system constraint. It deals with data responsibility, not system-level performance or behavior constraints.

C. Can the fulfillment system implement a contract-first Outbound Messaging interface?
Reason:
Outbound Messaging is a Salesforce-specific integration pattern, not a universal system constraint. This question is about technical compatibility or design choice, not about fundamental system behavior (like latency or idempotency). Also, in this scenario, the integration is from Salesforce to fulfillment system — Salesforce is sending, not the other way around.

Reference:
Salesforce Architects Guide: Integration Patterns
MuleSoft Integration Best Practices: “Design integrations considering latency tolerance, throughput limits, and idempotency requirements.”

Summary:
When designing the Salesforce-to-fulfillment system integration, consider:
➡ A. Acceptable latency — determines sync vs async processing.
➡ D. Idempotent design — prevents duplicates and ensures data integrity.