Salesforce Certified Slack Developer Slack-Dev-201 Exam Questions

Page: 1 / 14
Total 134 questions
Question 1

You are the sole developer on a Slack application and you are ready to distribute the app on the App Directory. You invite a few of your coworkers to be App Collaborators through the Collaborators page in the App Dashboard.

What can App Collaborators do when added as a Collaborator through the App Dashboard?



Answer : D

The supplied Slack Developer question bank identifies D, and the central collaborator-management behavior remains consistent with current Slack documentation. App collaborators are intended to share responsibility for an application's configuration rather than leave application administration dependent upon one developer. Current Slack guidance confirms that collaborators can manage an application's settings and that existing collaborators can add additional collaborators. Slack Marketplace guidance also requires Marketplace applications to have another collaborator, specifically to ensure continued configuration access if the original application creator leaves the associated workspace. Collaborator membership therefore represents administrative access to the application rather than ordinary end-user access. An important distinction concerns ownership. Being added as an App Collaborator does not mean a collaborator can simply unilaterally designate themselves the application owner. Current Slack tooling explicitly distinguishes collaborator permission from owner permission; owner assignment is a separate permission operation in supported Slack CLI workflows. That eliminates options A, B, and C because each incorrectly includes self-assignment as owner. Accordingly, D remains the exam-bank answer. Current Slack terminology also uses Slack Marketplace rather than App Directory. This maps to Distribute Your App, particularly application ownership continuity, collaborators, and Marketplace operational requirements.


Question 2

What is exchanged for an access token at the end of the OAuth installation flow?



Answer : B

Slack's OAuth 2.0 authorization-code flow issues a temporary authorization code after the installing user reviews and approves the permissions requested by the application. Slack redirects the user to the application's configured redirect URI with this temporary code. The application backend then sends the code to Slack's token-exchange endpoint together with the required application credentials. If the exchange succeeds, Slack returns the applicable access credentials, which can include bot or user tokens depending on the requested authorization. Slack explicitly summarizes the process as requesting scopes, receiving user approval, and exchanging a temporary authorization code for an access token. A workspace ID identifies the Slack workspace but is not exchanged for credentials. Application manifests describe configuration, and user passwords must never be collected as part of Slack OAuth. Therefore, B is correct.


Question 3

Which token type is generally scoped to a single workspace installation and used for most API calls?



Answer : B

A bot token represents the bot identity associated with a Slack app installed in a workspace and is the standard credential used by many Slack applications when calling Web API methods. Modern bot tokens use Slack's granular permission model, meaning their actual capabilities are determined by the bot scopes approved during installation. Bot tokens conventionally begin with `xoxb-`. They differ fundamentally from app-level tokens, which represent the application itself across installations and are limited to specific application-level functionality such as Socket Mode connectivity. A session cookie is not an application API credential. A refresh token is used when token rotation is enabled to obtain replacement access tokens rather than serving as the ordinary credential for API operations. Consequently, among the available choices, the bot token is the correct token type for routine workspace application API operations.


Question 4

Where would a developer look first to start building an AI agent for Slack?



Answer : A

The official Slack Developer documentation provides a dedicated Agent quickstart specifically for developers beginning an AI-powered Slack agent project. The quickstart covers the essential starting workflow: installing Slack CLI, logging into a development workspace, creating the support-agent sample project, selecting an AI agent framework, configuring required credentials, and running the application locally with `slack run`. Slack's general application quickstart also directs developers who want to explore agent development to the Agent quickstart as the next starting point. The pricing, legal, and Marketplace pages do not provide the implementation sequence needed to build an agent. Accordingly, the developer documentation path identified in option A is the appropriate first technical resource. The PDF's supplied answer is therefore verified as correct against Slack's current documentation.


Question 5

What prefix commonly identifies a bot token in Slack?



Answer : A

Slack bot tokens use the `xoxb-` prefix. These tokens represent the application's bot identity within an installed Slack workspace and carry the granular bot OAuth scopes granted during installation. Slack's official token documentation explicitly states that bot token strings begin with `xoxb-`. Developers must treat these values as secrets because possession of a valid token can permit API operations authorized by its associated scopes. Credentials should therefore be stored in a secure secrets-management system or protected environment rather than embedded in source code or exposed in logs. The `xapp-` prefix belongs to app-level tokens, which are used for application-level functionality such as Socket Mode. The remaining prefixes do not represent the standard Slack bot token type described by this question. Therefore, option A is correct.


Question 6

Your growing HR team wants to send newsletters regularly to specific regional Slack channels. They are unable to automate the process themselves.

How can Block Kit Builder help your HR team?



Answer : B

Block Kit Builder is Slack's visual prototyping environment for designing and previewing Block Kit layouts. It allows users to add, rearrange, and configure blocks while simultaneously reviewing the associated JSON representation and seeing how the completed layout will render. For the HR newsletter use case, the team can therefore construct and visually review a formatted message before the application or automation sends it to the required regional channel. Slack describes Block Kit Builder as a tool for choosing, configuring, arranging, and previewing blocks across Slack surfaces. Option A overstates its function: Block Kit Builder is not fundamentally a template-management repository for organizing recurring newsletters. Option C is also too broad. The builder can expose example interaction payloads and validate message composition, but it does not execute an application's complete backend interactivity workflow end-to-end. Option D is unsupported; it does not automatically convert arbitrary word-processing documents into production-ready Block Kit structures. Therefore, B accurately describes its intended role: prepare and preview the Slack UI/message composition before deployment. This belongs to Tools, specifically Block Kit Builder and visual prototyping of Slack application surfaces.


Question 7

While building a Slack app, when must you implement Slack OAuth 2.0 to obtain tokens?



Answer : C

Slack distinguishes between a development application installed only in its associated workspace and an application intended for installation across multiple workspaces. For a single-workspace application, Slack allows installation directly through the application's configuration without requiring the developer to implement a complete OAuth installation flow. Once an application is distributed to other workspaces, however, each installation must be explicitly authorized. Slack therefore requires the application to implement the OAuth 2.0 authorization-code flow and store the resulting installation information, including the applicable access tokens. OAuth is not required merely because an application has slash commands or a bot user. Those features require appropriate scopes and application configuration, but they do not independently dictate multi-workspace OAuth installation. OAuth is also not simply an optional additional security layer; it is Slack's authorization mechanism for obtaining workspace-specific authorization during distributed installation. The application typically sends the installer to Slack's authorization endpoint, receives a temporary authorization code through its configured redirect URI, exchanges that code through oauth.v2.access, and securely stores the resulting installation credentials. Therefore, C is correct and maps directly to Distribute Your App, particularly multi-workspace installation and OAuth-based authorization.


Page:    1 / 14   
Total 134 questions