Salesforce-Tableau-Architect Practice Test Questions

Explanation

When Tableau Server performance is slow through a web proxy, the first troubleshooting step is to examine the proxy configuration.

Why B is correct:

1. Web proxies can impose bandwidth throttling, content filtering, or caching rules that impact performance.
2. Checking and adjusting these settings is a non-disruptive initial step and can quickly identify if the proxy is the bottleneck.
3. Disabling the proxy or reinstalling the server should be done only after confirming whether the proxy itself is responsible.

Why not the others?

A. Disabling the web proxy
This might help identify the cause, but it’s more intrusive than first checking settings. If the proxy is needed for security/compliance, disabling it might not be possible.

C. Reinstalling Tableau Server
Reinstallation is not an initial troubleshooting step. Performance issues through a proxy are rarely due to the Tableau Server installation itself.

D. Configuring Tableau Server to use an alternative port
Changing ports is not the standard first step unless the issue is clearly port-specific. This is more of a targeted fix after isolating the problem.

Reference
Tableau Help: Configure Proxies and Load Balancers

Key point from docs: "If users experience delays or slow load times when connecting through a proxy, check proxy settings such as caching, bandwidth limits, and filtering."

Explanation:

Why This is the Correct Approach:

Tableau Server relies on multiple processes to handle different tasks, and balancing them is critical for performance:

VizQL: Renders visualizations for users (needs more instances if many users access dashboards simultaneously).

Data Server: Manages data extracts and live connections (important if the business uses many extracts).

Backgrounder: Runs scheduled refreshes and subscriptions (needs enough capacity to avoid delays).

A medium-sized business should adjust process counts based on:

Concurrent users (more VizQL if many users).

Extract usage (more Data Server if heavy on extracts).

Refresh schedules (more Backgrounder if many automated tasks).

Why the Other Options Are Not Ideal:

A) Excessive processes:
Wastes server resources and can slow down performance due to overhead.

B) Equal processes for all types:
Doesn’t account for actual usage patterns (e.g., may need more VizQL than Backgrounder).

D) Only prioritizing VizQL:
Neglects data refreshes and extract performance, leading to bottlenecks.

Best Practices for Medium-Sized Businesses:
Start with a balanced baseline (e.g., 4-6 VizQL, 3-4 Backgrounder, 2-3 Data Server).

Monitor performance using Tableau’s Admin Views to adjust as needed.

Scale up processes only where necessary (e.g., add VizQL if dashboard load times increase).

Key Takeaway:
Tailor process counts to match real-world usage—don’t over-allocate or assume all processes need equal resources.

Explanation:

Why B is Correct?

Air-gapped environments are isolated from external networks (no internet access).
Tableau Server updates must be:
1. Manually downloaded from Tableau’s official site on a connected machine.
2. Vetted for security/compliance before being transferred via secure offline methods (e.g., USB, internal network).

This ensures control over updates and prevents unauthorized changes.

Reference:
Tableau’s Offline Installation Guide outlines steps for air-gapped deployments.

Why Other Options Are Incorrect?

A) Impossible—air-gapped systems cannot connect to the internet for real-time updates.
C) Automatic updates require internet access, violating air-gapped security.
D) Satellite connections defeat the purpose of air-gapping (physical isolation is mandatory for high-security environments).

Key Takeaway:
Air-gapped systems require manual, controlled update processes to maintain security and compliance.

Explanation:

In a multi-node Tableau Server deployment, database connectivity issues can stem from multiple sources — network interruptions, authentication problems, database server load, or driver issues. The most effective and structured way to identify the root cause is to:

Check Tableau Server logs (e.g., tabsvc, vizqlserver, backgrounder logs) for error codes or failed connection attempts.

Check database server logs for matching timestamps of failed logins, query failures, or timeouts.

Correlate these logs to see if the issue is network-related, credential-related, or due to resource constraints.

Why other options are incorrect:

A: Hardware replacement is costly, disruptive, and should only be considered after confirming physical layer issues.

C: Reducing access might temporarily reduce load but does not address the actual connectivity failure.

D: Migrating to a new database server is a drastic measure that doesn’t guarantee resolution and risks introducing new problems.

Reference:
Tableau Help – Troubleshoot Connectivity Issues:

Explanation

For maximum data security in a Tableau Server deployment, two encryption layers are required:

1. Encryption over the wire (in transit):
Achieved by enabling SSL/TLS for Tableau Server so all communications between clients, browsers, Tableau Desktop, and the server are encrypted.

2. Encryption at rest:
Protects stored data such as extracts, repository data, and backups.
In Tableau Server, you can enable at-rest encryption for extracts, repository, and file store (available in certain editions and versions).

Why C is correct:

It’s the only option that covers both types of encryption—this ensures compliance with strict financial data regulations (e.g., PCI-DSS, SOX, GLBA).

Why not the others?

A. Enabling only SSL/TLS → Secures transit but leaves data at rest vulnerable.

B. External file storage without encryption → Data at rest is exposed if the storage is compromised.

D. Network-level encryption only → Relies on external network controls but does not secure stored files or server-to-server comms natively.

Reference:

Tableau Help: Encrypt Extracts at Rest
Tableau Help: Configure SSL for Tableau Server
From Tableau docs: "Tableau Server supports encryption for data in transit with SSL/TLS, and encryption at rest for extracts and repository data."

Explanation:

Why B is Correct?

1. Financial institutions require high availability, data integrity, and compliance (e.g., GDPR, SOX, Basel III).
2. Frequent backups minimize data loss in case of failure.
3. Encryption ensures data security (mandatory for regulatory compliance).
4. Off-site storage protects against physical disasters (e.g., fire, flood).
5. Quick recovery mechanisms (e.g., failover clusters, standby servers) ensure business continuity.

Reference:
Tableau’s Disaster Recovery Best Practices recommend encrypted, geographically redundant backups.

Why Other Options Are Incorrect?

A) Infrequent on-site backups risk data loss and fail compliance (no off-site redundancy).
C) Manual backups on removable drives are error-prone, insecure, and non-scalable.
D) Cloud-only strategies may violate data sovereignty laws (some regulations require on-premises copies).

Key Takeaway:
A multi-layered, compliant disaster recovery plan is critical for financial institutions using Tableau Server.

Explanation:

When dashboards in Tableau Cloud aren’t updating with the latest data, the most common cause is that the data source refreshes aren’t running or the connection to the source is broken.

Why B is correct:

1. Tableau Cloud relies on scheduled refreshes for published data sources and extracts.
2. If refresh schedules are disabled, misconfigured, or failing due to connection/authentication issues, dashboards will show stale data.
3. The logical first step is to verify the data source connection status and check if the refresh jobs have succeeded in Tableau Cloud’s Tasks or Schedules page.

Why not the others?

A. Rebuilding dashboards → Overkill; the visualizations are fine—it’s a data refresh issue.

C. Transitioning back to on-premises → This is a drastic move that doesn’t address the root cause and wastes resources.

D. Limiting user access → Might reduce load but has no effect on whether the data updates.

Reference:

Tableau Help: Schedule Refreshes in Tableau Cloud
Tableau Help: Troubleshoot Extract Refresh Failures
From docs: "If your data is not up to date, verify that the data source connection is valid and that the refresh schedule is enabled and successful."

Explanation:

Why B is Correct?

Windows Task Scheduler is a native Windows tool designed for automating script execution at predefined times or intervals.

It is lightweight, reliable, and tightly integrated with Windows, making it ideal for routine Tableau Server maintenance tasks (e.g., log cleanup, backup scripts, extract refreshes).

Supports custom triggers, conditions, and logging, ensuring scripts run without manual intervention.

Why Other Options Are Incorrect?

A) Tableau Desktop is for visual analytics, not server maintenance automation.

C) Jenkins is overkill for simple maintenance tasks—it’s better suited for CI/CD pipelines.

D) Manual execution defeats the purpose of automation, increasing human error risk.

Key Takeaway:
For Windows-based Tableau Servers, Task Scheduler is the simplest, most effective way to automate maintenance scripts.

Explanation

In large, high-security, high-performance Tableau Server deployments (especially for financial institutions), the service-to-node topology should be strategic:

Critical services (e.g., Repository [pgsql], Data Server, Coordination Service) handle sensitive data and are central to server operations. These should be:

. Isolated on dedicated nodes to prevent resource contention and limit exposure.
. Hardened with security configurations, limited access, and strong OS/network protections.

Less critical or stateless services (e.g., VizQL Server, Application Server) can be collocated on shared nodes to optimize resource usage without jeopardizing security.

This approach balances security (minimizing the attack surface for critical components) and performance (avoiding CPU/memory contention).

Why not the others?

A. Isolating all services on individual nodes → Overly complex, costly, and often unnecessary. It doesn’t give a meaningful performance/security boost for non-critical services.

B. Collocating all services on a single node → Creates a single point of failure and resource bottlenecks, not suitable for high-security environments.

D. Randomly distributing services → No control over performance or security; risks inefficiency and possible downtime.

Reference:

Tableau Help: Distributed and High Availability Deployments
Tableau Blueprint: "Isolate critical Tableau Server processes on dedicated hardware to enhance both performance and security in large-scale deployments."

Explanation:

Why B is Correct?

1. Small startups with limited IT resources need a simple, low-maintenance solution.
2. Tableau’s local identity store requires no additional infrastructure (like LDAP or SAML) and is easy to set up.
3. Admins can manage users directly in Tableau Server without dependencies on external systems.
4. Cost-effective (no need for enterprise identity providers like Okta or Azure AD).

Reference:
Tableau’s Authentication Overview recommends local identity for small deployments.

Why Other Options Are Incorrect?

A) LDAP adds unnecessary complexity for a small team (overkill for current needs).
C) Enterprise identity providers (e.g., SAML/OAuth) are expensive and require expertise.
D) Separate credentials hurt user adoption (increases friction and password fatigue).

Key Takeaway:

For startups, Tableau’s built-in authentication balances simplicity and security. Scale to LDAP/SAML later if needed.