Salesforce Certified Identity and Access Management Architect (SP24): Exam Guide
The Salesforce Certified Identity and Access Management Architect credential validates whether you can assess identity requirements, design secure and high-performing Salesforce Platform solutions, and satisfy single sign-on needs across connected systems. It is aimed at identity, security, integration, and solution architects who must turn business requirements into an explainable architecture. This guide helps you decide whether your experience is ready, which identity topics need deliberate study, how to organize preparation, and what delivery and maintenance requirements to verify before scheduling.
What the credential validates
This certification tests architecture judgment rather than isolated configuration recall. Salesforce says candidates should assess environments and requirements, design sound Salesforce Platform solutions that meet single sign-on requirements, and explain the design considerations, benefits, and recommendations behind an identity architecture.
The official scope is broader than configuring one login flow. Candidates are expected to design identity architectures spanning multiple platforms, with integration and authentication across systems. That means preparation should connect Salesforce capabilities to the surrounding identity ecosystem instead of treating Salesforce as an isolated application.
A strong candidate can move between three levels of discussion: the business requirement, the identity design, and the implementation consequence. For example, a requirement for centralized workforce access should lead to questions about the identity provider, trust relationship, authentication flow, user lifecycle, authorization boundaries, operational ownership, and how the design behaves when a dependency is unavailable.
The credential’s current official name is Salesforce Certified Platform Identity and Access Management Architect. The “Identity and Access Management Architect (SP24)” wording may be useful as a catalogue or version label, but candidates should use Salesforce’s credential page and certification account for the name and status applicable to their registration.
Who should take this exam
The intended candidate is an identity professional who can assess identity architecture, design secure high-performance access-management solutions on Customer 360, and communicate technical solutions to both business and technical stakeholders. The exam is therefore a better fit for practitioners who already reason about enterprise identity than for candidates beginning with Salesforce administration.
Salesforce describes the target architect as having at least 1 year of experience designing and implementing identity and access-management solutions on Customer 360 and at least 2 years of identity or security-technology experience. These are Salesforce’s descriptions of the target profile, not a substitute for checking any current registration conditions in the official certification information.
Typical roles associated with the credential include enterprise architect, technical architect, security architect, integration architect, identity architect, and solution architect. The role title matters less than the work: you should be comfortable gathering requirements, evaluating trade-offs, documenting trust and integration decisions, and defending a recommendation to stakeholders.
Use an experience gap as a preparation signal. If you understand SAML terminology but have not designed an end-to-end identity architecture, spend more time on scenario analysis and design documentation. If your identity background is strong but your Salesforce Platform exposure is limited, reverse that emphasis and map identity patterns to Salesforce implementation choices.
Which skills deserve the most attention
The supplied official exam material does not provide blueprint percentages in the research available for this guide. Do not use unsourced domain weights to set your study schedule. Instead, organize preparation around the measured abilities Salesforce explicitly describes: architecture assessment, cross-platform authentication and integration, identity best practices, design communication, and single sign-on solution design.
Architecture assessment means identifying the systems, actors, trust boundaries, business constraints, and operational requirements before selecting a feature. Practice distinguishing what the organization needs from what a product can do. A technically possible design may still be unsuitable because it creates excessive administrative effort, weakens control, or fails a requirement for resilience or user experience.
Cross-platform design requires you to follow identity information across system boundaries. Study how the identity provider, service provider, Salesforce orgs, connected applications, and integration components relate to one another. Draw the direction of authentication, identify who issues assertions or tokens, and record which system owns the relevant user or access decision.
The communication dimension is easy to underprepare. Work on concise architecture explanations that state the recommendation, the reason for it, the main benefit, the significant limitation, and the operational responsibility. An architect answer should not merely name SAML, delegated authentication, or federation; it should explain why that choice fits the stated environment.
Use the official domains as a checklist, not as a memorization list. For every topic, ask what requirement it addresses, what trust it assumes, what happens during failure or change, and which stakeholders must own the outcome.
How to study federated and delegated SSO
Begin by separating federated SSO from delegated authentication and then compare each pattern against a concrete requirement. The official exam guide specifically includes federated versus delegated SSO, delegated authentication, SAML, IdP-initiated versus SP-initiated SAML, trust between an identity provider and service provider, and identity-federation capabilities.
For federated SSO, map the identity provider and service provider roles and identify the artifact or protocol exchange used to establish trust. Do not stop at definitions. Practice explaining where authentication occurs, how Salesforce accepts the result, what configuration or metadata must agree, and what the user experience looks like from each initiation direction.
For delegated authentication, focus on the division of responsibility between Salesforce and the external authentication service. Consider the authentication request, the response, the dependency on the external service, and the consequences of an outage or a change in the external system. The useful exam habit is to evaluate the whole operating model, not to select a label from memory.
Compare IdP-initiated and SP-initiated SAML as user journeys. In one case, the user begins at the identity provider; in the other, the user begins at the service provider. Draw both flows and annotate the systems involved, the trust relationship, the expected destination, and the point at which the user is authenticated.
A practical study exercise is to write a short decision record for a fictional organization with multiple platforms. State the preferred SSO pattern, identify the trust parties, describe the flow, name one benefit and one risk, and list the information needed before implementation. Then review whether the recommendation actually answers the requirement.
How to connect authentication with authorization
Authentication answers who the user is; access management also requires a defensible decision about what that user can do. Prepare by tracing the boundary between proving identity, establishing a Salesforce user context, assigning access, and controlling data or application behavior.
Create a matrix for each practice scenario with the user population, identity source, authentication path, Salesforce entry point, authorization responsibility, and lifecycle owner. This prevents a common error: assuming that successful SSO automatically supplies appropriate Salesforce access. It also exposes unresolved questions about onboarding, changes, termination, and exceptional access.
When evaluating an architecture, ask whether the design centralizes only authentication or also coordinates user and access administration. Record which decisions remain in Salesforce and which depend on an external identity or security system. The point is not to force every decision into one platform; it is to make responsibility explicit.
Apply least-privilege thinking to the design discussion. A recommendation should avoid granting broad access merely because a user has authenticated successfully. Consider how roles, groups, profiles, permission assignments, application access, and data access fit the stated requirement, while avoiding claims about a specific implementation feature unless the official material or your verified product documentation supports it.
Use diagrams and tables during study because they expose missing actors and hidden assumptions faster than flashcards. For each proposed flow, mark authentication, trust, provisioning or lifecycle activity, authorization, logging, and support ownership separately.
How to prepare for architecture scenarios
Scenario questions are best approached as constrained design decisions. Read for the business objective, existing environment, security requirement, user population, integration boundary, and stated limitation before considering a solution. The strongest option is usually the one that satisfies the complete requirement with the fewest unacknowledged assumptions.
Use a four-pass method. First, identify the required outcome. Second, list the systems and trust relationships. Third, eliminate options that violate an explicit constraint. Fourth, compare the remaining options by security, performance, maintainability, user experience, and operational ownership. This method keeps familiar terminology from overpowering the actual scenario.
Watch for answers that solve only the visible login problem. A design may authenticate users while leaving lifecycle management, cross-platform consistency, failure handling, or stakeholder communication unresolved. Conversely, an answer may be technically elaborate but unsuitable because it introduces unnecessary dependencies or ignores the organization’s operating model.
When two options appear plausible, ask which one better addresses the requirement stated in the question. Do not select an answer because it is the most advanced, the most centralized, or the most familiar. Select the option whose assumptions, trust model, and responsibilities can be defended from the facts provided.
After each practice scenario, write why the rejected options fail. This is more useful than recording only the correct choice. Your notes should contain requirement signals, decision rules, and exceptions that can be reused when a later scenario changes the user population or system boundary.
A preparation sequence that avoids shallow coverage
Study in layers: identity foundations first, Salesforce architecture second, cross-platform scenarios third, and timed decision practice last. This order lets you understand the concepts before judging trade-offs, while still leaving time to correct gaps revealed by applied questions.
Start with an inventory of your current experience. Mark each topic as explain, design, or implement. “Explain” means you can define it; “design” means you can compare it against requirements; “implement” means you have worked with its configuration and operational consequences. The exam’s architect orientation makes the second category especially important.
Next, use Salesforce’s official Architect Journey: Identity and Access Management Trailmix as the backbone of your study plan. Treat each linked learning item as a prompt for investigation, then verify that you can apply the topic to a multi-system design. Completing learning content without producing your own diagrams or decisions can leave an application gap.
Build a personal reference sheet with sections for SSO patterns, SAML flows, trust relationships, identity federation, authentication responsibility, authorization responsibility, lifecycle considerations, and stakeholder concerns. Keep it conceptual and source-grounded. Do not turn it into a collection of supposed exam answers or unauthorized question material.
Finish with scenario drills. For every drill, identify the requirement, draw the flow, name the trust parties, choose the design, and explain the trade-off in a few sentences. If you cannot explain the choice without repeating product terminology, return to the underlying identity principle.
A four-stage study roadmap
A useful roadmap has four stages: establish the model, map it to Salesforce, rehearse decisions, and confirm readiness. The stages can be completed at different speeds, but skipping the first two usually produces memorization without architecture judgment.
Stage one is identity modeling. Review authentication, federation, delegated authentication, service-provider and identity-provider roles, SAML flow direction, trust establishment, and the distinction between authentication and authorization. Draw the same user journey from both initiation directions and label each handoff.
Stage two is Salesforce mapping. Use the official learning trailmix and relevant Salesforce documentation to connect the identity model to Customer 360 and Salesforce Platform requirements. For each capability, record the problem it addresses, prerequisites or trust assumptions, affected systems, operational owner, and likely failure or change scenario.
Stage three is design rehearsal. Create several fictional requirements with different user populations and system landscapes. Produce a one-page architecture decision for each. Include the requirement, options considered, recommended pattern, trust model, authentication path, access responsibility, benefits, risks, and questions that must be answered before implementation.
Stage four is readiness review. Explain a design aloud or in writing without notes, then challenge it with an outage, a new application, a changed user population, or a requirement for a different initiation flow. Review the official exam information again for any registration or delivery details that may have changed before you schedule.
A practical stopping rule is not a particular practice-test percentage. It is consistent reasoning: you can identify the governing requirement, reject attractive but incomplete alternatives, and communicate a complete architecture with explicit assumptions.
What to do when your background is uneven
Do not study every subject for the same amount of time. Allocate effort according to the gap between what you can configure, what you can explain, and what you can design under constraints.
If you are a Salesforce specialist, strengthen identity fundamentals and cross-platform thinking. Practice drawing trust relationships and explaining SAML initiation directions, delegated authentication, and federation without relying on a Salesforce menu path. Then revisit how those patterns affect user access and integration design.
If you are an identity specialist, strengthen Salesforce Platform and Customer 360 context. Study how an enterprise identity decision becomes a Salesforce architecture, what information stakeholders need, and how Salesforce fits into a broader application landscape. Avoid assuming that a generic identity pattern transfers without qualification.
If you are an integration architect, add lifecycle and access-governance questions to every design. Authentication between systems is only one part of the operating model. Ask who creates, changes, disables, reviews, and supports access, and how those responsibilities are communicated.
If you are preparing with a group, divide reviews by decision type rather than by product feature. One person can challenge trust assumptions, another can test operational ownership, and another can act as the business stakeholder. This produces the communication practice the official target profile expects.
Common preparation mistakes
The most damaging mistake is memorizing protocol names without understanding the requirement they serve. Correct this by attaching every term to a flow, a trust relationship, a responsibility, and a trade-off.
Another mistake is treating SSO as a complete identity architecture. SSO addresses a user’s authentication experience, but an architecture discussion may also need to address authorization, lifecycle, integration, support, resilience, and communication. Keep these concerns in separate columns when taking notes.
Avoid studying only from unofficial answer banks or exam-dump material. Such sources cannot replace understanding, may be inaccurate or unauthorized, and encourage recall of supposed answers instead of analysis. No collection of remembered questions guarantees a pass.
Do not assume that the most centralized design is automatically the best design. Centralization can simplify governance, but it may also create dependencies, ownership questions, or constraints that matter in the scenario. Evaluate the complete environment and the stated requirements.
Do not ignore wording that identifies the initiation direction or the party responsible for authentication. In identity scenarios, a small change in flow direction or responsibility can change the appropriate design. Circle those details during practice.
Finally, do not schedule solely because you have completed a learning path. Use the path as structured learning, then test whether you can make and defend architecture decisions in unfamiliar scenarios.
How to use official Salesforce preparation resources
Use Salesforce’s official resources to establish the scope, then turn that scope into applied work. The official certification page confirms the credential’s current name and describes the solution-design capability; the exam guide supplies the target profile and identity topics; the Architect Journey provides a preparation route.
Begin with the official Architect Journey: Identity and Access Management Trailmix. Capture the concepts it points you toward, but do not treat completion as evidence that every architecture decision is automatic. After each topic, create a diagram, comparison, or decision record.
Use the Identity and Access Management Designer Trailmix as an additional official learning route if its content fits your preparation needs. The supplied page also states, “Register three or more to unlock $999 passes.” Because offers and eligibility can change, verify the terms directly on the official page before using that information in a group scheduling decision.
When official documentation and a practice explanation differ, give priority to current Salesforce documentation and the exam information applicable to your registration. Record the publication or update context where available, especially for product behavior that can change. Keep the exam guide’s concepts separate from assumptions based on older project experience.
Your notes should answer practical questions: Which system authenticates? Which system is trusted? How does the user begin? What happens when the dependency fails? Who owns access? What evidence supports the recommendation? These questions convert official topics into architect behavior.
How the exam can be delivered
Salesforce states that all proctored certification exams can be delivered online through Pearson OnVUE or in person at a Pearson VUE testing facility. Confirm the available appointment choices, technical conditions, identification requirements, and current policies through the official scheduling process before selecting a delivery method.
Choose online delivery only after checking that your workspace, equipment, network, and privacy conditions meet the current Pearson OnVUE requirements. Choose a testing facility if a controlled location is more reliable for your circumstances. This is a practical recommendation, not an additional Salesforce eligibility rule.
Do not infer a price, exam duration, question count, passing score, language list, or appointment availability from the supplied research. Those details are not included in the verified facts for this guide and can change. Use the official Salesforce and Pearson VUE registration information for the details attached to your appointment.
Before scheduling, verify that the credential name shown in your certification account matches the credential you intend to take, review the current delivery instructions, and allow time to resolve account or system issues. Schedule when your preparation evidence supports the decision, not simply when a preferred date appears.
How to plan certification maintenance
Certification maintenance is an ongoing responsibility. Salesforce requires certified professionals to complete one certification-specific Trailhead maintenance badge per year, and the certification expires if the assigned maintenance requirement is missed.
Record the maintenance requirement as soon as the credential is earned. Do not rely on memory or assume that completing a general Trailhead badge satisfies the assigned requirement. Check the certification maintenance information associated with your credential and complete the specified badge within the applicable window.
Maintenance is also a reason to keep your architecture notes current. Identity capabilities and recommended designs can change, so revisit your trust diagrams, flow comparisons, and operational assumptions when Salesforce assigns the maintenance work. Treat maintenance as a structured update to your knowledge rather than an administrative afterthought.
Because maintenance rules are time-sensitive, confirm the current assignment and deadline in Salesforce’s certification and Trailhead systems. The official rule supplied here establishes the annual certification-specific badge requirement and expiration consequence; it does not establish an individual deadline for every candidate.
What to do before scheduling
Schedule after you can demonstrate applied architecture reasoning and have verified the current official registration details. A short readiness review should cover both knowledge and logistics.
First, explain federated and delegated SSO in your own words and distinguish their responsibilities. Second, draw IdP-initiated and SP-initiated SAML flows and identify the trust relationship. Third, design a multi-platform identity architecture from a written requirement. Fourth, explain the benefits, limitations, assumptions, and operational ownership of your recommendation.
Then check the practical items: credential name, account access, delivery choice, appointment availability, current Pearson VUE instructions, and any applicable Salesforce policies. Do not use the absence of a supplied price, duration, score, or question count as a reason to guess; retrieve those details from the live official registration information.
Prepare a compact final review rather than attempting to learn every topic at the last moment. Revisit your decision rules, failure scenarios, and common distinctions. The final goal is not to reproduce an answer pattern but to recognize the requirement and select a defensible architecture under exam conditions.
Your next actions
Start with the official exam guide and credential page, compare the target profile with your experience, and identify the two or three identity decisions you explain least confidently. Turn those gaps into diagrams and scenario exercises before you think about scheduling.
Use this sequence: confirm the official credential information; work through the Architect Journey: Identity and Access Management Trailmix; review federation, delegated authentication, SAML, initiation direction, and trust; create multi-platform architecture decisions; rehearse stakeholder explanations; then verify delivery and registration details through Salesforce and Pearson VUE.
Keep a dated study log with three fields: concept understood, design practiced, and unresolved question. This makes your next study action concrete and prevents repeated passive reading. Resolve uncertain product behavior with current official documentation rather than relying on memory or third-party claims.
After the exam, maintain the credential by monitoring the assigned certification-specific Trailhead maintenance badge and its deadline. The credential is most useful when its architecture knowledge remains current and connected to the identity decisions you make in real Salesforce environments.
Conclusion
This exam is a design and communication challenge centered on identity architecture across Salesforce and connected platforms. Prepare by understanding the trust and authentication flows, separating authentication from authorization and lifecycle responsibility, and practicing requirement-led recommendations. Use Salesforce’s official resources for scope and updates, verify current delivery details before scheduling, and track the annual maintenance requirement after certification.
