Configure and manage automation of tasks →easyMultiple Choice

DP-300 Configure and manage automation of tasks Practice Question

You are a database administrator for a healthcare company that uses Azure SQL Database. The compliance team requires that all automated tasks that modify data must be logged with the identity that executed them. You need to configure an elastic job to run a T-SQL script that updates patient records. Which authentication method should you use for the job step to meet the auditing requirement?

⚠ Common exam trap

A common mix-up: candidates confuse the authentication used by the job agent to connect to the job database with the authentication used to execute steps in target databases.

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 job agent's managed identity with a contained database user in the target database.

The job agent's managed identity provides a distinct, auditable identity for elastic job execution. By creating a contained database user for that identity, all actions performed by the job are attributed to it, which satisfies the compliance need. Managed identities also eliminate password management, making them the recommended approach for elastic jobs.

Answer analysis

Option-by-option breakdown

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

✗
Microsoft Entra ID authentication using a service principal with a client secret.
Why it's wrong here
While Microsoft Entra ID authentication is supported for connecting to Azure SQL Database, elastic jobs do not natively use a service principal for job step execution. The job agent itself uses its managed identity. Configuring a service principal would require additional components and would not be the identity under which the job step runs. This adds complexity and does not meet the requirement as directly as using the managed identity.
✗
A database-scoped credential that stores a SQL login and password.
Why it's wrong here
Database-scoped credentials are used to store secrets for external data sources, but they do not provide the identity context for executing T-SQL steps in elastic jobs. Elastic jobs execute under the job agent's identity or a specified user, not under a credential stored in the job database. Using a credential would not satisfy the requirement to log the identity that executed the task.
✓
The job agent's managed identity with a contained database user in the target database.
Why this is correct
Elastic jobs can authenticate to target databases using the job agent's managed identity. By creating a contained database user mapped to that managed identity and granting it the necessary permissions, all T-SQL steps run under that identity. This provides a clear, auditable identity for any data modifications, satisfying the compliance requirement. Managed identities are also more secure because they avoid storing passwords.
✗
SQL authentication using a server-level login stored in the job database.
Why it's wrong here
Elastic jobs do not support using a server-level SQL login directly for job step execution. While you can create a credential with a SQL login, the job step execution context is not tied to that login in a way that provides a consistent auditable identity. Moreover, storing passwords in credentials increases security risk. This approach would not reliably log the executing identity as required.

Go deeper

DP-300 Configure and manage automation of tasks Practice Question

Why each option matters

Option-by-option breakdown

Related to this question