The instructions are using "gitlab.example.com" as a placeholder. They expected you to substitute your server's actual domain name, like "gitlab.briefwishbone9091.com". The domain name could be publicly registered like "linux.org" (or you could register "briefwishbone9091.com" yourself), or it could be private to your lab only and not registered. In this case, you picked their example, "gitlab.example.com". That may not have been the best choice, but it should work. The people who wrote the documentation assumed that you already had your own domain name for your GitLab server and had some kind of DNS running. If you are the only user, then it may not be a concern.
Confirming what @dos2unix posted above:
There are special domain names that are reserved for special uses, and "example.com" is one of them. It is intended for examples in documentation. Anything that uses example.com will not work on the real internet.
Adding the "gitlab.example.com" entry to your hosts file on your computer overrides everything. That is why the DNS lookup on your computer returns the 192.168 IP address for your GitLab server. DNS on your computer returns the entry in the hosts file, even though anything with "example.com" is technically "reserved" and will not work on the real internet.
If you are the only person accessing that GitLab server, then modifying your hosts file is quick and easy, even if it is not the "elegant solution." When your computer does a DNS lookup, it checks the hosts file first. That is why this trick works.
If other people will be using your GitLab server from separate computers, then you will probably want a real DNS setup in your lab. It would be "poor practice" to modify the hosts file on each separate computer ... but it would work. (Think about what it would take to fix later if you change the GitLab server's IP address. Would you remember that you hid that DNS entry in a bunch of hosts files? Would you want to update their hosts files one-by-one?)
