Whether or not you have all the AppArmor utilities you need will depend on which Linux distro you have. On my OpenSUSE Leap workstation, the utilities were there out of the box.  On my Ubuntu Server virtual machine, I had to install them myself:

sudo apt install apparmor-utils

First, let's look at the status of AppArmor on the Ubuntu machine:

donnie@ubuntu5:~$ sudo aa-status
[sudo] password for donnie:

apparmor module is loaded.
13 profiles are loaded.
13 profiles are in enforce mode.
   /sbin/dhclient
   /usr/bin/lxc-start
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/sbin/mysqld
   /usr/sbin/tcpdump
   lxc-container-default
   lxc-container-default-cgns
   lxc-container-default-with-mounting
   lxc-container-default-with-nesting
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/mysqld (679)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
donnie@ubuntu5:~$

The first thing to note here is that AppArmor has an enforce mode and a complain mode.  The enforce mode does the same job as its enforcing mode counterpart in SELinux. It prevents system processes from doing things that the active policy doesn't allow, and it logs any violations. The complain mode is the same as the permissive mode in SELinux. It allows processes to perform actions that are prohibited by the active policy, but it records those actions in either the /var/log/audit/audit.log file, or the system log file, depending on whether you have auditd installed. (Unlike the Red Hat-type distros, auditd doesn't come installed by default on Ubuntu.) You would use the complain mode to either help with troubleshooting or to test new profiles.

Most of the enforce mode profiles we see here have to do with either network management or with lxc container management. Two exceptions we see are the two profiles for snapd, which is the daemon that makes the snap packaging technology work. The third exception is for the mysqld profile.

Curiously, when you install a daemon package on Ubuntu, you'll sometimes get a predefined profile for that daemon and sometimes you won't. Even when a profile does come with the package that you've installed, it's sometimes already in the enforce mode and sometimes it isn't. For example, if you're setting up a Domain Name Service (DNS) server and you install the bind9 package for it, you'll get an AppArmor profile that's already in enforce mode.  If you're setting up a database server and install the mysql-server package, you'll also get a working profile that's already in the enforce mode.

But, if you're setting up a database server and you prefer to install the mariadb-server instead of mysql-server, you'll get an AppArmor profile that's completely disabled and that can't be enabled. When you look in the usr.sbin.mysqld profile file that gets installed with the mariadb-server package, you'll see this:

# This file is intensionally empty to disable apparmor by default for newer
# versions of MariaDB, while providing seamless upgrade from older versions
# and from mysql, where apparmor is used.
#
# By default, we do not want to have any apparmor profile for the MariaDB
# server. It does not provide much useful functionality/security, and causes
# several problems for users who often are not even aware that apparmor
# exists and runs on their system.
#
# Users can modify and maintain their own profile, and in this case it will
# be used.
#
# When upgrading from previous version, users who modified the profile
# will be promptet to keep or discard it, while for default installs
# we will automatically disable the profile.

Okay, so apparently, AppArmor isn't good for everything. (And, whoever wrote this needs to take spelling lessons.)

And then, there's Samba, which is a special case in more ways than one. When you install the samba package to set up a Samba server, you don't get any AppArmor profiles at all.  For Samba and several other different applications as well, you'll need to install the AppArmor profiles separately:

sudo apt install apparmor-profiles apparmor-profiles-extras

When you install these two profile packages, the profiles will all be in the complain mode.  That's okay, because we have a handy utility to put them into enforce mode.  Since Samba has two different daemons that we need to protect, there are two different profiles that we'll need to place into enforce mode:

donnie@ubuntu5:/etc/apparmor.d$ ls *mbd
usr.sbin.nmbd  usr.sbin.smbd
donnie@ubuntu5:/etc/apparmor.d$

We'll use aa-enforce to activate enforce mode for both of these profiles:

donnie@ubuntu5:/etc/apparmor.d$ sudo aa-enforce /usr/sbin/nmbd usr.sbin.nmbd
Setting /usr/sbin/nmbd to enforce mode.
Setting /etc/apparmor.d/usr.sbin.nmbd to enforce mode.

donnie@ubuntu5:/etc/apparmor.d$ sudo aa-enforce /usr/sbin/smbd usr.sbin.smbd
Setting /usr/sbin/smbd to enforce mode.
Setting /etc/apparmor.d/usr.sbin.smbd to enforce mode.
donnie@ubuntu5:/etc/apparmor.d$

To use aa-enforce, you first need to specify the path to the executable file of the process that you want to protect. (Fortunately, you normally won't even have to look that up, since the path name is normally part of the profile filename.) The last part of the command is the name of the profile. Note that you'll need to restart the Samba daemon to get this AppArmor protection to take effect.

Placing a profile into other modes is just as easy. All you have to do is to replace the aa-enforce utility with the utility for the mode that you need to use. Here's a chart of the utilities for the other modes: