Implement a secure environment →hardMultiple Choice

DP-300 Implement a secure environment Practice Question

Exhibit

Refer to the exhibit.

```json
{
  "type": "Microsoft.Sql/servers/auditingSettings",
  "apiVersion": "2021-02-01-preview",
  "properties": {
    "state": "Enabled",
    "auditActionsAndGroups": [
      "DATABASE_LOGOUT_GROUP",
      "DATABASE_ROLE_MEMBER_CHANGE_GROUP",
      "BATCH_COMPLETED_GROUP"
    ],
    "isAzureMonitorTargetEnabled": true,
    "storageEndpoint": "https://auditlogs.blob.core.windows.net/",
    "retentionDays": 365
  }
}
```

You are a database administrator for a financial services company. You have deployed an Azure SQL Database and configured auditing using the JSON policy shown in the exhibit. After a security incident, you need to review all successful and failed login attempts to the database. However, you notice that login events are not being captured in the audit logs. What is the most likely reason?

⚠ Common exam trap

Candidates often assume auditing automatically captures all security events, but Azure SQL Database requires explicit inclusion of authentication action groups to log login attempts, and the JSON policy in the exhibit likely omits these groups.

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 audit actions and groups do not include login events

The JSON policy shown in the exhibit defines audit actions and groups, but it does not include the `SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP` or `FAILED_DATABASE_AUTHENTICATION_GROUP` action groups. These groups are required to capture both successful and failed login attempts (authentication events) in Azure SQL Database. Without them, login events are not recorded in the audit logs, regardless of other settings.

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 audit logs are being sent to Azure Monitor instead of blob storage
Why it's wrong here
Azure Monitor is a supported audit destination, so routing logs there does not prevent login events from being captured; they are simply queried elsewhere. It is tempting because destination misconfiguration can hide logs from the expected store, and would be correct if the administrator were checking only blob storage.
✗
The retention days are set too high, causing logs to be truncated
Why it's wrong here
Retention days determine how long audit records are kept before deletion, not whether login events are written at all, so truncation cannot explain their absence. It is tempting because retention genuinely affects log availability, and would be the answer if events were recorded but had aged out before review.
✓
The audit actions and groups do not include login events
Why this is correct
The audit policy's action list omits the relevant login groups, so authentication events are never written to the audit log. Azure SQL Database auditing captures only the actions and action groups explicitly specified in the policy; without SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP or FAILED_DATABASE_AUTHENTICATION_GROUP, both successful and failed logins remain uncaptured.
✗
Auditing is disabled at the server level
Why it's wrong here
Server-level auditing is a separate scope from database-level auditing; a database audit policy still captures events even when the server policy is off. It is tempting because server-level settings do govern some inherited behaviour, and disabling server auditing would matter if the database policy itself were absent.

Go deeper

DP-300 Implement a secure environment Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question