Analytics-Admn-201 Practice Exam Tests Latest Updated on Sep-2026 [Q25-Q44]

Tableau Server’s user-based licensing model assigns licenses to individual users (Creator, Explorer, Viewer) rather than machines or cores. Key features include:
Subscription license: Licenses are typically subscription-based, renewed annually or monthly, aligning with Tableau’s pricing model.
Distinct user roles: It supports three roles (Creator, Explorer, Viewer), each with specific capabilities, enabling granular access control.
Option A (A subscription license): Correct. User-based licenses are subscription-based by default.
Option B (Enables distinct user roles): Correct. The model defines Creator, Explorer, and Viewer roles.

Editing permissions on a workbook in Tableau Server depends on the user’s role and the project’s permission settings. Since permissions are not locked (i.e., “Managed by Owner”), let’s dissect who can edit them:
Permission Model:
Not Locked: Owners of content (workbooks, data sources) can set permissions, and Project Leaders can override at the project level.
Site Roles: Define maximum capabilities (e.g., Viewer, Explorer, Creator). Capabilities: “Set Permissions” is explicit–only certain users get it.
Option C (The workbook’s owner): Correct.
Details: The owner (typically the publisher) has full control over their workbook when permissions are Managed by Owner:
How: In the UI, go to Content > Workbooks > Actions > Permissions–owners can edit rules (e.g., grant Editor to a group).
Site Role: Minimum of Explorer (can publish) or Creator to publish, ensuring “Set Permissions” capability.
Why: Ownership inherently includes permission management unless locked.
Option D (Users set to Project Leader for the workbook’s project): Correct. Details: Project Leaders are assigned via Content > Projects > Actions > Permissions > Set Project Leader:
Power: Can edit permissions for all content in the project, even if not the owner.
Site Role: Requires Site Administrator or Server Administrator (Creator/Explorer variants suffice).
Why: Overrides ownership in Managed by Owner mode–ensures project-level governance.

Tableau Server has specific hardware requirements for production environments to ensure stability and performance. The minimum recommended free disk space for a production installation is 50 GB. This accounts for:
* The installation itself (approximately 1-2 GB).
* Space for log files, temporary files, and extracts managed by the File Store and Data Engine.
* Room for backups and operational overhead.
The full minimum hardware recommendations for a single-node production deployment are:
* 8 CPU cores (2.0 GHz or faster).
* 32 GB RAM.
* 50 GB free disk space (on the system drive, typically C: on Windows).
* Option A (32 GB): Incorrect. While 32 GB is the minimum RAM requirement, it’s insufficient for disk space in production.
* Option B (50 GB): Correct. This matches Tableau’s official recommendation for production environments.
* Option C (15 GB): Incorrect. 15 GB is the minimum for a non-production or trial installation, not production.
* Option D (64 GB): Incorrect. While 64 GB exceeds the minimum, it’s not the specified requirement-
50 GB is sufficient.
Reference: Tableau Server Documentation – “Minimum Hardware Recommendations” (https://help.tableau.
com/current/server/en-us/requirements.htm).

Tableau Server relies on several processes to function, each with a specific role. The Repository process (powered by PostgreSQL) serves as the database for metadata, storing critical information such as:
* User and group details.
* Permissions and site configurations.
* Workbook and data source metadata (e.g., schedules, subscriptions).
* Option B (Repository): Correct. The Repository is the centralized database that holds all metadata, making it the backbone of Tableau Server’s content management. There are typically two instances in an HA setup (one active, one passive), monitored by the Cluster Controller.
* Option A (Data Engine): Incorrect. The Data Engine manages in-memory data processing and extract storage (e.g., .hyper files), not metadata. It’s separate from the Repository.
* Option C (Backgrounder): Incorrect. The Backgrounder handles background tasks like extract refreshes and subscriptions, but it doesn’t store metadata-it interacts with the Repository to retrieve task details.
* Option D (File Store): Incorrect. The File Store manages physical extract files and workbook assets, not metadata, which is stored in the Repository.
Reference: Tableau Server Documentation – “Tableau Server Processes” (https://help.tableau.com/current
/server/en-us/processes.htm).

The tsm maintenance backup command creates a backup file (with a .tsbak extension) that captures critical data needed to restore Tableau Server in case of failure or migration. This backup primarily includes:
Repository data: This encompasses the PostgreSQL database, which stores metadata such as workbooks, data sources, user information, permissions, schedules, and subscriptions.
Configuration data: This includes server settings like authentication methods, port configurations, and service layouts, but it does not include topology data as a separate entity (topology is part of the configuration).
The command does not back up the following:
Extract files (stored in the File Store), which must be backed up separately if needed.
Log files, which are archived using tsm maintenance ziplogs.
Option A (Notification settings) is incorrect because while notification settings are part of the configuration data stored in the repository, they are not the primary focus of the backup. The broader category is “repository data.” Option B (SMTP server settings) is also incorrect for the same reason-SMTP settings are configuration data within the repository, but the backup is not limited to just these settings.
Option D (Topology data) is incorrect because topology data (e.g., how services are distributed across nodes) is part of the configuration included in the backup, but it’s not stored as a standalone item. The .tsbak file is centered on the repository database.
Reference: Tableau Server Documentation – “Back Up Tableau Server Data” (https://help.tableau.com/current
/server/en-us/backup_restore.htm).

TSM commands manage Tableau Server maintenance–let’s validate their syntax:
Command Requirements:
Some need arguments (e.g., file paths); others are standalone.
Valid and Complete: Must work as-is without errors.
Option C (tsm maintenance cleanup): Correct.
Details: Removes temporary files and old logs–no arguments required (optional flags like -l exist).
Use: tsm maintenance cleanup–runs fully.
Option D (tsm maintenance ziplogs): Correct.
Details: Creates a zip of logs (e.g., tsm-logs.zip)–no arguments needed (optional -d for date range).
Use: tsm maintenance ziplogs–complete and valid.

Locking a project’s permissions ensures all content inside (including in sub-projects) uses the project-level default permission rules, and publishers/owners cannot set custom permissions on individual items – useful for standardized governance.

The tsm maintenance backup command creates a backup file (with a .tsbak extension) that captures critical data needed to restore Tableau Server in case of failure or migration. This backup primarily includes:
Repository data: This encompasses the PostgreSQL database, which stores metadata such as workbooks, data sources, user information, permissions, schedules, and subscriptions.
Configuration data: This includes server settings like authentication methods, port configurations, and service layouts, but it does not include topology data as a separate entity (topology is part of the configuration).
The command does not back up the following:
Extract files (stored in the File Store), which must be backed up separately if needed. Log files, which are archived using tsm maintenance ziplogs.

The Backgrounder process executes scheduled and background tasks, including extract refreshes, subscriptions, and flow runs. If it is stopped everywhere, those tasks remain queued and simply wait until Backgrounder is restarted – they are not lost or rerouted to another process.

Tableau Server uses caching to speed up workbook loading by storing query results. After a scheduled extract refresh updates the data, the cache may need recomputing-let’s dive into the mechanics:
* Caching Basics:
* VizQL Cache: Stores rendered views and query results for faster access.
* Refresh Trigger: A scheduled refresh updates the underlying extract (.hyper), but the cache isn’t automatically invalidated-it’s demand-driven.
* Recompute Conditions: Tableau recomputes the cache when the workbook is accessed (viewed) and its data has changed (e.g., via refresh).
* Evaluation:
* Option B (The workbook has upcoming scheduled refresh tasks): Correct.
* Why: An upcoming refresh task indicates the workbook relies on an extract with a schedule. After the refresh runs, the data changes, priming the cache for recomputation on next view. Without a schedule, no refresh occurs, so this is a prerequisite.
* Detail: Schedules are set in Schedules > Tasks-e.g., “Daily at 2 AM.”
* Option D (The workbook has been viewed recently): Correct.
* Why: Viewing triggers cache recomputation if the data has changed (e.g., post-refresh).
Tableau uses a “lazy caching” model-cache updates only when a user loads the workbook, ensuring fresh results.
* Detail: “Recently” isn’t strictly defined but implies post-refresh access.
* Option A (Published in the last month): Incorrect.
* Why: Publish date is irrelevant-cache recomputation ties to data changes and access, not publication timing.
* Option C (All Users group has permission rule allowing access): Incorrect.
* Why: Permissions enable viewing, but recomputation requires actual access (viewing) and a refresh event, not just potential access.
Why This Matters: Caching balances performance and freshness-understanding triggers prevents stale data surprises.
Reference: Tableau Server Documentation – “Caching and Performance” (https://help.tableau.com/current
/server/en-us/perf_cache.htm).

Trusted Tickets is an authentication method in Tableau Server for embedding views in external applications (e.g., portals) without requiring users to log in manually. Here’s how it works:
* A trusted application (e.g., a web server) authenticates with Tableau Server using a trusted IP or username/password.
* Tableau Server issues a temporary ticket (a unique string).
* The ticket is embedded in a view URL (e.g., /trusted/<ticket>/views/…), granting access to the view for a short period (configurable, default 5 minutes).
* Option A (Access embedded views without being prompted for credentials): Correct. Trusted tickets enable SSO-like behavior for embedded content, bypassing the login prompt if the ticket is valid. This is ideal for seamless integration into external systems.
* Option B (Encrypt database connections): Incorrect. Encryption is handled by data source configurations (e.g., SSL), not trusted tickets, which focus on user authentication.
* Option C (Save and edit workbooks): Incorrect. Trusted tickets grant view access, not edit permissions-those depend on the user’s site role and permissions.
* Option D (Embed database credentials): Incorrect. Trusted tickets authenticate users to Tableau Server, not databases-database credentials are managed separately in the data source.
Why This Matters: Trusted tickets simplify embedding Tableau content securely in custom applications, enhancing user experience.
Reference: Tableau Server Documentation – “Trusted Authentication” (https://help.tableau.com/current/server
/en-us/trusted_auth.htm).

In an HA Tableau Server cluster, the Coordination Service (ZooKeeper ensemble) maintains cluster state- let’s find the best way to check it:
* Coordination Service:
* Runs on multiple nodes (3 or 5 in HA) to ensure quorum and failover.
* Status indicates if it’s running and synced-critical for cluster health.
* Option C (Run tsm status -v): Correct.
* Details: tsm status –verbose lists all processes across nodes, including Coordination Service (e.
g., “Coordination Service: RUNNING”).
* Why Best: Provides detailed, node-specific status in the CLI-e.g., “Node 1: RUNNING, Node
2: RUNNING.”
* Use: Run on the initial node; -v ensures full output.
* Option A (TSM web client Status page): Incorrect.
* Why: The TSM UI (Server > Status) shows process counts (e.g., “Coordination Service: 3 instances”), but not detailed per-node status-less granular than CLI.
* Option B (tsm maintenance ziplogs): Incorrect.
* Why: Generates log archives for troubleshooting, not a real-time status check.
* Option D (Tableau Server Status page): Incorrect.
* Why: The Server Status page (Server > Status in the web UI) monitors application processes (e.
g., VizQL), not TSM’s Coordination Service.
Why This Matters: Coordination Service health ensures HA stability-tsm status -v is the admin’s go-to for precision.
Reference: Tableau Server Documentation – “Check Server Status” (https://help.tableau.com/current/server/en- us/tsm_status.htm).

To force Tableau Server to require the setup of a new administrator account (e.g., resetting the server to an initial setup state), the tsm reset command is the appropriate tool. This command resets Tableau Server’s administrative configuration, including the TSM administrator account, while preserving content like workbooks and data sources.
Option B (Run the tsm reset command): Correct. Running tsm reset clears the current TSM administrator credentials and configuration settings. The next time you access TSM (e.g., via the web interface or CLI), it prompts you to set up a new administrator account, mimicking the initial setup process. Command: tsm reset –username <new-username> –password <new-password>.

The VizQL Server process in Tableau Server handles rendering visualizations and processing queries for users viewing dashboards or workbooks. During installation, Tableau Server automatically configures the number of VizQL instances based on the number of processor cores on the machine, following this rule:
Default VizQL instances = 2 per node, unless manually adjusted post-installation.
In multi-node setups, additional instances may be added based on core count, but the question specifies a single server with 16 cores.
The installer does not scale VizQL instances linearly with core count by default (e.g., it doesn’t set 1 instance per 4 cores). Instead:
For a single-node installation, the default is 2 VizQL instances, regardless of core count (assuming the minimum hardware requirements are met: 8 cores, 32 GB RAM).
Administrators can later adjust this using TSM (e.g., tsm topology set-process) based on performance needs, but the question asks for the default configured by the installer.
Option A (4): Incorrect. Four instances might be configured manually for a 16-core server, but it’s not the default.
Option B (6): Incorrect. Six instances exceed the default for a single node.
Option C (10): Incorrect. Ten instances are far beyond the default and would require manual configuration.
Option D (2): Correct. The installer sets 2 VizQL instances by default on a single-node installation.
Reference: Tableau Server Documentation – “Server Process Settings” (https://help.tableau.com/current/server
/en-us/processes.htm).

Tableau Server uses internal secrets (tokens) for secure communication between its processes (e.g., Repository, File Store). These are automatically generated during installation and can be regenerated if compromised or for security maintenance. The command to update these is:
tsm security regenerate-internal-tokens: This regenerates the internal security tokens, ensuring all processes use the new tokens after a restart.
Option C (tsm security regenerate-internal-tokens): Correct. This is the documented command for updating internal secrets.

Tableau Server’s minimum hardware recommendations for a production single-node deployment ensure reliable performance for small to medium workloads. As of the latest documentation:
CPU: 8 cores (2.0 GHz or higher) to handle concurrent users, rendering, and background tasks.
RAM: 32 GB to support in-memory processing (e.g., VizQL, Data Engine) and caching. Disk Space: 50 GB free for installation, logs, extracts, and temporary files.
Option C (8-Core CPU, 32 GB RAM, 50 GB free disk space): Correct. This matches Tableau’s official minimum for production:
8 cores ensure sufficient parallelism for processes like Backgrounder and VizQL. 32 GB RAM supports multiple users and extract refreshes. 50 GB disk space accommodates growth (initial install is ~1-2 GB, but logs and extracts expand).

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) during publishing. 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.
Reference: Tableau Server Documentation – “Publish a Workbook” (https://help.tableau.com/current/server
/en-us/publish_workbook.htm) and “Hyper Extract FAQ” (https://help.tableau.com/current/server/en-us
/hyper_faq.htm).

Tableau Server supports multi-tenancy via sites, each with customizable settings managed by server or site administrators. Let’s analyze what’s configurable per site:
* Site Settings: Found in the web UI under Site > Settings > General. Server admins can override site admin settings.
* Option B (Limitation on storage space): Correct.
* Details: Server admins can set a storage quota per site (e.g., 100 GB) to cap disk usage for extracts and workbooks.
* How: In TSM or site settings (if enabled)-e.g., tsm configuration set -k site.storage.quota -v
100000.
* Impact: Prevents one site from monopolizing resources in multi-site deployments.
* Option D (Language and locale): Correct.
* Details: Each site can set its language (e.g., English, French) and locale (e.g., date/number formats).
* How: Site settings UI-e.g., “Language: French, Locale: France.”
* Impact: Tailors the user experience per site’s audience.
* Option A (Ability to embed credentials): Incorrect.
* Details: Embedding credentials (e.g., in data sources) is a server-wide setting (tsm data-access), not per-site. Site admins can’t override it.
* Option C (Limitation on number of users): Incorrect.
* Details: User limits are tied to licenses (server-wide), not configurable per site. Site admins manage user assignments, not quotas.
Why This Matters: Site-specific settings enable tailored governance and resource allocation in multi-tenant environments.
Reference: Tableau Server Documentation – “Site Settings” (https://help.tableau.com/current/server/en-us
/site_settings.htm).

Tableau Server’s performance and stability depend on dedicated resources and proper configuration. Running additional software on the same server is the most likely to cause problems because:
* Resource contention: Tableau Server requires significant CPU, RAM, and disk I/O. Other software (e.
g., databases, web servers) can compete for these resources, leading to slowdowns, crashes, or failed tasks.
* Port conflicts: Tableau uses specific ports (e.g., 80, 443, 8850), and other applications might interfere.
* Security risks: Additional software increases the attack surface, potentially compromising Tableau Server.
Tableau recommends running the server on dedicated hardware without unrelated applications.
* Option A (Running additional software on the server): Correct. This is a common cause of performance issues and is explicitly discouraged in Tableau’s best practices.
* Option B (Separating the Backgrounder and VizQL processes to different machines): Incorrect.
This is a supported multi-node configuration that can improve performance, not cause problems, if properly set up via TSM.
* Option C (Configuring the server to use a static IP address): Incorrect. A static IP is recommended for Tableau Server to ensure consistent network access, so it’s unlikely to cause issues.
* Option D (Using a non-default installation path): Incorrect. While not default, a custom path is supported (via TSM or installer options) and unlikely to cause problems if permissions and disk space are adequate.
Reference: Tableau Server Documentation – “Best Practices for Installation” (https://help.tableau.com/current
/server/en-us/install_best_practices.htm).

Tableau Server’s installer configures process instances based on hardware and deployment type (single-node vs. multi-node). For a single-node installation with 4 cores, we need to consider the default process topology. Let’s break this down exhaustively:
Key Processes:
Gateway: Handles incoming requests (1 instance).
Application Server (VizPortal): Manages UI and sessions (1 instance).
VizQL Server: Renders visualizations (2 instances).
Backgrounder: Runs extract refreshes, subscriptions (1 instance).
Data Server: Manages data connections (1 instance).
File Store: Stores extracts (1 instance).
Repository: Metadata database (1 instance, active).
Cluster Controller, Cache Server, etc.: Supporting processes (typically 1 each).
Default Configuration:
On a single-node install, Tableau sets 1 instance per process unless specified otherwise, except for VizQL, which defaults to 2.
The installer doesn’t scale instances linearly with cores (e.g., 4 cores 4 instances). Post-install, TSM can adjust this (e.g., tsm topology set-process), but the question asks for the installed default. Minimum hardware (8 cores, 32 GB RAM) suggests higher defaults, but 4 cores still triggers a minimal setup.
Option B (1): Correct with Caveat.
Most processes (e.g., Backgrounder, Gateway, Data Server) default to 1 instance on install, regardless of 4 cores.
VizQL defaults to 2, but the question’s phrasing (“each process”) implies a general rule.
Historically (and per docs), 1 is the baseline for most, with VizQL as the exception. Interpretation:
Assuming “each” means the typical case, 1 fits most processes on a 4-core single- node setup.