Explanation:

A multi-workspace design can make sense (e.g., regulated environments, complex organizations, or partner separation), but the biggest tradeoff is that it increases context switching for users (who must jump between workspaces).

It also reduces scalability because conversations, discoverability, and collaboration are fragmented across multiple workspaces rather than centralized in one.

Admin overhead (option C) is less of an issue in this scenario since the admin team is well-staffed and trained (per the prompt).

Notification noise (option A) is actually better managed in a multi-workspace setup since users only join relevant workspaces.

Slack Connect (option B) isn’t the key issue — Slack is designed to securely handle external collaboration through Slack Connect or dedicated workspaces.

📖 Reference: Slack Enterprise Grid Overview → notes that multi-workspace setups often create complexity in user experience and scaling.

Explanation:

✅ Why A is Correct:
This strategy strikes the perfect balance between enabling productivity and maintaining security. By pre-approving a curated list of common, vetted apps (like Google Drive, Outlook, Jira, etc.), you remove friction for users—they can install these apps immediately without waiting for approval. Simultaneously, by proactively restricting known risky apps, you prevent security threats. This creates a seamless and secure "Day 1" experience.

❌ Why other are Incorrect:

Option B:
While the Admin API is powerful for automation, it is a technical tool, not a policy. The API can enforce a policy of auto-approving certain apps, but the critical first step is to define the policy itself (i.e., deciding which apps to pre-approve), which is described in option A. This is the more fundamental and correct answer.

Option C:
Turning on app approvals but requiring individual requests for every app creates significant friction and administrative overhead. This would hinder, not maximize, the value received on the first day, as users would be blocked from using apps until their requests were manually reviewed and approved.

Option D:
Restricting apps based solely on popularity ("not commonly used") is a poor security practice. A less common app might be critical for a specific team's workflow and perfectly secure, while a very common app could have known security vulnerabilities. Security decisions should be based on a risk assessment, not popularity contests.

Reference:
Slack Help Center - "Manage app approval for your workspace"

Explanation:

✅ Why A is Correct:
A Workspace Owner has all the same permissions as the Primary Owner, including the ability to deactivate any member's account, including other Owners. The deactivation process is immediate. The user is signed out of all sessions and cannot log back in.

❌ Why other are Incorrect:

Option B:
The "inactive" status is a result of deactivation; it is not a delayed process. The 72-hour concept is not part of the standard user deactivation process in Slack.

Option C:
Workspace Admins have fewer permissions than Workspace Owners. An Owner would not need to ask an Admin (a role with lower privileges) to perform a task they are fully authorized to do themselves.

Option D:
While the Primary Owner is a unique and important role, any Workspace Owner has the privileges to deactivate another Owner. The Primary Owner is the only one who can transfer the Primary Owner role itself, but not the only one who can manage user accounts.

Reference:
Slack Help Center - "Workspace roles and permissions" (This shows that Owners and Admins can deactivate accounts).

Explanation:

🟢 Why C is Correct: This is the most direct and secure course of action. The core problem is a terminated employee with active system access. The automated system (SCIM via Okta) is down, so manual intervention is required. A Workspace Admin has the authority to manually deactivate a user account immediately, which is the correct procedure to stop the disturbance and secure the workspace. Proactively coordinating with HR for further manual updates is a logical and responsible next step until the automated system is restored.

🔴 Why A is Incorrect: While changing the email and forcing a logout might prevent login if the user logs out, it is an incomplete and non-standard solution. The user's account would still be active, and they could potentially continue causing a disturbance if they are currently logged in on a mobile or desktop app. Deactivation is the definitive action for terminating access.

🔴 Why B is Incorrect: This only addresses the symptoms (the messages in #general) but not the root cause (the terminated user still has an active account). The user could simply move their disruptive behavior to another channel. Relying on a former manager to intervene is unprofessional and not a reliable security practice.

🔴 Why D is Incorrect: While contacting Okta is necessary to resolve the underlying outage, it is not the immediate step. The priority is to immediately stop the security incident (the terminated user's access). This can and should be done manually by the admin first; then, the outage can be addressed in parallel.

Reference: Slack Help Center - "Deactivate a member's account"

Explanation:

Why C is Correct: The primary purpose of Enterprise Key Management (EKM) is to give an organization ultimate control over its data encryption keys. By revoking a key, you instantly render all messages and files encrypted with that key unreadable. This is the most powerful and immediate action to take in a data leak or compliance incident, as it effectively "shreds" the mistakenly shared sensitive information, even if it has already been posted.

Why A is Incorrect: Inviting a Multi-Channel Guest is a standard user management function. EKM keys are not revoked for routine user access changes. Access for guests is controlled by their membership status, not by cryptographic key revocation.

Why B is Incorrect: Working with contractors via Slack Connect is a sanctioned collaboration method. EKM is designed to enable secure collaboration with external parties by allowing the organization to retain control of its keys, not to prevent it. Revoking a key would sever access for all users in that workspace or channel, including internal employees, which is not the desired outcome for normal contractor collaboration.

Reference: Slack Help Center - "About Enterprise Key Management for Slack"