Pair your devices with a code and playback position follows you: pause on this device, hit resume on the other. Position is saved to the site every minute and on pause.
Open this panel on your other device and enter the same code.
The quiz tests recall. This file rehearses speech. Say the answers out loud; every one is sized to be spoken in under 90 seconds. Where a number matters, the source is in the lessons — cite the doc, not your memory, if pressed.
"How does QuickSight connect to data in a private VPC?"
You create a VPC connection, which is Enterprise-edition only. Under the hood it's not a tunnel — QuickSight places elastic network interfaces into your subnets, at least two of them, and from then on your route tables and security groups govern that traffic like any other instance. So the real work is network work: three security group rules between the QuickSight interface and the database, and DNS that resolves to the instance's private IP. Once the connection's registered, you attach it to a data source and it can reach anything the VPC can reach — including on-premises, over Direct Connect or VPN.
"How does QuickSight authenticate to Athena or S3? There's no password."
Through IAM roles it assumes in your account. There's an account-level screen where an admin allowlists services and buckets, and that screen is really editing policies on service roles. The subtlety is there are two roles: an s3-consumers role that's used for Athena and S3 when it exists, and an older service role that's only the fallback. Half of all 'we already granted that' incidents are a policy attached to the role that isn't being used.
"How do you manage database credentials for BI connections?"
Secrets Manager, referenced by ARN, instead of a username and password stored in the data source. The secret's just JSON with username and password keys. Rotation happens in Secrets Manager and QuickSight picks it up on next access. Two caveats I'd flag: Jira and ServiceNow don't support it, and any console edit to the data source silently strips the secret — so API-managed sources should stay API-managed.
"A dashboard says it can't connect to the database. Where do you start?"
With which error surface I'm on. If creating or testing the data source failed, I describe the data source and read its error info. If a refresh failed, I list the ingestions and read that error — it's a much richer enum. Then I walk a fixed ladder: name, route, auth, query. Can the hostname resolve, can a packet get there and back, is the caller allowed in, and only then is the SQL wrong. The order matters because each layer masks the ones below it.
"What are the SPICE dataset limits?"
Twenty-five million rows or twenty-five gigabytes per dataset on Standard; two billion rows or two terabytes on Enterprise. Two thousand columns either way, and — the one people miss — none of those are adjustable. Hitting one is a redesign conversation, not a support ticket.
"Why does the QuickSight VPC security group need an all-ports inbound rule? That fails our security review."
Because that ENI's security group isn't stateful — AWS documents that explicitly. A normal security group remembers the outbound connection and admits the return traffic automatically. This one doesn't, and return packets arrive on randomly allocated ports, so you can't name a port. The correct hardening is on the source: allow all TCP ports, but only from the database's security group ID. Wide on ports, narrow on source. And the outbound side stays port-specific — all-ports outbound is the actual mistake.
The follow-up they ask next: "Is that still true for new connections?" — Honest answer: the docs scope those rules to connections created before April 2023 and never say what applies after. I'd deploy the documented-safe config and get AWS Support to state the current behavior in writing before loosening anything.
"You said auth failures look like network failures. Give me a real example."
KMS. Athena data encrypted with a customer-managed key: QuickSight reaches Athena fine, the query runs, and the read of the results fails because the QuickSight role can't decrypt. From the dashboard it looks like a connection error. The fix is one command — a KMS grant for Decrypt to the QuickSight role — but you only find it if your triage separates 'couldn't get there' from 'wasn't allowed in.'
The follow-up: "Which role gets the grant?" — Whichever one is live: the s3-consumers role if it exists, otherwise the service role. Check with get-role before granting.
"Direct query or SPICE — how do you decide?"
It depends, and here's what I'd ask: how fresh does the data need to be, how fast is the source, and how many concurrent viewers. The hard constraint pushing toward SPICE is the two-minute visual timeout on direct query — it's not adjustable. The hard constraints pushing toward direct query are SPICE's per-dataset ceilings and the refresh quota. And there's a trap in the middle: with Redshift, the driver doesn't honor the two-minute cancel, so a slow direct-query dashboard can pile zombie queries on the cluster. If the source is a busy warehouse and viewers are many, SPICE isn't an optimization, it's protection for the warehouse.
"How would you do cross-account connectivity to a Redshift cluster in another account?"
Two layers, and I'd keep them separate in the design doc. Network: a VPC connection reaches whatever the VPC can route to, so cross-account VPC peering or Transit Gateway makes the cluster reachable at a private IP, with the three security-group rules referencing the peered SG or CIDR. Auth: either database credentials in a secret, or Redshift IAM parameters with a role. What I would not do is quote the exact cross-account Athena mechanism from memory — the API has a ConsumerAccountRoleArn field for that, and I'd read its page before committing to an architecture.
"What breaks when someone 'cleans up' IAM policies in an account with QuickSight?"
Two distinct blast radii. If they hand-edit one of the managed policies the Security & permissions screen owns, the screen detects it and locks — and the documented recovery is to delete that policy and reload, which is a scary change in a locked-down account. If they uncheck a bucket on the shared screen, they break every team's datasets reading that bucket, because those grants are account-global. That second one is why I treat that screen as production infrastructure with change control.
"Your ingestion failed with UNROUTABLE_HOST. What's your differential versus UNRESOLVABLE_HOST?"
Unresolvable is stage one — DNS never produced an address, so I'm looking at the hostname, the resolvers on the VPC connection, private zones, the Region. Unroutable means DNS worked and no path exists — now it's security groups, route tables, the VPC connection's availability status. The enum is literally handing me the triage stage; the hour it saves is the hour people spend checking security groups for what is actually a typo in a hostname.
"Design the data connectivity for a BI rollout: Redshift in a private VPC, a data lake queried via Athena, and a vendor MySQL reachable only from on-prem. 300 viewers."
Requirements first: three sources with three different trust models, plus concurrency that could hurt the warehouse.
Redshift: Enterprise edition, VPC connection — two private subnets in different AZs, dedicated security group for the QuickSight interface, the three-rule pattern, DNS resolvers only if we're using private zone names. Credentials via Secrets Manager, or Redshift IAM parameters to avoid a stored password entirely.
Athena: no VPC path — it rides the service roles. So: confirm which of the two roles exists, grant the data buckets and the workgroup results bucket, and KMS grants for any encrypted prefixes. This is IAM work, not network work, and I'd assign it to whoever owns IAM.
Vendor MySQL: the VPC connection reaches on-prem through whatever connects the VPC to the site — Direct Connect or VPN — so it becomes a routing and firewall exercise, plus a secret for credentials.
The trade-off I'd surface: with 300 viewers, Redshift dashboards go SPICE-first — the two-minute timeout plus the driver's failure to cancel means direct query at that concurrency can take the warehouse down. Direct query only for the few dashboards that genuinely need freshness.
What I'd monitor: ingestion errors split by type, the VPC connection's availability status, rows-dropped on refreshes, and Redshift's running-queries view with an alarm on long-running queries from the QuickSight user.
"Refreshes from the on-prem MySQL started failing at 3am. Nothing was deployed. Go."
- List ingestions, read the error type — it names the layer.
- If it's auth-family: did a credential rotate at 3am? Check the secret's rotation schedule, and whether the data source still has its SecretArn — did someone touch it in the console yesterday?
- If it's network-family: describe the VPC connection — availability status first — then the VPN/Direct Connect health to the site.
- If it's UNRESOLVABLE_HOST: on-prem DNS or the resolver endpoints changed.
- Whatever I find, I keep the RequestId and the enum value — that's the support case if it turns out to be AWS-side.
"A new Athena data source works for you but fails for every viewer."
- That symptom is the two-identities asymmetry — my access worked at create time, the runtime path is broken. So: which service role exists, and does it have the data buckets?
- The workgroup results bucket — granted?
- KMS on either bucket — does the live role have Decrypt?
- If credentials involve a secret: the secretsmanager role exists and covers this secret?
- Last, RLS or dataset permissions — but permission-to-the-asset fails differently than permission-to-the-data, and the error text usually distinguishes them.
"Your VPC connection shows AVAILABLE but connections still time out."
- Reproduce from inside the VPC: from an instance in the same subnets, can I hit the DB host and port? That splits QuickSight-specific from network-general.
- Walk the three rules — especially the QNI inbound rule someone may have 'hardened' to a single port.
- Confirm DNS resolves to a private IP from outside the VPC — public-IP answers break the documented requirement.
- Check the DB side: is it refusing connections, at max connections, or just slow past the two-minute visual timeout — which isn't a connectivity failure at all.