SPLK-2003
Splunk SOAR Certified Automation Developer Exam
Splunk SOAR Certified Automation Developer Exam Guide
The Splunk SOAR Certified Automation Developer exam validates practical ability to configure a SOAR environment, connect it with Splunk, and plan, build, and troubleshoot playbooks. It is aimed at candidates working with SOAR administration and automation rather than people studying security concepts in isolation. This guide helps you make a sensible decision about whether the legacy certification still matches your goal, identify the skills the blueprint emphasizes, and organize hands-on preparation before scheduling an attempt.
Is this certification still the right target?
Check the certification’s current status before investing in exam preparation. Splunk lists Splunk SOAR Certified Automation Developer as a legacy certification, and the blueprint says legacy exam content will no longer be actively maintained or updated to reflect product changes or releases. That status should shape both your study scope and your scheduling decision.
The certification was formerly referred to as Splunk Phantom Certified Admin. That historical name matters when searching for older course references, internal job descriptions, or archived learning material. It does not mean that every older Phantom resource is automatically suitable preparation. Use the current official exam page and blueprint as the controlling references, then treat older material as background that must be checked against the documented objectives.
A legacy exam can still be relevant when an employer specifically requires this credential, when a team uses the associated product terminology, or when you need to document skills on an existing platform. It may be a poor choice when your objective is a current certification aligned with later product releases. Confirm the status, availability, and current registration path directly through Splunk before paying for an attempt.
Do not confuse the certification’s legacy label with permission to ignore the blueprint. The available blueprint remains the best evidence for the tested skill areas. Your preparation should therefore prioritize the capabilities it names, while avoiding assumptions that a newer SOAR interface or release has identical behavior.
What decision should you make first?
Decide whether you are preparing for a mandated legacy credential or building current SOAR capability. For a mandated credential, study the published blueprint closely and verify that the exam can still be scheduled. For broader professional development, compare this target with the current certification options on Splunk’s certification pages before committing time and an exam fee.
What does the exam validate?
The exam validates more than the ability to click through a playbook editor. Splunk describes capabilities involving SOAR-server installation and configuration, Splunk integration, and the planning, design, creation, and debugging of playbooks. The blueprint also covers operational use of SOAR, including analyst queues, investigation pages, case management, workbooks, customizations, and system maintenance.
This combination creates two preparation tracks. The first is platform administration: deployment, initial configuration, users, apps, assets, and ongoing maintenance. The second is automation development: selecting actions, designing playbook flow, using visual blocks, handling results, and debugging execution. A candidate who studies only Python or only the analyst interface leaves a material part of the stated scope unaddressed.
The exam’s professional-level designation is a useful signal about the expected perspective. You should be able to reason about how a configuration or playbook design supports an operational outcome, not merely recognize isolated product vocabulary. When reviewing a topic, ask what problem it solves, what inputs it needs, what output it produces, and how an analyst or administrator would verify the result.
Splunk’s certification track describes the target in terms of complex SOAR solution capabilities and knowledge of installing and configuring a SOAR server and integrating it with the Splunk platform. That wording supports a preparation approach based on complete workflows: configure the environment, connect the relevant components, design an automation, test it, inspect its results, and correct failures.
Who benefits most from this target?
The strongest fit is a practitioner who administers SOAR, develops or maintains playbooks, integrates SOAR with Splunk, or supports security operations automation. The exam has no prerequisite certification or prerequisite course, but the absence of a formal prerequisite does not remove the need to understand the product’s administrative and automation concepts.
What should a beginner not assume?
A no-prerequisite policy is not evidence that general security knowledge alone will be enough. The blueprint is product-oriented. If you have not worked with SOAR objects, apps, assets, playbook execution, and administrative settings, begin with guided product learning and a controlled practice environment rather than jumping directly to memorization.
How is the exam structured?
Splunk’s blueprint specifies 45 questions, and the exam page lists the exam length as 60 minutes. The blueprint clarifies that the 60-minute total exam time includes three minutes to review the exam agreement. The listed format is multiple choice, and Splunk states that Pearson VUE delivers the exam.
That combination requires disciplined pacing. The agreement review is part of the stated total time, so do not plan as though the full appointment is available for answering questions. You should also confirm the current registration, delivery, identification, and scheduling instructions with Pearson VUE or Splunk because operational policies can change and the supplied evidence does not establish every current delivery condition.
The listed price is $130 USD per exam attempt. Treat that as the published figure in the supplied exam-page evidence, not as a guarantee that taxes, regional handling, payment conditions, or later changes will be identical for every candidate. Verify the amount and availability at the point of registration.
Multiple-choice delivery rewards careful interpretation, not a memorized list of screen labels. Read each question for the requested outcome, identify the relevant SOAR object or capability, eliminate answers that solve a different problem, and choose the option most consistent with the documented behavior. Do not use exam dumps or leaked questions as a preparation strategy; they are not a substitute for understanding and may not reflect the maintained scope of the product.
How should you use the time limit in practice?
Rehearse a two-pass approach with your own legal study questions. On the first pass, answer items where the scenario and capability are clear. Mark questions that require a comparison between similar options, then return to them with the remaining time. Practice reading the full stem before evaluating the answer choices; partial reading is especially risky for configuration and workflow questions.
What should you verify before booking?
Confirm the certification’s legacy availability, the current exam page, the Pearson VUE scheduling route, the published price, and any applicable candidate policies. The official Splunk certification page is the appropriate starting point, while the blueprint is the appropriate source for the tested scope.
Which administration topics need deliberate study?
The blueprint names deployment, installation, initial configuration, user management, apps, assets, and playbooks. Study these as a connected operating model: a SOAR deployment must be configured for people and integrations, integrations expose actions through apps and assets, and playbooks use those capabilities to support repeatable response work.
For deployment and installation, focus on purpose and sequence. Know which decisions belong to bringing up the platform, which belong to initial configuration, and which belong to later operational tuning. Build a checklist in your notes that separates environment setup from feature configuration. This prevents a common mistake: treating every product setting as an interchangeable administration task.
User management deserves more than a glossary review. Organize your study around the relationship between users, responsibilities, access, and the actions they must perform. When you encounter a permission-related scenario, identify who needs to perform the operation, which object or capability is involved, and what the least disruptive configuration would be.
Apps and assets are another important distinction. An app represents an integration capability, while an asset represents a configured instance or connection that an action can use. In your lab or walkthrough, trace an action backward: determine which app supplies it, which asset provides the target connection, what inputs it expects, and what result it returns. That mental trace is more useful than memorizing names without relationships.
Playbooks belong in both the administration and development portions of your notes. Administratively, consider how they are made available and maintained. As automation, consider triggers, inputs, actions, branching, results, user interaction, and debugging. Keeping these viewpoints separate helps you answer questions about platform management without confusing them with questions about flow design.
A practical administration exercise
Create a written scenario for a new SOAR environment. List the installation and initial-configuration decisions, identify the users who need access, choose the integration app and asset conceptually, and describe how a playbook would use the resulting action. Then review the blueprint and label each step with the relevant domain. This exposes gaps before they become vague revision topics.
Administration mistakes to avoid
Do not study installation while ignoring maintenance, or apps while ignoring assets. Do not assume that an available action is usable without the correct configured connection. Avoid notes that list interface terms without recording their purpose, dependencies, inputs, and outputs. Those omissions make scenario questions much harder to reason through.
How should you study playbook design and execution?
Start with the lifecycle of an automation: define the response objective, identify the required data, choose available actions, arrange the control flow, test normal and exceptional paths, inspect results, and debug the implementation. The blueprint explicitly includes automation best practices, playbook capabilities, available app actions, and the I2A2 design methodology, so your study should connect design decisions to execution behavior.
Use I2A2 as a design lens rather than a phrase to memorize. In each exercise, make the intended input, action, decision, and outcome explicit. Ask what information enters the playbook, which action or transformation is applied, how a decision is made, and what the analyst or downstream step receives. If your design cannot answer those questions, it is not ready for testing.
The visual editor topics are specific. The blueprint includes decision and filter blocks, join options, user interaction during execution, format blocks, and action-result structure. Practice explaining when each type of control is appropriate. A decision may route execution based on a condition; a filter may reduce or select data; a join may coordinate branches; a format block may prepare data for later use; and user interaction introduces a human choice into the flow. These descriptions should be verified against the product material you use rather than treated as a substitute for the interface’s exact behavior.
Action-result structure is central to reliable automation. When an action runs, do not stop at whether it succeeded. Identify what result is returned, how later blocks consume it, what happens when the result is empty or unexpected, and how the playbook exposes useful information to an analyst. Many weak designs fail because the author understands the action but not the shape and handling of its output.
Available app actions should be studied by purpose and prerequisites. Select an action because it advances the response objective and can receive the required inputs, not because its name sounds relevant. In a practice exercise, document the action’s source app, asset dependency, inputs, expected result, and possible failure path. This creates a compact reference that supports both design and troubleshooting.
A repeatable playbook exercise
Choose a benign response scenario such as enriching an observable and routing the result for analyst review. Write the objective first. Map the required input, select the integration action, add a condition for the result, decide where branches rejoin, format the information needed later, and include a clear failure path. Test each step independently before testing the complete flow.
How to test a design rather than admire it
Use at least three cases in your own practice: a normal result, an empty or incomplete result, and an action failure. For each case, record the expected branch, the data passed onward, and the point at which a human should intervene. This makes debugging concrete and prevents success-only testing.
What operational SOAR knowledge belongs in the plan?
The blueprint covers analyst-queue use, investigation-page operations, case management, workbooks, customizations, and system maintenance. These topics show that the exam is not limited to building automation in isolation. Prepare to understand how automation fits into the analyst’s working context and how administrators keep the environment usable over time.
Study the analyst queue and investigation page as operational destinations for automation. Ask what an analyst needs to inspect, update, prioritize, or act on after an event enters SOAR. Then connect those needs to the playbook’s outputs. A technically successful playbook that produces confusing or incomplete investigation data is not a strong operational design.
Case management and workbooks should be approached as ways of organizing response activity. Map the difference between immediate investigation work and structured case or workbook activity in the product material available to you. The goal is not to invent a universal workflow; it is to recognize which SOAR capability supports the task described in a scenario.
Customizations require restraint. Before changing a default behavior or presentation, identify the operational problem, the users affected, and the maintenance cost. In practice, document why a customization exists and how it can be tested. Exam preparation should reinforce the principle that customization is a controlled design decision, not a replacement for understanding the standard workflow.
System maintenance is easy to postpone because it is less visible than playbook creation. Give it a dedicated review session. Build a maintenance checklist from the official product material, and distinguish routine administration from troubleshooting a failed automation. This separation helps you avoid selecting a playbook change when a scenario is actually asking for an environment or configuration response.
An analyst-centered review method
Take one automation you have studied and follow its output into the investigation workflow. Note what the analyst can see, what must be confirmed manually, what belongs in a case or workbook, and which result should be retained for later review. If you cannot describe that handoff, revisit the relevant operational topics before moving on.
How can you build a study environment without overreaching?
Use an authorized SOAR learning environment, employer-provided instance, or official training material that permits the exercises you plan to perform. The supplied sources establish that Splunk provides learning paths and SOAR assistance, but they do not establish a universal lab entitlement, product version, or free access arrangement. Do not assume that every candidate can reproduce every production integration.
Begin with observation and mapping. Identify the objects shown in the environment, trace how users reach investigations, locate apps and assets, and follow a playbook from trigger or input through action and result. Only then build a small automation. This sequence reduces the chance of copying steps without understanding the dependencies.
Keep experiments safe and reversible. Use non-sensitive data and approved test connections. Avoid actions that could alter external systems unless the environment and authorization explicitly allow them. The objective is to learn flow, configuration, and debugging—not to simulate an uncontrolled incident response operation.
Maintain a study log with four columns: concept, evidence, exercise, and unresolved question. Put the blueprint topic in the first column, the official material or product observation in the second, the task you performed in the third, and any uncertainty in the fourth. This makes revision targeted and prevents unsupported assumptions from becoming notes you later memorize.
What if you do not have a lab?
Use the blueprint to create design artifacts: configuration checklists, app-to-asset dependency maps, playbook flow diagrams, result-handling tables, and troubleshooting decision trees. These cannot replace hands-on access, but they can reveal whether you understand the relationships among the platform objects. Seek approved demonstrations or training support for behaviors that cannot be verified from documentation.
How can official help fit into preparation?
Splunk Lantern provides a “Getting help with SOAR” resource, and Splunk’s learning-path and certification pages direct candidates toward education information. Splunk states that most customers have OnDemand Services included as part of their license purchase, but those services expire at the end of each quarter. Check your organization’s entitlement rather than assuming access.
What six-stage roadmap keeps preparation focused?
A useful roadmap moves from scope confirmation to product mapping, administration, playbook engineering, operational integration, and timed review. Do not assign calendar dates or a fixed number of study hours unless your own schedule supports them. Advance only when you can explain and apply the current stage’s skills.
Stage one is scope and status. Read the exam page and blueprint together. Record the legacy designation, the stated format, the question count, the time allocation, the delivery provider, and the price. Mark each fact with the page where you found it, and verify time-sensitive details again before registration.
Stage two is product mapping. Create a one-page relationship map covering deployment, configuration, users, apps, assets, playbooks, investigations, cases, workbooks, customizations, and maintenance. For every term, write its purpose and its relationship to at least one other term. This is the point at which you should identify whether you lack platform access or basic product instruction.
Stage three is administration. Work through installation and initial configuration concepts, user management, apps, assets, and playbook administration. Use scenario prompts rather than passive rereading: which object is being configured, who needs it, what dependency is missing, and how would you verify the change?
Stage four is playbook engineering. Practice visual editing, decisions, filters, joins, user interaction, formatting, action selection, and result handling. Build small flows before combining them. Deliberately introduce a wrong input, an unavailable connection, and an unexpected result in an authorized environment or a paper design, then describe the debugging path.
Stage five is operational integration. Follow the automation into the analyst queue and investigation workflow. Add case management, workbooks, customizations, and system maintenance to your review. Revisit the I2A2 methodology and automation best practices by applying them to a complete response design.
Stage six is assessment and correction. Use original practice questions or exercises that do not claim to reproduce live exam content. Classify every missed answer by cause: vocabulary, object relationship, execution logic, administrative purpose, or careless reading. Study the cause, not merely the answer. Finish with a concise reference sheet built from official material and your own verified exercises.
When are you ready to schedule?
Schedule only after you have confirmed the certification is available and can explain the blueprint topics without relying on recognition alone. A practical readiness check is your ability to design a small playbook, trace its app and asset dependencies, explain its action results, identify a failure path, and connect the output to an analyst workflow.
How should you revise in the final review?
Review relationships and decisions, not every screen in sequence. Revisit the difference between configuration and operation, app and asset, action and result, decision and filter, automated step and human interaction, and successful execution and useful analyst output. Keep the official blueprint available as your checklist, but do not turn the final session into unsupported memorization.
Which mistakes waste the most preparation time?
The most expensive mistake is preparing for a current product from assumptions while overlooking the legacy status and published scope. Other common failures include studying playbook syntax without operational context, memorizing app names without understanding assets, skipping failure paths, and treating the absence of prerequisites as evidence that no product practice is needed.
A second mistake is confusing documentation coverage with skill. Reading that the blueprint includes a feature is not the same as being able to select it in a scenario. After every reading session, produce something: a flow diagram, dependency map, troubleshooting sequence, or explanation of when a capability should and should not be used.
A third mistake is overfitting to one successful automation. The exam scope includes administration, analyst work, case management, customization, and maintenance. Rotate your study tasks so that a playbook exercise is followed by an operational or administrative exercise. This exposes blind spots that a single end-to-end demo can hide.
Avoid unsupported certainty about product behavior. If your environment differs from the material you are reading, record the version or context and confirm the behavior through an official source or authorized support channel. Legacy content in particular should not be treated as a promise that every later product release behaves identically.
Finally, do not let practice questions become the entire study method. Questions are useful for checking interpretation, but they cannot replace the ability to design, inspect, and troubleshoot a workflow. Use them after learning and hands-on or diagram-based practice, not as a substitute for either.
A quick error audit
Before booking, list five topics you would struggle to explain to a colleague. For each, identify whether the problem is missing product knowledge, weak relationships among objects, or insufficient practice applying the concept. Address the highest-risk gaps first. If the same category continues to produce errors, extend preparation rather than relying on luck.
What should you do next?
Open the official exam page and blueprint, confirm the legacy certification’s current availability, and build your study checklist from the named objectives. Then choose an authorized learning or practice route, map your gaps, and complete a small end-to-end automation design before scheduling. The practical goal is not to memorize a product snapshot; it is to demonstrate that you can reason about SOAR configuration, automation, results, and analyst use.
Use the Splunk SOAR Certified Automation Developer exam page for the current certification description and registration information: https://www.splunk.com/en_us/training/certification-track/splunk-soar-certified-automation-developer.html. Use the official test blueprint for scope and exam-structure evidence: https://www.splunk.com/en_us/pdfs/training/splunk-test-blueprint-soar-automation-developer.pdf. For historical track context, consult the certification track document: https://www.splunk.com/en_us/pdfs/training/splunk-soar-certified-automation-developer-track.pdf.
For learning options, review Splunk’s certification learning paths and certification information. For SOAR assistance and possible customer-service entitlements, consult Splunk Lantern and verify what your organization actually receives. The official pages are the appropriate place to confirm changes after this guide was published.
A final preparation checklist
Confirm the certification status and scheduling route. Review every blueprint topic. Explain deployment, configuration, users, apps, assets, and maintenance. Design and debug a playbook using decisions, filters, joins, formatting, user interaction, and result handling. Connect automation to investigation and case workflows. Recheck the official exam details immediately before registration.
Conclusion
This exam is best approached as a product-and-workflow assessment, not a vocabulary quiz. Its published scope spans SOAR administration, integration, analyst operations, and playbook engineering, while its legacy status makes current verification especially important. Study from the blueprint, validate behavior through authorized resources, practice complete automation paths, and schedule only after confirming that the credential still serves your professional objective.
Related exams
- SPLK-1004 exam — Splunk Core Certified Advanced Power User Exam
- SPLK-1005 exam — Splunk Cloud Certified Admin
- SPLK-4001 exam — Splunk O11y Cloud Certified Metrics User Exam