Salesforce-Platform-Identity-and-Access-Management-Architect Practice Test
Updated On 10-Nov-2025
255 Questions
An Identity and Access Management (IAM) Architect is recommending Identity Connect to integrate Microsoft Active Directory (AD) with Salesforce for user provisioning, deprovisioning and single sign-on (SSO).
Which feature of Identity Connect is applicable for this scenario?
A. When Identity Connect is in place, if a user is deprovisioned in an on-premise AD, the user's Salesforce session Is revoked Immediately.
B. If the number of provisioned users exceeds Salesforce license allowances, identity Connect will start disabling the existing Salesforce users in First-in, First-out (FIFO) fashion.
C. Identity Connect can be deployed as a managed package on salesforce org, leveraging High Availability of Salesforce Platform out-of-the-box.
D. When configured, Identity Connect acts as an identity provider to both Active Directory and Salesforce, thus providing SSO as a default feature.
Explanation:
In this scenario, the Identity and Access Management (IAM) Architect is recommending Identity Connect for integrating Microsoft Active Directory (AD) with Salesforce to manage user provisioning, deprovisioning, and single sign-on (SSO).
One of the key features of Identity Connect is its ability to synchronize user account changes in near real-time from Active Directory to Salesforce.
Specifically, if a user is disabled or removed in AD, Identity Connect can immediately revoke that user's Salesforce session and disable the user in Salesforce as well.
This helps maintain security compliance by ensuring that deprovisioned users do not retain lingering access to Salesforce after their AD status changes. This behavior supports both operational efficiency and security enforcement.
The other options are incorrect:
B is incorrect because Identity Connect does not automatically disable users in a FIFO manner if license limits are exceeded. It respects license capacity and sync rules but does not force a FIFO deactivation logic.
C is incorrect because Identity Connect is not a managed package deployed in Salesforce; it is a separate on-premises middleware application installed and run outside of Salesforce, typically on a Windows server within the network that has access to AD.
D is incorrect because Identity Connect is not an Identity Provider (IdP). It is used for user provisioning and directory synchronization, and while it supports desktop SSO through integration with AD, it does not replace an IdP for broader SSO scenarios.
An identity architect has been asked to recommend a solution that allows administrators to configure personalized alert messages to users before they land on the Experience Cloud site (formerly known as Community) homepage.
What is recommended to fulfill this requirement with the least amount of customization?
A. Customize the registration handler Apex class to create a routing logic navigating to different home pages based on the user profile.
B. Use Login Flows to add a screen that shows personalized alerts.
C. Build a Lightning web Component (LWC) for a homepage that shows custom alerts.
D. Create custom metadata that stores user alerts and use a LWC to display alerts.
Explanation:
Why:
Login Flows run right after authentication and before landing on the site, and they can display screen content tailored by user/profile/criteria—all with low/no code configuration. This meets the requirement with the least customization.
Why not the others
A. Registration handler Apex: Code-heavy and only relevant for SSO/JIT flows; it doesn’t present UI screens.
C. LWC on homepage: Shows alerts after users land on the homepage, not before.
D. Custom metadata + LWC: Also requires custom code and displays post-landing.
Northern Trail Outfitters (NTO) is planning to roll out a partner portal for its distributors using Experience Cloud. NTO would like to use an external identity provider (idP) and for partners to register for access to the portal. Each partner should be allowed to register only once to avoid duplicate accounts with Salesforce.
What should a identity architect recommend to create partners?
A. On successful creation of Partners using Self Registration page in Experience Cloud, create identity in Ping.
B. Create a custom page m Experience Cloud to self register partner with Experience Cloud and Ping identity store.
C. Create a custom web page in the Portal and create users in the IdP and Experience Cloud using published APIs.
D. Allow partners to register through the IdP and create partner users in Salesforce through an API.
Explanation:
Northern Trail Outfitters (NTO) wants to:
Use an external Identity Provider (IdP) for authentication.
Enable partner self-registration for their Experience Cloud portal.
Ensure each partner registers only once, avoiding duplicate accounts.
The most robust and scalable solution is to:
✅ Let the IdP handle registration and identity creation,
then use Salesforce APIs to create the corresponding partner user record in Salesforce.
This approach ensures:
🔐 Centralized identity management in the IdP.
🔁 Synchronization between the IdP and Salesforce.
🚫 Prevention of duplicate accounts, since the IdP can enforce uniqueness.
⚙️ Automation of user provisioning using Salesforce APIs (e.g., REST or SCIM).
❌ Why the other options fall short:
A. Create identity in Ping after Salesforce registration: This reverses the flow and risks inconsistency or duplicate identities.
B. Custom page in Experience Cloud for dual registration: Adds complexity and may not enforce single identity creation.
C. Custom web page in the portal: Similar to B, but outside Experience Cloud — still risks fragmented identity management.
🔗 Reference:
Salesforce SCIM API for User Provisioning
External Identity and Experience Cloud Integration
Universal Containers (UC) is looking to build a Canvas app and wants to use the corresponding Connected App to control where the app is visible. Which two options are correct in regards to where the app can be made visible under the Connected App setting for the Canvas app? (Choose 2 answers)
A. As part of the body of a Salesforce Knowledge article.
B. In the mobile navigation menu on Salesforce for Android.
C. The sidebar of a Salesforce Console as a console component.
D. Included in the Call Control Tool that's part of Open CTI.
C. The sidebar of a Salesforce Console as a console component.
Explanation:
When Universal Containers builds a Canvas app, the app is packaged as a Connected App, and Salesforce provides several UI integration points where the app can be made visible to end users. The purpose of using a Canvas app is to embed a third-party web application directly into the Salesforce user interface in a seamless and secure manner.
One valid location is the Salesforce mobile navigation menu (✅ Option B).
Salesforce explicitly allows administrators to add Canvas apps to the mobile app navigation bar for both Android and iOS via the Connected App settings. This enables mobile users to launch and use the Canvas app from within the Salesforce mobile app, making this option officially supported.
Another supported location is the Salesforce Console sidebar (✅ Option C).
Canvas apps can be added as custom console components in apps like the Service Console or Sales Console. This lets the app appear alongside case records or other entities, helping agents access integrated functionality in the same workspace. This is a common use case for productivity tools, quoting engines, or external data systems embedded through Canvas.
On the other hand:
Option A (embedding a Canvas app inside the body of a Salesforce Knowledge article) is not supported. Knowledge articles allow rich text, images, and in some cases, Lightning components or Aura components—but Canvas apps are not supported inside article content.
Option D, which refers to the Open CTI Call Control Tool, is also incorrect. Although Open CTI allows for extensive integration with telephony systems and can display custom UI, it does not support embedding a Canvas app directly into the Call Control Tool. Instead, Open CTI uses its own JavaScript API, and integration is handled differently from how Canvas apps are embedded.
Universal Containers (UC) is using its production org as the identity provider for a new Experience Cloud site and the identity architect is deciding which login experience to use for the site.
Which two page types are valid login page types for the site? (Choose 2 answers)
A. Experience Builder Page
B. lightning Experience Page
C. Login Discovery Page
D. Embedded Login Page
C. Login Discovery Page
Explanation:
A: Experience Builder Page allows UC to create a custom-branded login page for the Experience Cloud site using Experience Builder, supporting tailored authentication.
C: Login Discovery Page enables dynamic routing to authentication methods (e.g., Salesforce IdP), ideal for flexible login flows in Experience Cloud.
Why Others are Incorrect:
B: Lightning Experience Pages are for internal Salesforce users, not Experience Cloud login.
D: Embedded Login Pages are for external apps, not Experience Cloud site login.
References
Salesforce Help: Login Pages
Salesforce Help: Login Discovery
| Page 1 out of 51 Pages |