Practice Free Analytics-Admn-201 Exam Online Questions
Question #1
Which three types of data should you backup to ensure that you can restore a Tableau Server? (Choose three.)
- A . Server secrets and Repository passwords
- B . Topology data
- C . Configuration data
- D . Repository data
Correct Answer: A, C, D
A, C, D
Explanation:
Backing up Tableau Server ensures recovery from failures or migrations. A full backup includes multiple data types―let’s dissect this comprehensively: Backup Components:
Repository Data: PostgreSQL database with metadata (users, permissions, workbooks). Backed up via tsm maintenance backup -f <filename>.tsbak.
Configuration Data: Server settings (e.g., ports, authentication) also in the .tsbak file. Server Secrets: Encryption keys, internal tokens, Repository passwords―critical for restoring functionality.
Extracts: .hyper files in File Store (optional, separate backup).
Option A (Server secrets and Repository passwords): Correct.
Details: Includes encryption keys (for extracts), internal tokens (process communication), and Repository credentials. Backed up separately or stored securely (e.g., tsm security export-keys).
Why Critical: Without these, restored data may be inaccessible or services may fail. Option C (Configuration data): Correct.
Details: Ports, authentication settings, process topology―part of the .tsbak file.
Why Critical: Restores server behavior and connectivity post-recovery.
Option D (Repository data): Correct.
Details: Core metadata database―also in .tsbak.
Why Critical: Without it, all content and user data is lost.
Option B (Topology data): Incorrect.
Details: Topology (process distribution) is part of configuration data in the .tsbak, not a separate entity. It’s not distinctly backed up as “topology data.”
Why This Matters: A complete backup (secrets, config, repository) ensures full restoration―missing any piece risks an unusable server.
Reference: Tableau Server Documentation – "Back Up Tableau Server Data"
(https://help.tableau.com/current/server/en-us/backup_restore.htm).
A, C, D
Explanation:
Backing up Tableau Server ensures recovery from failures or migrations. A full backup includes multiple data types―let’s dissect this comprehensively: Backup Components:
Repository Data: PostgreSQL database with metadata (users, permissions, workbooks). Backed up via tsm maintenance backup -f <filename>.tsbak.
Configuration Data: Server settings (e.g., ports, authentication) also in the .tsbak file. Server Secrets: Encryption keys, internal tokens, Repository passwords―critical for restoring functionality.
Extracts: .hyper files in File Store (optional, separate backup).
Option A (Server secrets and Repository passwords): Correct.
Details: Includes encryption keys (for extracts), internal tokens (process communication), and Repository credentials. Backed up separately or stored securely (e.g., tsm security export-keys).
Why Critical: Without these, restored data may be inaccessible or services may fail. Option C (Configuration data): Correct.
Details: Ports, authentication settings, process topology―part of the .tsbak file.
Why Critical: Restores server behavior and connectivity post-recovery.
Option D (Repository data): Correct.
Details: Core metadata database―also in .tsbak.
Why Critical: Without it, all content and user data is lost.
Option B (Topology data): Incorrect.
Details: Topology (process distribution) is part of configuration data in the .tsbak, not a separate entity. It’s not distinctly backed up as “topology data.”
Why This Matters: A complete backup (secrets, config, repository) ensures full restoration―missing any piece risks an unusable server.
Reference: Tableau Server Documentation – "Back Up Tableau Server Data"
(https://help.tableau.com/current/server/en-us/backup_restore.htm).
Question #2
Which three types of authentications can you use to implement single-sign-on (SSO) authentication to Tableau Server? (Choose three.)
- A . OpenID Connect
- B . Local Authentication
- C . Kerberos with Active Directory
- D . Security Assertion Markup Language (SAML)
Correct Answer: A, C, D
A, C, D
Explanation:
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.
Reference: Tableau Server Documentation – "Authentication" (https://help.tableau.com/current/server/en-us/auth_overview.htm).
A, C, D
Explanation:
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.
Reference: Tableau Server Documentation – "Authentication" (https://help.tableau.com/current/server/en-us/auth_overview.htm).
Question #3
A user published a workbook ten days ago. The user can see the workbook on the Server, but she is unable to find the workbook by using Search.
What should you do to resolve the problem?
- A . Instruct the user to re-publish the workbook with keywords
- B . Instruct the user to add tags to the workbook
- C . Instruct the user to log out, and then log back in
- D . Run the tsm maintenance reindex-search command
Correct Answer: D
D
Explanation:
Tableau Server’s search functionality relies on an indexed catalog of content (workbooks, data sources, etc.) stored in the Repository. If a user can see a workbook in the UI (e.g., under Content > Workbooks) but not find it via search, the search index may be outdated or corrupted. This can happen due to:
Indexing delays after publishing.
Server maintenance or crashes affecting the index.
Option D (Run the tsm maintenance reindex-search command): Correct. This command rebuilds the search index, ensuring all content (including the user’s workbook) is properly cataloged and searchable. Steps:
Stop Tableau Server (tsm stop).
Run tsm maintenance reindex-search.
Start Tableau Server (tsm start).
This is a server administrator task and resolves systemic search issues.
Option A (Re-publish the workbook with keywords): Incorrect. Re-publishing might update the index for that workbook, but it doesn’t fix a broader indexing problem. Keywords enhance relevance, not indexing itself.
Option B (Add tags to the workbook): Incorrect. Tags improve searchability but don’t address an index failure. If the workbook isn’t indexed, tags won’t help.
Option C (Log out, and then log back in): Incorrect. This refreshes the user session but doesn’t affect the server-side search index.
Why This Matters: A reliable search index is critical for content discovery in large deployments― reindex-search ensures consistency.
Reference: Tableau Server Documentation – "Reindex Search" (https://help.tableau.com/current/server/en-us/cli_maintenance_tsm.htm#reindex-search).
D
Explanation:
Tableau Server’s search functionality relies on an indexed catalog of content (workbooks, data sources, etc.) stored in the Repository. If a user can see a workbook in the UI (e.g., under Content > Workbooks) but not find it via search, the search index may be outdated or corrupted. This can happen due to:
Indexing delays after publishing.
Server maintenance or crashes affecting the index.
Option D (Run the tsm maintenance reindex-search command): Correct. This command rebuilds the search index, ensuring all content (including the user’s workbook) is properly cataloged and searchable. Steps:
Stop Tableau Server (tsm stop).
Run tsm maintenance reindex-search.
Start Tableau Server (tsm start).
This is a server administrator task and resolves systemic search issues.
Option A (Re-publish the workbook with keywords): Incorrect. Re-publishing might update the index for that workbook, but it doesn’t fix a broader indexing problem. Keywords enhance relevance, not indexing itself.
Option B (Add tags to the workbook): Incorrect. Tags improve searchability but don’t address an index failure. If the workbook isn’t indexed, tags won’t help.
Option C (Log out, and then log back in): Incorrect. This refreshes the user session but doesn’t affect the server-side search index.
Why This Matters: A reliable search index is critical for content discovery in large deployments― reindex-search ensures consistency.
Reference: Tableau Server Documentation – "Reindex Search" (https://help.tableau.com/current/server/en-us/cli_maintenance_tsm.htm#reindex-search).
Question #4
Your deployment of Tableau Server uses Active Directory authentication.
What statement correctly describes the process of importing a group from Active Directory?
- A . If an imported group contains any users that have Tableau Server accounts, their site role will be changed to match the site role specified during the import
- B . Importing a group from Active Directory requires a .csv file that lists user IDs
- C . You can change the name of a group during import, although this will not change the group’s name in Active Directory
- D . New users created as a result of importing a group are assigned the site role specified during the import
Correct Answer: D
D
Explanation:
Importing an AD group into Tableau Server syncs user management―let’s analyze the process and options:
AD Group Import Process:
How: In the UI (Users > Groups > Add Group > Active Directory), enter the AD group name, set a site
role, and sync.
Behavior:
Existing Users: If a user is already in Tableau Server, their site role remains unchanged unless manually adjusted―sync applies the minimum role only if it upgrades access. New Users: Added to Tableau with the site role specified during import.
Config: Requires AD authentication enabled in TSM.
Option D (New users created are assigned the site role specified during import): Correct.
Details: When importing (e.g., "SalesTeam" group, site role: Explorer):
New users get Explorer.
Existing users keep their role unless it’s below Explorer (e.g., Unlicensed → Explorer).
Why: Ensures consistent onboarding―new users align with the group’s intended access.
Option A (Existing users’ roles change to match import): Incorrect.
Why: Existing roles persist unless lower than the minimum―e.g., Viewer stays Viewer if import sets Explorer, but Unlicensed upgrades. Not a full overwrite. Option B (Requires a .csv file): Incorrect.
Why: AD import uses live sync via LDAP―no .csv needed (that’s for local auth imports).
Option C (Change group name during import): Incorrect.
Why: The AD group name is fixed―you can’t rename it in Tableau during sync (it mirrors AD). Post-import renaming is possible but not part of the process.
Why This Matters: Accurate AD sync ensures seamless user management―missteps can disrupt access or licensing.
Reference: Tableau Server Documentation – "Synchronize Active Directory Groups"
(https://help.tableau.com/current/server/en-us/groups_sync.htm).
D
Explanation:
Importing an AD group into Tableau Server syncs user management―let’s analyze the process and options:
AD Group Import Process:
How: In the UI (Users > Groups > Add Group > Active Directory), enter the AD group name, set a site
role, and sync.
Behavior:
Existing Users: If a user is already in Tableau Server, their site role remains unchanged unless manually adjusted―sync applies the minimum role only if it upgrades access. New Users: Added to Tableau with the site role specified during import.
Config: Requires AD authentication enabled in TSM.
Option D (New users created are assigned the site role specified during import): Correct.
Details: When importing (e.g., "SalesTeam" group, site role: Explorer):
New users get Explorer.
Existing users keep their role unless it’s below Explorer (e.g., Unlicensed → Explorer).
Why: Ensures consistent onboarding―new users align with the group’s intended access.
Option A (Existing users’ roles change to match import): Incorrect.
Why: Existing roles persist unless lower than the minimum―e.g., Viewer stays Viewer if import sets Explorer, but Unlicensed upgrades. Not a full overwrite. Option B (Requires a .csv file): Incorrect.
Why: AD import uses live sync via LDAP―no .csv needed (that’s for local auth imports).
Option C (Change group name during import): Incorrect.
Why: The AD group name is fixed―you can’t rename it in Tableau during sync (it mirrors AD). Post-import renaming is possible but not part of the process.
Why This Matters: Accurate AD sync ensures seamless user management―missteps can disrupt access or licensing.
Reference: Tableau Server Documentation – "Synchronize Active Directory Groups"
(https://help.tableau.com/current/server/en-us/groups_sync.htm).
Question #5
What should you do to configure the view URL and enable recording for a site that has recording workbook performance metrics enabled?
- A . Click the Performance link in the toolbar at the top of the view
- B . Type :record_performance=yes& at the end of the view URL, immediately after the session ID
- C . Type :record_performance=yes& at the end of the view URL, immediately before the session ID
- D . Delete the session ID in the URL and reload the view
Correct Answer: B
B
Explanation:
Tableau Server can record performance metrics for workbooks to troubleshoot slow-loading views. This feature must be enabled at the site level (via Settings > General > Allow Performance Recording). Once enabled, you can trigger recording for a specific view by modifying its URL.
The correct syntax is to append :record_performance=yes& to the view URL, immediately after the
session ID. For example:
Original URL: http://server/#/site/my-site/views/workbook/view?:iid=1
Modified URL: http://server/#/site/my-site/views/workbook/view?:iid=1:record_performance=yes& After loading the view with this parameter, a performance recording is generated and accessible via the Performance option in the toolbar.
Option B (Type :record_performance=yes& at the end of the view URL, immediately after the session ID): Correct. This follows Tableau’s documented method for enabling performance recording. Option A (Click the Performance link in the toolbar): Incorrect. The Performance link appears only after recording is triggered via the URL; it’s not the method to enable it.
Option C (Type :record_performance=yes& immediately before the session ID): Incorrect. The parameter must follow the session ID (e.g., :iid=1) to function correctly.
Option D (Delete the session ID in the URL and reload the view): Incorrect. The session ID is required for the view to load properly; removing it breaks the URL.
Reference: Tableau Server Documentation – "Record Performance of a View"
(https://help.tableau.com/current/server/en-us/perf_record.htm).
B
Explanation:
Tableau Server can record performance metrics for workbooks to troubleshoot slow-loading views. This feature must be enabled at the site level (via Settings > General > Allow Performance Recording). Once enabled, you can trigger recording for a specific view by modifying its URL.
The correct syntax is to append :record_performance=yes& to the view URL, immediately after the
session ID. For example:
Original URL: http://server/#/site/my-site/views/workbook/view?:iid=1
Modified URL: http://server/#/site/my-site/views/workbook/view?:iid=1:record_performance=yes& After loading the view with this parameter, a performance recording is generated and accessible via the Performance option in the toolbar.
Option B (Type :record_performance=yes& at the end of the view URL, immediately after the session ID): Correct. This follows Tableau’s documented method for enabling performance recording. Option A (Click the Performance link in the toolbar): Incorrect. The Performance link appears only after recording is triggered via the URL; it’s not the method to enable it.
Option C (Type :record_performance=yes& immediately before the session ID): Incorrect. The parameter must follow the session ID (e.g., :iid=1) to function correctly.
Option D (Delete the session ID in the URL and reload the view): Incorrect. The session ID is required for the view to load properly; removing it breaks the URL.
Reference: Tableau Server Documentation – "Record Performance of a View"
(https://help.tableau.com/current/server/en-us/perf_record.htm).
Question #6
When you use trusted tickets in Tableau Server, users can:
- A . Access embedded views without being prompted for credentials
- B . Encrypt database connections
- C . Save and edit workbooks
- D . Embed database credentials
Correct Answer: A
A
Explanation:
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).
A
Explanation:
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).
Question #7
You attempt to delete a user who owns content on a Tableau Server.
What is the result of the delete action?
- A . The user is deleted, and the user’s content is reassigned to the server administrator
- B . The user is deleted, and the user’s content is reassigned to the project leader
- C . The user and all of the user’s content is deleted
- D . The user is switched to an Unlicensed site role and is NOT deleted
Correct Answer: D
D
Explanation:
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 to Unlicensed, retaining their account and
content ownership.
Resolution: An admin must reassign ownership (e.g., via Users > 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.
Reference: Tableau Server Documentation – "Delete Users" (https://help.tableau.com/current/server/en-us/users_delete.htm).
D
Explanation:
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 to Unlicensed, retaining their account and
content ownership.
Resolution: An admin must reassign ownership (e.g., via Users > 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.
Reference: Tableau Server Documentation – "Delete Users" (https://help.tableau.com/current/server/en-us/users_delete.htm).
Question #8
What should you do to ensure that server tasks associated with a particular schedule run one-at-a-time?
- A . Set Execution to Serial
- B . Set Default priority to 0
- C . Set Frequency to Hourly
- D . Set Execution to Parallel
Correct Answer: A
A
Explanation:
In Tableau Server, schedules manage tasks such as extract refreshes and subscriptions. The execution mode of a schedule determines how tasks within that schedule are processed by the Backgrounder process:
Parallel: Tasks run simultaneously (up to the Backgrounder’s capacity), which is the default setting.
Serial: Tasks run one-at-a-time in sequence, ensuring that one task completes before the next begins. To ensure tasks associated with a particular schedule run one-at-a-time, you must configure the schedule’s execution mode to Serial. This is done in the Tableau Server web interface: Go to Schedules.
Select the schedule, click Actions > Edit Schedule.
Under Execution, choose Serial instead of Parallel.
Option A (Set Execution to Serial): Correct. This directly addresses the requirement by forcing tasks to execute sequentially.
Option B (Set Default priority to 0): Incorrect. Priority (1C100) determines the order of task execution across all schedules, not whether tasks run one-at-a-time within a single schedule. Also, 0 is not a valid priority value (minimum is 1).
Option C (Set Frequency to Hourly): Incorrect. Frequency (e.g., hourly, daily) controls when the schedule runs, not how tasks within it are executed.
Option D (Set Execution to Parallel): Incorrect. Parallel execution allows tasks to run simultaneously, which contradicts the requirement.
Reference: Tableau Server Documentation – "Create or Modify a Schedule" (https://help.tableau.com/current/server/en-us/schedule_manage_create.htm).
A
Explanation:
In Tableau Server, schedules manage tasks such as extract refreshes and subscriptions. The execution mode of a schedule determines how tasks within that schedule are processed by the Backgrounder process:
Parallel: Tasks run simultaneously (up to the Backgrounder’s capacity), which is the default setting.
Serial: Tasks run one-at-a-time in sequence, ensuring that one task completes before the next begins. To ensure tasks associated with a particular schedule run one-at-a-time, you must configure the schedule’s execution mode to Serial. This is done in the Tableau Server web interface: Go to Schedules.
Select the schedule, click Actions > Edit Schedule.
Under Execution, choose Serial instead of Parallel.
Option A (Set Execution to Serial): Correct. This directly addresses the requirement by forcing tasks to execute sequentially.
Option B (Set Default priority to 0): Incorrect. Priority (1C100) determines the order of task execution across all schedules, not whether tasks run one-at-a-time within a single schedule. Also, 0 is not a valid priority value (minimum is 1).
Option C (Set Frequency to Hourly): Incorrect. Frequency (e.g., hourly, daily) controls when the schedule runs, not how tasks within it are executed.
Option D (Set Execution to Parallel): Incorrect. Parallel execution allows tasks to run simultaneously, which contradicts the requirement.
Reference: Tableau Server Documentation – "Create or Modify a Schedule" (https://help.tableau.com/current/server/en-us/schedule_manage_create.htm).
Question #9
What process enables you to access Tableau Services Manager (TSM) over HTTPS?
- A . License Manager
- B . Administration Controller
- C . Administration Agent
- D . Coordination Service
Correct Answer: B
B
Explanation:
TSM is Tableau Server’s management layer, accessible via CLI or web UI (port 8850). HTTPS secures this access―let’s identify the responsible process: TSM Architecture:
Administration Controller: Core TSM process, running on the initial node, handling configuration, UI, and CLI commands.
HTTPS: Enabled by default on port 8850 with a self-signed certificate (configurable to custom certs).
Option B (Administration Controller): Correct.
Details: Hosts the TSM web UI (https://<server>:8850) and processes CLI requests. It manages the HTTPS listener, serving the interface securely.
Why: It’s the central hub for TSM operations, including secure access.
Option A (License Manager): Incorrect.
Why: Validates licenses, not responsible for HTTPS or UI access.
Option C (Administration Agent): Incorrect.
Why: Runs on additional nodes in multi-node setups to relay commands to the Controller―no direct HTTPS role.
Option D (Coordination Service): Incorrect.
Why: ZooKeeper manages cluster state, not TSM’s web interface or HTTPS.
Why This Matters: Secure TSM access protects server administration―Administration Controller is the linchpin.
Reference: Tableau Server Documentation – "TSM Overview" (https://help.tableau.com/current/server/en-us/tsm_overview.htm).
B
Explanation:
TSM is Tableau Server’s management layer, accessible via CLI or web UI (port 8850). HTTPS secures this access―let’s identify the responsible process: TSM Architecture:
Administration Controller: Core TSM process, running on the initial node, handling configuration, UI, and CLI commands.
HTTPS: Enabled by default on port 8850 with a self-signed certificate (configurable to custom certs).
Option B (Administration Controller): Correct.
Details: Hosts the TSM web UI (https://<server>:8850) and processes CLI requests. It manages the HTTPS listener, serving the interface securely.
Why: It’s the central hub for TSM operations, including secure access.
Option A (License Manager): Incorrect.
Why: Validates licenses, not responsible for HTTPS or UI access.
Option C (Administration Agent): Incorrect.
Why: Runs on additional nodes in multi-node setups to relay commands to the Controller―no direct HTTPS role.
Option D (Coordination Service): Incorrect.
Why: ZooKeeper manages cluster state, not TSM’s web interface or HTTPS.
Why This Matters: Secure TSM access protects server administration―Administration Controller is the linchpin.
Reference: Tableau Server Documentation – "TSM Overview" (https://help.tableau.com/current/server/en-us/tsm_overview.htm).
Question #10
A user named John publishes a workbook named Sales Quota to a project named Sales. The All Users group has the View and Download Workbook/Save As capabilities only to the Sales project. A user named Sandy has the Explorer (can publish) site role, on the Sales Quota workbook. No other users or groups have permissions to the Sales project. The Sales project is set to Managed by the owner.
What are the effective rights for Sandy?
- A . All of the capabilities associated with the Editor rule
- B . View and Download Workbook/Save As
- C . The same rights as John
- D . No access
Correct Answer: B
B
Explanation:
B
Explanation:
1 2