Linking an administrator to a site already decides most of what they can reach. The admin role you give them then either holds that boundary, narrows it, or opens it back up. Those are two separate layers, and mixing them up is the usual reason an admin sees too much or too little.
This article explains what the site link does on its own, what each admin role option does to it, which modules can be scoped to a site, and how to build a role that keeps someone inside their site while still giving them the wider access their job needs.

It scopes them to that site. Once an administrator is linked to a site, the opportunities, forms, sequences, groups and profiles linked to that site are the ones they work with, and what belongs to other sites stays out of their way. You do not have to configure anything module by module to get that behavior.
An administrator linked to more than one site gets all of those sites together, so their scope grows as you link them to more sites. If you never give them a custom admin role, the site link is the whole story. For what a site is and what can be linked to one, see How do Sites work on Vome?
The admin role decides, module by module, whether their access stops at the site boundary, stops short of it, or reaches past it. The role is the layer that wins, which is why the same site-linked administrator can be set up three very different ways:
Every module that lists items follows the same four-option pattern. Opportunities as the example, and the note under each option in the popup says the same thing:
Forms and Sequences work the same way and carry their own wording of each note.

Seven settings in the admin role offer a site-scoped option:
Notes has a site-aware option as well. Under "View limited notes" you can tick "Notes by admins who share their site(s)", so an administrator reads the notes written by colleagues at their own site and not those written elsewhere.
Yes, if you allow it. The site link is a default, not a wall, and every module's role setting can override it in either direction. That is deliberate, because real jobs rarely sit tidily inside one boundary. Someone can run only their own site's programs and still need to search the whole organization for a returning person.

A local coordinator who needs the whole database. Opportunities, Forms and Sequences all set to "linked to their sites", so they only run their own site's work. The Database question set to "Yes, they can access all profiles in the database", because before creating a profile they need to check whether that person already signed up at another site. Local for everything operational, organization-wide for looking people up.
A fully contained site administrator. Every one of the seven settings on its site-scoped option, the Database included. They cannot reach a profile, a form or a shift that belongs to another site. This is what the recommended setup in section 7 produces.
A site administrator plus one shared program. Site scoping everywhere, except Opportunities is set to "Access to some opportunities" and the organization-wide annual gala is ticked. Because that option is additive, they keep their whole site and gain the gala on top.
A regional lead over several sites. Link them to every site in the region and keep the site-scoped options. Their scope is all of those sites together, so it widens as you link another site without anyone touching the role.
For the wider question of how to divide administrators up by location, see What are the best practices for creating admin roles for multi-location segmentation?
Yes. When your organization has the Sites module active with at least one site created, the Create new admin role popup shows a banner at the top offering the recommended setup for a site-linked administrator. One click on Apply recommended settings puts every setting that offers a site-scoped option onto that option.
Treat it as the starting point rather than the finished role. Apply it first, then widen the one or two modules the job actually needs, which is exactly how the examples above are built.
In this order:
For the database specifically, Why can't an admin see a profile in the database? walks through every condition that can hide a profile.
Still stuck? Submit a ticket, or email us at support@vomevolunteer.zohodesk.com.