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 environments and requirements, then design secure, high-performing Salesforce Platform solutions that satisfy single sign-on needs. It is aimed at architects and identity professionals who must connect authentication, authorization, integration, and stakeholder requirements across Customer 360. This guide helps you decide whether your experience is ready, which subjects deserve practical study, how to structure preparation, and what to confirm before scheduling the exam.
What the credential validates
This certification tests architecture judgment rather than isolated configuration recall. Salesforce expects candidates to apply identity and access-management best practices to Salesforce implementations, design architectures across multiple platforms, and explain the benefits, trade-offs, and recommendations behind a proposed solution.
The official credential page calls the current certification Salesforce Certified Platform Identity and Access Management Architect. The requested SP24 label may identify the exam version or catalogue entry used by a training site, but the official source supplied here names the credential without presenting an SP24-specific blueprint, retirement statement, or schedule.
A strong candidate should be able to translate a business requirement into an identity design. That means identifying the parties involved, deciding where authentication occurs, defining how trust is established, considering how users and attributes move between systems, and explaining how the design remains secure and operationally sound.
The credential also covers communication. An architect must make technical consequences understandable to business and technical stakeholders: what changes for users, what an identity provider owns, what Salesforce owns, which integrations are affected, and what controls or operating procedures are required after implementation.
What it does not prove
Certification alone does not prove that a person has implemented every identity product, solved a particular organization’s migration, or memorized current production behavior. Preparation should therefore focus on reasoning from requirements and official concepts, not on recalled questions or unauthorized exam material.
Who should consider this exam
The intended audience is experienced identity and architecture practitioners. Salesforce describes a target candidate with 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. Treat those figures as Salesforce’s target profile, not as a substitute for checking the current registration rules.
Typical roles associated with the credential include enterprise architect, technical architect, security architect, integration architect, identity architect, and solution architect. The common thread is responsibility for decisions that cross Salesforce boundaries rather than responsibility for one narrow administrative task.
You are likely ready to begin formal preparation if you can examine an unfamiliar access requirement and ask useful questions before selecting a feature. For example, you should be comfortable clarifying who authenticates, which system is authoritative, whether access is interactive or programmatic, how users are linked to Salesforce identities, and what happens when employment or access changes.
You may need foundational study first if your experience is limited to creating users, assigning permission sets, or following a single sign-on setup without understanding the trust model. Those activities are useful, but this exam’s architecture emphasis requires you to explain why a pattern is appropriate and what risks or dependencies it introduces.
A practical readiness test
Take one real or hypothetical business scenario and produce a short architecture decision record. Identify the actors, systems, trust relationships, authentication flow, authorization boundaries, integration dependencies, failure handling, and stakeholder concerns. If you can defend each choice and identify alternatives, your study can become exam-focused. If you cannot, begin with the identity fundamentals before attempting broad revision.
Which subjects deserve the most attention
The supplied official research does not include domain percentages or a complete SP24 weighting table. Do not assign study time from invented percentages or compare unlabeled weights. Instead, use the named concepts in the official exam guide as a coverage checklist, then give additional practice to subjects where you cannot explain the design decision, security implication, or operational consequence.
Start with the identity architecture itself. Map the organization’s platforms, identity providers, Salesforce environments, external applications, integration clients, user populations, and administrative boundaries. Mark where authentication takes place and where authorization is enforced. This map prevents a frequent mistake: treating single sign-on as a complete access-management design.
Study federated and delegated SSO as distinct architectural choices. Be able to describe the trust relationship, the parties involved, the direction of the user journey, and the responsibilities that remain with Salesforce or the external identity system. A useful comparison should include user experience, control ownership, lifecycle implications, and the operational conditions under which each approach is suitable.
SAML deserves deliberate practice because the official guide specifically includes SAML, IdP-initiated and SP-initiated SAML, trust between an identity provider and service provider, and identity-federation capabilities. Do not stop at acronym recognition. Draw both initiation patterns and label the messages, redirects, assertions, trust configuration, and point at which Salesforce accepts the authenticated identity.
Include delegated authentication in your notes and distinguish it from federation. The exam guide names it separately, so your study should cover the purpose of the arrangement, the systems participating in the authentication decision, what Salesforce receives or verifies, and what happens when the external service is unavailable or returns an unusable result.
Finally, connect identity decisions to integration. The official scope calls for architectures spanning multiple platforms and including integration and authentication across systems. Practice deciding whether a requirement concerns a person signing in, an application accessing data, or both. Those paths may have different credentials, ownership, controls, and failure modes.
Why labels are not enough
A candidate can memorize that a pattern is “federated” or “delegated” and still choose incorrectly. For every term, write a plain-language answer to four questions: who authenticates the subject, who trusts the result, how Salesforce identifies the subject, and how access changes when the subject’s status changes. This turns vocabulary into architecture reasoning.
How to study the SSO and federation decision points
Use diagrams rather than flashcards as your main study tool for SSO. A diagram forces you to show initiation, trust, identity data, and system responsibility. After drawing a flow, challenge it with a changed requirement such as an external application, a different user population, a disabled account, or a temporary loss of the identity provider.
For a federated SSO scenario, label the identity provider and service provider explicitly. Record where the user begins, what assertion or authentication result crosses the boundary, how the relying system validates trust, and how the account is matched. Then write the design’s benefits and limitations in terms a security owner and a business owner would both understand.
For a delegated authentication scenario, identify the external authentication service and the Salesforce-side behavior. Consider what the organization gains by centralizing authentication and what it must operate or monitor. Your notes should include dependency, availability, troubleshooting ownership, and the effect of a policy change in the external service.
For IdP-initiated and SP-initiated SAML, draw separate sequences instead of describing them as interchangeable. Ask which system starts the journey, how the target service is selected, how unsolicited or requested responses are handled within the design, and what user experience or control requirement makes one initiation path preferable.
Include negative paths in every diagram. A sound architecture accounts for an unknown user, an invalid or expired assertion, a mismatched identity, an unavailable dependency, an unauthorized application, and a user whose employment or assignment has ended. The exact implementation details depend on the supported configuration, so use official Salesforce documentation when validating a feature-level answer.
Keep a small glossary, but make each entry operational. For example, define a trust relationship by naming its two parties and the evidence one accepts from the other. Define identity federation by describing the cross-system authentication arrangement, not merely by copying a short expansion of the term.
A repeatable diagram exercise
Choose one Salesforce user journey and one application-to-application journey. For each, draw the initiating party, authentication authority, relying party, identity identifier, authorization decision, and failure response. Explain the diagram aloud in business language, then revise it when a requirement changes. This exercise develops the design and communication skills the credential measures.
How to connect authentication with authorization
Authentication establishes or conveys identity; authorization determines what that identity may do. Treating the two as one problem leads to weak designs and confusing exam answers. For each scenario, state the authentication source separately from the Salesforce access model, then identify the controls that govern permissions, data visibility, administration, and lifecycle changes.
Begin with an access inventory. List the users, personas, applications, data domains, environments, and privileged operations involved. Separate normal workforce access from administrative access, external or customer access, integration access, and emergency access. The purpose is not to produce a universal permission recipe; it is to expose which requirement belongs to which control layer.
Ask whether the identity provider’s information is sufficient for the Salesforce authorization decision. If a role, group, attribute, or business relationship influences access, determine where that information originates, how it is mapped, how it is kept current, and who approves changes. Avoid assuming that successful SSO automatically grants the right Salesforce access.
Review the joiner, mover, and leaver lifecycle even when the question appears to concern login. A design that authenticates a former employee but fails to remove Salesforce access is incomplete. Likewise, a user who changes department may authenticate correctly while retaining inappropriate permissions unless lifecycle and authorization ownership are defined.
For integrations, distinguish the application identity from a human user’s identity. Document credential ownership, scope, rotation, monitoring, data access, and the effect of a failed call. The official scope emphasizes integration and authentication across systems, so practice explaining how a design protects both interactive access and system-to-system traffic.
When comparing options, use explicit criteria: security, performance, availability, maintainability, user experience, operational ownership, auditability, and fit with the stated requirement. A recommendation should say why the selected design meets the constraints and what risk is accepted or mitigated.
A useful review question
Whenever a proposed answer says “use SSO,” ask what happens next. Which Salesforce identity is used? Which permissions apply? How are changes propagated? What evidence is logged? Who investigates a failed login or excessive access? These questions expose whether the proposal addresses only authentication or the complete access-management requirement.
How to use the official preparation material
Use Salesforce’s official Architect Journey: Identity and Access Management Trailmix as the backbone of preparation, not as a reason to skip architecture practice. Work through each relevant resource, record the design principle it teaches, and immediately apply that principle to a diagram or scenario of your own.
The Salesforce identity and access-management designer Trailmix is another official preparation route. It also contains a practical scheduling-related note: registering three or more unlocks $999 passes. Because offers and eligibility can change, verify the current Trailhead page and any conditions before making a group-registration decision.
Read the official exam guide alongside the learning material. The guide identifies the expected ability to assess environments and requirements, design identity architectures across platforms, articulate system-design considerations and benefits, and apply general identity and access-management best practices to Salesforce implementations.
Do not treat a Trailhead completion mark as evidence that every architecture decision is mastered. After each module, write one “because” statement: because this requirement exists, this pattern is suitable; because this dependency exists, this risk or limitation must be addressed. Then test the statement against a different user journey.
Use Salesforce documentation to resolve feature-level uncertainty. The supplied Trailmix references OAuth authorization flows, which is relevant when your architecture includes programmatic access. Study the flow as an integration decision, including the participating parties and the control objective, rather than memorizing a sequence without understanding when it applies.
Keep a source log. For each topic, note the official page consulted, the requirement or concept it supports, and any point that still needs confirmation. This reduces the risk of relying on an outdated blog, an unverified answer bank, or a configuration claim that is not supported by the current Salesforce material.
How to read a scenario
Read the requirement twice. On the first pass, identify actors, systems, and constraints. On the second, underline words that imply trust, initiation, lifecycle, integration, availability, performance, or stakeholder communication. Only then compare solution patterns. This prevents a familiar product term from dictating the design before the actual requirement is understood.
A six-stage preparation roadmap
A structured sequence is more effective than repeatedly rereading identity terminology. Move from scope and vocabulary to diagrams, scenario decisions, communication, and final verification. Adjust the pace to your experience; the stages are a study order, not an official timetable or promise of readiness.
Stage 1: establish the boundary. Read the official credential description and exam guide, list every named subject, and mark your confidence in each. Confirm whether your registration page uses the requested SP24 label and check the current official credential page for the information that applies to your attempt.
Stage 2: repair foundations. Review authentication, authorization, federation, delegated authentication, SAML, identity providers, service providers, trust, and identity federation. For every concept, produce a definition plus a diagram. If you cannot explain the difference between two related approaches without relying on a slogan, keep studying that distinction.
Stage 3: model Salesforce architectures. Create scenarios involving a central identity provider, multiple Salesforce environments, external applications, workforce users, privileged users, and integrations. For each scenario, state the requirement, propose an architecture, identify dependencies, and explain how identity and access are controlled.
Stage 4: stress-test the design. Introduce failure and change: an identity provider outage, a failed trust validation, a changed user attribute, an inactive worker, a new external application, an integration credential problem, or a request for broader access. Revise the architecture and document who owns the response.
Stage 5: practice stakeholder communication. Explain the same design in three forms: a short executive recommendation, a technical flow, and an implementation decision record. Include benefits, limitations, assumptions, and unresolved questions. This directly supports the expectation that candidates communicate technical solutions to business and technical stakeholders.
Stage 6: perform a readiness review. Revisit the official guide, close gaps with Salesforce sources, redraw the hardest flows from memory, and confirm your practical logistics. Schedule only when you can reason through unfamiliar scenarios without depending on recalled exam items or unsupported claims.
A weekly study pattern
For each study session, combine three activities: learn one concept, draw one flow, and defend one recommendation. End by writing the question that would change your decision. This pattern is efficient because it links terminology to architecture and makes uncertainty visible instead of hiding it behind passive reading.
Common preparation mistakes
The most damaging mistake is preparing for a terminology quiz when the credential expects architecture application. A candidate who can expand SAML but cannot identify the trust parties, initiation path, identity mapping, and operational owner has not yet converted the subject into a design skill.
Another mistake is memorizing a preferred pattern without checking the requirement. Federated and delegated approaches have different responsibilities and dependencies. A good answer is conditional: it identifies the requirement that supports the choice, the benefit delivered, and the risk or limitation that must be managed.
Do not ignore integrations because your current role focuses on employee login. The official scope includes authentication and integration across systems. Practice questions in which a system acts without a person, then compare the identity, credential, authorization, monitoring, and lifecycle concerns with an interactive user journey.
Do not collapse identity lifecycle into login. An external identity provider may authenticate a user successfully while the user’s Salesforce access, role, or data visibility is no longer appropriate. Include provisioning, changes, deactivation, ownership, and review in your architecture analysis where the scenario requires them.
Avoid studying only happy paths. Security architecture must account for invalid assertions, unavailable dependencies, mismatched identities, excessive permissions, and incomplete deprovisioning. You do not need to invent undocumented Salesforce behavior; you do need to identify the control objective and verify implementation specifics in official documentation.
Do not use dumps, leaked questions, or memorization claims as a preparation strategy. They cannot establish that you understand the architecture, may be unauthorized, and can anchor you to inaccurate or obsolete information. Build original scenarios from the official scope and defend your reasoning instead.
Finally, do not schedule before checking current delivery and registration information. The supplied official delivery guidance says proctored certification exams can be delivered online through Pearson OnVUE or in person at a Pearson VUE testing facility. Availability, appointment details, identification rules, and other conditions should be confirmed through the official registration process.
A quick self-audit
If your notes contain feature names but few diagrams, owners, assumptions, or failure paths, change the study method. If every practice scenario produces the same answer, add constraints that force a comparison. If you cannot explain a recommendation to a non-specialist, practice communication before adding more terminology.
How to decide whether to schedule
Schedule when your readiness is based on repeatable analysis rather than a single reassuring practice result. You should be able to identify the requirement, separate authentication from authorization, map trust and integration boundaries, compare viable patterns, and explain trade-offs without relying on exam dumps or recalled live questions.
Use a final decision sheet with five columns: subject, evidence of understanding, unresolved uncertainty, official source to check, and next action. Include SSO patterns, delegated authentication, SAML initiation models, trust, federation, multi-platform integration, lifecycle, and stakeholder recommendations.
The official target experience can help you interpret your position, but it is not a guaranteed pass threshold. Someone with less experience may need more structured practice; someone with the stated experience may still have gaps in SAML flows, cross-platform design, or communication. Use demonstrated reasoning as the deciding evidence.
Confirm the official credential name and current exam information before registration, especially if a training catalogue labels the attempt SP24. Check the official Salesforce credential page and the applicable exam guide rather than assuming that a version label establishes current status, content, delivery, or eligibility.
For delivery, Salesforce states that all proctored certification exams can be delivered either online through Pearson OnVUE or in person at a Pearson VUE testing facility. Select the option that fits your environment, then review the current Pearson and Salesforce instructions before the appointment.
Do not treat registration as the end of preparation. Reserve time to revisit the most error-prone flows, prepare a concise explanation of your architecture method, and verify the practical requirements shown during scheduling. Keep the official pages bookmarked because certification procedures and maintenance information can change.
Questions to answer before booking
Can you explain why an architecture meets the stated SSO requirement? Can you name the trust parties and initiation path? Can you separate a human login from an integration identity? Can you describe what happens when a user changes or loses access? Can you communicate benefits and limitations to different stakeholders? A “no” identifies the next study task.
What to do after earning the credential
Treat maintenance as part of the certification decision. 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. Track the assigned requirement in Salesforce’s official maintenance information rather than relying on a personal reminder alone.
Keep your architecture notes current after certification. Identity designs change when organizations add applications, alter trust relationships, introduce new user populations, or change lifecycle ownership. A living decision record helps you distinguish what was certified knowledge from what must be rechecked in current Salesforce documentation.
Use the credential responsibly in project conversations. It supports a claim of validated identity and access-management architecture knowledge, but a proposal still needs discovery, threat analysis, testing, operational ownership, and confirmation against the organization’s Salesforce edition, integrations, policies, and current product documentation.
A useful post-certification habit is to review one design for clarity: can an administrator explain the access outcome, can a security stakeholder identify the control, can an integration owner identify the credential and dependency, and can a business owner understand the user impact? This reinforces the communication capability represented by the credential.
Your next action
Open the official exam guide and create the five-column readiness sheet. Then work through the Architect Journey Trailmix, drawing a flow for each major identity pattern and recording the question that would alter your recommendation. When the unresolved list is small and evidence-based, verify current registration and delivery details before choosing an appointment.
Conclusion
This exam is best approached as an architecture decision exercise: understand the requirement, map the trust and integration boundaries, separate authentication from authorization, compare patterns, and communicate the consequences. Use the official Salesforce guide and Trailhead resources to define scope, then use original diagrams and failure scenarios to test your reasoning. Confirm the current credential name, version information, delivery option, and maintenance obligation through Salesforce before scheduling or after certification.
