Salesforce Identity and Access Management Architect Practice Test

Correct answer: B. Federated authentication with SAML, where the identity provider authenticates the user and sends Salesforce a signed assertion asserting the result

Federated authentication is the pattern in which the password never reaches the service provider. The user authenticates at the identity provider, and Salesforce receives only a signed SAML assertion stating who the user is and that authentication succeeded.

Delegated authentication is the opposite: Salesforce accepts the password on its own login form and makes an outbound SOAP callout to a web service you host, passing the username, the password, and the source IP. The password demonstrably reaches Salesforce, so both delegated options fail the requirement. A login flow runs after authentication and cannot retroactively change what was transmitted.

Password synchronisation is not single sign-on at all — it creates a second credential store, which is the outcome the requirement is trying to avoid.

Exam section: Identity Management Concepts  ·  Difficulty: Easy

Correct answer: D. Salesforce is configured with the identity provider's issuer (Entity ID) and its signing certificate, so it can verify that the assertion was signed by that provider and is addressed to this org

Trust in SAML is certificate-based and one-directional for the assertion. You give Salesforce the identity provider's issuer value and its public signing certificate; Salesforce then validates the assertion's signature against that certificate and checks that the audience and recipient match this org's own service-provider values. Nothing else is required for Salesforce to accept the login.

Trusted IP ranges affect whether Salesforce asks for identity verification — they are not a trust anchor for assertions. There is no shared symmetric secret in SAML SSO settings, and a common public CA is not required at all: self-signed identity provider certificates are widely used, because Salesforce trusts the specific certificate you uploaded rather than a certificate chain.

Exam section: Identity Management Concepts  ·  Difficulty: Medium

Correct answer: C. Configure service-provider-initiated SAML — set the Identity Provider Login URL and request binding in the SSO settings — so Salesforce issues an AuthnRequest and the requested URL is preserved through RelayState

Deep linking is the classic reason to add service-provider-initiated SAML. When the flow starts at Salesforce, Salesforce records where the user was heading, redirects to the identity provider with an AuthnRequest, and restores the original destination from RelayState after the assertion comes back. Identity-provider-initiated flows start at the identity provider, which has no knowledge of the record the user clicked, so the user lands on the default page.

Telling users to log in first is a workaround, not a fix, and it fails the moment a link is clicked from a cold browser. The ACS URL is a single endpoint that receives assertions; it is not a list of destinations. Delegated authentication changes how credentials are validated and has no bearing on deep-link handling.

Exam section: Identity Management Concepts  ·  Difficulty: Medium

Correct answer: B. Set the SAML Identity Type to Federation ID and populate the Federation ID field on each user record with the employee number

The Federation ID exists precisely for this situation: it decouples the identifier your identity provider uses from the Salesforce username. Set Identity Type to Federation ID, populate the field on each user, and Salesforce resolves the assertion subject against that field instead of the username. The value must be unique across the org, and it is treated as case-sensitive — a mismatch in case is a common cause of single-user login failures.

Identity Location controls where in the assertion the identifier sits (the Subject's NameIdentifier element, or a named attribute); it does not change which field Salesforce compares against, so that option leaves the username mismatch unresolved. Renaming usernames is explicitly ruled out by the requirement. Using the Salesforce User ID couples the identity provider to record IDs that differ between production and every sandbox, so the configuration breaks on the next refresh.

Exam section: Identity Management Concepts  ·  Difficulty: Medium

Correct answer: D. The sandbox's My Domain and service-provider values differ from production, so the identity provider is still issuing assertions for the production audience and ACS URL — a sandbox-specific SSO configuration and identity provider entry are required

A refreshed sandbox gets its own My Domain, and therefore its own Entity ID and Assertion Consumer Service URL. An assertion is bound to a specific audience and recipient, so one issued for production will be rejected by the sandbox even though the certificate and issuer are correct. The fix is a separate connection: a sandbox application (or a sandbox-specific SSO setting) at the identity provider that targets the sandbox's own service-provider values.

The SSO configuration is copied by the refresh — that is exactly why it points at the wrong URLs. A certificate problem would produce a signature validation error, not an audience mismatch, and it would break production at the same time. A missing permission produces a per-user failure, not an audience mismatch. The SAML Assertion Validator naming the audience and recipient is the diagnostic that rules the other options out.

Exam section: Identity Management Concepts  ·  Difficulty: Hard

Correct answer: C. A provisioning tool — the identity provider's own Salesforce connector, or a general-purpose provisioning product — driving Salesforce's SCIM-based user provisioning, because it can create, update, and deactivate users independently of login activity

The requirement contains two clauses that eliminate just-in-time provisioning: deactivation and independence from login. Just-in-time provisioning is triggered by an assertion, so it only ever runs when a user signs in, and it has no mechanism to deactivate a user who has left. A push-based provisioning integration over SCIM handles the full lifecycle, including de-provisioning, and is what Salesforce points customers towards.

Just-in-time provisioning is still valuable, and it is common to combine the two — SCIM for lifecycle, just-in-time for keeping attributes fresh at login. A scheduled Data Loader job is brittle, has no real-time behaviour, and duplicates logic a provisioning product already implements. Self-registration is inappropriate for employees, where the directory is authoritative.

Note that Salesforce has announced the retirement of Identity Connect and is not building a replacement, so a new design for Active Directory sourced provisioning should be built on a third-party provisioning tool or the SCIM APIs rather than on Identity Connect.

Exam section: Identity Management Concepts  ·  Difficulty: Medium

Correct answer: A. Authentication proves who the user is (SAML, OAuth, OpenID Connect, or password plus multi-factor authentication); authorisation determines what they may do (profiles, permission sets, OAuth scopes, and connected app policies); accountability is the audit record (Login History, Identity Verification History, Setup Audit Trail, and event monitoring)

These are three distinct layers, and a complete identity design has to answer all three. It is worth being able to name the Salesforce feature that delivers each one, because governance boards ask “how do we prove it” as often as they ask “how do we control it”.

Profiles and permission sets are authorisation constructs, not authentication ones — they say nothing about how the user proved their identity. Organisation-wide defaults are part of the record sharing model, which sits underneath authorisation and is unrelated to authentication. Accountability is emphatically not authorisation: an org can be perfectly locked down and still be unable to answer who did what, which is the gap event monitoring and the audit trail exist to close.

Exam section: Identity Management Concepts  ·  Difficulty: Medium

Correct answer: B. At that user's record — a blank, duplicated, or differently-cased Federation ID (or an inactive user) means Salesforce cannot resolve the assertion subject to exactly one active user

The scope of the symptom is the diagnostic. A single user failing while everyone else on the same configuration succeeds points at per-user data, not at org-level configuration. The usual causes are an empty or duplicate Federation ID, a case mismatch in the Federation ID, or a user who is inactive or unlicensed. Login History records the specific SAML error for the attempt, and the SAML Assertion Validator will show the subject value the identity provider actually sent.

An expired certificate or a broken org-level SSO setting would fail for the entire population simultaneously, which contradicts the evidence. Modify All Data is an authorisation permission with no role in authentication; granting it would be a serious over-privilege and would not fix the login.

Exam section: Identity Management Concepts  ·  Difficulty: Hard

Correct answer: D. The identity provider host's clock has drifted, so the assertion's NotBefore and NotOnOrAfter validity window does not line up with Salesforce's view of the current time — synchronise the host to a reliable time source

A SAML assertion carries a short validity window, and Salesforce enforces it. If the issuing host's clock is ahead or behind, assertions arrive either not-yet-valid or already expired, which produces exactly this intermittent pattern — failures cluster around the edges of the window and disappear when the clock happens to be close enough. Pointing the identity provider host at a reliable NTP source is the fix.

Session timeout governs how long an established session lasts, not whether an assertion is accepted. Disabling signing is not a remedy and would remove the integrity guarantee that makes the trust model work. Trusted IP Ranges affect identity verification prompts, not assertion validity.

Exam section: Identity Management Concepts  ·  Difficulty: Medium

Correct answer: C. Salesforce is the service provider: configure a SAML Single Sign-On setting with the identity provider's issuer, signing certificate, identity type and location, then enable that setting on the My Domain authentication configuration

When another system authenticates the user and Salesforce consumes the result, Salesforce is the service provider. The configuration lives in Single Sign-On Settings, and the setting has to be exposed as a login option on the My Domain authentication configuration before users can actually use it — a step that is easy to miss and produces a working configuration that nobody can reach.

Enabling Salesforce as an Identity Provider is the opposite direction: it lets Salesforce assert identity to other applications. Delegated authentication does not make Salesforce an identity provider, and it still requires Salesforce to receive the password. An Auth. Provider of type Salesforce is used to accept identity from another Salesforce org, which is not what this scenario describes.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Easy

Correct answer: A. An Auth. Provider for Google (or a generic OpenID Connect provider) with an Apex class implementing Auth.RegistrationHandler, where createUser matches or creates the contact and user and updateUser keeps the record current on later logins

Social sign-on in Salesforce is implemented with an Auth. Provider plus a registration handler. The Auth. Provider handles the protocol exchange with Google; the Apex handler owns the identity decision — find the matching contact, create or update the user, assign the profile and permission sets. That is exactly where the “link to an existing contact” requirement is implemented.

SAML just-in-time provisioning applies to SAML identity providers; Google sign-in for consumers is an OAuth/OpenID Connect exchange handled through Auth. Providers. Self-registration creates a second credential store, which social sign-on exists to avoid. Delegated authentication requires the user to type a password into Salesforce, which defeats the purpose of federating to Google.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Medium

Correct answer: B. Provision on demand — accept the third-party identity and create the Salesforce user the first time the person actually signs in, using just-in-time provisioning or a registration handler, on an identity-oriented licence

At consumer scale, on-demand provisioning is the standard answer. It avoids creating and licensing millions of user records for people who may never sign in, and it keeps the created record aligned with what the identity provider actually asserts at the moment of first use.

Bulk pre-creation inflates the user population, complicates licence management, and creates a permanent reconciliation burden between two systems. Customer Community Plus is a role-based licence intended for external users who need broader functionality and sharing participation; assigning it to four million shoppers who mostly just log in is a costly over-provision. If a subset later needs case access, that is a licence upgrade for that subset, not a reason to over-license everyone.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Medium

Correct answer: D. Community just-in-time provisioning needs contact and account context, so the assertion must supply the required Contact (and where applicable Account) attributes alongside the User attributes — a missing required attribute causes the assertion to fail

An external user in Salesforce is not just a User record — it is a User linked to a Contact, which in turn belongs to an Account. Just-in-time provisioning for a community therefore requires the assertion to carry enough attribute data to establish or locate that chain, in addition to the user attributes that suffice internally. Missing a required attribute causes the whole assertion to be rejected rather than partially provisioning.

Just-in-time provisioning is supported for Experience Cloud, and self-registration is an alternative rather than a requirement. Delegated authentication is unrelated to provisioning and would not resolve a missing-attribute failure.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Hard

Correct answer: C. Login History for the who, when, where, and login type; Identity Verification History for step-up and verification events; and, where the org is licensed for event monitoring, the login event objects together with Transaction Security policies for real-time response

Login History is the primary record of authentication attempts, including the source IP, the application, the login type, and the status — which distinguishes a SAML login from a password login. Identity Verification History covers verification and step-up events. Event monitoring adds queryable login event data, and Transaction Security policies act on events as they occur, which is what the alerting requirement needs.

The Setup Audit Trail records configuration changes, not logins. Debug logs are a development tool with limited retention and enormous volume — entirely unsuitable as a security audit source. Field History Tracking records changes to field values on a record, which tells you nothing about authentication.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Medium

Correct answer: A. Two SAML single sign-on settings, with both of them and the Salesforce login form enabled on the My Domain authentication configuration; identifier-first login discovery can then route each user to the correct method

An org can hold multiple SAML single sign-on configurations, and the My Domain authentication configuration controls which of them (plus the standard login form) are offered. That covers all three populations in one org. Adding login discovery improves the experience: the user types an identifier, and a handler decides which authentication method applies rather than presenting a menu of buttons.

The premise that only one identity provider is possible is wrong, which invalidates both the consolidation answer and the delegated-authentication workaround. Splitting into two orgs to solve an authentication problem imposes a permanent data and integration cost for something the platform already supports.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Medium

Correct answer: B. It is a legitimate fallback when federation is genuinely impossible, but Salesforce receives the password and makes an outbound callout to your endpoint with the username, password, and source IP, so the endpoint must be highly available and hardened, and it is enabled per user through the single sign-on user permission rather than org-wide

Delegated authentication is the pattern of last resort. Two properties drive the design: Salesforce handles the password, and the login path now depends on your web service. If that endpoint is slow or down, affected users cannot log in at all, so availability and latency become authentication requirements. It is granted through the single sign-on permission on a profile or permission set, which is why it can be scoped to the population that needs it.

It is not a sensible org-wide default when SAML is available. It does not satisfy or replace multi-factor authentication — the external service returns a simple pass or fail and asserts nothing about factors. And Salesforce continues to host the login page in this pattern, so My Domain remains relevant.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Hard

Correct answer: D. Login discovery on the login page, with a Login Discovery Handler Apex class that inspects the identifier and routes the user to the appropriate authentication method

Login discovery is the identifier-first pattern: the page asks for an email address, phone number, or other identifier, and an Apex handler decides what happens next — redirect to an identity provider, prompt for a password, or send a one-time passcode. That is precisely the requirement.

Separate URLs work but push the routing problem onto the user and break down as soon as someone bookmarks the wrong one. A row of buttons is the experience the requirement explicitly rejects. Delegated authentication only validates a password that has already been typed into Salesforce; it cannot redirect a user to a federated identity provider.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Medium

Correct answer: C. Investigate which session policies are forcing the challenge — typically a profile-level or connected app requirement for a High Assurance session, or a session security level that does not credit the SSO login method — rather than weakening the multi-factor requirement

When single sign-on is in use, the multi-factor requirement can be satisfied at the identity provider — Salesforce trusts the authentication described in the assertion. So an unexpected challenge is a configuration signal: something in the org is demanding a higher assurance level than the SSO login method has been credited with. Session security levels, the High Assurance requirement on a connected app, and the profile setting that requires a session security level at login are the places to look.

Disabling multi-factor authentication org-wide is the wrong direction and undermines a contractual and security baseline. Login IP Ranges restrict where users may log in from; they are not an assurance-level exemption.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Medium

Correct answer: A. Disabling the directory account stops new interactive logins but does not invalidate tokens already issued, so offboarding must also freeze or deactivate the Salesforce user and revoke the OAuth tokens — a refresh token keeps working until it is revoked, the user is deactivated, or the connected app policy expires it

This is the single most consequential gap in SSO-only offboarding. Single sign-on governs new authentication. An OAuth refresh token is a separate, already-granted credential that the mobile app exchanges for access tokens directly with Salesforce — the identity provider is not consulted. The runbook therefore needs both halves: disable at the directory, and deactivate or freeze the Salesforce user and revoke tokens.

There is no automatic 24-hour expiry; the default refresh token policy is that the token remains valid until it is explicitly revoked. A password reset is not the mechanism to rely on either, particularly in an SSO org where the user may have no Salesforce password at all. Revoking from the user's Connected App access, the connected app's OAuth usage page, or the token revocation endpoint is the direct control, and a suitable refresh token policy limits exposure in advance.

Exam section: Accepting Third-Party Identity  ·  Difficulty: Hard

Correct answer: B. The JWT bearer flow, using a certificate whose public key is uploaded to the connected app, with Permitted Users set so the integration user is pre-authorised

The JWT bearer flow is the standard server-to-server pattern. The client signs a JSON Web Token with its private key; Salesforce validates it against the certificate on the connected app and issues an access token with no user interaction and no password anywhere. It requires the connected app to pre-authorise the user — typically by setting Permitted Users to admin-approved and assigning the app through a profile or permission set.

The username-password flow is discouraged, is blocked by default in newer orgs, and stores exactly the credential the requirement forbids. Driving a headless browser through an interactive flow is fragile and defeats the purpose of having a server-to-server grant. The device flow needs a human at a second device, which contradicts an unattended nightly job.

Exam section: Salesforce as an Identity Provider  ·  Difficulty: Medium

Correct answer: D. The authorisation code flow with PKCE, where the client sends a code challenge and later proves possession with the verifier, so a public client can complete the code exchange safely

PKCE (Proof Key for Code Exchange) exists to make the authorisation code flow safe for clients that cannot keep a secret. The client generates a random verifier, sends its hash as the code challenge with the authorisation request, and presents the verifier when redeeming the code — so an intercepted authorisation code is useless on its own. This is now the recommended pattern for browser and mobile clients, in place of the older user-agent (implicit) flow that returned tokens in the URL fragment.

Anything shipped inside a distributed application — a client secret or a private key — must be treated as public, so both of those options are broken by construction. The client credentials flow authenticates the application rather than the person, so it cannot represent an end user.

Exam section: Salesforce as an Identity Provider  ·  Difficulty: Medium

Correct answer: C. The device flow: the scanner displays a short user code and a verification URL, the user completes login on a phone or PC, and the scanner polls the token endpoint until the authorisation is granted

The device flow (OAuth device authorisation grant) exists precisely for input-constrained devices. Authentication happens on a capable second device, and the constrained device only ever displays a code and polls for the result — it never handles the credential.

A user-agent flow needs a real browser with redirect handling, which the scanner does not have. Typing credentials on a numeric keypad is both impractical and reliant on a discouraged flow. Asset tokens are for identifying devices and connected products rather than for authenticating a person at a keypad.

Exam section: Salesforce as an Identity Provider  ·  Difficulty: Medium

Correct answer: A. The openid scope, which is what causes Salesforce to return an ID token, plus email and profile as needed — and refresh_token or offline_access only if long-lived access is required

An ID token is an OpenID Connect artefact, and Salesforce issues one only when the openid scope is requested. The application can then validate it against the keys published at the org's OpenID Connect discovery document and, if it needs more claims, call the UserInfo endpoint. The email and profile scopes control which claims are available.

The full scope grants broad access to everything the user can do — it is not the mechanism that produces an ID token, and requesting it for a sign-in use case is a significant over-grant. The api and web scopes concern data and UI access. The custom_permissions scope returns the user's custom permissions in the token; it does not create an ID token.

Exam section: Salesforce as an Identity Provider  ·  Difficulty: Hard

Correct answer: C. Expire the refresh token if it has not been used for a set period, which lapses idle devices without forcing active users to re-authenticate on a fixed schedule

The requirement describes an inactivity-based expiry, and that is exactly what the “expire if not used for” policy provides. Active users are never interrupted, while a device that goes quiet loses its access automatically — which is the practical control for lost or decommissioned handsets.

“Valid until revoked” leaves indefinite access on a device nobody is tracking. Immediate expiry forces a full interactive login on every launch, which field users will not tolerate. Session timeout governs the lifetime of an access session, not the refresh token, so shortening it produces constant re-prompting without addressing the idle-device risk.

Exam section: Salesforce as an Identity Provider  ·  Difficulty: Medium

Correct answer: B. The api scope, adding refresh_token only if a long-lived token is genuinely required

api is the scope that grants data access through the APIs, and nothing more. Adding refresh_token (or its synonym offline_access) is a separate decision about token lifetime. That pair is the minimum that satisfies the requirement.

It is true that profiles and permission sets still apply, but scopes are a second, independent boundary, and the whole point of least privilege is that a leaked token should be able to do as little as possible. The full scope grants everything the user can do, and web or visualforce scopes add the user interface access the requirement explicitly rules out. Bundling openid with full compounds the over-grant rather than reducing it.

Exam section: Salesforce as an Identity Provider  ·  Difficulty: Hard

Correct answer: D. Enable Salesforce as an identity provider (which requires My Domain and an identity provider certificate), create a connected app with SAML enabled — Entity ID, ACS URL, subject type, and Name ID format supplied by the HR vendor — and assign the app through a profile or permission set so the tile appears

Outbound single sign-on means Salesforce is the identity provider and the HR system is the service provider. That is enabled under Identity Provider setup and then expressed per application as a connected app with SAML enabled. Assigning the connected app is what makes the tile visible in the App Launcher.

Single Sign-On Settings configure the inbound direction, where Salesforce consumes assertions — the opposite of this requirement. Auth. Providers also handle inbound identity. Delegated authentication is an inbound password-validation pattern and is unrelated.

Exam section: Salesforce as an Identity Provider  ·  Difficulty: Medium

Correct answer: A. Set the connected app's IP relaxation to relax IP restrictions — or to enforce them for the initial authorisation but relax them for token refresh — so the exception is scoped to that application rather than to the org or the profile

A connected app has its own IP relaxation setting, and that is the correct place to make an exception for one integration. It leaves the profile restriction intact for interactive logins. The middle option — enforce for authorisation, relax for refresh — is a useful compromise when the initial authorisation happens from a known location but the refresh may come from elsewhere.

Removing the profile restriction weakens the control for every user on that profile. Trusted IP Ranges are a different control: they suppress identity verification prompts for logins from those addresses, but they do not override profile login IP ranges. Modify All Data is an authorisation permission and has no effect on login restrictions.

Exam section: Salesforce as an Identity Provider  ·  Difficulty: Hard

Correct answer: C. Revoke the token at the OAuth revocation endpoint, or revoke the application's access from the connected app's OAuth usage page or the user's connected app access list; and use the token introspection endpoint to check whether a given token is still active

Salesforce exposes both halves of this: a revocation endpoint for killing a token, and an introspection endpoint for asking whether a token is still valid. Administratively, the connected app's OAuth usage view and the user's connected app access list both allow revoking an application's access without touching the app definition.

Rotating the consumer secret affects new authorisations, not tokens already issued, so it does not achieve immediate termination. Deactivating the user is effective but disproportionate when the goal is to stop one application. Deleting the connected app is destructive, affects every user of that app, and discards the configuration and audit context.

Exam section: Salesforce as an Identity Provider  ·  Difficulty: Medium

Correct answer: B. SMS and email one-time codes are identity verification methods used for things like device activation, and are not accepted as a multi-factor authentication factor; the accepted methods are the Salesforce Authenticator app, third-party time-based one-time password apps, security keys, and built-in platform authenticators such as fingerprint or face recognition

This is a distinction the exam and real projects both care about. Salesforce treats email and SMS codes as identity verification — used when a user logs in from an unrecognised browser or device — and does not count them as a multi-factor authentication factor, because both channels are susceptible to interception and account-takeover attacks.

Third-party authenticator apps that implement time-based one-time passwords are accepted, so restricting the answer to Salesforce Authenticator is wrong. And when single sign-on is in use, the requirement can be satisfied at the identity provider — that is a normal and supported design, not a prohibited one. Always confirm the current list of accepted methods in Salesforce Help before committing a design, since the guidance is updated over time.

Exam section: Access Management Best Practices  ·  Difficulty: Medium

Correct answer: D. Raise the session security level of the multi-factor login method to High Assurance in Session Settings, then require a High Assurance session on the connected app, so a lower-assurance session triggers a step-up prompt instead of a refusal

Session security levels are how Salesforce expresses assurance. Each login and verification method maps to a level, and resources — connected apps, reports and dashboards, and individual profiles at login — can require High Assurance. The behaviour the requirement asks for is exactly what the platform does: a user in a Standard session who reaches a High Assurance resource is prompted to raise their session rather than being turned away.

Profile and permission set gymnastics approximate the outcome but encode a session property as a static assignment, which drifts and cannot react to how the user authenticated in this particular session. IP ranges control location, not assurance.

Exam section: Access Management Best Practices  ·  Difficulty: Medium

Correct answer: A. A login flow — a screen flow that runs after authentication and before the landing page, assigned to those profiles, which can collect consent, force verification-method registration, or block the session

Login flows are designed for this: they interpose a screen between successful authentication and the user's landing page, they are assigned by profile, and they can gather consent, enforce registration of a verification method, present terms, or end the session. That matches every clause in the requirement.

Validation rules fire on record save and cannot interrupt a login. An Apex trigger has no ability to control the user's browser session. Transaction Security policies act on events to block, freeze, or require verification, but they are not a mechanism for presenting a consent screen and capturing a response.

Exam section: Access Management Best Practices  ·  Difficulty: Medium

Correct answer: C. Send the entitlement attributes in the assertion and map them during just-in-time provisioning or in a registration handler, while accepting that this only runs at login — so pair it with push-based provisioning or a scheduled reconciliation for users who do not sign in

Attribute-driven authorisation is the right pattern, and the important architectural caveat is the trigger: an assertion only arrives when someone logs in. A user who stops logging in keeps yesterday's entitlements, which is a real audit finding. So the design pairs login-time mapping with a push mechanism — SCIM-based provisioning from the identity provider, or a scheduled job that reconciles assignments against the directory.

A single hard-coded profile cannot express differentiated entitlements. Quarterly manual review is precisely the control failure the requirement is trying to eliminate. Sharing rules govern record-level access and cannot grant permission sets.

Exam section: Access Management Best Practices  ·  Difficulty: Hard

Correct answer: B. Login History for the time, source IP, application, login type, and status; Identity Verification History for verification and step-up events; and the Setup Audit Trail for the configuration changes that followed

Each question maps to a specific source. Login History answers when, where, and how. Identity Verification History covers the verification events around that login. The Setup Audit Trail answers what changed in configuration and by whom. Where the org is licensed for event monitoring, login event data and event log files add depth and longer retention.

Debug logs are short-lived and not an audit source; Field History Tracking records field changes on records, not logins. The sharing hierarchy explains record access, and Health Check scores security settings against a baseline — neither answers an authentication question. OAuth usage covers connected app access only.

Exam section: Access Management Best Practices  ·  Difficulty: Medium

Correct answer: D. Permitted users, IP relaxation, the refresh token policy, the session timeout and High Assurance requirement for the app, and the OAuth scopes and callback URL

Those are the levers a connected app gives you, and they matter because they let an integration be governed independently of the org-wide baseline — a tighter refresh token policy for one app, or an IP exception for another, without changing anything for interactive users.

Password policies, profile login IP ranges, and login hours are org and profile settings. Organisation-wide defaults belong to the record sharing model and have nothing to do with connected apps.

Exam section: Access Management Best Practices  ·  Difficulty: Medium

Correct answer: A. Transaction Security policies, part of real-time event monitoring, which evaluate events as they occur and can block the action, require multi-factor verification, freeze the user, or notify

The distinguishing requirement is mid-session enforcement. A report export happens long after login, so any login-time control is structurally incapable of catching it. Transaction Security policies subscribe to platform events as they occur and can take an action, which is what “as they happen” requires.

A login flow only runs at authentication time. Validation rules apply to record saves; reports are not records being saved. Session timeouts and IP ranges are blunt, login-time controls that neither detect the export nor prompt for step-up.

Exam section: Access Management Best Practices  ·  Difficulty: Hard

Correct answer: C. Identity Connect's use case was exactly that, but Salesforce has announced its retirement and is not building a replacement, so a new design should use the identity provider's own Salesforce connector or a general-purpose provisioning product working through Salesforce's SCIM-based user provisioning APIs

Identity Connect was an on-premises component that synchronised Active Directory users into Salesforce and could also provide single sign-on. Salesforce has published its retirement and stated that no replacement is being built, pointing customers instead at their identity provider's own Salesforce connector, general-purpose provisioning products, and the SCIM APIs. For a new design, that makes it the wrong foundation regardless of its historical fit.

It was never mandatory, and it did not remove the need for a federation configuration — single sign-on still relied on the standard SSO settings. Because retirement timelines and recommended alternatives change, verify the current position in Salesforce Help before advising a client.

Exam section: Salesforce Identity  ·  Difficulty: Medium

Correct answer: B. Salesforce Identity licences, which provide identity services to employees — single sign-on, App Launcher access, and connected app provisioning — without full CRM object access

The Salesforce Identity licence exists for internal users whose relationship with Salesforce is identity rather than CRM: federate out to third-party applications, receive an App Launcher tile, and have their accounts in those applications provisioned from Salesforce.

A Platform licence is a broader and more expensive grant aimed at custom application users. External Identity and Customer Community licences are for external users — customers and consumers — and are not appropriate for employees. Licence entitlements and included quantities change, so confirm the current terms with Salesforce before sizing.

Exam section: Salesforce Identity  ·  Difficulty: Medium

Correct answer: D. External Identity, which is scoped and sized for consumer-scale identity with limited data access, moving to a community licence only if those users later need service functionality

External Identity is the consumer identity option: registration, login, profile and consent management, with deliberately limited access to data. That matches the requirement precisely and at a very different price point from a community licence at millions of users.

Customer Community Plus and Partner Community are role-based licences intended for external users who participate in sharing and use community functionality — buying that capability for millions of users who only log in is a major over-provision. The guest user is unauthenticated by definition and cannot represent a registered customer with a profile and consent record. Because the exact object and functionality entitlements attached to each licence change over time, confirm them in the current licence documentation before finalising a design.

Exam section: Salesforce Identity  ·  Difficulty: Hard

Correct answer: A. Embedded Login, which renders the Salesforce-hosted login experience inside the external page through a JavaScript include and a connected app, so credentials are handled by Salesforce

Embedded Login is the feature for exactly this shape of requirement: an inline experience on a non-Salesforce page, where the login itself is still served and processed by Salesforce.

Redirecting works but fails the “inline” requirement. Reproducing the login form on an external site and posting credentials to Salesforce is a credential-harvesting anti-pattern — it puts the password in the hands of the external application, which is what the requirement forbids, and it breaks as soon as multi-factor authentication or a verification step is involved. Delegated authentication inverts the trust in the wrong direction. If the team needs total control of the interface rather than an embedded Salesforce experience, the Headless Identity APIs are the right alternative.

Exam section: Salesforce Identity  ·  Difficulty: Medium

Correct answer: C. It depends on where the identity of record belongs: if a dedicated platform already authenticates the consumer across channels, Salesforce should accept that identity as a service provider and keep the CRM contact as the profile record; Salesforce Identity for customers is the right choice when Salesforce owns the login and the surrounding experience

The architectural question is ownership of the identity of record, not which product is more capable. When another platform is already the authentication authority for most channels, adding a second one fragments the consumer's experience and creates two places to reset a password. Salesforce accepting that identity keeps one login while still owning the contact and consent data.

“Always” answers are a warning sign at architect level. Synchronising credentials between two stores is a security anti-pattern: it doubles the attack surface and guarantees drift. Delegated authentication does not create dual authority — it just routes a password Salesforce has already received to an external validator.

Exam section: Salesforce Identity  ·  Difficulty: Hard

Correct answer: B. The Headless Identity APIs — headless registration, login, passwordless login, and forgot-password endpoints — against an Experience Cloud site and connected app, so the application owns the interface while Salesforce owns the credentials and tokens

The Headless Identity APIs exist for native and fully custom experiences: the application calls Salesforce endpoints directly for registration, login, passwordless login, and password recovery, and receives tokens back. No Salesforce-rendered page appears in the flow, which is the requirement.

A customised community login page and Embedded Login both still render Salesforce-hosted content, which the requirement rules out. Having the mobile app validate the passcode itself would move the credential decision into a distributed client — the opposite of what a sound identity design does.

Exam section: Salesforce Identity  ·  Difficulty: Medium

Correct answer: D. The site's own SAML configuration or Auth. Provider must be enabled on that site's login and registration settings, because each site controls which authentication options it exposes and can offer more than one

Each Experience Cloud site has its own login and registration configuration, and an identity provider only appears as an option for that site once it is selected there. This is a frequent cause of “the configuration is correct but nobody can use it”. A site can expose several options at once — one or more identity providers, social sign-on, and the standard login form.

Org-level settings do not propagate automatically to sites. SAML is fully supported for sites, alongside Auth. Providers. And a single org can serve multiple sites with different identity providers, so a second org is unnecessary.

Exam section: Community (Partner and Customer)  ·  Difficulty: Medium

Correct answer: A. Sharing sets, which grant high-volume users access to records related to their account or contact, together with a share group to give internal users access to records owned by those high-volume users

High-volume community users have no role, which means they cannot be referenced in the role hierarchy or in sharing rules. Salesforce provides two purpose-built mechanisms instead: a sharing set to grant those users access to records related to their account or contact, and a share group to give internal users access to records those high-volume users own.

Sharing rules are unavailable to this population for the reason above. Trigger-driven manual sharing is a maintenance and volume liability at community scale. Raising the external default to public read/write would expose every customer's records to every other customer — a severe data breach in a multi-tenant community.

Exam section: Community (Partner and Customer)  ·  Difficulty: Hard

Correct answer: C. Keep open self-registration off and provision partner users from the account and contact records, or use a self-registration handler combined with an approval process, so the account linkage and role assignment stay controlled

Partner users are role-based and inherit a position in the account's external role hierarchy, so which account they are attached to directly determines what they can see. That makes uncontrolled creation risky, and it is why enabling a partner user from the contact record — or running a self-registration handler that resolves the correct account and then routes through approval — is the right pattern.

Open self-registration cannot enforce the approval requirement or guarantee correct account linkage. Guest access is unauthenticated and cannot represent a named partner. Attribute-only just-in-time provisioning with no handler leaves the account resolution to whatever the identity provider happens to send, which is exactly the control the requirement wants.

Exam section: Community (Partner and Customer)  ·  Difficulty: Medium

Correct answer: B. Guest users are always private, cannot own records, cannot be added to public groups, and cannot be granted write access through sharing — so the confirmation has to be rendered from data returned within the same transaction, or the visitor has to authenticate to see it later

The guest user is deliberately the most constrained identity in the platform. It cannot own records, so it has no ownership-based path back to its own submission, and guest user sharing rules grant read access only. The practical designs are to display the confirmation from data already held in the request context, or to require authentication before showing submission history.

A sharing rule matching on email would expose any case whose email field matched — trivially abusable by typing someone else's address. Licences are assigned to authenticated users, not to the guest user. Loosening the external default to public read only would expose other customers' cases to every unauthenticated visitor.

Exam section: Community (Partner and Customer)  ·  Difficulty: Hard

Correct answer: D. Either person accounts, or consumer contacts placed under a single bucket account — with the caveat that a bucket account concentrates a very large number of child records under one parent, which is the account data skew pattern, so the choice has to be made with volume in mind

Both models are legitimate, and the architect's contribution is naming the trade-off. Person accounts represent an individual as a single record and avoid the skew problem, but they change the data model org-wide and interact with a number of features. A bucket account is simpler to adopt but concentrates children under one parent, which is the classic account data skew pattern and can cause locking and sharing-recalculation pain at volume.

One account per consumer inflates the account object enormously and is rarely justified for pure consumers. An external community user must be linked to a contact — that is structural, not optional. Leads are a pre-conversion sales object and cannot be authenticated community users.

Exam section: Community (Partner and Customer)  ·  Difficulty: Medium

Correct answer: A. Set the external organisation-wide default to private — noting that it cannot be less restrictive than the internal default — rely on the external account role hierarchy so partner users see only their own account's records, and give the internal team access through the role hierarchy or a sharing rule

External access is governed by the external organisation-wide default, which is a separate setting from the internal default and cannot be more permissive than it. With it set to private, partner users see records within their own account's external role hierarchy, which produces the required isolation between the two partner organisations. Internal access is then granted upward through the hierarchy or by an explicit sharing rule.

Relying on the internal default alone leaves the external default unaddressed, which is where the exposure would be. Sharing sets are for high-volume users without roles — partner users are role-based, so the hierarchy already does this work. Restriction rules subtract access and would be a fragile, high-maintenance way to reproduce what the external hierarchy provides natively.

Exam section: Community (Partner and Customer)  ·  Difficulty: Hard

Correct answer: C. External Identity is scoped to identity services — registration, login, profile and consent management with limited data access — so requirements for case work and Knowledge point to a Customer Community or Customer Community Plus licence; raising the licence question early avoids a late redesign

Licence type sets a hard ceiling that permission sets cannot lift. External Identity is intentionally an identity licence; case management and Knowledge access are community functionality. The architectural point the exam rewards is the timing: this question has to be asked during requirements, because discovering it after the site is built means re-licensing a live user population.

Permission sets grant permissions within what the licence allows — they cannot exceed it. Routing real case work through the guest user would be both functionally inadequate and a security problem. Verify current licence entitlements in the Salesforce documentation, as they are revised over time.

Exam section: Community (Partner and Customer)  ·  Difficulty: Medium

Correct answer: B. The identity provider is targeting the org's service-provider values rather than the site's — a site needs its own SAML configuration with the site's Entity ID and Assertion Consumer Service endpoint, and that configuration has to be selected on the site's login and registration settings

An Experience Cloud site has its own login URL and its own assertion consumer endpoint. If the identity provider posts the assertion to the org's endpoint, the user is authenticated into the internal experience rather than the site — which is precisely the symptom described. The fix is a site-specific SAML configuration, with matching Entity ID and ACS URL at the identity provider, enabled on that site.

A certificate problem produces a signature validation error, not a redirect to the wrong destination. Licence type does not determine which login page a user lands on. Self-registration governs how new users create accounts and has no bearing on where an assertion is delivered.

Exam section: Community (Partner and Customer)  ·  Difficulty: Hard

Correct answer: D. Embedded Login, which renders the Salesforce-hosted login inside the external page through a connected app and a JavaScript include so credentials never pass through the external application; if a fully custom interface is required instead, the Headless Identity APIs are the alternative

Embedded Login gives the inline experience without moving the credential. The distinction worth carrying into the exam and into design reviews is who renders the login: Embedded Login means Salesforce still renders and processes it inside your page, whereas the Headless Identity APIs hand the interface entirely to you while Salesforce keeps the credentials and issues the tokens.

A hand-built form that collects a password and posts it to Salesforce puts the credential in the external application, cannot handle verification or multi-factor step-up, and is the pattern security reviews reject. A redirect fails the inline requirement. Delegated authentication runs in the opposite direction and does not apply.

Exam section: Community (Partner and Customer)  ·  Difficulty: Medium