Free Practice Questions for Tableau SCA-C01 Exam

In Tableau Server,projectsare containers for organizing and securing content. They help manage permissions and structure content hierarchically. Let’s define what can be contained:

Workbooks: Visualizations and dashboards published to the Server.

Data Sources: Published connections or extracts reusable across workbooks.

Nested Projects: Sub-projects within a parent project, introduced in later versions (e.g., 2018.2) for deeper organization.

Option B (Workbooks): Correct. Workbooks are the primary content type in projects, containing views and dashboards.

Option C (Nested Projects): Correct. Nested projects allow hierarchical structuring (e.g., a "Sales" project with "Q1" and "Q2" sub-projects), with inherited or custom permissions.

Option D (Data Sources): Correct. Published data sources reside in projects, providing reusable data connections.

Option A (Groups): Incorrect. Groups are collections of users managed at the site or server level, not stored within projects. Projects contain content, not user entities.

Why This Matters: Projects are key to content governance—knowing what they hold helps administrators organize and secure assets effectively.

Data-driven alerts notify users when data meets conditions (e.g., sales > $10K). Let’s examine when Tableau checks these:

Alert Mechanics:

Enabled per site (Settings > General > Data-Driven Alerts).

Backgrounder evaluates conditions against extract data.

Check Intervals: Configurable via tsm configuration set -k dataAlerts.checkIntervalInMinutes (default: 60 minutes).

Refresh Trigger: Also checks post-extract refresh for immediate updates.

Option A (Every 60 minutes): Correct.

Details: Default interval—Backgrounder polls every hour to evaluate alert conditions.

Config: Adjustable (e.g., -v 30 for 30 minutes).

Option D (Whenever extracts in the related workbook are refreshed): Correct.

Details: An extract refresh updates the data, triggering an immediate alert check to catch changes promptly.

Why: Ensures timely notifications without waiting for the next poll.

Option B (Every 10 minutes): Incorrect.

Why: Not the default—possible via config, but not standard.

Option C (Whenever a new extract is published): Incorrect.

Why: Publishing creates the extract; alerts trigger on refreshes or polling, not initial publication.

Why This Matters: Timing affects alert responsiveness—balancing frequency and server load is key.

Deleting a user in Tableau Server involves handling their owned content (workbooks, data sources)—let’s analyze the process:

Deletion Rules:

Ownership Check: Tableau prevents deletion if the user owns content to avoid orphaning it.

Action: Instead of deleting, the user’s site role is set toUnlicensed, retaining their account and content ownership.

Resolution: An admin must reassign ownership (e.g., viaUsers > Actions > Change Owner) before deletion.

Option D (User switched to Unlicensed and NOT deleted): Correct.

Details: Attempting deletion (e.g.,Users > Select User > Actions > Delete) triggers a check. If content exists, the user becomes Unlicensed—still in the system but unable to log in.

Why: Protects data integrity—content remains accessible for reassignment.

Option A (Deleted, content to server admin): Incorrect.

Why: No automatic reassignment to the server admin—manual action is required first.

Option B (Deleted, content to project leader): Incorrect.

Why: Project leaders don’t automatically inherit content—no such mechanism exists.

Option C (User and content deleted): Incorrect.

Why: Tableau avoids deleting content with the user—too destructive without explicit intent.

Why This Matters: This safeguard prevents accidental data loss, ensuring admins manage ownership transitions deliberately.

Comments on Tableau Server visualizations facilitate collaboration. Let’s explore what’s supported:

Comments Feature: Enabled per site (Settings > General > Allow Comments). Users with "Add Comment" permission can post on views.

Option B (Text): Correct.

Details: The primary content type—users type free-form text in the comment box.

Use: Notes, questions, or feedback (e.g., "Sales spiked here—why?").

Option C (@mentions): Correct.

Details: Typing @username notifies the mentioned user via email or the UI (if notifications are enabled).

Use: Directs comments to specific people (e.g., "@John, check this trend").

Option A (Interactive snapshots of a view): Incorrect.

Details: Snapshots (static images) aren’t supported in comments—users must take screenshots externally and can’t embed them interactively.

Option D (Images - jpg, png): Incorrect.

Details: No attachment or image embedding in comments—text and mentions only. Workaround: Link to an image hosted elsewhere.

Why This Matters: Comments enhance teamwork, but their simplicity (text + mentions) keeps the interface lightweight and focused.

Installing Tableau Server on Windows requires an account with sufficient privileges to configure services, write to the file system, and manage registry settings. Let’s analyze this in depth:

Installation Requirements:

The installer creates services (e.g., Tableau Server Gateway), writes to Program Files and ProgramData, and configures TSM.

It needslocal administrative privilegeson the machine to perform these tasks.

Post-install, a "Run As" account can be set for services (e.g., NT AUTHORITY\NetworkService), but this is separate from the install account.

Option C (An account in the local administrator group): Correct.

Why: The account must be in the local Administrators group to:

Install software (UAC elevation).

Configure services and ports.

Write to protected directories (e.g., C:\Program Files\Tableau).

Examples: A local admin (e.g., Administrator) or a domain user added to the Administrators group (e.g., DOMAIN\AdminUser).

Process: Log in as this account, run the installer, and provide TSM admin credentials during setup.

Option A (A local user account): Incorrect.

A standard local user (not in Administrators) lacks permissions—installation would fail with "Access Denied" errors.

Option B (A domain user account): Incorrect unless clarified.

A domain user without local admin rights can’t install. If it’s in the Administrators group, it qualifies, but C is more specific.

Option D (NT AUTHORITY\NetworkService): Incorrect.

This is a built-in service account for running services (default "Run As" post-install), not for executing the installer—an interactive user account is required.

Why This Matters: Using the right account prevents install failures and ensures secure configuration—critical for production setups.

When Tableau Server uses Active Directory (AD) for authentication, group synchronization imports AD groups and assigns aminimum site role(e.g., Viewer, Explorer) to users in that group. This ensures users meet a baseline access level. The behavior for existing users during sync is:

If the user’s current site role providesmore accessthan the minimum (e.g., Explorer vs. Viewer), their roleremains unchanged.

If the user’s current role providesless accessthan the minimum (e.g., Unlicensed vs. Viewer), their role isupgradedto the minimum.

This preserves higher privileges while enforcing a floor. “Reduces access” means the minimum role is lower than the current role (e.g., Viewer vs. Explorer), in which case the existing role stays.

Option A (It will change to the minimum site role only if the minimum site role reduces access): Correct. The user’s role changes only if the minimum increases access (e.g., Unlicensed to Viewer); otherwise, it stays higher.

Option B (It will change only if the minimum provides more access): Incorrect wording. This is the inverse of the actual behavior—change occurs when needed to meet the minimum, not to exceed it.

Option C (It will always change): Incorrect. Existing higher roles are preserved.

Option D (It will never change): Incorrect. It changes if the current role is below the minimum.

Tableau Desktop and Tableau Server have versioning considerations when publishing content, particularly regarding compatibility between older Desktop versions (e.g., 10.5) and newer Server versions (e.g., 2020.1). Let’s break this down step-by-step:

Version Context: Tableau Desktop 10.5 was released in 2017 and used the .tde (Tableau Data Extract) format for extracts. Tableau Server 2020.1, released in 2020, introduced the .hyper extract format (starting with version 10.5, but fully standardized later). When publishing from an older Desktop version to a newer Server version, Tableau ensures backward compatibility but may upgrade certain components.

Publishing Process: With a Creator site role and Publisher permissions, you have the rights to publish workbooks to the specified project. Tableau Server accepts workbooks from older Desktop versions (e.g., 10.5) and upgrades them to the current Server version (2020.1) duringpublishing. This process is seamless for the workbook itself, but extracts require special handling.

Extract Handling: If the workbook contains embedded .tde extracts (stored within the .twb or .twbx file), Tableau Server 2020.1 converts these to .hyper format upon publishing. This conversion is necessary because .hyper replaced .tde as the default extract engine starting in Tableau 10.5 and beyond, offering better performance and scalability. During this process, Tableau Desktop or Server displays a warning to inform the user of the upgrade, as it’s a one-way conversion (you can’t revert to .tde on the Server).

Now, let’s evaluate the options:

Option A (You will successfully publish without any errors or warnings): Incorrect. While the publishing succeeds, a warning about the .tde to .hyper conversion appears if the workbook contains embedded extracts. Without extracts, no warning occurs, but the question’s context implies extracts are likely involved (common in visualizations).

Option B (Error message: unable to publish to a newer version): Incorrect. Tableau supports publishing from older Desktop versions to newer Server versions. There’s no outright error blocking this; compatibility is maintained.

Option C (Warning: embedded .tde extracts will be upgraded to .hyper): Correct. This is the precise warning displayed when a workbook with .tde extracts is published to a Server version that uses .hyper. It ensures the user is aware of the format change, which might affect extract refresh schedules or performance expectations.

Option D (Warning: workbook will be upgraded to a new version): Partially correct but less specific. The workbook is upgraded to 2020.1 compatibility, but the warning focuses on the extract format change (.tde to .hyper), not the workbook version generically. Option C is more accurate.

Why This Matters: The .tde to .hyper shift improves query performance and supports larger datasets, but users need to know about it for planning (e.g., extract refresh schedules might need adjustment). The warning ensures transparency.

Single Sign-On (SSO) allows users to authenticate once (e.g., via a corporate identity provider) and access Tableau Server without re-entering credentials. Tableau Server supports several SSO methods:

OpenID Connect (OIDC): An OAuth 2.0-based protocol for SSO, configured via Tableau’s SAML settings with an OIDC-compatible IdP (e.g., Google, Okta).

Kerberos with Active Directory: A ticket-based SSO protocol, widely used in Windows environments with AD integration.

SAML: A flexible SSO standard using XML assertions, supporting various IdPs (e.g., ADFS, PingFederate).

Let’s evaluate:

Option A (OpenID Connect): Correct. OIDC is an SSO method, implemented as a SAML variant in Tableau Server, enabling seamless login.

Option C (Kerberos with Active Directory): Correct. Kerberos provides SSO in AD environments, delegating authentication to the domain controller.

Option D (Security Assertion Markup Language - SAML): Correct. SAML is a core SSO method in Tableau, widely adopted for enterprise integrations.

Option B (Local Authentication): Incorrect. Local Authentication uses Tableau’s internal user database, requiring manual credential entry—no SSO support.

Why This Matters: SSO enhances user experience and security by leveraging existing identity systems, reducing password fatigue.

Kerberos delegationallows Tableau Server to pass a user’s Kerberos credentials to a data source for seamless authentication (SSO)—let’s explore which sources support it:

Kerberos Overview:

Used with Active Directory (AD) for SSO in Windows environments.

Tableau Server delegates the user’s ticket to the data source, avoiding embedded credentials.

Requires:

Data source support for Kerberos.

Proper configuration (e.g., SPN, constrained delegation).

Supported Data Sources: Per Tableau’s documentation:

Option A (Teradata): Correct.

Details: Supports Kerberos delegation—common in enterprise data warehouses.

Config: Enable in TSM (tsm authentication kerberos configure) and set SPN for Teradata.

Option C (SQL Server): Correct.

Details: Fully supports Kerberos—widely used with AD-integrated SQL Server instances.

Config: Requires AD setup and "Trustworthy" delegation in SQL Server.

Option D (SAP HANA): Correct.

Details: Supports Kerberos SSO via delegation—popular in SAP ecosystems.

Config: Needs HANA Kerberos setup (e.g., keytab) and Tableau Server integration.

Option B (PostgreSQL): Incorrect.

Why: Supports Kerberos authentication natively, but Tableau Server doesn’t enable delegation to PostgreSQL—users must embed credentials or use other methods (e.g., OAuth).

Why This Matters: Kerberos delegation enhances security by avoiding stored passwords—knowing supported sources ensures SSO feasibility.