Salesforce Platform Identity & Access Architect Free Practice Test | 200+ Questions

Salesforce Platform Identity and Access Management Architect Practice Test

The Salesforce Platform Identity and Access Management Architect certification is designed for professionals who make high-level decisions about secure sign-on, identity federation, user provisioning, authorization, external-user access, and identity monitoring. A useful practice test should develop your ability to choose the right solution for a business scenario rather than reward simple term memorization. You can Find mock tests across major IT vendors while building a preparation plan that combines official Salesforce documentation, hands-on identity exercises, and regular knowledge checks.

Who should use this practice test?

This practice resource is suitable for enterprise architects, technical architects, security architects, integration architects, identity architects, solution architects, and experienced Salesforce professionals who work with authentication and user access.

According to Salesforce, the typical candidate has at least one year of experience designing and implementing identity and access management solutions on the Salesforce Customer 360 platform and at least two years of identity or security technology experience. These are recommended experience levels rather than a required certification path. Salesforce currently lists no prerequisite credential for this certification.

The target learner should be able to discuss more than setup clicks. You need to understand why a design is secure, how trust is established, what happens throughout the user lifecycle, and which party performs each identity role. You should be comfortable with questions such as:

• Is Salesforce acting as the service provider or identity provider?
• Should a scenario use SAML, OpenID Connect, OAuth, delegated authentication, or another approach?
• Should users be created in advance, provisioned through automation, or created just in time?
• Which OAuth flow matches an interactive user, mobile or browser client, device, or server-to-server integration?
• How should profiles, permission sets, roles, licenses, and external-user records be assigned and maintained?
• How will administrators monitor login activity and troubleshoot failed sign-on attempts?
• How should authentication work for employees, partners, customers, and high-volume external users?

The official guide says candidates are not expected to know the product-specific capabilities of every identity provider outside Salesforce or how to obtain signed certificates. The focus is architecture: requirements, protocols, trust, security, trade-offs, user experience, and operations.

Current Salesforce Platform Identity and Access Management Architect topics

The following outline is based directly on the official Salesforce Platform Identity and Access Management Architect guide. It contains six domains. The percentages and objectives below follow Salesforce’s current published blueprint; the short explanations simply make those objectives easier for students to understand.

1. Identity Management Concepts — 17%

According to Salesforce, this domain measures whether a candidate can:

• Describe common authentication patterns and explain how those patterns differ.
• Explain the main parts of an identity solution: authentication, authorization, and accountability.
• Describe how two systems establish trust.
• Recommend an appropriate Salesforce user-provisioning method for a scenario.
• Troubleshoot common SSO failures involving technologies such as SAML and OAuth.

For students, this means first understanding three basic questions. Authentication confirms who a person or system is. Authorization determines what that identity is allowed to access or perform. Accountability creates an audit trail so activity can be connected to the correct identity.

You should be able to compare common authentication approaches instead of treating every login as the same. The official candidate description specifically expects knowledge of federated SSO, delegated SSO, SAML, OAuth, OpenID Connect, social sign-on, and Salesforce authentication mechanisms.

Trust is another essential topic. When Salesforce and another system exchange identity information, both sides must recognize the other as an approved party. Depending on the protocol, trust can involve certificates, signatures, identifiers, endpoints, application registration, secrets, scopes, and token validation.

Provisioning questions ask how a user account should be created and maintained. Possible approaches include manual creation, automated provisioning, and Just-in-Time provisioning. The correct answer depends on the user population, source of identity data, onboarding speed, access-governance requirements, and account-maintenance process.

Troubleshooting questions can involve incorrect identifiers, expired certificates, mismatched endpoints, invalid signatures, missing attributes, time differences, inactive users, or incorrect access. Students should learn to follow the authentication flow and identify the point where it fails.

2. Accepting Third-Party Identity in Salesforce — 21%

This is the largest official domain. Salesforce states that candidates must be able to:

• Explain when Salesforce is acting as a service provider.
• Recommend a provisioning approach for users from identity stores in business-to-employee and business-to-consumer situations.
• Select an authentication mechanism when Salesforce accepts a third-party identity.
• Determine how Salesforce users can be provisioned for SSO and given the correct access rights.
• Identify auditing and monitoring approaches and use platform tools to diagnose identity-provider problems.

Salesforce is the service provider when users authenticate through an external identity provider and then access Salesforce. The identity provider verifies the person, and Salesforce trusts the identity information it receives when the configured requirements are satisfied.

For business-to-employee scenarios, study how an enterprise identity store can support workforce onboarding and access. For business-to-consumer scenarios, consider a larger and more varied user population, registration needs, external identities, account relationships, and the user experience. The blueprint expects candidates to recommend provisioning that fits each population rather than use one method everywhere.

The authentication mechanism must also fit the source of identity. The guide refers broadly to enterprise directory, social, and community identity scenarios. Candidates should understand how Salesforce accepts external identity information and how the selected method supports the required login experience.

Provisioning and access assignment must work together. Creating a Salesforce user does not automatically give that user the correct authorization. The solution must also apply suitable licenses, profiles, roles, permission sets, or other access controls and keep those assignments current.

Monitoring is part of this domain because an identity design must be supportable. Students should know that Salesforce provides tools for reviewing logins, identity verification, and identity-provider activity. The purpose is to determine whether the failure occurred at the identity provider, during the protocol exchange, during provisioning, or when Salesforce evaluated the user and access settings.

3. Salesforce as an Identity Provider — 17%

The official guide lists four skills for this domain:

• Select the appropriate OAuth flow for a scenario: web-based, JWT, user-agent, or device authorization flow.
• Recommend the appropriate OAuth scope and connected-app configuration for authorization.
• Explain OAuth concepts including scopes, secrets, access tokens, refresh tokens, expiration, and revocation.
• Recommend the Salesforce technologies used to provide identity to a third-party system.

Salesforce acts as the identity provider when a user signs in through Salesforce and uses that trusted identity to access another application. This is the opposite of the previous domain, where Salesforce accepts identity from an external provider.

Students must know the OAuth flows named by Salesforce. A web-based flow supports an interactive application. A JWT flow supports an approved server-to-server situation without an interactive login. A user-agent flow works through the user’s browser. A device authorization flow supports a device that cannot easily accept normal credentials or display a full login experience.

Do not choose a flow only from its name. Determine whether a person is present, whether the client can protect a secret or private key, whether a browser is available, and whether the system must continue working without repeated user interaction.

OAuth scopes define the access an application requests. Connected-app configuration controls matters such as the permitted users, callback location, authorization settings, and token policy. Candidates should understand the purpose of secrets, tokens, refresh tokens, token expiration, and token revocation at an architecture level.

The official objective also expects candidates to recommend Salesforce technology for providing identity to other systems. The more detailed version of the official guide gives examples such as Canvas, Connected Apps, and App Launcher. Focus on how Salesforce makes an authenticated identity available to the external service and how access is controlled.

4. Access Management Best Practices — 15%

Salesforce identifies four objectives in this area:

• Choose an appropriate MFA method and determine the type of session it should produce.
• Decide how roles, profiles, and permission sets should be assigned during SSO and kept up to date.
• Select tools that can audit and verify user activity during and after login.
• Identify the required connected-app settings for a scenario.

MFA strengthens authentication by requiring an additional verification factor. The scenario may also require a particular session assurance level. Students should connect the authentication method to the security level required for the user’s actions.

Access assignment is a separate design decision. During SSO or provisioning, a user may need a role, profile, and one or more permission sets. The architect must decide where the assignment information comes from, how it is mapped, and how it changes when the person’s responsibilities change.

The audit objective covers both the login and later user activity. Candidates should understand which Salesforce monitoring or history tools provide the evidence needed for the situation. The goal is to verify that the correct person logged in, understand the authentication method, and investigate relevant activity.

For connected apps, study the settings that control authorization and access. These can include the allowed users, OAuth scopes, callback information, token behavior, and other security policies required by the scenario. Answers should follow least privilege and the customer’s security requirements.

5. Salesforce Identity — 12%

The official Salesforce guide limits this domain to three objectives:

• Identify the role of Identity Connect in a Salesforce Identity implementation.
• Decide whether Salesforce Customer 360 Identity fits a developed Customer 360 solution.
• Recommend the appropriate Salesforce license type for a given set of requirements.

For Identity Connect, focus on the role it plays in connecting enterprise identity information with Salesforce. Candidates should understand when it is relevant to an identity design rather than memorize a configuration path.

For Customer 360 Identity, determine whether the capability fits the customer’s wider solution and identity requirements. Consider the intended users, the systems involved, how identities are managed, and the experience the organization wants to provide.

Licensing is part of the architecture because different employee, partner, customer, and external-user populations can require different capabilities. Match the license recommendation to the stated access and identity needs. Because license names and entitlements can change, confirm current product documentation during preparation.

6. Community (Partner and Customer) — 18%

The official domain name still uses “Community,” while the first objective refers to Experience Cloud. Salesforce expects candidates to:

• Explain how the Experience Cloud user experience can be customized.
• Determine how to support external identity providers and select the right user-and-contact model for the community experience.
• Understand the benefits and limitations of External Identity solutions and related licenses.
• Decide when Embedded Login is appropriate.

Experience Cloud customization can include branding, authentication options, identity verification, self-registration, user communications, and password reset. Students should connect these capabilities to the external user’s complete login and account-recovery experience.

External identity-provider questions require both authentication and data-model decisions. The identity provider controls how the person proves identity, while the Salesforce user-and-contact model affects account relationships, authorization, and the Experience Cloud experience.

External Identity solutions and licenses must be evaluated against the number and type of external users, required access, login pattern, registration needs, and available features. The objective is to recommend a solution that meets the requirements without assuming every external population is the same.

Embedded Login is explicitly named in the blueprint, so candidates must understand its purpose and decide when it fits a scenario. For real implementations, also review Salesforce’s latest product guidance because browser behavior and platform recommendations can change.

Official weighting check

The six verified domain percentages are 17% + 21% + 17% + 15% + 12% + 18% = 100%. This is the outline students should use when organizing practice-test sessions and measuring topic coverage.

Identity concepts every student should understand

Authentication is not authorization

Authentication proves identity; authorization determines access. A SAML assertion can successfully identify a user, yet the user can still be unable to open an object because the assigned license or permissions do not allow it. Conversely, an overprivileged user can authenticate securely and still represent excessive authorization risk.

When analyzing a scenario, separate the two questions. First decide how the person or system proves identity. Then decide how Salesforce assigns and maintains the correct access.

SAML, OAuth, and OpenID Connect solve different problems

SAML is commonly used for browser-based enterprise SSO. It exchanges signed assertions between an identity provider and service provider. OAuth delegates access to protected resources using scopes and tokens. OpenID Connect adds an identity layer on OAuth 2.0 and uses an ID token to communicate information about the authenticated user.

They can appear together in one architecture. The correct protocol depends on the client, user journey, integration type, existing identity platform, and security requirements.

Provisioning must cover the whole lifecycle

Creating the user is only the start. A complete design handles joiner, mover, and leaver events. It assigns the correct access when a person joins, updates access when responsibilities change, and removes access quickly when the relationship ends.

JIT provisioning is useful at first login, but it may not immediately deactivate someone who never signs in again. For high-risk access, combine authentication with lifecycle automation, reconciliation, ownership, and audit processes.

Trust depends on configuration and operations

Certificates, keys, endpoints, redirect URIs, identifiers, claims, scopes, and metadata establish technical trust. Owners, rotation procedures, monitoring, incident response, and change control keep that trust healthy over time.

An architecture that works on launch day can fail later because a certificate expires, an endpoint changes, a redirect URI is added carelessly, or an integration owner leaves. Plan for renewal, rotation, testing, alerting, documentation, and recovery.

Identity design must include failure paths

Plan what happens when the identity provider is unavailable, the certificate is invalid, MFA cannot be completed, a user loses a device, JIT provisioning fails, a token is stolen, or an administrator needs emergency access. Resilient identity architecture makes recovery possible without opening an unsafe bypass.

How focused practice strengthens identity-architecture thinking

A strong preparation platform should help students learn how to reason through identity scenarios. Structured practice can provide:

• Current-domain coverage: Work across all six blueprint areas instead of concentrating only on SAML terminology.
• Role clarity: Practice identifying the identity provider, service provider, authorization server, client, user, and authoritative identity store.
• Protocol selection: Compare SAML, OAuth, OpenID Connect, delegated authentication, and social sign-on using realistic constraints.
• Lifecycle awareness: Connect sign-on to provisioning, permission assignment, updates, deactivation, reconciliation, and auditing.
• Security judgment: Learn to prefer least privilege, strong sessions, limited scopes, controlled app access, and monitored emergency paths.
• Troubleshooting discipline: Use the flow and available evidence to locate failures rather than guessing.
• Readiness tracking: Group mistakes by domain and study objective so each review session has a clear purpose.

The explanation after a practice item is more valuable than the letter of the answer. For every missed question, write down the actor, protocol, trust mechanism, provisioning method, access decision, and audit source. This small habit turns memorized vocabulary into reusable architecture knowledge.

You can also Study for an Salesforce exam with practice questions while organizing related certification resources. Site-owner note: the supplied destination is a Microsoft vendor page even though the requested anchor refers to Salesforce. Replace it with the correct Salesforce vendor URL when available so the anchor and destination accurately match.

How to use this practice test effectively

Begin with an untimed diagnostic

Complete a mixed set before deep study. Do not search for answers during the attempt. Mark every question you answer with low confidence, even if it turns out to be correct. Your aim is to identify gaps, not create an impressive first score.

Build an identity-flow diagram

For every scenario, draw the flow. Include the user, device or client, identity provider, Salesforce role, target application, protocol, token or assertion, provisioning event, and audit record. A simple diagram often reveals which component the question is testing.

Review why the other choices fail

Identity questions frequently include several technologies that could work in general. The best answer is the one that fits the exact requirements with appropriate security and complexity. Explain why the strongest alternative is weaker for this scenario.

Separate protocol facts from design decisions

Create short notes for SAML, OAuth, and OpenID Connect, but do not stop there. Add when each is appropriate, its participants, its important artifacts, a security risk, a troubleshooting source, and one reason not to choose it.

Use current official guidance

The blueprint may name technologies or flows that now have stronger alternatives. For example, students should recognize the user-agent flow, yet current Salesforce guidance recommends safer flows for many implementations. Learn what the objective asks, then confirm current implementation recommendations.

Reattempt only after review

Repeating the same questions immediately can test short-term answer memory. Review the underlying source, explain the concept without looking, complete a small exercise, and return later. Fresh questions are better for measuring transfer.

Treat scores as one signal

No third-party practice score guarantees a certification result. Look for stable performance across new scenarios and all domains. More importantly, confirm that you can explain the identity roles, trust mechanism, lifecycle, least-privilege choice, and monitoring plan.

A six-week preparation plan

Week 1: Identity foundations

Read the official guide. Study authentication, authorization, accountability, federation, delegated authentication, SSO, SAML, OAuth, OpenID Connect, trust, and user provisioning. Complete a diagnostic set and group gaps by domain.

Week 2: Salesforce accepts external identity

Focus on Salesforce as a service provider. Compare IdP-initiated and SP-initiated SAML. Review employee and customer provisioning, JIT, identity-store integration, social sign-on, and SSO troubleshooting. Draw at least three inbound identity flows.

Week 3: Salesforce provides identity

Study Salesforce as an identity provider. Compare web server, JWT bearer, user-agent, and device authorization flows. Review scopes, access tokens, refresh tokens, secrets, certificates, callback URLs, expiration, and revocation. Add connected-app and External Client App governance.

Week 4: Access and operations

Review MFA, session assurance, direct-login recovery, permission assignment, least privilege, login flows, app policies, and identity monitoring. Practice matching evidence sources to troubleshooting needs.

Week 5: Salesforce Identity and Experience Cloud

Study directory integration, customer identity, external-user licenses, contact and account relationships, self-registration, authentication providers, branding, recovery, external identity, and Embedded Login limitations.

Week 6: Mixed scenario practice

Complete timed mixed sets using fresh questions. Review every incorrect and uncertain answer. Return to official documentation for weak topics. In the last few days, focus on reasoning summaries, not last-minute memorization.

If your schedule is shorter, combine adjacent weeks but keep the same learning order. Identity concepts are easier to understand before product scenarios.

Practical activities that improve understanding

Hands-on work does not need to be a full enterprise implementation. Use small, safe exercises:

• Draw an IdP-initiated and SP-initiated SAML sequence and label the trust points.
• Compare a pre-provisioned employee with a JIT-provisioned external user.
• Design joiner, mover, and leaver steps for an employee population.
• Select an OAuth flow for an interactive web app, server process, and limited-input device.
• Review OAuth scopes and remove every permission not required by the use case.
• Create a connected-application governance checklist covering ownership, users, scopes, tokens, callbacks, review, and retirement.
• Map a business role to a license, profile, permission sets, role, and data-sharing needs.
• Trace a failed SAML login using assertion values and Salesforce monitoring tools.
• Design emergency administrator access for an identity-provider outage.
• Model registration, account linking, login, password recovery, and deactivation for an Experience Cloud customer.

These activities teach you to follow the entire identity lifecycle. That is more useful than remembering isolated setup labels.

Common study mistakes

Confusing authentication with authorization

SSO does not decide every Salesforce permission. Always separate proof of identity from access assignment and data visibility.

Assuming SSO automatically manages offboarding

SSO can stop a disabled identity from authenticating, but Salesforce account status, active sessions, tokens, and assigned access still need lifecycle controls. Plan deactivation and revocation explicitly.

Choosing a protocol from one keyword

“Mobile,” “external,” or “server” is not enough information. Consider user presence, client-secret protection, browser availability, token use, refresh needs, and required assurance.

Granting broad OAuth scopes

Broad scopes increase risk. Select the smallest scopes that meet the integration requirement and combine them with controlled users, Salesforce permissions, token policy, monitoring, and regular review.

Ignoring certificate and secret operations

An identity solution needs owners, secure storage, rotation, expiration monitoring, testing, and recovery. A diagram without operations is incomplete.

Using outdated Embedded Login assumptions

Current Salesforce guidance warns that Embedded Login depends on third-party cookies and recommends redirect-based OAuth flows. Study its blueprint use case, but do not ignore current browser and platform limitations.

Forgetting the external-user data model

Experience Cloud identity affects accounts, contacts, licenses, sharing, duplicates, and support. Authentication alone does not create a complete external-user architecture.

Memorizing old percentages

Use the live Salesforce guide. At the time of this review, the outline has six domains, and Accepting Third-Party Identity in Salesforce is weighted at 21%.

Readiness checklist

You are approaching readiness when you can:

• Explain authentication, authorization, and accountability in plain language.
• Compare federated SSO and delegated authentication.
• Describe IdP-initiated and SP-initiated SAML.
• Explain how trust is established and maintained between systems.
• Select pre-provisioning, JIT, automated provisioning, or manual creation for a scenario.
• Design joiner, mover, leaver, reconciliation, and revocation processes.
• Troubleshoot SAML and OAuth using the correct evidence.
• Explain Salesforce as a service provider and as an identity provider.
• Choose among web server, JWT bearer, user-agent, and device flows using scenario requirements.
• Apply least-privilege OAuth scopes and app policies.
• Explain access and refresh tokens, expiration, storage, rotation, and revocation.
• Recommend MFA and session controls appropriate to risk.
• Keep licenses, profiles, roles, and permission sets synchronized with business responsibilities.
• Use Login History, Identity Verification History, and Identity Provider Event Log appropriately.
• Design safe direct administrator access for an SSO outage.
• Match Salesforce identity capabilities and licenses to user populations.
• Design an Experience Cloud identity journey, including registration and recovery.
• Explain why current Salesforce guidance limits Embedded Login use.
• Defend your recommendation and reject plausible alternatives.

Continue building your Salesforce identity skills

Use the official blueprint to organize study, current Salesforce documentation to verify technical guidance, and practice tests to measure reasoning across new scenarios. Review a missed item until you can explain the actors, protocol, trust, provisioning, authorization, and monitoring in simple language. To explore additional certification resources, Learn more about the Edurely platform.

Frequently asked questions

What does a Salesforce Platform Identity and Access Management Architect do?

The architect assesses identity requirements and designs secure authentication, authorization, provisioning, federation, external-user access, monitoring, and recovery solutions. They coordinate Salesforce with enterprise directories, identity providers, applications, security teams, administrators, and business stakeholders.

Is the Salesforce Identity and Access Management Architect certification still active?

Yes. Salesforce currently lists it as an active architect credential and provides an official preparation path. Always confirm its current status on the official credential page before registering because Salesforce can change its certification catalog.

Is there a prerequisite certification?

No. Salesforce’s official guide currently lists no prerequisite. However, identity, security, and Salesforce implementation experience is strongly recommended because the questions focus on design choices and trade-offs.

Is this credential appropriate for beginners?

It is an architecture-level credential, so it is not aimed at complete beginners. A new learner can study the concepts, but real experience with SSO, provisioning, permissions, integrations, external users, and troubleshooting makes the scenarios much easier to understand.

Which domain has the highest weighting?

Accepting Third-Party Identity in Salesforce is the largest domain at 21%. Community (Partner and Customer) follows at 18%. Identity Management Concepts and Salesforce as an Identity Provider are each 17%. Do not ignore the smaller domains because the percentages are relatively close.

What is the difference between an identity provider and a service provider?

The identity provider authenticates the user and issues trusted identity information. The service provider hosts the application or resource the user wants to access. Salesforce can perform either role depending on the architecture.

Is SAML the same as OAuth?

No. SAML is commonly used for enterprise browser SSO using signed assertions. OAuth is an authorization framework that gives applications controlled access through tokens and scopes. OpenID Connect adds authentication and identity information on top of OAuth 2.0.

What is Just-in-Time provisioning?

JIT provisioning creates or updates a Salesforce user during a successful SAML sign-in. It can simplify first access, but the organization still needs a complete lifecycle process for changes, deactivation, access review, and exceptions.

Why is MFA important when an organization already uses SSO?

SSO centralizes authentication but does not remove credential risk. MFA adds another verification factor and can strengthen the identity-provider login. The architecture should also verify how Salesforce receives assurance information and how emergency direct-login accounts are protected.

Which OAuth flow should I memorize?

Understand all flows named in the official blueprint, but focus on selection logic rather than memorization. Know whether a user is present, whether the client can protect a secret or key, whether a browser is available, and whose identity the integration uses.

What should I know about connected apps?

Understand OAuth and SAML settings, scopes, callback URLs, permitted users, preauthorization, certificates or secrets, token policies, session controls, monitoring, ownership, and revocation. Also review current Salesforce External Client App guidance because the platform’s app-integration model continues to evolve.

How can administrators troubleshoot failed SSO?

Follow the transaction step by step. Check the identity-provider result, assertion or token, issuer, audience, endpoint, signature, certificate, time, identifier mapping, user status, provisioning attributes, permissions, and Salesforce login or identity-provider logs.

Are practice tests enough for preparation?

No. Use practice tests with the official guide, Trailhead, Salesforce Help, architecture guidance, hands-on exercises, and real scenario review. A mock test shows gaps; it does not replace implementation understanding.