Free Practice Questions for Salesforce Slack-Dev-201 Exam

Slack's current Marketplace review policy explicitly requires applications to request only scopes associated with functionality that reviewers can currently test. Developers should not request access for speculative or future features. Because the feature requiring files:read does not yet exist, the application should omit that scope from the present submission. Once the feature has been implemented and can be demonstrated to Slack reviewers, the developer should update the requested OAuth permissions and submit the modified application for review again. That makes C correct. Option B is incorrect because adding a materially new scope to a published Marketplace application cannot simply bypass review. Slack reviews both application functionality and the permissions required to implement it. Options A and D violate least privilege by requesting access before any production feature requires it. This is particularly important for files:read, which Slack currently classifies among scopes that can provide substantial access to workspace data and may therefore trigger enhanced review. The older term App Directory in the source question corresponds to today's Slack Marketplace. This belongs to Distribute Your App, with a strong relationship to security through scope minimization and Marketplace review governance.

`app.action()` registers a Bolt action listener for interactions generated by Block Kit interactive components. Examples include button clicks, select-menu choices, overflow-menu selections, date-picker interactions, and other components that generate an `action_id`. The developer associates the listener with an action identifier or matching pattern, and Bolt invokes the registered function when Slack delivers the corresponding interaction payload. Slack's official Bolt examples demonstrate `@app.action("button_click")` for handling a button whose `action_id` is `button_click`. The listener should promptly call `ack()` so Slack knows that the interaction was received, after which the application can update a message, call an API, open another surface, or perform backend processing. `app.click()`, `app.select()`, and `app.interactive()` are not the standard Bolt listener methods for handling these Block Kit actions. Therefore, A is correct.

A clear privacy policy is a mandatory requirement for applications listed in what Slack now calls the Slack Marketplace. Slack requires the application's public landing page to provide a clear link to that privacy policy. The policy must explain, at minimum, what third-party data is collected, how that information is used, how long it is retained, and how individuals can request access, transfer, or deletion of their information. It must also provide a means of contacting the service regarding data-related requests. Slack specifically notes that even applications that do not actively use certain received data may nevertheless receive identifiers or other information through platform payloads, and this handling must be disclosed. Bank-account information is not a universal Marketplace submission requirement. A security assessment or penetration-testing report may become relevant for certain applications or review circumstances but is not the general listing requirement represented here. Slack also does not require every Marketplace description to be translated into every supported language. Therefore, B is correct. This belongs to Distribute Your App, specifically Marketplace listing requirements, privacy governance, and public application documentation.

Option C provides the cleanest modal architecture because each required decision is represented independently: reservation date, permitted time block, and the user's stored vehicle. A select menu is specifically designed to present a controlled list of choices without consuming excessive modal space. Slack's Block Kit specification provides date pickers, time/datetime elements, and select menus for precisely these kinds of structured inputs. A static or externally populated select menu can represent the employee's saved vehicles while the displayed option text can include identifying information such as license plate and parking classification. Option B becomes progressively unusable as users store more vehicles because one button per vehicle increases visual clutter and competes for limited modal space. Slack's design guidance emphasizes reducing unnecessary choices and avoiding overloaded surfaces. Option D combines the date and time into a datetime picker, but the scenario requires users to select a date and a defined time range/block, making separate controls more appropriate. Option A automatically preselects the previous vehicle, which can encourage users to submit an unintended selection and is not required by the scenario. Therefore, C remains the most appropriate Block Kit modal layout. This maps to Design a Great User Experience, particularly concise forms and appropriate input controls.

Slack recommends transmitting OAuth access tokens through the HTTP `Authorization` header using the Bearer authentication scheme. A typical request therefore includes a header such as `Authorization: Bearer xoxb-...`, where an `xoxb-` value represents a bot token. When using JSON request bodies for write methods, Slack explicitly requires the token to be transmitted as a bearer token in this header. Keeping credentials in headers also avoids exposing sensitive tokens through URLs, browser history, intermediary logs, or query-string processing. Slack does permit token transmission as an encoded POST body parameter in some cases, but the Authorization header is the preferred mechanism. `X-Slack-Token`, browser cookies, and the `Referer` header are not the documented authentication mechanisms for ordinary Slack Web API calls. Therefore, A is the verified answer.

Among the supplied options, B is the intended answer because Slack's Web API is HTTP-based and Web API responses are JSON objects. Successful and failed responses contain a top-level Boolean `ok` property, together with method-specific fields or an `error` value. Many write methods also accept `application/json` request bodies. However, one technical correction is important: current Slack documentation explicitly states that the Web API is not a REST API. Slack describes it more precisely as a collection of HTTP RPC-style methods with endpoints such as `https://slack.com/api/METHOD_FAMILY.method`. Therefore, “REST with JSON” is not perfectly worded, but it is still the only defensible choice among A–D because SOAP/XML, GraphQL, and gRPC are incorrect. For current Slack terminology, “HTTP RPC-style methods with JSON responses” would be more precise.

Slack's documented macOS and Linux installation method uses the official shell installer hosted on Slack's downloads domain. The command `curl -fsSL https://downloads.slack-edge.com/slack-cli/install.sh | bash` retrieves the installer securely and runs it through Bash, installing the Slack CLI and making the `slack` command available for development. Slack's current CLI installation documentation presents this command as the supported installation path for macOS and Linux. The alternatives do not represent the official installation command in the Slack Developer documentation: Slack CLI is not installed through the listed npm or pip commands, and `brew install slack` does not correspond to Slack's documented CLI installer. Therefore, option B is the verified installation command for the environments named in the question.

Slack defines every Audit Logs API event around four principal components: action, actor, entity, and context. The action specifies what occurred—for example, a user login, application installation, role change, or file-related administrative event. The actor identifies the user, application, or system responsible for performing the action. The entity represents the Slack resource affected by that action. The context provides environmental information surrounding the event, such as the location, workspace, organization, or session-related information relevant to interpreting what happened. Slack summarizes this relationship conceptually as an actor taking an action on an entity within a context. This structured model enables security teams to ingest Slack audit data into SIEM, monitoring, anomaly-detection, and forensic-analysis systems. Option A substitutes the vague terms “event” and “user,” which do not reflect Slack's formal audit schema. Option B incorrectly replaces entity with team, and D omits context. For certification purposes, these four fields are foundational because Audit Logs API workflows depend on understanding who performed an activity, what activity occurred, which resource was affected, and the surrounding operational context. This question belongs to APIs for Managing Your Slack, specifically the Audit Logs API data model.

A and C are the two choices that best align with the current official Slack design guidance. Slack emphasizes concise, easily processed content. Applications should communicate clearly and minimize unnecessary cognitive load so users can understand information quickly rather than reading lengthy or overly complex interfaces. This supports the principle represented by option A. Slack's Block Kit design guidance also recommends simplifying suitable information with pictures. For example, faces may communicate user identity more efficiently than lists of names, and maps can sometimes communicate location more effectively than text. Images must still be accessible through appropriate alt_text; the recommendation is not to remove essential textual meaning indiscriminately. Option B is incorrect under current official guidance. Slack explicitly states that shortcut names should start with a verb, not a noun. Option D conflicts with Slack's recommendation to avoid excessive notifications, while option E is directly contrary to the guidance to reduce complexity by progressively revealing controls and information. The supplied document marks A and B, but B conflicts with Slack's published developer guidance and therefore should not be retained as the verified answer. This question belongs under Design a Great User Experience.

A Slack application created for use exclusively inside its associated workspace does not need public distribution or a multi-workspace OAuth installation architecture. Slack classifies such an application as an undistributed or single-workspace app. It can be installed directly into its associated development workspace through the app-management configuration. Because the IT manager needs access to the app's configuration, adding that person as an application collaborator provides the appropriate administrative access. The collaborator can then install the application to the Business Operations workspace through the app dashboard. Option A unnecessarily enables distribution to other workspaces. Once public distribution is activated, Slack provides a shareable installation URL intended for multi-workspace installations. Option C similarly introduces OAuth infrastructure that is required when distributing an application beyond its associated workspace but is unnecessary for this internal single-workspace scenario. Option D is even broader because Slack Marketplace publication is intended for externally distributed applications that have completed Slack's review process. Slack's current lifecycle documentation confirms that newly created apps reside in an associated workspace and can be installed there directly without building a separate authorization flow. This belongs to Distribute Your App, particularly understanding single-workspace versus distributed application models.