Free Salesforce-Slack-Developer Practice Test Questions (2026)

Explanation:

The question asks about the relationship between Bolt and the Node/Python/Java Slack SDKs. Bolt is a framework that is built on top of the underlying Slack SDKs for each language, providing higher-level abstractions that make it faster and simpler to build Slack apps. In other words, the SDKs handle the low-level details of communicating with Slack's APIs — constructing HTTP requests, managing tokens, handling WebSocket connections for Socket Mode, parsing responses, and so on — while Bolt wraps those SDKs with an ergonomic, event-driven programming model. This layered design means a Bolt developer writes listeners like app.command(), app.action(), app.view(), and app.event() instead of manually handling raw HTTP requests and payload parsing.

❌ Why Other Options Are Incorrect:

A. They are unrelated products – This is false. Bolt is explicitly built on top of the Slack SDKs and depends on them at runtime; they are tightly related, not independent.

C. The SDKs replace Bolt entirely – This is false. The SDKs and Bolt serve different layers. The SDKs are the foundation; Bolt is the higher-level framework layered above them. Neither replaces the other.

D. Bolt only works without any SDK installed – This is false. Bolt requires the underlying SDK to function — for example, Bolt for Python installs and uses slack_sdk, and Bolt for JavaScript uses the Node Slack SDK packages. Bolt cannot operate without its SDK dependency.

📚 References:

Bolt for JavaScript documentation – States that Bolt is built on top of the Slack SDK for Node, using packages such as @slack/web-api and @slack/socket-mode.

Explanation

Socket Mode allows a Slack app to receive events and interactive payloads over a WebSocket connection instead of a public HTTP endpoint. When the app starts and calls apps.connections.open, Slack returns a WebSocket URL that is unique to that session — it is not a fixed or permanent address. Because the URL is generated fresh each time the app connects (and can change on reconnect), it is non-static and is created dynamically as the app is running. This makes option B the correct answer.

Why the other options are incorrect:

A. Socket Mode listens to a static WebSocket URL that is created dynamically as the app is running – The phrase "static WebSocket URL" is contradictory and incorrect. A static URL implies a fixed, unchanging endpoint, but Socket Mode URLs are unique per session and are not reused as a permanent address.

C. Socket Mode listens to a non-static WebSocket URL that is created at runtime – While "non-static" and "created at runtime" are both accurate descriptions, this option is incomplete compared to option B. The official Slack documentation emphasizes that the WebSocket URL is created dynamically while the app is running, and the wording in option B aligns more precisely with the documented behavior of the apps.connections.open flow.

D. Socket Mode listens to a static WebSocket URL that is created at runtime – This is incorrect because it combines two contradictory ideas. A URL cannot be both "static" (fixed and unchanging) and "created at runtime" in the way Socket Mode operates. Socket Mode URLs are non-static and session-specific.

Reference:

Slack Developer Documentation— Socket Mode overview, describing how apps call apps.connections.open to obtain a WebSocket URL and how that URL is dynamically generated per session.

Explanation

Slack Developer Tools is the officially recommended resource for inspecting posted messages and reviewing Slack API methods during development. It provides a built-in interface that lets developers view the exact payloads sent to and from Slack, inspect message structures in real time, and browse the available Slack API methods with their parameters and example responses. This makes option A the correct answer.

Why the other options are incorrect:

B. Postman – Postman is a general-purpose API testing tool that can be used to send manual HTTP requests to Slack's Web API, but it does not provide native, Slack-specific inspection of posted messages or an integrated reference for Slack methods. It requires manual configuration and does not offer the same out-of-the-box Slack context.

C. Chrome Developer tools – Chrome Developer Tools is useful for inspecting network traffic and debugging web applications in the browser, but it is not tailored to Slack app development. It cannot parse Slack-specific payloads or provide a curated view of Slack API methods, and it only captures traffic visible to the browser, not server-side events.

D. Slack CLI built-in debugger – The Slack CLI provides tooling for creating, running, and deploying Slack apps, and it does include logging and some debugging output. However, its debugger is focused on app execution and local development workflows rather than serving as a dedicated resource for inspecting posted messages and reviewing Slack API methods the way Slack Developer Tools does.

Reference:

Slack Developer Documentation — Slack Developer Tools overview, describing its use for inspecting messages and reviewing Slack API methods during app development.

Explanation

Socket Mode allows a Slack app to receive events, slash commands, and interactive payloads over a persistent WebSocket connection instead of requiring Slack to deliver those payloads to a publicly accessible HTTP endpoint. This means developers can build and test apps without exposing a public URL, which is especially useful for internal apps, apps behind a firewall, or local development environments. This makes option B the correct answer.

Why the other options are incorrect:

A. Using OAuth – Socket Mode does not remove the need for OAuth. Apps still must be installed to a workspace and obtain the appropriate tokens (bot token, app-level token, etc.) through the OAuth installation flow. Socket Mode changes the transport for receiving events, not the authorization model.

C. Using Block Kit – Block Kit is Slack's UI framework for building rich message layouts and modals. It is entirely independent of how the app receives events, and Socket Mode has no effect on whether an app uses Block Kit. Apps using Socket Mode can and often do use Block Kit.

D. Installing to a workspace – A Slack app must still be installed to a workspace regardless of whether it uses Socket Mode or HTTP endpoints. Installation is required to grant permissions and generate tokens, and Socket Mode does not bypass this step.

Reference:

Slack Developer Documentation — Socket Mode overview, which states that Socket Mode enables apps to receive events without exposing a public HTTP endpoint.

Explanation

In Bolt for Python, the @app.message decorator is used to listen for messages that match a specified text or pattern. It is a convenience listener built on top of the message event, allowing developers to respond to specific message content without manually filtering the raw event payload. For example, @app.message("hello") triggers when a user posts a message containing "hello". This makes option B the correct answer.

Why the other options are incorrect:

A. @app.event – The @app.event decorator is a general-purpose listener used to handle any Slack event by name, such as @app.event("app_mention") or @app.event("team_join"). While it can be used to listen for the message event, it does not natively filter by specific message text and requires manual handling of the event payload.

C. @app.listen – There is no @app.listen decorator in Bolt for Python. This is not a valid listener method in the Bolt framework. The closest concept is app.listen(), but that is a lower-level registration method, not a decorator used for matching specific message text.

D. @app.on_message – There is no @app.on_message decorator in Bolt for Python. This naming convention does not exist in the framework; the correct decorator for matching message text is @app.message.

Reference:

Slack Developer Documentation — Bolt for Python, "Listening for messages" guide, describing the @app.message decorator and its use for matching specific message text or patterns.

Explanation

Slack officially provides the Slack CLI as its command-line tool for scaffolding, running, and deploying Slack apps. The Slack CLI supports creating new apps from templates, running them locally, deploying them to Slack's hosted infrastructure, and managing app lifecycle tasks — all from the terminal. It works with Bolt for JavaScript and Bolt for Python projects. This makes option A the correct answer.

Why the other options are incorrect:

B. npm create-slack – There is no official npm package named create-slack provided by Slack for scaffolding apps. While npm is used to install dependencies for Bolt for JavaScript projects, it is not Slack's official scaffolding and running tool.

C. pip slack-init – There is no official pip package named slack-init from Slack. Python developers use pip to install slack_bolt, but pip itself is not a Slack-provided tool for scaffolding or running apps.

D. Bolt Studio – There is no official tool called "Bolt Studio" from Slack. This appears to be a fabricated or confusing name. Slack's official tooling for app development is the Slack CLI, sometimes used alongside the Slack Developer Tools.

Reference:

Slack Developer Documentation — Slack CLI overview, describing it as the official command-line tool for creating, running, and deploying Slack apps.

Explanation

In Slack's official Bolt framework (available for JavaScript/TypeScript and Python), the say() utility function is passed directly into listener functions (such as app.message(), app.command(), or app.action()). It allows your app to send a response message back to the exact channel or thread where the incoming event or interaction originated without requiring you to manually specify the channel_id or fetch a bot token.

Under the hood, calling say('hello') automatically invokes the chat.postMessage Web API method using the context-appropriate token and channel context.

Why the other options are incorrect:

A. reply() is not a built-in parameter or helper function in the Bolt framework event listener context payload.

B. send() is commonly seen in generic Node.js/Express response objects or standard WebSocket implementations, but it is not a standard Bolt listener argument.

D. respond_to() is not a standard Bolt listener helper. Bolt provides a respond() helper (which utilizes the response_url from interactive payloads), but respond_to() does not exist.

References

Slack Bolt for JavaScript – Basic Concepts (Listeners & say): Explains that the say() function sends a message to the channel associated with the incoming event.

Explanation

Slack's Bolt framework has exactly three official, first-party implementations maintained by Slack: Bolt for JavaScript, Bolt for Python, and Bolt for Java. C# is not among them — Slack does not provide an official Bolt framework for C#. Developers working in .NET can use the community-maintained SlackNet library, but it is not part of the official Bolt family. This makes option A the correct answer.

Why the other options are incorrect:

B. JavaScript – JavaScript is fully supported through Bolt for JavaScript (@slack/bolt), Slack's official first-party framework maintained in the slackapi GitHub organization.

C. Java – Java is fully supported through Bolt for Java (com.slack.api:bolt), part of the official Java Slack SDK maintained by Slack.

D. Python – Python is fully supported through Bolt for Python (slack_bolt), Slack's official first-party framework maintained in the slackapi GitHub organization.

Reference:

Slack Developer Documentation — Bolt framework overview, listing the official implementations for JavaScript, Python, and Java.

Explanation

The slack run command is used to run a Slack app locally in development mode while simultaneously installing it to a chosen workspace. When executed, the Slack CLI prompts the developer to select a workspace, installs (or reinstalls) the app to that workspace, and starts the app locally so that changes can be tested in real time. This makes option B the correct answer.

Why the other options are incorrect:

A. slack start – There is no slack start command in the Slack CLI. This is not a valid command; the correct command for local execution and workspace installation is slack run.

C. slack deploy – The slack deploy command deploys an app to Slack's hosted infrastructure for production use. It does not run the app locally, and it is intended for deployment rather than local development and testing.

D. slack serve – There is no slack serve command in the Slack CLI. This is not a valid command; local execution is handled by slack run.

Reference:

Slack Developer Documentation — Slack CLI command reference, describing slack run as the command that runs an app locally and installs it to a selected workspace for development and testing.