In the previous lesson, we touched on the key elements that make up RBAC. They include security principles, role definitions and scopes. Let's touch on each of these in a little more detail. Security principles are objects that represent users, groups, service principals or even managed identities that request access to Azure resources. 

A role definition, which is sometimes referred to as just a role, refers to a set of permissions. It lists operations that can be performed. For example, read, write and delete. Some role definitions can be high level. Examples of such high-level roles would be things like owner or maybe something like virtual machine reader. 

While there are many built-in roles in Azure, there are four fundamental built-in roles. These include owner, contributor, reader and user access administrator. The owner role provides full access to all resources. Owners can also delegate access to other users. 

The contributor role can create and manage all types of Azure resources but can't grant access to other users. Readers can only view existing Azure resources while the user access administrator role allows you to manage user access to Azure resources. 

The term scope refers to a set of resources that a role's access applies to. Whenever you assign a role to a user, you can also limit the actions that the user can take by defining a scope. Scopes, which are structured in a parent-child fashion, can be defined at several levels, including management groups, subscriptions, resource groups and even on individual resources. A fourth element, called a role assignment, attaches a role definition to a user, group, service principal, or managed identity at a specific scope. This is done to provide necessary access. Revoking access is accomplished by removing the role assignment. 

So with some background now under your belt regarding what RBAC is and what it does, let's dive into how to configure it.