Free Salesforce-Platform-Integration-Architect Practice Test Questions 2026

Connect REST API

Explanation

The requirement is:
When a Chatter post with #thanksNTO is created → automatically post to Twitter.
This is a real-time, event-driven integration triggered by a Chatter feed item.

Why Connect REST API is the Right Choice
The requirement involves real-time detection of a Chatter post containing the #thanksNTO hashtag and automatically posting it to Twitter. This is a Chatter-driven, outbound social integration. The Connect REST API is specifically designed for such scenarios. It provides full access to Chatter feeds, feed items, and social publishing capabilities within Salesforce. Using this API, the integration can monitor feed activity, extract posts with the hashtag, and initiate cross-posting to external platforms like Twitter — all while maintaining user context and security.

How It Works in Practice
An Apex trigger on the FeedItem object listens for new Chatter posts. When a post includes #thanksNTO, the trigger uses Connect REST API endpoints (under /connect/) to retrieve the full post context, including author and community details. From there, a secure HTTP callout (via Named Credential) sends the content to the Twitter API. The Connect REST API ensures the action is user-aware and supports community-specific feeds, making it ideal for NTO’s custom mobile app interacting with Community Cloud.

Why Other Options Fail

REST API (B):
This is the general Salesforce REST API for CRUD operations on standard and custom objects. It does not provide native access to Chatter feeds or social publishing features. You’d need complex workarounds, making it inefficient and unsupported.

Streaming API (C):
Excellent for real-time notifications (e.g., PushTopic, Platform Events), it can alert when a Chatter post is made. However, it is inbound-only — it cannot post to Twitter. It’s a detection tool, not a publishing mechanism.

Apex REST (D):
This allows you to expose custom endpoints in Salesforce for external systems to call. It is inbound, not outbound. It cannot initiate a post to Twitter — it’s the wrong direction

Official References
Salesforce Help: Connect REST API Developer Guide
Trailhead: Integrate with External Social Networks

Exam Success Tip
For any integration involving Chatter + external social networks (Twitter, Facebook, etc.), the answer is always Connect REST API. It’s the only API that bridges Salesforce Chatter with third-party social platforms securely and natively.

Use Salesforce Connect to display the financial transactions as an external object.

Explanation

The core requirement is to allow community users to view their financial transactions, which are mastered in a high-volume, state-of-the-art core banking system processing 10 million transactions daily. The key architectural principle here is to avoid duplicating this massive, sensitive, and frequently updated data into Salesforce.

Let's evaluate the options:

A. Use Salesforce Connect to display the financial transactions as an external object.
This is the correct approach. Salesforce Connect with external objects implements a data virtualization pattern. It allows the community portal to display data that resides in the core banking system in real-time without storing a copy in Salesforce. The data is fetched on-demand when a user loads the page, ensuring they always see the most current information. This is ideal for high-volume, transactional data that is mastered elsewhere.

C. Use Salesforce External Service to display financial transactions in a community lightning page.
This is incorrect for this specific use case. External Services is designed to call external APIs (like REST endpoints) to execute actions or retrieve data that is then processed in Apex or Flows. It is excellent for invoking specific functions but is not the optimal tool for directly presenting a large, queryable list of transactional records in a standard UI. External Objects provide a much more seamless, native Salesforce experience for viewing and searching records.

D. Use Iframe to display core banking financial transactions data in the community.
This is incorrect and an anti-pattern. While technically possible, an iFrame creates a disjointed user experience that is not mobile-friendly and breaks the native look and feel of the community. More importantly, it introduces significant security complexities, as the core banking system would need to be directly exposed to the internet and manage its own authentication separately from the Salesforce community, which is a major security risk for a financial institution.

Key Concept
The key concept is Data Virtualization vs. Data Replication.
Data Replication (the alternative not listed):
This would involve building ETL jobs to copy the 10 million daily transactions into Salesforce objects. This is a poor choice as it creates data latency, consumes massive data storage, and introduces a complex synchronization overhead.
Data Virtualization (Option A):
This leaves the data in its source system (the core banking system) and provides a real-time, virtual "window" to it from within Salesforce. This ensures data is always current, avoids data duplication, and is perfectly suited for high-volume, externally mastered data that needs to be viewed in the Salesforce UI.

Reference
This recommendation is based on the official Salesforce integration pattern known as "Virtual Data Integration with External Objects." The Salesforce documentation for Salesforce Connect and External Objects explicitly supports this use case for providing real-time read-only (or read-write) access to data stored in an external system. This is the standard, supported method for building a unified customer view without replicating operational system-of-record data, which is a critical requirement in the financial services industry.

Remote Process Invocation-Fire and Forget

Explanation

The scenario involves a massive surge of concurrent workshop registrations through a Salesforce Community when the conference schedule opens. The external scheduling system is the authority on room capacity and availability, but Salesforce must accept submissions quickly without locking up the user experience.

Remote Process Invocation - Fire and Forget is the right pattern because:

Salesforce receives the registration and immediately fires an asynchronous message (via Platform Event, Outbound Message, or Queueable Apex) to the scheduling system.
It does not wait for a response, so the user gets instant acknowledgment (“Registration received”) and the UI stays responsive.
The external system processes capacity checks in the background at its own pace.
Once decided, the scheduling system can push confirmation or rejection back into Salesforce (e.g., via a REST callback—Remote Call-In).
This decouples the systems, avoids timeouts, respects governor limits, and scales under high load.

Why the other options are incorrect

A. Remote Process Invocation - Request and Reply
This is synchronous: Salesforce sends a request and waits for the reply. During a surge, long waits cause timeouts, user frustration, and Apex CPU or callout limit breaches. Not viable for high concurrency.

C. Batch Data Synchronization
This pattern moves data in bulk (e.g., nightly ETL via Data Loader or MuleSoft). It’s not real-time and cannot handle immediate, event-driven registration spikes.

D. Remote Call-In
This means an external system calls into Salesforce (e.g., via REST/SOAP API). Here, Salesforce initiates the call outward, so Remote Call-In is not the primary pattern. It may be used later for callbacks, but not to manage the initial surge.

Reference
Trailhead – Integration Patterns and Practices
Module: Choose the Right Integration Pattern
Link: https://trailhead.salesforce.com/content/learn/modules/integration-patterns-and-practices → Defines Fire and Forget as: “The invoking application sends a message and continues processing without waiting for a response.”
Salesforce Developer Documentation – Asynchronous Apex
Use Queueable, @future, or Platform Events for fire-and-forget callouts.
Queueable Apex

Recommended Flow
User submits → Community → Platform Event → Queueable Apex → HTTP Callout (Fire and Forget) → Scheduling System → (Later) REST callback to Salesforce (Remote Call-In) with status. Ready for the next question!

The endpoint URL has been added to Remote Site Settings.

Explanation

When a callout is made from a Lightning Web Component (LWC), the underlying Apex code that performs the HTTP callout is subject to Salesforce's strict security policies. The very first and most fundamental requirement for any Apex callout to an external service is that the endpoint's domain must be registered in the Remote Site Settings.

Why D is Correct:
Remote Site Settings is a security feature in Salesforce that explicitly whitelists external domains that Apex code is permitted to call. If the domain is not listed here, the Apex callout will fail immediately, regardless of any other configuration. This is the most common and first point of failure to check for any server-side callout from Salesforce.

Why A is Incorrect:
Cross-Origin Resource Sharing (CORS) is a browser-enforced security mechanism. It is relevant when a web application (like an LWC) running in a browser tries to call an API on a different domain. While the external endpoint might need CORS configured if called directly from the client-side JavaScript of the LWC, the question specifies a "callout from a Lightning Web Component," which, for external systems, is almost always done via an Apex method. Apex runs on the Salesforce server, not in the browser, so it is not subject to CORS policies.

Why B is Incorrect:
Content Security Policies (CSP) are also a browser-level security control. They define which resources (scripts, stylesheets, images, etc.) a browser is allowed to load. While CSP can be used to whitelist endpoints for certain directives like connect-src for client-side fetch/XMLHttpRequest calls, the primary and mandatory configuration for a server-side Apex callout is the Remote Site Setting. CSP is a secondary concern for direct client-side calls and is not a prerequisite for Apex.

Why C is Incorrect:
Outbound firewall rules are managed at the network infrastructure level by a company's IT team. While it's possible that a corporate firewall could block the callout, the Integration Architect's first validation should be within the Salesforce application itself. Remote Site Settings is the most likely and directly controllable cause within the Salesforce context. You would only investigate firewall rules after confirming that all Salesforce-side configurations (like Remote Site Settings) are correct.

Reference
This is a fundamental concept for Apex integration.
Salesforce Apex Developer Guide:
The documentation for making callouts explicitly states, "To make a callout to an external site, that site must be registered in the Remote Site Settings page, or the callout fails." This is a non-negotiable prerequisite.
Governance Limit:
This setting is also a key part of Salesforce's security and governance model, preventing Apex code from arbitrarily calling any external URL on the internet.

In summary, the logical troubleshooting steps are:

Check Remote Site Settings (The Salesforce server-side whitelist for Apex).
If the callout is made from client-side JavaScript (less common for external systems in LWC), then check CSP (The browser whitelist).
If both are correct, then investigate network-level issues like firewall rules.

Use middleware queuing and buffering to insulate Salesforce from system outages.

Explanation:

When integrating Salesforce with external systems, service availability cannot always be guaranteed. If the manufacturing system web-service goes down, the integration should gracefully handle outages without losing critical data. Here’s why option A is correct:

Middleware Queuing and Buffering:
Middleware platforms (like MuleSoft, Dell Boomi, or Informatica) can queue or buffer requests when the target system is unavailable.
Salesforce can continue sending messages to the middleware, and the middleware retries delivery once the external system is back online.
This decouples Salesforce from system downtime and ensures no data is lost.

Why not the other options?

B. Platform Event replayId and scheduled Apex:
Platform Events are great for event-driven integrations, but replaying events doesn’t solve the problem of callouts failing due to the target system being down.

C. @future and scheduled Apex retries:
This is a possible workaround for small-scale failures, but Apex retry logic is limited (governor limits, retries not guaranteed for long outages). It’s not suitable for multi-day outages.

D. Outbound Messaging retries:
Outbound Messaging only retries for a limited number of times over a short period (up to 24 hours). It won’t cover outages lasting several days.

Key takeaway:
For long-duration outages, middleware with queuing and buffering is the most reliable, scalable solution.

Reference:
Salesforce Architects Guide: Integration Patterns
Queue-Based Load Leveling Pattern: “Use a queue to decouple producers and consumers, enabling the system to handle temporary service outages without losing data.”

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.

Handle authentication in the code.

Explanation

When using a Named Credential with an Apex callout, authentication is configured within the Named Credential itself, not via separate login flows or external tools. The Named Credential acts as a container that securely stores the endpoint URL and authentication details. In the Apex code, you simply reference the Named Credential by name in the HttpRequest — no credentials are hardcoded or managed manually. Salesforce automatically injects the authentication (e.g., OAuth, Basic Auth, or Custom Header) at runtime.

Example:
apexHttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_Named_Cred/services/data/v60.0/query');
req.setMethod('GET');
Http http = new Http();
HttpResponse res = http.send(req);

Here, callout:My_Named_Cred tells Salesforce:
"Use the authentication defined in the Named Credential called My_Named_Cred."
Thus, authentication is handled in the (configuration of the) code — specifically, in the Named Credential setup, which is referenced in Apex.

Why the other options are incorrect

A. Handle authentication with login flows.
"Login flows" typically refer to user authentication in Experience Cloud (Communities) or Identity flows (e.g., OAuth Web Server Flow). While Named Credentials can use OAuth, the login/refresh is managed automatically by Salesforce, not via manual login flows in code. This option is misleading and incorrect.

C. Connect via Salesforce Connect.
Salesforce Connect is for external objects — it virtualizes external data as Salesforce objects using OData. It is not used for arbitrary Apex HTTP callouts. Completely different tool and pattern.

D. Connect via Communities.
Communities (Experience Cloud) are user-facing portals, not integration mechanisms. They have nothing to do with backend Apex callouts or Named Credentials.

Reference
Salesforce Help – Named Credentials"A named credential specifies the URL of a callout endpoint and its required authentication parameters in one definition... Salesforce manages all authentication for Apex callouts that specify a named credential as the callout endpoint."
Named Credentials

Apex Developer Guide – Using Named Credentials"To call an external web service, create a named credential with the endpoint URL and authentication details. Then reference it in your Apex code using callout:My_Named_Cred."
Named Credentials as Callout Endpoints

Trailhead – Apex Integration Services
Module: Use Named Credentials
Link: https://trailhead.salesforce.com/content/learn/modules/apex_integration_services/apex_integration_named_credentials

ESB (Mule) with cache/state management to return a requestID (or) response if
available from external system.

When responses are received by Mule, create a Platform Event in Salesforce via Remote-Call-In and use the empAPI in the lightning UI to serve 3,000 concurrent users.

Implement a 'Check Update' button that passes a requestID received from ESB (user action needed).

Explanation

A. ESB (Mule) with cache/state management to return a requestID (or) response if available from external system.

Why this is correct:
This is the foundation of the solution. When Salesforce makes a call, the ESB must immediately return a control flow (a requestID) instead of making Salesforce wait for the 90-second process. This allows the initial call to complete well within the 9-second timeout. The ESB acts as an asynchronous broker, managing the state of the long-running request with the backend systems. If the eligibility check is quick for some reason, it can return the response directly, optimizing for the happy path.

D. When responses are received by Mule, create a Platform Event in Salesforce via Remote-Call-In and use the empAPI in the lightning UI to serve 3,000 concurrent users.

Why this is correct:
This is the "push" mechanism for delivering the final result. Once the external system finally completes its 90-second processing, MuleSoft (using its credentials) calls into Salesforce to publish a Platform Event containing the requestID and the eligibility result. The Lightning UI uses the Empathy API (empAPI) to subscribe to these events. When the event with the matching requestID is received, the UI updates in real-time. This is highly scalable for 3,000 users as Platform Events and the empAPI are designed for high-volume, real-time user notifications.

E. Implement a 'Check Update' button that passes a requestID received from ESB (user action needed).

Why this is correct:
This provides a user-driven fallback or alternative to the real-time push mechanism. Networks or browser sessions can be unreliable. If the user misses the Platform Event (e.g., due to a lost connection), they need a way to manually retrieve the result. This button would call an Apex method that checks the final status (likely by querying a Salesforce object where results are stored or by making a new call to the ESB with the requestID). This ensures the solution is robust and user-friendly.

Why the Other Options are Incorrect

B. Recommend synchronous Apex call-outs from Lightning UI to External Systems via Mule and implement polling on API gateway timeout.

Why this is incorrect:
This is the opposite of what is needed. A synchronous call will hit the 9-second API Gateway timeout and fail every time. The external system takes 90 seconds, so waiting for it synchronously is architecturally impossible given the constraints. Polling after a timeout is a messy workaround and doesn't solve the fundamental problem.

C. Use Continuation callouts to make the eligibility check request from Salesforce from Lightning UI at page load.

Why this is incorrect:
Continuation callouts (also known as Long-Running Apex) are designed for synchronous callouts that last longer than the standard 10-second Apex transaction limit, extending it up to 120 seconds. However, they still require the client to hold the connection open and wait for a response.
The 9-second API Gateway timeout would still break this.
Making users wait 90 seconds on a loading screen is an unacceptable user experience.
Holding an Apex transaction open for 90 seconds for 3,000 concurrent users would catastrophically hit platform limits and could not scale.

Architecture Flow:
Request: UI calls MuleSoft, which instantly returns a requestID to avoid timeout.
Process: MuleSoft handles the slow backend process.
Notify: MuleSoft pushes the result back to the UI in real-time via Platform Events.
Fallback: A "Check Update" button provides a manual backup to fetch the result.

Named Credentials

Two way SSL

Explanation

Salesforce users need to read data from an external system via HTTPS. To ensure this integration is secure, an Integration Architect must choose security mechanisms that handle both authentication and data protection. The correct methods within Salesforce are Named Credentials and Two-Way SSL, which provide secure, scalable, and compliant integration practices.

✅ Correct Answers
✅ B. Named Credentials
Named Credentials provide a secure and centralized way to store authentication details (like usernames, passwords, OAuth tokens, or certificates) for external callouts.
They eliminate the need to hardcode credentials in Apex and automatically handle authentication for HTTPS requests.
Named Credentials also simplify endpoint management and enhance overall integration security.

Key Benefits:

Centralized credential management
Supports OAuth, JWT, Basic Auth, and custom authentication
Prevents exposure of sensitive data in code

✅ D. Two-Way SSL (Mutual Authentication)
Two-Way SSL ensures both Salesforce and the external system authenticate each other using digital certificates before data exchange occurs.
This mutual trust enhances the security of HTTPS callouts by confirming the identity of both the sender and the receiver.

Key Benefits:

Provides strong mutual authentication
Ensures encrypted and trusted communication
Ideal for highly sensitive integrations

❌ Incorrect Options
⚙️ A. Connected App
Reason:
Connected Apps are designed for inbound integrations — that is, when external systems access Salesforce using OAuth. In this scenario, Salesforce is the client making an outbound HTTPS request, so Connected App does not apply.

🚫 C. Authorization Provider
Reason:
Authorization Providers are used to define external identity providers for OAuth-based authentication into Salesforce. They are not used for securing outbound HTTPS requests from Salesforce to another system.

Reference:
Salesforce Help: Named Credentials
Salesforce Help: Configure Two-Way SSL Certificates

Summary:
To securely make outbound HTTPS requests from Salesforce:
➡ Use Named Credentials for secure credential and endpoint management.
➡ Implement Two-Way SSL for mutual authentication and encrypted communication.

Platform Shield Encryption

Explanation

The core requirements are:

Encrypt widely used standard fields.
Be able to use these encrypted fields in workflow rules (and other standard platform functionalities like search, validation rules, formula fields, etc.).
Platform Shield Encryption is the security solution designed to meet both of these requirements effectively.

Standard Field Encryption:
Shield Platform Encryption allows you to encrypt data at rest, including many standard fields (like Name, Phone, Email, etc.) and custom fields, while maintaining most application functionality.

Maintain Functionality:
Unlike Classic Encryption, Shield Platform Encryption supports using the encrypted fields in most standard features, including workflow rules, validation rules, formula fields, search, and Apex code, because the encryption is transparently managed by the platform.

❌ Why other options are incorrect:

A. Cryptography Class:
The Apex Cryptography class is for implementing encryption/decryption within custom Apex logic (e.g., encrypting data before sending it to an external system). It is not a solution for encrypting widely used standard fields and automatically having them work in platform features like workflow rules.

B. Data Masking:
Data Masking is a tool used to replace sensitive data with realistic dummy data, typically in sandboxes for development or testing purposes. It is not an encryption solution for production data to fulfill a runtime security requirement.

C. Classic Encryption:
Classic Encryption (the "Encrypt Text" custom field type) is limited. While it can encrypt data, fields encrypted with Classic Encryption cannot be used in many standard platform features, including:
Search or filters.
Workflow rules and Process Builder criteria.
Formula fields.
Therefore, Classic Encryption fails to meet the requirement of using the fields in workflow rules.

🌐 Reference
Salesforce Documentation: Shield Platform Encryption vs. Classic Encryption
Shield Platform Encryption: Encrypts data at rest, supports a wider range of standard and custom fields, and allows encrypted fields to be used in most standard platform features (including workflow rules).
Classic Encryption: Limited to a single custom field type, and prevents the use of the encrypted field in workflow rules and se

Create a custom object to store the file location URL, when community user clicks on the file URL, redirect the user to the on-prem system file location.

Explanation:

Why C is Correct:

The design files are 2.5 GB each — far exceeding Salesforce file size limits (max 2 GB for Files, but not practical for upload/download via UI or API due to governor limits).Files are stored in an on-premise file store already accessible by both internal users and third-party agencies.Community users (external) need view access — not necessarily upload or edit within Salesforce.

Solution C avoids moving or duplicating large files into Salesforce. Instead:

A custom object stores the file URL (e.g., \\fileserver\designs\banner1.psd or https://files.uc.com/designs/...).
Clicking the URL redirects the user to the on-premise system, which already handles authentication and access control.
This is lightweight, scalable, and leverages existing infrastructure.
This follows the "Remote System Access" integration pattern — ideal when data volume is high and real-time access via existing system is sufficient.

Why Others Are Wrong:

❌ A. Lightning component with Request and Reply pattern
Request/Reply is for real-time data calls, not large file transfers.Downloading 2.5 GB via a Lightning component would hit heap size (6–12 MB), API limits, and timeout errors.Not feasible for large binary files.

❌ B. External Data Source + Salesforce Connect + External Object
Salesforce Connect is for structured data (e.g., accounts, orders), not binary files.You cannot upload 2.5 GB files via Salesforce Connect.Even if possible, performance would be unacceptable in a community context.External Objects don’t support file streaming at this scale.

❌ D. Use Salesforce Files to link the files
Salesforce Files max size is 2 GB but, Uploading 2.5 GB files is not allowed.Even if under 2 GB, uploading from on-prem to Salesforce duplicates storage and creates sync issues.Syncing large files between on-prem and Salesforce is not supported via Files Connect or otherwise.Files Connect (for SharePoint, etc.) has severe size and performance limitations for external access.

References:
Salesforce File Size Limits
→ Salesforce Help: File Size Limits
→ “Maximum file size for upload: 2 GB” — 2.5 GB exceeds this.
Files Connect (for external file systems)
→ Trailhead: Files Connect
→ Supports SharePoint/OneDrive/Google Drive, but not arbitrary on-prem file servers, and large file access is slow/unsupported in communities.
Integration Patterns – Remote System Access
→ Salesforce Integration Patterns Whitepaper
→ Recommends URL-based access when data is large and already managed externally.
Community Cloud File Access Best Practices
→ Avoid embedding large file downloads in Lightning components or external objects.

Recommended Architecture (Summary):
textOn-Prem File Server ←→ Custom Object (File_URL__c) ←→ Community Page (Lightning Card with hyperlink)
Secure the on-prem share with VPN or SSO for external users.
Optionally use Salesforce Content Delivery or presigned URLs if HTTP access is enabled.

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.