AWS Training
Modules Listen Certification
The landscape — what connects, from where Q1 — Data Sources and Connectivity
0:00 0:00

← Data Sources and Connectivity

Q1 Lab — break a connection three ways, then diagnose it

Target: a real Amazon Quick / Quick Sight account where you can create and delete data sources. Parts 1–3 need only the CLI and a tiny S3 bucket. Part 4 (VPC) needs Enterprise edition and an existing database in a VPC — it's marked optional.

Cost: cents. One small S3 object, a handful of API calls, optional Secrets Manager secret (billed per secret per month, pro-rated — we tear it down). No SPICE capacity is consumed beyond a tiny file. Teardown at the end is part of the lab.

Write your answers down. The point of this lab is that you cause every failure yourself, so the error taxonomy stops being a list and becomes a reflex.

Setup

export ACC=<your 12-digit account id>
export REG=<your Quick Sight home region>
export BUCKET=<a bucket you can write to>

Q1. Before touching anything: which of the two Athena/S3 roles exists in this account?

aws iam get-role --role-name aws-quicksight-s3-consumers-role-v0 --query Role.Arn 2>&1
aws iam get-role --role-name aws-quicksight-service-role-v0 --query Role.Arn 2>&1

Write down which one Quick Sight is actually using for Athena/S3 connections, and why.

Part 1 — a working S3 data source (the control)

Create a two-line CSV and a manifest:

printf 'city,amount\nakron,10\nboise,20\n' > /tmp/lab.csv
aws s3 cp /tmp/lab.csv s3://$BUCKET/q1lab/lab.csv

cat > /tmp/manifest.json <<EOF
{ "fileLocations": [ { "URIs": [ "s3://$BUCKET/q1lab/lab.csv" ] } ],
  "globalUploadSettings": { "format": "CSV" } }
EOF
aws s3 cp /tmp/manifest.json s3://$BUCKET/q1lab/manifest.json

aws quicksight create-data-source \
  --aws-account-id $ACC --region $REG \
  --data-source-id q1lab-s3 --name "Q1 Lab S3" --type S3 \
  --data-source-parameters "{\"S3Parameters\":{\"ManifestFileLocation\":{\"Bucket\":\"$BUCKET\",\"Key\":\"q1lab/manifest.json\"}}}"

Q2. What CreationStatus came back? Now poll:

aws quicksight describe-data-source --aws-account-id $ACC --region $REG \
  --data-source-id q1lab-s3 \
  --query 'DataSource.{Status:Status,Err:ErrorInfo}'

Record the final status. If it failed, the likely cause is bucket access — fix it via Security & permissions (lesson 3) and note what you changed.

Q3. Rename the manifest to manifest.txt in S3 and create a second data source pointing at it. What happens, and which lesson-2 rule explains it? (Delete the .txt copy after.)

Part 2 — break it three ways

The heart of the lab. For each break: predict the ErrorInfo.Type before running describe, then record what you actually got. A miss is more instructive than a hit.

Break A — NAME

aws quicksight create-data-source \
  --aws-account-id $ACC --region $REG \
  --data-source-id q1lab-badhost --name "Q1 Lab Bad Host" --type MYSQL \
  --data-source-parameters '{"MySqlParameters":{"Database":"nope","Host":"db.does-not-exist.internal","Port":3306}}' \
  --credentials '{"CredentialPair":{"Username":"x","Password":"placeholder-not-real"}}'

Q4. Prediction vs reality for ErrorInfo.Type? Which triage stage is this?

Break B — ROUTE

Point at a host that resolves but won't answer on that port (a real internal IP with no listener, or an RDS endpoint with its SG closed — anything you own):

Q5. Prediction vs reality? How long did the failure take to report compared to Break A, and why is that difference itself a diagnostic signal?

Break C — AUTH

Take a real, reachable database you own and supply a wrong password.

Q6. Prediction vs reality? Explain why no security-group change could ever fix this one — and why the console error text alone wouldn't have told you that.

Q7. Now the reflex test. Fill in from memory, then check against the cheat sheet:

You see Stage First command you run
UNKNOWN_HOST
TIMEOUT
ACCESS_DENIED

Part 3 — the secret and the console trap

  1. Create a secret:
aws secretsmanager create-secret --name q1lab-secret --region $REG \
  --secret-string '{"username":"labuser","password":"placeholder-not-real"}'
  1. In Manage Quick → Security & permissions, grant Quick Sight access to q1lab-secret (lesson 2). Confirm the role appeared:
aws iam get-role --role-name aws-quicksight-secretsmanager-role-v0 --query Role.Arn
  1. Update your Break-C data source to use --credentials "{\"SecretArn\":\"<arn>\"}" (fix the secret's password to the real one if you want it to actually connect).

Q8. Open that data source in the console, change anything (even the name), save, then:

aws quicksight describe-data-source --aws-account-id $ACC --region $REG \
  --data-source-id <id> --query 'DataSource.{Status:Status,Err:ErrorInfo}'

What happened to the secret, per lesson 2? What's the restore command? This is the deliberate failure most worth having caused yourself — it's near-impossible to diagnose the first time it happens to you in production.

Part 4 (optional, Enterprise + existing VPC database) — the VPC connection

Do not create new infrastructure for this — use a dev database that already exists.

  1. Create the three security-group rules from the cheat sheet (QNI SG: all-TCP inbound from DB SG, port-specific outbound to DB SG; DB SG: port inbound from QNI SG).
  2. Create the VPC connection (console, or create-vpc-connection with two subnet IDs).
  3. Q9. Record both CreationStatus and AvailabilityStatus. Why are there two?
  4. Q10. Remove the QNI SG's inbound rule (leave outbound intact). Test the connection. Reconcile what you observe with the "isn't stateful" paragraph of lesson 4 — and note the April 27, 2023 caveat: does your (new) connection behave per the documented pre-2023 rules? You have just produced an empirical answer to a question the docs leave open. Keep it.
  5. Restore the rule.

Teardown

aws quicksight delete-data-source --aws-account-id $ACC --region $REG --data-source-id q1lab-s3
aws quicksight delete-data-source --aws-account-id $ACC --region $REG --data-source-id q1lab-badhost
# ...and the Break B / Break C data sources by their ids
aws secretsmanager delete-secret --secret-id q1lab-secret --region $REG --force-delete-without-recovery
aws s3 rm s3://$BUCKET/q1lab/ --recursive
# Part 4 only:
# aws quicksight delete-vpc-connection --aws-account-id $ACC --region $REG --vpc-connection-id <id>
# ...and remove the three SG rules you added.

Verify: aws quicksight list-data-sources --aws-account-id $ACC --region $REG shows none of the lab IDs.

Done when you can

Facilitator notes