Please fill in the following information:

Issue description

There is a bad conceptual design in this exercise that makes the student think that the exposed port and the internal port of the container are the same. 

A feedback question from a student reveals this and I quote:

"Dear Team, According to the Lab: Troubleshooting Application Issues step 3.5. the port 3306 is not open. I can confirm that the port is not open in my lab. Though the port ist not open and no portmapping between the host and the container exists (this would be done in step 3.7.) I'm getting the correct view count when executing `curl http://localhost/showviews.php`. I'm able to connect to the database and insert the command from step 4.2. which should be impossible IMHO. I don't understand why the commands succeed without running step 3.7. So I think there might be something fishy here. Please investigate and fix this. Best regards, Joerg"

So the exercise in itself won't show up any errors unless the user deliberately tries to access the container database without exposing the port to the host. It's possible to access the database by pointing directly to 10.89.0.2:3306. 

Steps to reproduce:

Workaround:

For the exercise to fail while "curling" when the port is not exposed to the localhost, the hostname variable in the HTML code should point to localhost, and not 10.89.0.2, as shown in the attached image. 

So I would introduce a step saying that pods can change IP at any point and it's not a good practice to hardcode the IP in the HTML code.  

Expected result: