Exam Certified Data Engineer Professional topic 1 question 48 discussion

https://docs.databricks.com/api/azure/workspace/jobs/create API/jobs/create:run_as object Write-only setting, available only in Create/Update/Reset and Submit calls. Specifies the user or service principal that the job runs as. If not specified, the job runs as the user who created the job. In the question, it's not stated that user A creates a service principal. So runas can only be himself.

Both uses their own credential for specific tasks

User A created the jobs via the REST API using their personal access token, so the workspace audit logs will record these job creation events with User A’s identity. Conversely, when User B triggers job runs through the REST API (again, using their own personal access token) via an external orchestration tool, those events will be logged with User B’s identity.

Answer C - the run_as property is not said to be configured, so the job will run with the permissions of the creator - user A. However, still user B will be the one that triggered the run, which is what the question is about.

C should be the correct answer. Although User A has it's user associated to the creation, and by default the run as user if omitted on the creation of the job, the question specifies the Audit Logs (Run Event Logs) associated to the run. I've tried it this out on a job and for a job which was created and has a run as user different from mine, if I go to the run event logs, there are logs which stated that my user trigged a "started" event type

based on the standard understanding of how personal access tokens typically work, each user's actions should be logged separately with their respective identities. Therefore, "C" would be the standard answer unless there is a specific behavior or configuration in Databricks that causes the job run events to be attributed back to User A.

Answer C. The audit logs distinguish between actions like job creation and job execution, so User A and User B will be identified separately for these actions.

I tried myself and E seems correct

When you use the API to commit the jobs the creation is logged using the PAT info, the same happens when you start a run using a different PAT.

Specifies the user, service principal or group that the job/pipeline runs as. If not specified, the job/pipeline runs as the user who created the job/pipeline. Either user_name or service_principal_name should be specified. If not, an error is thrown.

C is the right answer

In Databricks, audit logs capture the identity of the user associated with each distinct event, whether it’s creating or running a job. Since User A used their personal access token to create the jobs and User B used theirs to trigger job runs, the audit logs will reflect User A's identity for job creation events and User B's identity for job run events.

By default, jobs run as the identity of the job owner. This means that the job assumes the permissions of the job owner. You can change the identity that the job is running as to a service principal. Then, the job assumes the permissions of that service principal instead of the owner. https://docs.databricks.com/en/jobs/create-run-jobs.html#run-a-job-as-a-service-principal

When you create a job your role is IS OWNER and RUN AS. So when you trigger a job, it will run as the RUN AS entity. And it should be user A if someone dosen't have changed it

C is correct

C is correct