AWS re/Start Lab · Bases de Datos

Challenge Lab: Build Your DB Server and Interact With Your DB

This challenge lab uses Amazon RDS and a LinuxServer to create and query a custom schema. The exercise creates two tables, inserts sample data, verifies the rows, and joins both tables to combine student and certification information.

Lab Summary

Launched an RDS instance, connected from the LinuxServer using the MySQL client, created the RESTART and CLOUD_PRACTITIONER tables, inserted sample rows, queried each table, and finished with an INNER JOIN that combined student IDs, names, and certification dates.

Client Connection

Verified the MySQL client on the LinuxServer and connected to the RDS endpoint with the lab credentials.

Table Creation and Inserts

Built two custom tables and populated them with sample data for the challenge.

Join Validation

Queried both tables separately and then combined them with an inner join to produce a single result set.

Step-by-Step Walkthrough

This challenge emphasized doing the full path yourself: create the database connection, define the schema, insert data, and then query it meaningfully.

01

Connect from the LinuxServer to the RDS endpoint

  • Created an RDS instance within the allowed lab limits, using the Lab VPC and a security group that allowed access from the LinuxServer.
  • Connected to the LinuxServer, verified the client installation with mysql --version, and opened a session to the endpoint using mysql -h ... -P 3306 -u main -p.
  • Confirmed the connection when the MySQL prompt appeared and the server version information was displayed.
This first connection is the real checkpoint for the networking setup. If the client cannot reach the endpoint, the RDS instance and its security rules still need review.
02

Create and populate the RESTART table

  • Selected the lab database with USE lab;.
  • Created the RESTART table with the columns student_id, student_name, restart_city, and graduation_date.
  • Inserted ten sample rows representing students and their re/Start cities.
  • Queried the table with SELECT * FROM RESTART; to confirm the ten inserted records.
03

Review the RESTART result set

  • Displayed the complete contents of RESTART with SELECT * FROM RESTART;.
  • Confirmed that each row included the expected student ID, name, city, and graduation date values before building the second table.
04

Create and populate the CLOUD_PRACTITIONER table

  • Created the CLOUD_PRACTITIONER table with the columns student_id and certification_date.
  • Inserted five sample certification rows and verified that the insert completed without warnings.
05

Query the second table and join both datasets

  • Ran SELECT * FROM CLOUD_PRACTITIONER; to confirm the five certification rows.
  • Executed an INNER JOIN between RESTART and CLOUD_PRACTITIONER on student_id.
  • Displayed student_id, student_name, and certification_date in the final result set to show only the students present in both tables.

Query Reference

Main commands and SQL statements used to create the schema and join the resulting tables.

cmd

mysql --version

Checks that the MySQL client is installed on the LinuxServer.

cmd

mysql -h <endpoint> -P 3306 -u main -p

Connects from the LinuxServer to the RDS instance through the MySQL client.

sql

CREATE TABLE RESTART (...)

Defines the student table with ID, name, city, and graduation date columns.

sql

INSERT INTO RESTART (...) VALUES (...)

Loads the sample student rows into the RESTART table.

sql

CREATE TABLE CLOUD_PRACTITIONER (...)

Defines the second table used to store certification dates.

sql

SELECT * FROM CLOUD_PRACTITIONER;

Displays the certification rows before the join.

sql

INNER JOIN CLOUD_PRACTITIONER c ON r.student_id = c.student_id

Combines both tables and keeps only the rows that exist in both datasets.

Key Learnings

What Was Actually Learned

A successful RDS deployment still needs a reachable client path from the LinuxServer before any SQL work can start.
Creating small custom tables is a good way to validate both the schema design and the connection to the managed database.
An INNER JOIN returns only the shared keys between two tables, which makes it useful for combining related datasets without including unmatched rows.

Technical Conclusion

This challenge lab was more complete than a simple query exercise because it joined infrastructure and data work in the same flow. The database had to exist, be reachable, contain the right tables, and then return meaningful joined data.

The final join was the clearest proof that the schema was usable. It showed that the tables were not only created correctly, but also related in a way that allowed the student and certification information to be queried together.