Self-check: job requisitions over REST

Four questions on the read-only and full privilege sets, the duty roles that grant them, why a role can appear twice, and what the security page does not tell you.

4 questionsPass mark 70%Back to the lesson
  • Distinguish read-only from full privilege
  • Name the duty role that grants read-only access
  • Explain why a role can appear under two duty roles
  • State what the security page does not contain

Every incorrect option names the misconception it represents. A wrong answer tells you which model of the process you reached for, which is the part that is worth correcting.

1. Which privileges does the read-only duty role grant on the recruitingJobRequisitions resource?

Distinguish read-only from full privilege · targets: Reading "read only" as a vague restriction and assuming it still allows a create, which it does not.

2. Which duty role grants the read-only privilege on recruitingJobRequisitions?

Name the duty role that grants read-only access · targets: Guessing at the abstract role name pattern from the full-privilege duty role and inventing one that reads correctly.

3. A requisition integration creates successfully in one tenant and is refused in another, using the same role. What is the most likely cause?

Explain why a role can appear under two duty roles · targets: Comparing job roles between tenants and concluding the role configuration must be wrong, when the duty-role grants are what differ.

4. The security reference page for recruitingJobRequisitions is enough to write a working API integration against it, because it names the privileges the resource is granted.

State what the security page does not contain · targets: Treating a privilege matrix as API documentation, which gets every grant right and every payload wrong.