Free Slack-Dev-201 Questions Attempt

The Discovery API is specifically designed for Enterprise security, compliance, archiving, and eDiscovery use cases involving extraction of Slack content into approved third-party systems. Slack explicitly describes eDiscovery applications as pulling messages and files from Slack and storing the information in third-party data warehouses, where that content can subsequently be searched, archived, or retrieved. The Discovery API can provide organization-level message and file information, including historical content that remains available under applicable retention and legal-hold policies. Its use is restricted to approved security and compliance scenarios such as eDiscovery, archiving, and Data Loss Prevention. The Audit Logs API provides administrative and security event records rather than the actual body of message and file content needed for an external archive. Admin APIs manage Enterprise configuration and administrative resources. Legal Holds preserve relevant Slack data from deletion or retention-policy expiration but are not themselves the general extraction mechanism described in the scenario. Therefore, D directly matches the legal department's requirement to transfer Slack content into a third-party data warehouse. This question belongs to APIs for Managing Your Slack, specifically Enterprise content governance, eDiscovery, archiving, and Discovery API use cases.

One of the strongest benefits of Slack app manifests is that application configuration becomes portable, reviewable, and reproducible. Slack explicitly recommends storing manifests in version-control systems such as GitHub, where collaborators can understand application setup and track configuration changes over time. A manifest can then be reused to create or configure apps consistently instead of manually reproducing settings through the web interface. This significantly reduces configuration drift between development, testing, and related application environments. A manifest is not the only mechanism for enabling bot functionality, does not eliminate OAuth authorization requirements, and does not automatically publish an application to the Slack Marketplace. Distribution and Marketplace publication remain separate lifecycle processes with their own requirements. Therefore, the version-controlled and repeatable configuration benefit described in B is precisely aligned with Slack's manifest documentation.

A Slack application distributed across multiple independent workspaces must implement an OAuth installation flow. Slack explicitly states that enabling installation on other workspaces allows the application to generate access tokens for each workspace and applicable user authorization. Bolt's current OAuth documentation likewise explains that each app installation issues unique access tokens and installation information that the application must store securely and retrieve when processing requests. This is fundamentally different from a single-workspace application, which can receive one access token through direct installation without implementing the full distributed OAuth flow. Independent workspaces do not normally share one universal token. Organization-wide Enterprise installations are a distinct model and can use an organization-level authorization, but that does not invalidate the standard multi-workspace distribution behavior tested here. Therefore, A is correct.

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.