Important Salesforce Plat-Arch-204 Exam Questions

Answer: C

Explanation:

Managing identity across a global enterprise with diverse user personas (Employees, Customers, Partners) requires a centralized Identity and Access Management (IAM) strategy. In a landscape involving multiple local Active Directories, social logins (Google), and a central ERP system, attempting to manage authentication natively within Salesforce or through custom-built local silos would result in high technical debt and security vulnerabilities.

The architect should recommend a third-party Single Sign-On (SSO) solution, acting as a central Identity Provider (IdP). This IdP serves as the orchestration layer for all authentication requests.

For Internal Users: The IdP can federate with the various local Active Directories, allowing users to log in with their existing corporate credentials.

For Customers: The IdP can handle 'Social Sign-On' (OpenID Connect) with Google and manage self-registration.

For Partners: It provides the 'central system' required for their authentication.

By using a central SSO solution, Salesforce acts as a Service Provider (SP). When a user attempts to access Salesforce, the request is redirected to the IdP via the SAML 2.0 or OpenID Connect protocol. Once the IdP validates the user against the appropriate backend (AD, Google, or its own directory), it sends a secure assertion back to Salesforce to grant access.

Furthermore, this central IdP can facilitate access to the ERP system and other internal systems. If these systems support SAML, the same SSO session used for Salesforce can be extended to them, providing a true single sign-on experience. This architecture centralizes security auditing, simplifies user de-provisioning (the 'kill switch' effect), and ensures a consistent user experience across the global manufacturing landscape. Implementing a thir2d-party IdP is the industry-standard approach for complex integrations where security, scalabi3lity, and multi-protocol support are primary requirements.

Answer: A

Explanation:

For a requirement focused on synchronizing record updates from Salesforce to an external system in an event-driven and asynchronous manner, Change Data Capture (CDC) is the architecturally preferred solution over custom Platform Events.

CDC is designed specifically for data replication and synchronization. It automatically publishes change events for Salesforce records (Create, Update, Delete, and Undelete) to the event bus. Unlike Platform Events, which require manual publishing via Apex triggers or Flows, CDC is a low-code feature that requires only a simple activation for the Contact object in Setup. The external homegrown application can then act as a CometD subscriber, listening to the specialized /data/ContactChangeEvent channel to receive near real-time updates without the need for constant polling. Furthermore, CDC provides ordered, replayable events and an extended 72-hour retention window, ensuring that the homegrown application can recover missed updates using a Replay ID if it momentarily loses connection. This native broadcasting capability ensures data integrity across systems while breaking the tight coupling between Salesforce and the legacy application.

Answer: B

Answer: B

Explanation:

In a standard API-led connectivity model, the First Tier (Experience APIs) is responsible for tailoring data for specific systems of engagement.

The Experience APIs take the core data from the lower tiers and transform it into the specific return formats (e.g., JSON for mobile, XML for legacy web) and security protocols (e.g., OAuth for Salesforce, API Keys for web) required by each consumer. Option B correctly identifies that these transformations and security enforcements should happen at this outer layer. While an API Gateway (Option A) can provide generic security and rate limiting, it is the Experience API layer that provides the functional transformation and specific protocol requirements defined by the business needs of the engagement systems.

Answer: A

Explanation:

When dealing with high-volume data (1 million transactions per day) that does not need to be stored natively in Salesforce, the architect should recommend Data Virtualization via Salesforce Connect.

Salesforce Connect allows the company to display external data as External Objects. This approach provides several architectural advantages for a banking community:

No Data Storage: Transactions remain in the core banking system, avoiding the massive storage costs and complex synchronization logic required to house millions of records natively in Salesforce.

Real-Time Visibility: Because External Objects are queried on-demand via the OData protocol or a custom Apex adapter, customers see the most up-to-date transaction history every time they refresh the page.

While an Iframe (Option B) is technically possible, it is often discouraged due to security concerns (such as clickjacking) and a poor user experience, as the Iframe does not natively integrate with Salesforce UI components or reporting. Salesforce Connect provides a 'seamless' look and feel, allowing External Objects to be used in related lists and Lightning components just like standard Salesforce records, while keeping the heavy data burden on the performant core banking system.