ACP-120 study guide
ACP-120 ยท Work through your exam, one topic at a time.
ACP-120, the Atlassian Certified Professional: Jira Cloud Administrator credential, is a professional-level certification that verifies you can configure, govern, and troubleshoot a Jira Cloud site rather than simply use one. It targets administrators, platform owners, and consultants who already run a site day to day - people who own schemes, user provisioning, workflow design, and permission decisions. The ACP-120 study guide has 8 sections and about 2,718 words.
01Jira Cloud Administration Fundamentals and System Settings
Most questions start with one decision: is this a site concern or a Jira configuration concern? Site-level work - creating users, granting product access, billing, verified domains, security policies, app management - happens at admin.atlassian.com .
336 words, about 2 min02User, Group, and Role Management
An Atlassian account is the identity (email plus verification). Product access decides whether that identity can open Jira Software, Jira Service Management or Jira at all - usually via a default access group such as jira-software-users .
337 words, about 2 min03Project Configuration and Project Types
Company-managed projects are built from shared schemes: issue type scheme, workflow scheme, field configuration scheme, issue type screen scheme, permission scheme and notification scheme can all be shared across many projects, and only a Jira administrator can edit them. Team-managed projects are self-contained: the project administrator edits their own workflow, fields, types and access, and those settings cannot be shared or reused elsewhere.
307 words, about 2 min04Issue Types, Fields, Screens, and Field Configurations
A field reaches a user only when every link holds: it exists and has a context matching the project and issue type; it is on the relevant screen (Create, Edit or View); the field configuration does not mark it hidden or read-only; and, to change it, the user has the relevant project permission. A field missing from a screen cannot be edited even if it is required elsewhere.
363 words, about 2 min05Workflows, Transitions, and Status Configuration
A status is where an issue is; a transition is the arrow that moves it, and it is the only place you attach a condition (who may), a validator (what must be true), a screen (what must be captured), and post functions (what happens next: set resolution, clear a field, fire an event). Post functions run in order, and the event fired at the end is what notification schemes react to.
352 words, about 2 min06Permission Schemes, Project Roles, and Issue-Level Security
Permission schemes answer "what may this user do in this project?" - Browse Projects, Create Issues, Edit Issues, Transition Issues, Assign Issues, Administer Projects, Set Issue Security, Delete Issues. Each permission is granted to a user, group, project role, "Any logged-in user", or application access.
346 words, about 2 min07Notifications, Email, and Communication Settings
An event occurs (issue created, updated, assigned, commented, transitioned, deleted). The project's notification scheme maps that event to recipients: Current Assignee, Reporter, Project Lead, All Watchers, a specific user, a group, or a project role.
330 words, about 2 min08Automation Rules and Administrative Efficiency
A Jira Automation rule is trigger โ condition(s) โ action(s) , optionally with branches that repeat actions for related work (for each sub-task, for each linked issue, for a JQL query). Triggers include issue created, transitioned, field changed, comment added, sprint events, scheduled (cron-based, expressed in UTC), and incoming webhooks.
347 words, about 2 min