Explanation:

Northern Trail Outfitters has a mobile application secured with OAuth that already interacts with Salesforce. The new requirement is to obtain GPS coordinates from the mobile device and store them in a custom geolocation field in Salesforce.

REST API Inbound Call from Mobile Device

The mobile app collects GPS coordinates locally.

It then makes a REST API call into Salesforce to update the geolocation field.

Since the field is secured with field-level security (FLS), users can view the value but not modify it directly in the UI. However, the integration user or API process can update the field.

This approach leverages the existing OAuth-secured integration and requires minimal additional customization.

Why not the other options?

A. REST Apex inbound call
Incorrect. Apex REST services are for exposing custom endpoints from Salesforce. Here, the mobile device should use the standard Salesforce REST API, not a custom Apex REST service, since the requirement is straightforward field update.

C. REST Apex callout call
Incorrect. Apex callouts are outbound from Salesforce to external systems. In this case, the mobile device is the one sending data into Salesforce, not the other way around.

Thus, the correct approach is for the mobile device to make a REST API inbound call to Salesforce to update the geolocation field.

Reference
Salesforce Docs: REST API Developer Guide
Salesforce Docs: Field-Level Security in Salesforce

Explanation:

When configuring a Salesforce Connect OData external data source, the Identity Type setting controls how Salesforce authenticates to the external system for each request. This is the primary security configuration for outbound requests to the OData producer.

The available Identity Type options are:

Named Principal: A single set of credentials is used for all Salesforce users accessing the external data source. This is appropriate for system-to-system integrations where the external system does not need to distinguish between individual Salesforce users.

Per User: Each Salesforce user must provide their own credentials for the external system. The external system can then enforce user-specific access controls and audit trails.

Anonymous: No authentication is used (typically only for publicly accessible OData endpoints).

For securing requests coming from Salesforce, the architect must select the appropriate Identity Type based on the organization's security model. If the external system needs to know which Salesforce user is making the request, Per User authentication is required. If a single integration account suffices, Named Principal is used.

Why the Other Options Are Incorrect

Option A (Configure Special Compatibility for OData connection): The "Special Compatibility" field is a specific setting used only for certain non-standard OData producers, such as Socrata open data portals. It is not a general security configuration for OData connections and does not control authentication or request security.

Option B (Configure CSRF Protection for OData connection): There is no "CSRF Protection" setting for OData external data sources in Salesforce Connect. CSRF (Cross-Site Request Forgery) protection is a concern for browser-based applications, not for server-to-server OData callouts made by Salesforce. This option describes a non-existent configuration.

Exam Focus Point
When a question asks about securing Salesforce Connect OData requests, the key configuration is the Identity Type (Named Principal vs. Per User) combined with the Authentication Protocol (Password, OAuth, etc.). These settings determine how Salesforce authenticates to the external OData producer and are the primary security controls for outbound requests.

Reference
Salesforce Help: Define External Data Sources for OData 2.0 or 4.0 Adapters (documents Identity Type and Authentication Protocol fields)
Salesforce Help: Define an External Data Source for the Salesforce Connect OData 4.01 Adapter

Explanation:

Why C is correct
This is a design and lifecycle consideration specific to platform events. Unlike custom objects, a deleted platform event definition is hard deleted: it does not go to a recycle bin and cannot be undeleted. Deleting it also removes its associated triggers and subscriptions' target, and the event messages already published are lost. An architect recommending platform events should plan for that, for example by controlling who has permission to delete event definitions, managing changes through source control and deployments, and testing changes in a sandbox first.

Why A is wrong
The statement is true of Event Monitoring, but Event Monitoring is a separate feature (event log files for logins, report runs, API calls, and so on). It is not a consideration when choosing platform events as an integration solution.

Why B is wrong
AssetTokenEvent is a real event, but it is a standard platform event used with Connected Apps and OAuth 2.0 to track authentication activity (the related security events are part of Real-Time Event Monitoring). Subscribing to it to monitor OAuth activity is a security monitoring use case, not a factor in deciding whether platform events are the right integration approach.

Other platform event considerations the exam tests
72-hour event retention, with replay IDs for catching up
Publish behavior (Publish After Commit vs. Publish Immediately)
Allocations for event publishing and delivery, and limits on concurrent subscribers
Delivery is at-least-once and asynchronous, so subscribers should be idempotent

Reference
Platform Events Developer Guide: Platform Event Considerations, Deleting Platform Events
Trailhead: Platform Events Basics

Explanation:

1. Why B is Correct (OAuth 2.0 Web Server Flow & Connected Apps for Multi-Org Packaging)

Secure Cross-Org Communication:
When a distributable package is installed across multiple distinct subscriber orgs ("spoke" orgs) and needs to communicate securely with a central "hub" org via custom Apex REST endpoints, it must authenticate using a robust delegation protocol rather than hardcoded credentials.

OAuth 2.0 Web Server Flow:
Setting up a Connected App in the central org enables the OAuth 2.0 flow. This allows the security team in the central org to maintain strict control over which specific subscriber instances can authenticate and interact with the central org.

Callback URLs:
Because each subscriber org has its own unique instance URL, configuring the appropriate callback URLs (redirect URIs) within the central org's Connected App ensures that the authorization code is accurately returned and handled after the target integration account is explicitly authorized post-installation.

2. Why the Other Options are Incorrect

A. Use an encrypted field to store the password:
Hardcoding or storing passwords/secrets in custom fields—even if encrypted—is considered an architectural anti-pattern and violates security compliance frameworks. Credentials should never be managed via manual password fields when standard token-based OAuth delegation is available.

C. Contact Salesforce Support and create a case to temporarily enable API access for managed packages:
API access is enabled by default across enterprise editions and standard package lifecycle models; contacting Salesforce Support is entirely unnecessary for standard API-based integrations.

Explanation:

The key requirement is that Salesforce users should be able to see the ERP order-processing stages such as:

Order Created
Order Shipped
Order Paid

within Salesforce during the event retention window.

For high-volume Platform Events and Change Data Capture events, Salesforce retains event messages for 72 hours (3 days). This allows subscribers to retrieve events that occurred during that retention period, including after a temporary disconnection.

Therefore, the architect should design around the 3-day retention period.

Why A is incorrect

A. High-volume event messages are stored for 24 hours (1 day). ❌
24 hours applies to legacy/standard-volume event types such as PushTopic and Generic Events. High-volume events are retained for 72 hours.

Why C is incorrect

C. ReplayID is used with a value of -1 to be able to see new events. ❌
ReplayId = -1 means the subscriber receives new events published after the subscription. It does not retrieve previously stored events.

To retrieve previously retained events, the subscriber needs an appropriate stored Replay ID. Salesforce documents -2 as the option to receive all retained events within the retention window, although it should be used carefully.