Explanation:

This question addresses the configuration required to implement Two-Way SSL (Mutual TLS), where both the client and the server verify each other's identities through digital certificates. This is a critical security requirement for high-trust environments to ensure that only authorized systems can establish a connection with the company portal.

✔️ Correct Option: Enforce SSL/TLS Mutual Authentication
To satisfy the requirement, the architect must specifically Enforce SSL/TLS Mutual Authentication within the Salesforce security settings. This feature requires the client (the integrating system) to present a valid certificate that Salesforce validates against its trust store. Unlike standard one-way SSL, where only the server's identity is verified, mutual authentication provides an extra layer of security by ensuring that Salesforce also verifies the identity of the calling application before any data is exchanged.

❌ Incorrect Option: A. Enable My Domain and SSL/TLS
While My Domain is a prerequisite for many Salesforce identity features and SSL/TLS (One-Way) is standard for encrypting data in transit, simply enabling them does not satisfy the "mutual" requirement. Standard SSL/TLS only ensures the client trusts the Salesforce server. Without enforcing mutual authentication, the portal remains open to any client that trusts the Salesforce certificate, rather than strictly verifying the client's own certificate.

❌ Incorrect Option: C. Generate a certification authority (CA) signed certificate
Generating a CA-signed certificate is a necessary step in the process (to provide the identity used by Salesforce or the client), but it is not the recommendation that ensures integrations use mutual authentication. Having a certificate available does nothing to enforce its use during the handshake. The architect must recommend the administrative action of enforcing the protocol, rather than just the artifact of the certificate itself.

🔧 Reference:
→ Configure Certificate-Based Authentication
This documentation confirms the steps to enable and enforce mutual authentication for secure API and portal integrations.

→ Mutual Authentication for Web Services
This link validates how mutual TLS provides a higher level of security by requiring both parties to present certificates.

Explanation:

This question tests whether you can translate a vague integration requirement into concrete architectural drivers. The key missing detail in the requirement is how and when data should move between systems, which directly determines the integration pattern.

🟢 Correct Option:

C. Timing aspects, real-time/near real-time (synchronous or asynchronous), batch and update frequency
Integration architecture is primarily driven by data movement characteristics. Whether updates must happen instantly (real-time), shortly after (near real-time), or in scheduled batches determines the choice of APIs, middleware, and patterns like request-reply, event-driven, or bulk processing. Without defining timing and frequency, it is impossible to design a correct or scalable integration solution.

🔴 Incorrect options:

A. Core functional and non-functional requirements for User Experience design, Encryption needs, Community and license choices
These are important system design concerns, but they are not the primary drivers for selecting an integration pattern. UX and licensing decisions do not determine how systems exchange data.

B. Integration skills, SME availability, and Program Governance details
These are project execution and organizational concerns, not architectural requirements. They do not define how data synchronization between systems should technically occur.

🔧 Reference:
→ Integration Patterns Overview
Explains how timing (sync vs async, batch vs real-time) drives integration architecture decisions.

Explanation:

This question tests your ability to configure self-registration and SSO for Salesforce Community Cloud with an external IAM system. The IAM system supports both SAML and OpenId Connect. The requirement is to give new self-service customers instant access upon first login. This requires two components: an authentication provider to trust the IAM system’s identity, and a provisioning mechanism to create the user record automatically without manual admin intervention.

✔️ Correct Option:

✅ Option A (OpenId Connect Authentication Provider and Just-in-Time (JIT) provisioning) – OpenId Connect is supported as an authentication provider in Salesforce, allowing users to log in with external credentials . JIT provisioning automatically creates community users on the fly during first-time SSO login using attributes from the identity provider, eliminating the need for pre-creation .

❌ Incorrect Options:

❌ Option B (OpenId Connect Authentication Provider and Registration Handler) – While Registration Handler works for social sign-on (Facebook, Google) , it is not required for OpenId Connect with JIT. JIT provisioning handles user creation directly from the identity provider’s assertion without a separate registration handler class .

❌ Option C (SAML SSO and Registration Handler) – SAML SSO supports JIT provisioning natively , but pairing it with Registration Handler is redundant. Registration Handler is designed for social authentication providers, not SAML or OpenId Connect flows .

🔧 Reference:
→ Configure an Authentication Provider Using OpenID Connect – Explains that OpenID Connect is a supported authentication provider type for Experience Cloud sites.
→ RegistrationHandler Interface – Documents that Registration Handler is for third-party authentication providers like Facebook, not for SAML or OpenId Connect SSO with JIT.

Explanation:

The question tests your knowledge of the four Salesforce Streaming API event types and their key constraints. The architect must guide the developer to pick the right event type by understanding publishing methods, payload customization, and security/sharing behavior of each option.

✔️ Correct Option:

C. Change Data Capture does not have record access support.
Change Data Capture events are automatically published by the platform when DML occurs on supported objects and are delivered to all subscribers regardless of organization sharing rules. This means CDC bypasses record-level security and field-level security, so downstream systems receive changes for records a user might not normally see. Architects must consider this when compliance or data segregation is required.

❌ Incorrect options:

A. Change Data Capture can be published from Apex.
Change Data Capture events are system-generated only when Salesforce records are created, updated, deleted, or undeleted. You cannot fire CDC events from Apex. Only custom Platform Events support EventBus.publish() from Apex code.

B. PushTopic Events can define a custom payload.
PushTopic events are based on a SOQL query against an sObject. The payload always contains the fields specified in that query plus standard event headers. You cannot add arbitrary fields or custom structures. For custom payloads you must use Generic Streaming or Platform Events.

🔧 Reference:
→ What is Change Data Capture? Confirms CDC gets broad access to all data regardless of sharing rules and cannot be manually fired or customized like Platform Events.
→ Platform Events vs Streaming API Events Explains PushTopic events track sObject field changes and Generic events contain arbitrary payloads, while Platform Events provide granular customization.

Explanation:

This scenario focuses on integrating a massive, highly sensitive healthcare dataset with Salesforce while adhering to strict privacy and residency laws. Because identifiable patient data must remain in the secure database and cannot be stored permanently in Salesforce, the architecture must rely on real-time access and robust protection layers.

✔️ Correct Option: Callouts to RESTful services
The requirement states that identifiable prescriptions must reside only in the secure external database. Therefore, the Community Cloud portal must use Callouts to RESTful services to retrieve and display data on-demand without persisting it in Salesforce. This "view-only" approach ensures compliance with the policy that data exists only in the secure system while still making it available to authorized nurses, doctors, and patients.

✔️ Correct Option: Encryption in transit and at rest
To satisfy policies regarding data security and "pre-approved" access, the architect must enforce Encryption in transit and at rest. Encryption in transit (TLS/SSL) is mandatory for the RESTful callouts to protect data as it moves from the secure database to the portal. Encryption at rest ensures that any temporary data or de-identified datasets used by Einstein Analytics remain protected against unauthorized physical or logical access, meeting the company’s core security guidelines.

❌ Incorrect Option: Identity token data storage
Storing Identity tokens within Salesforce is a security risk and contradicts the "one-time use" nature of the tokens described. These tokens are meant to be generated and validated dynamically to authenticate users for a single session or action. Storing them in Salesforce would create an unnecessary vulnerability and does not align with best practices for short-lived, high-security identity management.

❌ Incorrect Option: Bulk load for Einstein Analytics
The prompt specifies that employees analyze de-identified data in Einstein Analytics. While bulk loading is a common way to get data into Analytics, the primary integration challenge here is the security and residency of identifiable data. Furthermore, the requirement for real-time, authorized access for doctors and patients is not solved by a bulk load, which is a batch-oriented process typically used for historical reporting rather than secure, per-patient clinical access.

🔧 Reference:
→ Salesforce Security Guide: Encryption
This link confirms the requirements for protecting sensitive data at rest and in transit to meet regulatory compliance.

→ Apex Callouts to External Services
Validates the use of RESTful services to integrate external data into Salesforce communities without local storage.