Explanation:

The scenario involves a large surge of workshop registration requests when the conference schedule goes live. Attendees register through the Salesforce Community, and the external scheduling system must check/update room capacity.

Remote Process Invocation — Fire and Forget is the appropriate pattern because:

Salesforce can quickly accept the registration request and hand it off asynchronously (via Platform Event, Queueable Apex, outbound message, or middleware queue).

The Community user receives an immediate acknowledgment and is not blocked waiting for the scheduling system.

The external system processes capacity checks and reservations at its own pace, protecting both systems from being overwhelmed during the peak load.

This decouples the front-end experience from the back-end processing limits.

Why the other options are less suitable

A. Remote Process Invocation Request and Reply
This is a synchronous pattern. Every registration would hold an Apex transaction open while waiting for the scheduling system to respond. During a surge this risks concurrent long-running request limits, timeouts, and a poor user experience.

C. Batch Data Synchronization
Batch patterns are designed for bulk data movement on a schedule (or on-demand bulk loads). They are not suitable for interactive, user-driven registration requests that need near-real-time handling.

Key takeaway
When the business expects a high-volume surge of user-initiated requests and does not require an immediate synchronous response from the external system, prefer the Fire and Forget pattern to maintain scalability and responsiveness.

Explanation:

The requirements here are:

Encrypt standard fields (not just custom fields).
Fields must remain usable in record-triggered Flows (i.e., the encrypted data must still be usable/referenceable in automation, not just stored securely at rest).

Why Shield Platform Encryption is the correct solution:
Shield Platform Encryption is the correct solution because it:

Supports encryption of many standard fields (e.g., Account Name, Phone, Email, Address fields, and other widely-used standard fields), in addition to custom fields — this directly satisfies the requirement to encrypt "widely-used standard fields," which Classic Encryption does not support.
Uses probabilistic or deterministic encryption at the platform level, with encryption/decryption happening transparently as needed for authorized access.
Is designed to work with Salesforce automation tools including Flow, Process Builder, and Apex, allowing encrypted fields to still be used in record-triggered Flows, validation rules, and other business logic. Shield Platform Encryption is built to preserve platform functionality (search, workflow, and automation) as much as possible while protecting sensitive data at rest.
Provides enterprise-grade key management, audit trails, and compliance features appropriate for a company like NTO with sensitive data protection needs.

Why not the others:

B (Classic Encryption) — Classic Encryption (the older "Encrypted Custom Fields" feature) has significant limitations: it only supports custom fields (specifically custom text fields) — it cannot encrypt standard fields at all. Since the requirement explicitly calls for encrypting standard fields, Classic Encryption is disqualified outright. Additionally, Classic Encryption has historically had limited compatibility with automation tools like Flow and Apex (encrypted classic fields can't be used in most formulas, workflow rules, or many automation contexts), making it unsuitable even if standard field encryption weren't a blocker.

C (Data Masking) — Data Masking is a feature primarily used to obscure/anonymize sensitive data in sandbox environments (e.g., for development/testing purposes, so real production data isn't exposed to developers working in sandboxes). It is not a field-level encryption-at-rest security solution for production data, and it doesn't address the requirement to have usable, encrypted fields functioning within live record-triggered Flows in a production context. This is a fundamentally different use case (sandbox data anonymization vs. production field encryption).

Key exam takeaway:
When a requirement specifies encrypting standard fields (not just custom fields) while preserving usability in automation (Flow, Apex, etc.), the answer is Shield Platform Encryption — it's the Salesforce encryption solution designed to support standard fields while maintaining compatibility with platform functionality and automation. Classic Encryption is custom-field-only and has automation limitations; Data Masking is for sandbox data obfuscation, not production field-level encryption.

Reference:
Shield Platform Encryption Guide — "Encryption for Standard and Custom Fields" and "Compatibility with Automation Tools (Flow, Apex)."

Explanation:

The core requirement is to protect secrets (usernames, passwords, OAuth tokens) used in callouts from being exposed in plain text or accessible by unauthorized users/packages. The correct combination of Salesforce mechanisms for this is:

Named Credentials
This is the purpose-built Salesforce feature for securely storing authentication credentials (username/password, OAuth tokens, certificates) used in callouts. When you use Named Credentials, Salesforce encrypts and stores the credentials securely, and critically, Apex code and declarative tools never need to see or handle the actual credential values — you simply reference the Named Credential by name in your callout (callout:My_Named_Credential), and Salesforce injects the authentication automatically at runtime. This means credentials are never exposed in code, logs, or debug output, directly solving the "plain text secrets" vulnerability. Named Credentials also handle OAuth token refresh automatically, adding another layer of security/convenience.

Protected Custom Metadata Types
When secrets or configuration values need to be stored as metadata (e.g., supplementary configuration used alongside Named Credentials, or values referenced by managed/unmanaged package logic), marking the Custom Metadata Type as Protected ensures that subscriber orgs and other packages cannot directly query, view, or access the metadata records via SOQL or API — protecting it from being read or exposed by unauthorized package components. This is specifically relevant to the question's context of unmanaged package vulnerabilities, since "Protected" visibility controls access at the package boundary.

Together, these two mechanisms directly address the stated vulnerability: secrets are encrypted/hidden (Named Credentials) and configuration/metadata is shielded from unauthorized package-level access (Protected Custom Metadata Types).

Why not the others:

B (Encrypted Custom Fields and Protected Custom Settings)
Custom Settings are deprecated in favor of Custom Metadata Types for this kind of use case, and importantly, Custom Settings do NOT support a "Protected" visibility option the way Custom Metadata Types do — Custom Settings are generally accessible via Apex across the org without the same package-level protection mechanism. Additionally, Encrypted Custom Fields (Shield Platform Encryption) protect field-level data at rest but are not the purpose-built mechanism for storing callout authentication credentials — Named Credentials remains the correct, dedicated tool for that specific use case.

C (Named Credentials and Protected Custom Settings)
Named Credentials is correct here, but pairing it with Protected Custom Settings is problematic because, as noted above, Custom Settings don't support "Protected" status in the same robust way Custom Metadata Types do for package visibility protection. This makes the combination technically inconsistent with Salesforce's actual security model.

Key exam takeaway:
For protecting callout credentials/secrets, the answer almost always centers on Named Credentials (purpose-built, encrypted, hides secrets from Apex/logs). For protecting configuration data from unauthorized package/org access, use Protected Custom Metadata Types (not Custom Settings, which lack this protection mechanism). Remember: Custom Metadata Types support "Protected" visibility; Custom Settings do not.

Reference:
Salesforce Security Implementation Guide — "Named Credentials" and "Protect Custom Metadata Types."

Explanation:

The key distinction is record-sharing/record-access behavior among the different Streaming API event types.

Change Data Capture (CDC) does not support record-sharing access checks. Salesforce's event comparison specifically lists:

CDC: Record-sharing support = No
PushTopic: Record-sharing support = Yes
Platform Events: Not applicable in the same record-change sense
Generic Events: Not applicable

Therefore, B is correct.

Why A is incorrect

A. PushTopic Events can define a custom payload. ❌
PushTopic notifications are based on a SOQL query. The fields selected in the query determine the fields included in the notification. They don't provide the same user-defined custom payload capability as Platform Events.

For example:

SELECT Id, Name, Status__c FROM Account

The selected fields form the notification payload.

Platform Events, rather than PushTopics, are designed for custom event schemas and user-defined payloads.

Why C is incorrect

C. Change Data Capture can be published from Apex. ❌
CDC is automatically generated when changes occur to objects that are enabled for CDC. It isn't a custom event that you publish manually from Apex.

By contrast, Platform Events can be published through Apex. Salesforce explicitly lists Apex publishing as supported for Platform Events but not CDC.

Explanation:

Why C is correct:
When building custom client applications (such as mobile apps or web frontends) that require the exact look, feel, and behavioral styling of Salesforce Lightning Experience, the User Interface (UI) API is the definitive architectural choice. UI API is specifically engineered to return both data and metadata (including page layouts, field-level security, picklist values, and localized labels) in a single unified response. This allows developers to build high-fidelity native user interfaces that dynamically respect user permissions and org configuration without manually hardcoding layout rules.

Why A is incorrect:
Connect REST API is focused on specialized domain features such as Chatter, Experience Cloud (Communities), Files, and CMS content. It does not provide the comprehensive object-level layout and record-rendering metadata required to mirror standard Lightning Experience record pages.

Why B is incorrect:
While the standard REST API provides robust access to raw sObject records and data CRUD operations, it returns only data values without contextual layout metadata, requiring custom UI layers to manually reconstruct form fields, layouts, and field-level security constraints.

Reference / Best Practice:
Salesforce Pattern: User Experience Integration & UI API Architecture
Salesforce Documentation: User Interface API Developer Guide - Overview