Exam Certified Data Engineer Professional topic 1 question 117 discussion

As long as User B’s PAT is used to trigger the run, User B’s email will appear in creator_user_name

The correct answer is: E. User C will only ever appear in this field if they manually trigger the job, otherwise it will indicate User B. Explanation: The creator_user_name field in Databricks job run metadata indicates the identity of the user or token that triggered the job run, not the job owner or notebook creator. User A created the jobs but is no longer relevant once job ownership is transferred and jobs are triggered by another identity. User B triggers the jobs via the REST API using their personal access token—this makes User B the creator of the runs. User C now owns the jobs but does not trigger the runs unless they manually do so, in which case their email would appear. So unless User C manually triggers a run, User B’s identity (email) will consistently appear in the creator_user_name field because their token is being used for the API-triggered runs.

Suretly B

It's E as hameur01 mentioned.

It should be User A. Go to any existing workflow which has a few runs and see the JSON. It will have the creator_user_name as the creator of the workflow. For the user who has triggered the job, the field name is "run_as_user_name"

It should be User A. Go to any existing workflow which has a few runs and see the JSON. It will have the creator_user_name as the creator of the workflow. For the user who has triggered the job, the field name is "run_as_user_name"

B - the person that triggered the job. Since we are using User B personal access token, it is going to say User B's email address.

User A was OWNER, B just run job, doesn't became OWNER, then User C became OWNER - so case "A"

creator_user_name reflects the user who triggered the job run, not the job owner or the notebook creator. For programmatically triggered runs, the field will reflect the user whose personal access token was used (User B in this case). If User C manually triggers a job, the field will show User C’s email address for that specific run.

It's B.

ownership of job an be assigned to user not for a group. Option A is correct.

Seems correct.

The creator_user_name field in the run information returned by the REST API reflects the user who originally created the job. Since User A created the jobs using their personal access token, their email address will always appear in this field, regardless of who triggers the job runs or who takes ownership of the job later.

C based on previous comment

Job creator can't be changed. Owner can be changed. So creator_user_name field always return who created the job: User A. But UserA no longer owns the job. So Answer C is partially correct.

Job creator can't be changed. Owner can be changed. So creator_user_name field always return owner: User A. But UserA no longer owns the job. So Answer C is partially correct.

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