Salesforce Certified Slack Developer Practice Exam
This Slack Developer practice exam covers all nine objectives on Salesforce’s official outline — led by Design the Interactive Flow of Your App (20%) and Design for Security (19%) — with scenario questions on Block Kit and modals, the Web and Events APIs, OAuth and request signing, Socket Mode, and the admin APIs. Immediate feedback in Learn mode; a timed 60-question, 90-minute run in Exam mode.
457 practice questions — about 11¢ each, and a fraction of the $200 exam fee.
Backed by our satisfaction guarantee. Instant access — no software to install.
PowerKram’s value promise vs. typical competing Slack Developer practice sets. On sale now.
Slack Developer exam at a glance
- Credential
- Salesforce Certified Slack Developer
- Issued by
- Salesforce (Slack is a Salesforce company)
- Blueprint
- 9 weighted objectives (20 / 19 / 13 / 12 / 9 / 8 / 7 / 7 / 5)
- Format
- 60 multiple-choice / multiple-select questions, plus up to 5 unscored
- Duration
- 90 minutes
- Passing score
- 67%
- Release alignment
- Questions align to the Summer ’24 release (current exam guide)
- Registration fee
- US$200 (JPY 30,000) plus applicable taxes
- Retake fee
- US$100 (JPY 15,000) plus applicable taxes
- Prerequisite
- None
- Recommended experience
- 6+ months with Slack’s APIs and at least one app built on Slack
- Delivery
- Proctored at a testing center or online; closed book
- Maintenance
- Annual Slack Developer maintenance module on Trailhead
Sources: Salesforce — Certified Slack Developer exam guide and the Trailhead Slack Developer credential page. Format, weights, and fees are set by Salesforce and can change. Our 457-question count is PowerKram’s practice bank, not the number of items on the official exam.
About the Salesforce Certified Slack Developer credential
The Salesforce Certified Slack Developer credential shows that you can plan, design, and build custom apps on the Slack platform using Slack’s APIs. It sits in the Salesforce program beside the Slack Administrator and Slack Consultant credentials, but it is plainly a developer exam: Salesforce expects you to read and write JSON, work with web and event-based APIs (JSON over HTTP and, to a lesser extent, WebSockets), and build and deploy a web app in a language such as Node.js, Python, or Java.
The questions are design decisions more than syntax recall. You are asked which surface fits a use case (App Home, a modal, or a message), which entry point starts a workflow (slash command, shortcut, button, or event), whether an app should use Socket Mode or HTTP delivery, which scopes and tokens an install needs, and how an app should behave across an Enterprise organization or a Slack Connect channel. Interactive flow and security together are 39% of the exam, so they deserve the most study time. For how this credential fits the wider Salesforce catalog, see our Salesforce exam study guide.
Terminology note. The current exam guide still aligns questions to the Summer ’24 release and uses the names from that time. Slack’s developer docs have since moved from api.slack.com to docs.slack.dev, “Enterprise Grid” is now described as Enterprise organizations, and the App Directory is now the Slack Marketplace. PowerKram explanations link the current docs page and name both terms where they differ.
Slack Developer exam objectives and weights
Salesforce publishes nine weighted objectives; they sum to 100%. No single objective dominates — the heaviest is 20% — so broad coverage matters more here than on exams with one oversized domain. The ordering below is by weight; the exam guide lists them in a different order.
Build common business workflows and use cases for Slack apps; recommend an app design that works with Slack’s architecture; handle the user entry points into a workflow; choose among components and features such as incoming webhooks, slash commands, shortcuts, interactive components, and bots; and build app UIs with Block Kit.
Implement the OAuth installation flow; request the right scopes and the right tokens for a use case; make the app communicate securely with Slack; and store and retrieve data and tokens safely.
Recommend which Slack API fits a use case; implement the Web API and the Events API; distinguish Socket Mode from HTTP-based event delivery; tell current Slack terms from legacy API language; and handle rate limits across the platform.
Recommend when an Admin API can automate workspace or org administration; manage users and groups with the SCIM API; monitor events with the Audit Logs API; use the Discovery API for data-loss prevention, compliance archiving, or eDiscovery; and identify the user role needed to generate an admin token.
Design for the architecture, features, and roles of Enterprise Grid (now called Enterprise organizations in Slack’s docs); describe an Enterprise Grid sandbox; and decide when to support channels shared externally through Slack Connect.
Build an experience that matches Slack’s aim of making work life simpler, more pleasant, and more productive — in practice, choosing quiet, contextual responses over channel noise.
Recommend how to automate or enhance a workspace; choose among Slack’s surfaces — App Home, modals, and messages — for a use case; and know when to set up a team to collaborate on an app.
Decide when to keep an app to a single workspace; share it with other workspaces; distinguish single-workspace, distributed, and published directory apps; and follow the process and expectations for submitting to the Slack Marketplace (the guide still says Slack Directory).
Recommend when to use sample code and external resources and when to use the Bolt framework; explain the value of Block Kit Builder; and use Slack Developer Tools while building apps.
Weights and objective wording per the official Salesforce Certified Slack Developer exam guide. Percentages sum to 100%.
Who the Slack Developer exam is for
This is a builder’s credential, not an admin one. It fits:
- App and integration developers building Slack apps, bots, and workflows in Node.js, Python, or Java who want their platform skills formally recognized.
- Backend and full-stack engineers connecting Slack to ticketing, CRM, and CI/CD systems through the Web and Events APIs.
- Platform engineers automating workspace and org administration with the Admin, SCIM, Audit Logs, and Discovery APIs.
- Salesforce developers extending into Slack as the two platforms integrate more deeply.
If you run Slack rather than build on it, the Slack Administrator exam is the better fit, and client-facing implementers often choose the Slack Consultant exam. See the developer career paths this Slack credential supports — skills, tools, and salary ranges.
What this Slack Developer practice exam delivers
Weighted to the outline
Questions follow the published nine-objective split — interactive flow 20%, security 19%, Slack’s APIs 13%, admin APIs 12%, and the rest — so practice time lands where the exam’s points are.
Learn mode
The answer, the reasoning, and why each other option fails, right after each question — built for the “which API, surface, or token fits” decisions that make up most of this exam.
Exam mode
A timed run in the real 60-question, 90-minute format, so you build pacing for long scenario stems and multi-select items.
Linked to docs.slack.dev
Explanations cite the current Slack developer docs page — Block Kit, modals, OAuth, request signing, Socket Mode, SCIM — and flag where the exam’s older terms differ from today’s.
The full PowerKram exam engine
Every practice question runs in our purpose-built study engine — not a static PDF or a one-shot quiz. That’s what gets you to a passing score.
- Study by objectives / domains
- Detailed score breakdown
- Exam and Learn mode
- Complete coverage of resources
- High quality, verified accurate
- Not just a public dump
Sample Slack Developer practice questions
Ten scenario questions spread across the outline in rough proportion to its weights, each with a full explanation and a link to the Slack developer documentation it draws on. Tools (5%) is covered in the full bank.
An expense app posts a message with a “Submit expense” button. When a user clicks it, the app must show a form with several input fields and receive the values when the user submits.
Which approach correctly opens the form?
- Post an ephemeral message asking the user to type each value as a separate reply in the channel
- Call dialog.open with the button’s response_url to render a dialog
- Call views.open with the trigger_id from the button’s block_actions payload and a modal view of input blocks, then handle the view_submission payload
- Call chat.update on the original message to turn the button into a text field the user can type into
Show answer & explanation
Correct: C — call views.open with the trigger_id and a modal of input blocks. A modal is the Slack surface built for collecting structured input. views.open exchanges the trigger_id carried in the button’s interaction payload for an open modal — the trigger expires in three seconds and can be used only once — and when the user submits, Slack sends a view_submission payload with the input values.
Why not the others: collecting values as channel replies (A) is unstructured and noisy; dialogs (B) are the legacy predecessor of modals and were never opened with a response_url; chat.update (D) changes a message’s content but cannot turn a message into a multi-field form with a submission payload.
Source: Slack — views.open method →Users click an “Approve” button, and the app then calls a slow ERP API that can take 8–10 seconds before it posts the result. Users intermittently see an error in Slack even though the approval eventually succeeds.
What should the developer change?
- Return an HTTP 200 acknowledgment immediately, run the ERP call asynchronously, then post the outcome through the response_url or the Web API
- Raise the request timeout in the app’s settings so Slack waits for the ERP call to finish
- Have the app re-send the interaction payload to itself until the ERP call completes
- Change the button to a link button so that no interaction payload is sent
Show answer & explanation
Correct: A — acknowledge immediately, then finish the work asynchronously. Slack requires an HTTP 200 response to an interaction payload within 3 seconds, or the user sees an error. The fix is to acknowledge first and do the slow work afterward, then update the user via the payload’s response_url or a Web API call such as chat.postMessage or chat.update.
Why not the others: there is no configurable timeout that makes Slack wait longer (B); re-sending the payload (C) does nothing to satisfy the 3-second acknowledgment; a link button (D) only opens a URL and throws away the in-Slack approval flow.
Source: Slack — Handling user interaction →An app exposes a public Request URL for slash commands and interactivity. The security team wants the endpoint to act only on requests that genuinely come from Slack and to reject replayed requests.
What should the app do with every incoming request?
- Accept the request if its source IP address looks like it belongs to Slack
- Compute an HMAC-SHA256 of “v0:” + the X-Slack-Request-Timestamp + “:” + the raw request body with the app’s signing secret, compare it to X-Slack-Signature, and reject requests whose timestamp is more than five minutes old
- Compare the verification token in the payload with the stored token and accept on a match
- Require users to include a shared password in the slash command text
Show answer & explanation
Correct: B — verify the request signature with the signing secret and check the timestamp. Slack signs every request it sends: the app rebuilds the v0 basestring from the timestamp header and raw body, hashes it with its signing secret, and compares the result to the X-Slack-Signature header. Rejecting timestamps older than five minutes blocks replay attacks.
Why not the others: an IP check (A) proves nothing about the request’s integrity and does not stop replays; verification tokens (C) are the deprecated mechanism that signing secrets replaced; a password typed into a command (D) is visible to others and is not request authentication.
Source: Slack — Verifying requests from Slack → Further reading: PowerKram — Enterprise security practices →A developer is building an app that other companies will install. After an admin clicks “Add to Slack” and approves the requested scopes, Slack redirects back to the app’s redirect URL with a temporary code.
What is the next step in the OAuth v2 installation flow?
- Store the temporary code as the app’s long-term credential for future API calls
- Ask the installing admin to paste a personal user token from their account settings
- Call chat.postMessage with the code to confirm the installation
- Exchange the code by calling oauth.v2.access with the app’s client ID and client secret, then securely store the returned bot token for that workspace
Show answer & explanation
Correct: D — exchange the code with oauth.v2.access and store the bot token securely. In OAuth v2, the temporary code is exchanged server-side — using the client ID and client secret — through oauth.v2.access, which returns the access token (a bot token, xoxb-, plus a user token if user scopes were requested). That token is the credential the app stores, encrypted, per installation.
Why not the others: the temporary code (A) is short-lived and single-use, not a credential; asking for a personal token (B) bypasses OAuth and over-grants access; chat.postMessage (C) itself requires a token, so it cannot be the exchange step.
Source: Slack — Installing with OAuth →An internal-only app runs on a server inside a corporate network. Security policy forbids exposing any public HTTP endpoint, but the app still has to receive events and interactivity payloads.
Which delivery approach fits?
- Incoming webhooks, so Slack can push events to the app
- HTTP-based Events API delivery to a Request URL on the internal hostname
- Socket Mode, where the app opens a WebSocket connection to Slack using apps.connections.open and receives payloads over it
- Polling conversations.history every few seconds for new activity
Show answer & explanation
Correct: C — Socket Mode. Socket Mode lets an app receive events and interactive payloads without exposing a public Request URL: the app calls apps.connections.open and Slack delivers payloads over a WebSocket. Slack’s docs call out exactly this case — developers behind a corporate firewall.
Why not the others: incoming webhooks (A) only post messages into Slack and deliver no events; HTTP delivery (B) needs a Request URL Slack can reach from the public internet; polling (D) cannot receive interactivity payloads and burns Web API rate limits.
Source: Slack — Using Socket Mode →An identity team wants people created in its identity provider to be provisioned as Slack users automatically, placed in the right groups, and deactivated on their last day.
Which Slack API is designed for this?
- The Audit Logs API
- The SCIM API
- The Discovery API
- The Events API’s team_join event
Show answer & explanation
Correct: B — the SCIM API. The SCIM API provisions and manages user accounts and groups, including deactivation, and is what identity providers use for automated onboarding and offboarding. It is available on Business+ and Enterprise plans, and the token must come from an Owner or Admin — in an Enterprise organization, only Org Owners can install the SCIM app.
Why not the others: the Audit Logs API (A) monitors events but changes nothing; the Discovery API (C) serves eDiscovery, archiving, and data-loss prevention; team_join (D) only notifies an app after someone joins and cannot create or deactivate users.
Source: Slack — Using the Slack SCIM API → Further reading: PowerKram — Slack Administrator practice exam →An app is deployed organization-wide across twelve workspaces in an Enterprise organization (the structure the exam guide calls Enterprise Grid). It stores per-user preferences, and people regularly work across several workspaces.
How should the app key each person’s data so it follows them across workspaces?
- By the Enterprise user ID, which represents the same person across every workspace in the organization
- By the combination of the workspace team_id and the user’s display name
- By channel ID, so preferences are shared by everyone in the channel
- By a separate installation and database per workspace with no cross-workspace mapping
Show answer & explanation
Correct: A — the Enterprise (organization-wide) user ID. In an Enterprise organization, users keep one identity and profile across all workspaces, and the Enterprise user ID represents that person org-wide. Keying data to it keeps preferences consistent wherever the user works.
Why not the others: team_id plus display name (B) splits one person into many records, and display names change; a channel ID (C) identifies a conversation, not a person; isolated per-workspace stores (D) fragment identity and defeat an org-wide deployment.
Source: Slack — Enterprise organizations → Further reading: PowerKram — Slack Consultant practice exam →A /status slash command returns a detailed diagnostic readout. Channel members complain that every run clutters the conversation with output only the person who ran it needs.
What is the best UX fix?
- Post the readout as a pinned message so it is easier to find later
- Move the readout to an external web page and post the link in the channel
- Reply with an ephemeral message, visible only to the invoking user
- Post the readout to the channel and delete it after a minute
Show answer & explanation
Correct: C — reply with an ephemeral message. Ephemeral messages are shown temporarily to one specific user in the conversation — exactly right for requester-only output. A slash command can reply ephemerally through its response, and an app can also call chat.postEphemeral.
Why not the others: pinning (A) still posts to everyone and adds pin clutter; an external page (B) forces a context switch and still posts a link in channel; post-then-delete (D) still interrupts the channel and loses the information.
Source: Slack — chat.postEphemeral method →A team built an app in its own development workspace. Customers at other companies now need to install it, but the team is not ready to go through Slack Marketplace review.
What must the team do?
- Nothing — any Slack app can be installed in any workspace by default
- Submit the app to the Slack Marketplace, since that is the only way other workspaces can install it
- Share the app’s bot token with each customer so they can use it in their workspace
- Enable distribution and implement the OAuth 2.0 installation flow, so other workspaces can install it as an unlisted distributed app
Show answer & explanation
Correct: D — enable distribution with an OAuth flow, as an unlisted distributed app. A newly built app can only be installed in its own workspace. Activating distribution and building the OAuth flow lets other workspaces install it as an unlisted distributed app; Marketplace listing is a separate, optional step.
Why not the others: apps are not installable everywhere by default (A); the Marketplace (B) is not required for distribution; handing out a bot token (C) is insecure, and a token is tied to the workspace that issued it.
Source: Slack — App lifecycle & distribution →Each user needs a personal dashboard inside Slack that lists their open tasks and refreshes whenever they open the app — without posting anything into channels.
Which surface and method fit?
- A shared channel message that the app edits with chat.update for each user
- The App Home tab, publishing a per-user view with views.publish when the app_home_opened event fires
- A modal that opens automatically when the user signs in to Slack
- A scheduled direct message sent to every user each morning
Show answer & explanation
Correct: B — the App Home tab, published per user with views.publish. The App Home tab is a private, per-user surface. Subscribing to app_home_opened and calling views.publish with that user’s ID refreshes the dashboard each time they open the app, and nothing is posted to channels.
Why not the others: a channel message (A) is shared, not per-user; modals (C) need a trigger_id from a user interaction and cannot open on sign-in; a morning DM (D) is a snapshot, not a live dashboard, and adds noise.
Source: Slack — App Home →Keep going: study & career resources
Slack Developer sits at the point where Salesforce’s developer and collaboration tracks meet. Here is where to go next.
Deep dive: Slack Developer format, the heavy objectives, APIs, scale, and study path
Exam structure and scoring
The exam is 60 scored multiple-choice and multiple-select questions plus up to five unscored items mixed in at random, with 90 minutes to finish and a 67% passing score. It is proctored at a testing center or online, and it is closed book. Registration is US$200 with a US$100 retake. Questions align to the Summer ’24 release per the current guide, and holders renew by completing a Trailhead maintenance module once a year — there is no fixed multi-year validity. Salesforce — Slack Developer exam guide →
The two heaviest objectives: interactive flow and security
Design the Interactive Flow of Your App (20%) is about entry points and surfaces: slash commands, shortcuts, buttons, and events as triggers; Block Kit for layout; modals opened from a short-lived trigger_id; and the rule that every interaction must be acknowledged within 3 seconds. Design for Security (19%) covers the OAuth v2 install flow, choosing minimal scopes, knowing which token fits (bot xoxb-, user xoxp-, app-level xapp- for Socket Mode), verifying requests with the signing secret, and storing tokens safely. PowerKram — Enterprise security practices →
Slack’s APIs and the admin APIs
Spotlight on Slack’s APIs (13%) tests when to use the Web API versus the Events API, how Socket Mode differs from HTTP delivery, how to tell current terms from legacy ones (modals replaced dialogs; signing secrets replaced verification tokens), and how to handle the tiered Web API rate limits and HTTP 429 with Retry-After. APIs for Managing Your Slack (12%) is the administrator’s toolkit seen from the developer side: the Admin APIs, SCIM for users and groups, the Audit Logs API (installed by the Owner of an Enterprise organization), and the Discovery API for eDiscovery and DLP. PowerKram — Slack Administrator practice exam →
Scale, Slack Connect, and distribution
Design for Scale (9%) expects you to build for Enterprise organizations — org-wide deployment, users who keep one identity across workspaces, and the Enterprise sandbox for testing — and to know when to support Slack Connect channels, where the app receives messages and events from users on external teams. Distribute Your App (7%) covers the path from a single-workspace app to an unlisted distributed app (OAuth required) to a Marketplace listing, including the fact that Socket Mode apps cannot currently be listed in the public Slack Marketplace. PowerKram — Slack Consultant practice exam →
A realistic study path
Salesforce points to the Prepare for Your Salesforce Slack Developer Certification trailmix, but the recommended six months of API experience is the real preparation. Build at least one app end to end with Bolt: an OAuth install, a slash command that opens a modal, an App Home view, and an Events API subscription — once over HTTP and once in Socket Mode. Prototype layouts in Block Kit Builder, then use practice questions to find the objectives you have not touched. Developers who work in JavaScript can pair this with the Salesforce JavaScript Developer practice exam. Career Hub — Developer →
Slack Developer exam FAQ
How many questions is the Slack Developer exam, how long is it, and what score do I need?
What are the Slack Developer exam objectives and weights?
Are there prerequisites for the Salesforce Certified Slack Developer exam?
What does the exam cost, and does the certification expire?
The exam guide says Summer ’24 and Enterprise Grid. Is that out of date?
How long do I have access to this practice exam, and is it a subscription?
Prepare now, pay over time with Affirm & Klarna
Split the cost of full exam access into scheduled payments at checkout with Affirm or Klarna — start preparing right away without paying it all up front. Choose your plan when you check out.
Get full Slack Developer practice exam access
All nine objectives, both study modes, docs-linked explanations, objective-level scoring, and unlimited retakes for a full year.
Buy one exam, get a second free — and it’s backed by our satisfaction guarantee.
