/etc/puppet/

Main configuration directory. Holds client configuration (puppet.conf), as well as master configuration (puppet.conf, fileserver.conf, tagmail.conf), and directories and files relevant for the puppet master (manifests/).

/etc/puppet/manifests/

Holds the manifests the puppet master uses to determine the configuration to push to the client. At the very least, this directory should have a file named site.pp. This directory also contains nodes/, classes/, utils/, and groups/.

/etc/puppet/manifests/nodes/

Holds the declaration of nodes (clients) being managed, and what configuration should be included for these clients. An example node declaration looks like this:

node 'dummy.example.org' {
    include some-class
}

which causes client dummy.example.org to include configuration held by the class some-class.

/etc/puppet/manifests/classes/

Holds the classes that are not modular. Using non-modular classes is a bad idea, and you should avoid it whenever possible. Although perfectly valid, it obfuscates the configuration applied to the clients and does not scale very well. In addition, it doesn't allow for a naming standard for the files such as the service or configuration item it is managing.

/etc/puppet/manifests/utils/

Particularly useful if the managed systems are somewhat homogeneous (they are all Linux?), so you can set defaults. Imagine you have to set the PATH for each Exec. Instead, defining in utils/exec.pp:

Exec {
    path => [
        "/bin/",
        "/usr/bin/",
        "/usr/local/bin/",
        "/sbin/",
        "/usr/sbin/",
        "/usr/local/sbin/",
    ]
}

and importing it once (in site.pp) will save you from having to define the PATH over and over again.