Q1 — Data Sources and Connectivity

Why this module exists

Before a single row reaches SPICE, three separate systems have to agree: the data source's own authentication, the IAM roles Quick Sight assumes on your behalf, and the network path between Quick Sight's elastic network interfaces and your database. When any one of them disagrees, the console shows you roughly the same unhelpful red banner.

The result is a support queue full of misdiagnoses. "The VPC connection is broken" that's actually a KMS key without a grant. "Athena permissions" that's actually the wrong service role. "Quick Sight can't reach the database" that's actually a security group doing exactly what it was told.

This module walks the connectivity stack in order — what you can connect to, how a data source is actually created, how the AWS-managed sources are authorized, how VPC connections really move packets — and finishes with a triage method that tells auth failures and network failures apart in minutes instead of days.

The one idea to hold onto

A data source failure has exactly three suspects, and they fail in a fixed order:

   1. NAME        can the hostname resolve?          → DNS, resolvers, private zones
   2. ROUTE       can a packet get there and BACK?   → security groups, subnets, VPC connection
   3. AUTH        is the caller allowed in?          → credentials, IAM roles, KMS grants
      ─────────────────────────────────────────────
      only then:  the query itself                  → SQL, schema, timeouts

Work the list top to bottom, every time. The single most expensive mistake in this territory is debugging auth while the problem is a route, or debugging the network while the problem is a KMS key — and the console error text will happily send you to the wrong floor.

What you'll be able to do

Say what Quick Sight can and cannot connect to — including the environments a database must live in — and name the data source Type the API expects for each.
Create a data source entirely through the API: parameters, credentials, SSL, permissions — and use a Secrets Manager secret instead of a stored password.
Explain how Quick Sight is authorized to touch Athena, S3, RDS, and Redshift, name the service roles involved, and fix the KMS case that breaks encrypted Athena results.
Build a VPC connection that works on the first try, because you know the Quick Sight network interface's security group is not stateful and what that does to your inbound rules.
Triage any connection failure with the name → route → auth method, read DataSourceErrorInfo.Type, and open a support case with evidence instead of a symptom.

Lessons

#	Lesson	Read	Listen
1	The landscape — what connects, from where	24 min	9 min
2	Creating data sources through the API	26 min	9 min
3	The AWS-managed sources — Athena, S3, and the two roles	26 min	9 min
4	VPC connections — how the packets actually move	28 min	10 min
5	The failures that look like network failures	24 min	9 min

Then: Cheat sheet · Lab · Quiz · Interview prep

A note on the docs

Researching this module surfaced more October-2025-rename debris, flagged where it arises:

The connectivity pages live in the old doc tree (/quicksight/latest/user/…) but have been rewritten to say "Amazon Quick" and "Amazon Quick Sight" — while linking to /quick/latest/userguide/… pages from inside their own bodies. Same content, two trees, both live.
The security-group rules that every VPC connection tutorial repeats are marked in the user guide as applying "if the connection was created before April 27, 2023" — and the page never says what applies after that date. Lesson 4 covers what that means for you.
The API still calls OpenSearch AMAZON_ELASTICSEARCH — and also has AMAZON_OPENSEARCH — and the CreateDataSource page itself tells you to use the old one. Lesson 1 has the details.

Facts verified 2026-08-16 against the pages cited in each lesson.

Keeps playing into the following modules — 146 min from here to the end of the course.