Implement a secure environment →hardMultiple Choice

DP-300 Implement a secure environment Practice Question

Exhibit

Refer to the exhibit.

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "Microsoft.Sql/servers/databases/read"
      ],
      "Principal": {
        "AzureAD": "devops@contoso.com"
      },
      "Scope": "/subscriptions/12345678-1234-1234-1234-123456789abc/resourceGroups/rg1/providers/Microsoft.Sql/servers/sqlsrv1/databases/db1"
    }
  ]
}
```

You are reviewing an Azure RBAC role assignment for an Azure SQL Database. The role assignment shown in the exhibit is intended to allow a user to read data from the database. However, the user reports they cannot connect to the database. What is the most likely reason?

⚠ Common exam trap

Many candidates confuse Azure RBAC roles (management plane) with SQL database-level permissions (data plane), assuming that a role with 'read' in the name allows reading data from tables.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The RBAC role does not grant data plane access; the user must be mapped to a database user and granted database-level permissions.

Azure RBAC roles control management plane operations (e.g., creating or deleting resources) but do not grant access to the data plane (e.g., reading or writing data in a database). To read data from an Azure SQL Database, the user must be mapped to a database user (via a contained database user or an Microsoft Entra ID user) and granted database-level permissions such as db_datareader. The RBAC role assignment shown only provides the 'Microsoft.Sql/servers/databases/read' action, which allows reading database metadata (like tags or properties) but not connecting to the database or querying tables.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
The RBAC role does not grant data plane access; the user must be mapped to a database user and granted database-level permissions.
Why this is correct
Azure RBAC roles such as Reader apply to the control plane, governing resource management rather than T-SQL connectivity. Data plane access requires a contained database user mapped to a Microsoft Entra ID login or an external provider, plus database-level permissions such as db_datareader.
✗
The principal is incorrectly specified; it should be a security group.
Why it's wrong here
The principal's type does not determine connectivity; a correctly assigned user account authenticates and connects exactly as a security group does. Security groups are tempting because they simplify bulk permission management, but they are a governance convenience, not a requirement, so this cannot explain the connection failure.
✗
The scope is too broad; it should be at the server level.
Why it's wrong here
Broadening scope to the server would not fix a connection failure; scope controls which resources an assignment covers, not whether a client can reach the logical server. Server-level scope is tempting because it covers every database at once, which suits estate-wide administration, but the user cannot connect at all.
✗
The action 'Microsoft.Sql/servers/databases/read' is not valid; it should be 'Microsoft.Sql/servers/databases/dataReader'.
Why it's wrong here
'Microsoft.Sql/servers/databases/read' is a valid control-plane action; the dataReader action does not exist as a resource-provider operation. Data-plane roles such as SQL DB Reader are tempting because they grant table access, but the reported symptom is failure to connect, which points to server-level authentication or firewall configuration instead.

Quick reference

Access Control Model Comparison

Model	Acronym	Who Controls Access?	Best For
Discretionary Access Control	DAC	Resource owner	Small teams, file shares
Mandatory Access Control	MAC	System / security labels	Classified govt / military
Role-Based Access Control	RBAC	Administrator (via roles)	Enterprise environments
Attribute-Based Access Control	ABAC	Policy engine (user + resource attributes)	Fine-grained, dynamic policies
Rule-Based Access Control	RuBAC	System rules / ACLs	Firewall rules, network ACLs

Go deeper

DP-300 Implement a secure environment Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Access Control Model Comparison

Related to this question