Stuck on Cloud Quest Networking Concepts Practice Lab
Hi folks, failing to validate the DIY part of Networking Concepts Practice Lab for Cloud Quest Cloud Practitioner. I managed to get the visual confirmation from the diagram that there's an established connection, see screenshot.
However the validation part keeps failing "could not find a rule in security group DbServerSecurityGroup-027b7300 that opens port 3306 to security group WebServerSecurityGroup, check the security group and try again.", even though I have successfully created the inbound rule in DbServerSecurityGroup using WebServerSecurityGroup as the source:
What am I missing? Do I need to change anything in the Outbound rules in DbServerSecurityGroup? Is this a bug?Thanks.
- Newest
- Most votes
- Most comments
I had the same problem. None of these solutions work for it. It is possible that AWS will allow you to continue even though you click skip. :(
repost error: Invalid security group value. Did you mean 'DbServerSecurityGroup'?
You have to allow access from the WebServerSecurityGroup public subnet 10.10.0.0/24 to the DbServerSecurityGroup security group.
To fix this:
- Edit the DbServerSecurityGroup inbound rules
- Add a new rule for
MySQL/Aurora(port 3306) - For the source, Custom
10.10.0.0/24 - Save the rule
Was facing the same issue...
- Just delete the rule.
- Custom TCP
- Port:3306
- Save Rules
- Validate
You are good to go!
Looking at your screenshots and the error message, I can identify the issue with your security group configuration.
The error message indicates that the validation is looking for a specific type of security group rule - one that references the WebServerSecurityGroup as the source rather than using a CIDR range.
In your screenshot, I can see that you've created an inbound rule for port 3306 (MySQL), but you've specified a CIDR range (0.0.0.0/0) as the source. This allows access from any IP address, which is not what the lab is asking for.
Instead, you need to create a security group rule that specifically references the WebServerSecurityGroup as the source. This is a more secure practice in AWS as it allows only resources with that specific security group attached to connect to your database.
To fix this:
- Edit the DbServerSecurityGroup inbound rules
- Add a new rule for MySQL (port 3306)
- For the source, don't use a CIDR range - instead select the WebServerSecurityGroup from the dropdown
- Save the rule
This approach creates a rule that allows traffic only from instances that have the WebServerSecurityGroup attached, rather than from any IP address. Security group references are a more secure and flexible approach than IP-based rules, especially in dynamic environments where IP addresses might change.
Regarding outbound rules - you typically don't need to modify them as security groups are stateful, meaning if inbound traffic is allowed, the corresponding outbound response traffic is automatically allowed regardless of outbound rules.
Sources
Struggling with Cloud Quest Networking Concepts Practice Lab | AWS re:Post
allow security group , which associated with other ec2, to allow it access | AWS re:Post
Relevant content
- AWS OFFICIALUpdated 4 years ago
- published 3 years ago
I am having the exact same problem. Connection is established and confirmed through the java app, but the validation itself is not working. From what I've seen on older versions of Cloud Quest (ex. https://www.youtube.com/watch?v=YkG_t4sO4wY), the Web Server and DB Server instances names are generated without the unique identifiers attached at the end. I am wondering if the validation was never updated to include the identifiers.
@Jason tried it again today and it worked, Web Server and Db Server security groups didn't have the identifiers attached at the end, looks like they reversed w/e they did with the names.