Free Salesforce Slack Developer Practice Test Questions

Explanation:

The app must respond when a user posts a message containing "hello" in public channels the app is in. To do that, the app needs two capabilities:

Read message content in those public channels so it can detect "hello" — this requires channels:history (read messages in public channels the app is a member of).

Send its response back into the channel — this requires chat:write (post messages as the app/bot).

So the two scopes needed tomorrow are chat:write and channels:history. Note the key exam concept: request only the scopes you need now — do not pre-request scopes for the "next year" features (joining channels, reacting to messages), because Slack reviews require scopes to map to existing functionality.

✅ D. chat:write and channels:history – Reading messages (channels:history) and posting responses (chat:write) cover the app's current functionality.

❌ Why Other Options Are Incorrect

A. chat:write and channels:join – channels:join supports the future "join channels" feature, which isn't needed tomorrow. It also omits channels:history, which is required to read messages.

B. channels:join and reactions:write – Both relate to future features (joining channels and reacting). Neither covers reading messages, and the response scope should be chat:write, not reactions:write.

C. channels:read and reactions:write – channels:read lists channel info but does not read message content (that's channels:history), and reactions:write is for the future feature. Neither matches tomorrow's needs.

📚 References

Slack API Docs – Scopes (chat:write, channels:history) – channels:history reads messages in public channels; chat:write posts messages.

Slack API Docs – Scope best practices / App review – Request only scopes used by current functionality; future features require a new submission.

Explanation

Slack uses OAuth scopes to grant an app specific permissions. When a user or admin installs your app, Slack's OAuth flow asks for consent to a defined set of scopes — each scope grants access to particular methods, resources, or event data (e.g., chat:write to post messages, channels:history to read public-channel messages, users:read to view user info). The resulting access token is bound to exactly those approved scopes, and every API call your app makes is authorized (or rejected) based on them.

This follows the principle of least privilege: apps should request only the scopes their functionality actually needs. Scopes come in types (bot, user, and admin/org-level), and they determine both what the app can do and what events it can receive. Apps get scopes via OAuth installation, and changes to scopes require re-authorization and (for distributed apps) a new review.

✅ B. OAuth scopes – Slack grants app permissions through OAuth scopes tied to the installation token.

❌ Why Other Options Are Incorrect

A. IP allowlisting – IP allowlisting is a network security control, not a permission-granting mechanism for apps. It doesn't define what an app can do.

C. Workspace passwords – Users' passwords are unrelated to app authorization. Apps never receive or use workspace passwords.

D. App manifests alone – A manifest describes an app's configuration, including requested scopes, but the manifest itself does not grant permissions — the OAuth installation of those scopes does.

📚 References

- Slack API Docs – Permission scopes – Defines OAuth scopes as the mechanism granting apps specific permissions.

- Slack API Docs – Installing with OAuth – Explains how scopes are requested and approved during installation.