In Azure AD Identity Governance, application access granted through Entitlement management is organized around catalogs and access packages. The SC-300 study materials explain that “a catalog is a container for resources and access packages” and that you must add your enterprise applications (or the groups tied to those apps) to a catalog before you can build access packages that users can request. Creating the catalog first enables you to place only the required resources in scope and to delegate day-to-day ownership: “catalog owners can manage the resources and access packages within their catalog without being tenant-wide admins,” satisfying the delegation requirement to use custom catalogs and least privilege. After the catalog exists, you create one or more access packages that include the application (or groups) and policies that control who can request, how they are approved, and for how long. Identity Governance then lets you track access package assignments and review who has the app over time. By contrast, programs are used to group and report on governance initiatives (for example, collections of access reviews) rather than to onboard application resources; and modifying user/admin consent settings affects app consent behavior, not the lifecycle tracking of assignments. Therefore, the correct first step to track application access assignments while meeting the delegation requirements is to create a catalog.