If you want to use a single class, then do as I suggested in my post: Declare a Public variable in a Standard Module:

Public gclsConnect As clsConnect

Now set this up in your setup routine (whether that's Sub_Main or a Form):

Set gclsConnect = New clsConnect
gclsConnect.DBPath = "Fullpath to your database"
If gclsConnect.Connect Then
  Msgbox "Connection made"
End If

From there, you'd use the Connection as need be ... the ADODB.Connection object (which you'd refer to as gclsConnection.MyConnection) would be the actual "connection" to your database. You'd use Recordsets to pull information from that database, so you'd do this:

Dim rst As ADODB.Recordset
Set rst = New ADODB.Recordset

rst.Open "SELECT * FROM MyTAble", gclsConnect.MyConnection

The major differences Standard Modules and Class Modules is that you can only ever have one "instance" of a Standard Module, while you can have xx number of instances of a single Class module. For example, if I have a Module name basCustomer, which stores all the information for a particular customer, then I can have only ONE customer loaded at a time ... this may not be a bad thing, but what if I need to load all the Orders for that customer? If have the code to do this in a Standard Module, I'd be able to work with only ONE Order at a time (since I can't instantiate more than one "instance" of that Standard Module). If I move the Order code to a Class Module, I can then have xx number of Orders:

Dim clsOrder1 As new clsOrder
Dim clsOrder2 As New clsOrder
Dim clsOrder3 As New clsOrder

Each of those objects above would have information about a different order, and I could refer to them independantly:

If clsOrder1.Price > clsOrder2.Price Then
  <do something here>
End If

In general: You'd have commonly used routines in an Standard Module, or routines that really don't belong in a Class module. For example, if you have a code routine that returns an OrderCount, then you might include that in a Standard Module since this would likely be needed outside of the Class object (actually, you'd probably prefer to build a Collection Class to include all the Orders for a particular Client, Date, etc, which would expose items such as Count - but that's another story entirely).

And I have to say, if you're not really even clear as to what a Recordset is vs a Connection, you probably should make this ABUNDANTLY clear to your interviewer ...