How to pass the ACP-120 Jira Administration for Cloud Exam

Marta, the Staffing lead, created a filter and tried to share it with the project role “Recruiters” in the Jira project “Staffing”. Marta has the Browse Project permission in the “Staffing” project. She was able to create the filter but after choosing the “Staffing” project she could not find the “Recruiters” project role in the sharing drop-down. What is the reason?

• ❏ A. Marta does not have the global Share filters and dashboards permission

• ❏ B. Marta is not a member of the “Recruiters” project role in the “Staffing” project

• ❏ C. Marta must first share the filter with all project roles in the Staffing project and then she will be able to pick the “Recruiters” role

• ❏ D. Jira Cloud does not support sharing filters with project roles

Sana at AtlasSoft wants her Jira instance to reflect the company branding. Which settings under the Look and feel global configuration can she modify to accomplish this? (Choose 3)

• ❏ A. Application background color

• ❏ B. Site favicon

• ❏ C. System default language

• ❏ D. Date and time display format

• ❏ E. Site logo

• ❏ F. Application title text

Lina is auditing a HarborTech company managed project that uses these issue types Story Task Bug Enhancement and Sub-item where Sub-item is the sub task issue type and she notices that Enhancement and Sub-item are rarely used so she wants to remove them from the project issue type scheme What statement is true?

• ❏ A. Jira will automatically map Enhancement and Sub-item issues to the project’s default standard issue type

• ❏ B. She will be required to choose a destination issue type for each Enhancement when removing it from the scheme

• ❏ C. She must first convert any existing Sub-item issues into a standard issue type before she updates the issue type scheme

• ❏ D. She must reassign all existing Enhancement issues to another standard issue type before making changes to the scheme

• ❏ E. If multiple sub task types existed she could remove one and Jira would prompt to move existing sub tasks to the other sub task type

Priya recently started as a delivery lead at NovaApps and she needs permission to manage project versions and project components and to create a new sprint and to update an issue due date? (Choose 4)

• ❏ A. Manage Project Roles

• ❏ B. Schedule Issues

• ❏ C. Manage Components

• ❏ D. Administer Projects

• ❏ E. Edit Issues

• ❏ F. Manage Sprints

Which JQL queries will return resolved issues from the saved filter ‘ACP-125 Practice’? (Choose 3)

• ❏ A. filter = ‘ACP-125 Practice’ AND status = Done

• ❏ B. filter = “ACP-125 Practice” AND resolution is NOT EMPTY

• ❏ C. filter = “ACP-125 Practice” AND resolution is NOT NULL

• ❏ D. filter = ‘ACP-125 Practice’ AND resolution = Done

Which Jira configuration affects whether email notifications are sent to users when issue events occur?

• ❏ A. Permission schemes

• ❏ B. Screens

• ❏ C. Agile boards

• ❏ D. Issue security levels

• ❏ E. Dashboards

Ravi is unable to locate any accounts when he tries to pick a user in the assignee field on the Vertex Systems Jira Cloud instance. Which configuration must be updated so users appear in the user picker?

• ❏ A. Issue security scheme

• ❏ B. User directory settings

• ❏ C. Global permission to browse users and groups

• ❏ D. Project permissions

Maya ran three JQL queries against the Bluewave project and she expected the third query to return 110 issues. JQL A of project = “Bluewave” returns 130 issues. JQL B of project = “Bluewave” AND fixVersion = “Release 2.0” returns 20 issues. JQL C of project = “Bluewave” AND fixVersion != ‘Release 2.0’ returns 40 issues. What could explain the discrepancy?

• ❏ A. Maya must reindex Jira to obtain the correct counts

• ❏ B. Change the single quotes around the fixVersion value to double quotes

• ❏ C. Some issues are not visible because Maya does not have Browse Projects permission

• ❏ D. An issue security level has been applied that limits which issues Maya can see

• ❏ E. project = “Bluewave” AND (fixVersion != ‘Release 2.0’ OR fixVersion is EMPTY)

Marisol has just created a new company managed project from a Scrum template and she must update the project configuration to satisfy several constraints. The Summary system field on the Sub task issue type must be prevented from being edited after creation. The Affects Versions system field must be added to the Create and Edit screens for the Task issue type. A new sub task issue type named Infrastructure Sub task must be added to the project and it must keep the default configuration. No other project settings should be changed. The project currently contains the following issue types Epic Standard Issue Type Story Standard Issue Type Task Standard Issue Type Bug Standard Issue Type and Sub task Sub task issue type. How many screen schemes does Marisol need to create?

• ❏ A. 4

• ❏ B. 0

• ❏ C. 2

• ❏ D. 1

• ❏ E. 3

Which Jira workflow configuration automatically sets the issue assignee when an issue transitions?

• ❏ A. Transition screen

• ❏ B. Post function

• ❏ C. Automation rule

Your operations team at Skyline Apps changed a company managed project key from “APP” to “MOB” as requested by product. The project contains fewer than eight issues in total. Which statement about this change is correct?

• ❏ A. All saved JQL filters that mention the old key “APP” must be updated to reference the new key “MOB”

• ❏ B. No background project reindex will be triggered because this instance is Jira Cloud

• ❏ C. The original key “APP” will remain reserved and cannot be reused

• ❏ D. The rename will only become visible after 48 hours have passed

At HarborTech support a customer message created a ticket but the customer did not get a reply from Aisha so they resent the original email to prompt a response. What will occur when the resent email is processed?

• ❏ A. A new issue will be created in the project

• ❏ B. A new comment will be added to the existing issue

• ❏ C. A new issue will be created and linked to the original issue

• ❏ D. A new subtask will be added under the original issue

• ❏ E. The mail handler will ignore the forwarded message as a duplicate

Clearpath Labs is choosing between team managed and company managed projects and they need to know which capability can only be delivered by a company managed project. Which feature requires a company managed project?

• ❏ A. Show subtasks grouped on the project board

• ❏ B. Send notifications to the chosen component lead

• ❏ C. Add the issue navigator to the project sidebar

• ❏ D. Turn on a backlog for a Kanban board

• ❏ E. Change the color assigned to an epic

A company called Solstice Systems provisioned a Jira Software Cloud site for about 2 500 staff who are located across multiple regions and who use several corporate email domains. Which of the following is not a supported way to grant people access to your Jira site?

• ❏ A. Allow any domain signups

• ❏ B. Invitation links

• ❏ C. Approve multiple domains

• ❏ D. User invites

• ❏ E. Atlassian Access

Which Jira attribute values are not translatable using the built-in translation feature in the Jira interface? (Choose 2)

• ❏ A. Statuses

• ❏ B. Issue Security Levels

• ❏ C. Custom Field Names

• ❏ D. Issue Links

All exam questions come from my Jira ACP-120 Udemy course and certificationexam.pro

Maya needs to create a new team managed project on her Jira site where only administrators and the people she explicitly adds can search for view create or edit the issues in the project. Which project access setting satisfies this requirement?

• ❏ A. Limited access

• ❏ B. Site visible

• ❏ C. Open access

• ❏ D. Private access

Maya created a new Filter Subscription using the following JQL and set the recipient to the executive-board group. assignee in membersOf(“executive-board”) Maya holds the board project role and she can view all issues in her project. Who will receive the subscription emails?

• ❏ A. All users assigned the board project role and members of the executive-board group

• ❏ B. All users assigned the board project role

• ❏ C. All members of the executive-board group

• ❏ D. Only Maya

Yesterday Maya linked the story TASK-210 that she is working on to two other stories APP-210 and UI-210. Today Maya tried to add a comment and update the due date on TASK-210 and she noticed that all links from TASK-210 have disappeared while she can still view TASK-210 APP-210 and UI-210 across their projects. What are two possible causes? (Choose 2)

• ❏ A. “Link Issues” project permission was revoked for Maya in the TASK APP and UI projects

• ❏ B. Maya has been excluded from a global permission

• ❏ C. The connections between TASK-210 and APP-210 and UI-210 were removed

• ❏ D. Maya is no longer a project administrator for TASK APP and UI projects

• ❏ E. “Edit Issues” project permission was revoked for Maya in the TASK APP and UI projects

• ❏ F. Issue linking was turned off at the site level

Marina needs to perform a bulk update in the QA project to set the Component field to “Backend”. The QA project sends notifications to both the Assignee and the Reporter whenever an issue is changed. The bulk edit completed successfully. Which statements about the outcome are true? (Choose 2)

• ❏ A. Marina Evan and Sara will be notified

• ❏ B. The Resolution of QA-31 is updated

• ❏ C. The updated date of QA-31 QA-58 and QA-62 is changed

• ❏ D. The updated date of QA-31 and QA-58 is changed

• ❏ E. Marina is assigned to all three issues

• ❏ F. Marina Evan Sara and Liam will be notified

How can you remove “Time tracking” and its associated features from company managed Jira Cloud projects that share the same configuration?

• ❏ A. Disable “Time tracking” as a global feature

• ❏ B. Hide “Time tracking” in each Field Configuration

• ❏ C. Remove “Time tracking” from all screens

A product owner at SummitApps must create a new Jira project to oversee several concurrent initiatives and to enable a steady stream of ongoing bug fixes. Which project type should they pick?

• ❏ A. Team-managed Scrum board project

• ❏ B. Company-managed Kanban board project

• ❏ C. Company-managed Scrum board project

• ❏ D. Team-managed Kanban board project

Marisol at BrightLayer has added a new status called “Published” to her Jira workflow and she needs to move several issues into the “Published” status. What steps must she take to update those issue statuses? (Choose 4)

• ❏ A. Use the bulk change feature and select the Transition Issues operation to set the new status

• ❏ B. Ensure there are no Validators that block the transition

• ❏ C. Request the Transition Issues project permission

• ❏ D. Confirm there are no workflow status properties restricting changes to that status

• ❏ E. Use the bulk change Move Issues operation to alter the status

• ❏ F. Request the Edit Issues project permission

Alex was hired as a Product Owner and you granted them access to the HR company managed project that is operated in Jira with a Scrum board where ranking is enabled. Alex can create issues, add comments, upload attachments, set due dates, change the reporter, assign issues and edit them. Despite these abilities Alex cannot reorder items in the backlog. What is preventing Alex from ranking issues on the board?

• ❏ A. Board administrator role

• ❏ B. Schedule issues project permission

• ❏ C. Jira Administrator product access

• ❏ D. Jira Software product access

Marco often applies a filter that returns issues from both a team-managed project and a company-managed project. The filter uses the query Project IN ( TMX , CMR ) AND Resolution = Done AND status = Done. Issues of type Task from the team-managed project unexpectedly vanished from the filter results. What is a likely root cause?

• ❏ A. A status was renamed via the Statuses administration page

• ❏ B. The project key was changed in the team-managed project

• ❏ C. A board column was renamed inside the team-managed project

• ❏ D. A resolution was renamed via the Resolutions administration page

Which JQL expressions will return issues where the summary contains the token “Skillwise”? (Choose 3)

• ❏ A. summary is “Skillwise”

• ❏ B. summary ~ “Skillwise”

• ❏ C. summary ~ “\[Skillwise\]”

• ❏ D. summary ~ “[Skillwise]”

Maya works for a company called Orbital Systems which employs about 1,500 people and plans an aggressive recruitment drive next year. The organization uses multiple domains such as example.com and hr.example.com and Maya recently provisioned a new cloud site and turned on Jira Software Cloud. She needs to configure access so that every employee receives product access at once access is limited to company accounts and administrative effort for future hires is minimal. What configuration should Maya apply to meet these requirements?

• ❏ A. Enable user invites so employees can invite colleagues

• ❏ B. Enable Atlassian Access and configure automatic provisioning

• ❏ C. Add all company domain names as approved domains

• ❏ D. Set the site to Public and use IP allowlisting

• ❏ E. Verify all company domain names

You administer the Jira site at https://acme-systems.example.com where only Jira Software is enabled and the instance contains both company managed and team managed projects. Your team proposes using a powerful private server in your corporate datacenter at no cost so they can run extensive staging tests. All Jira Cloud site configuration must be retained in the new staging environment. What is the best way to proceed?

• ❏ A. Follow your team’s recommendation and take a Cloud backup of the Jira site https://acme-systems.example.com and attempt to restore that backup to your on premises server after installing Jira 9

• ❏ B. Do not follow your team’s recommendation and produce a Server backup of the Jira site https://acme-systems.example.com then create a new Jira Cloud site with Jira Software and try to restore the Server backup into the new Cloud site

• ❏ C. Follow your team’s recommendation and create a Server backup of the Jira site https://acme-systems.example.com then restore that backup to your on premises server after installing Jira 9

• ❏ D. Do not follow your team’s recommendation and create a Cloud backup of the Jira site https://acme-systems.example.com then provision a new Jira Cloud site with Jira Software and restore the Cloud backup to that new site

Which statements about sub-tasks in a Jira Cloud site are accurate? (Choose 3)

• ❏ A. Administrators can turn off the Sub-Task feature when no sub-tasks exist in the instance

• ❏ B. Sub-tasks can be converted into standard issue types and standard issues can be converted into sub-tasks

• ❏ C. Sub-tasks can hold additional sub-tasks beneath them

• ❏ D. Sub-task names and descriptions can be localized for the installed languages

• ❏ E. Sub-tasks cannot be moved to different projects

• ❏ F. Sub-tasks automatically count in board sprint capacity the same as their parent issues

Maya at Nimbus Solutions must retrieve every subtask that does not have any labels assigned in their tracker. Which JQL will return those subtask issues? (Choose 2)

• ❏ A. issuetype in standardIssueTypes() AND labels is EMPTY

• ❏ B. issuetype in subTaskIssueTypes() AND labels is EMPTY

• ❏ C. issuetype in subTaskIssueTypes() AND labels = “”

• ❏ D. type in subTaskIssueTypes() AND labels is EMPTY

• ❏ E. labels in (NULL)

• ❏ F. issuetype in subTaskIssueTypes() AND labels = NULL

Which configuration change allows a user to perform bulk edits, delete issues, create and share filters and dashboards, and make fields required in a company managed project?

• ❏ A. Modify project role assignments

• ❏ B. Change group memberships

• ❏ C. Update field configuration scheme

When Mark mentions Lucy in a comment on issues she does not receive any email alerts but when Oscar mentions Lucy in comments on the same issues she immediately receives email alerts. Which configuration is causing Lucy to miss notifications when Mark mentions her?

• ❏ A. The notification scheme was modified so the “Issue Commented” event does not include mentioned users

• ❏ B. Lucy has disabled the personal setting “Someone mentions you”

• ❏ C. Mark is missing the global permission “Browse users and groups”

• ❏ D. Mark lacks the project permission “Add Comments”

• ❏ E. A security level on the issue prevents Lucy from seeing the issues where she is mentioned

BlueWave Solutions runs a company managed project in Jira Cloud and needs an automation rule so that when a sub task has its due date changed and that new date is later than the parent issue due date then the parent issue due date is updated to match the sub task due date. Which automation rule configuration will accomplish this?

• ❏ A. Configure a trigger When issue updated and add a condition If parent exists then branch For parent and verify that the parent “Due date” is after the “Due Date” from the trigger issue and then edit the parent “Due Date”

• ❏ B. Use a trigger When value changes for “Due Date” and add a condition If parent exists then branch For parent and check that the parent “Due date” is before the “Due Date” from the trigger issue and then edit the parent “Due Date”

• ❏ C. Create a trigger When value changes for “Due Date” add a condition If parent exists and then verify that the current issue “Due date” is after the parent “Due Date” before editing the “Due Date”

• ❏ D. Set a trigger When value changes for “Due Date” and add a condition If parent exists then branch For sub tasks and check that the sub task “Due date” is after the “Due Date” from the trigger issue and then edit the sub task “Due Date”

In an organization managed project at Riverton Systems which administrators are able to create and modify user groups?

• ❏ A. Project administrators

• ❏ B. Jira administrators

• ❏ C. Organization administrators

• ❏ D. Site administrators

Both company-managed and team-managed projects currently use the ‘Done’ resolution. If Samira renames that resolution to ‘Finished’ what will happen?

• ❏ A. Dashboards will show errors in team-managed projects

• ❏ B. Saved filters and JQL queries will return different results in company-managed projects

• ❏ C. Some automation rules in the company-managed project will stop working

• ❏ D. Reports will error only in company-managed projects

Which Jira subscription types can you advise a user to configure when the user will create the filters themselves and you have no access to their Jira site? (Choose 2)

• ❏ A. Send unresolved Highest priority issues each morning to the project role Engineers

• ❏ B. Send monthly resolved issues to the group “ops managers”

• ❏ C. On the final Friday each month email released fix versions to the group “administrators”

• ❏ D. Send a weekly list of issues she resolved to herself

All exam questions come from my Jira ACP-120 Udemy course and certificationexam.pro

Rita added a new custom field named ‘Project Cost’ and she notices the field is missing from some issues within the same project while it appears on others. Which statement best explains this behavior?

• ❏ A. The field has a context that limits it to particular issue types or screens

• ❏ B. Issue security levels are preventing the field from being visible on some issues

• ❏ C. The ‘Project Cost’ field is set to hide when empty

• ❏ D. The user does not have Browse Projects permission on those particular issues

About six weeks ago you provisioned a new Jira Software Cloud site for Nimbus Systems and posted invitation links on the company intranet. Employees are now reporting that those links are invalid. What action should you take to fix the issue and stop receiving complaints?

• ❏ A. Resend individual email invitations to the affected staff from the user management console

• ❏ B. Create a fresh invitation link and replace the expired link on the company intranet

• ❏ C. Create a new invitation link and place it next to the previous link on the intranet

• ❏ D. Open an Atlassian support case and provide the invitation link and site address

You manage the project “WorkflowPro” and it includes two components called “TaskService Red” and “TaskService Blue” and you need to change every issue that references “TaskService Red” so that they reference “TaskService Blue” and then remove “TaskService Red” from the project components list, and both components currently have issues assigned to them, what is the best way to accomplish this?

• ❏ A. Use a bulk edit to update issues from “TaskService Red” to “TaskService Blue” and then delete the “TaskService Red” component

• ❏ B. Delete the component “TaskService Red” and reassign its issues to “TaskService Blue&quot

• ❏ C. Merge the component “TaskService Red” into “TaskService Blue&quot

• ❏ D. Rename the component “TaskService Red” to “TaskService Blue&quot

At Nimbus Systems you manage ProjectBoard Cloud user accounts for your team and you need to understand account status and billing implications. Which statements correctly describe how those accounts are handled and billed? (Choose 2)

• ❏ A. Deleting a user permanently removes their global account

• ❏ B. Users who are suspended cannot sign in to your organization or access its products

• ❏ C. Removed users no longer occupy a ProjectBoard Cloud seat

• ❏ D. Suspended users continue to occupy a ProjectBoard Cloud license

• ❏ E. A disabled managed account cannot be reinstated

• ❏ F. A disabled managed account can only be restored within 30 days

Which workflow elements implement the following behaviors which include sending an email after a transition, setting the resolution, requiring all fields, restricting who can add attachments, and showing the transition only to the appsec group?

• ❏ A. 1 Condition 2 Validators 1 Post Function 1 Status Property

• ❏ B. 1 Condition 1 Validator 2 Post Functions 1 Status Property

• ❏ C. 2 Conditions 1 Validator 1 Post Function 1 Status Property

Riya needs to close out her active sprint at EchoTech but three issues remain unresolved and must be handled before the sprint can finish. As the project administrator what minimum project permissions does Riya need to complete the sprint? (Choose 4)

• ❏ A. Administer sprints

• ❏ B. Transition issue workflow

• ❏ C. Modify issues

• ❏ D. Allow moving issues between projects

• ❏ E. View the project

• ❏ F. Schedule issues into sprints

Ravi collected requirements from his product and engineering teams. The group needs one workflow that can be reused across several projects. Every developer must have uniform permissions across all projects. Teams require multiple boards that cover different projects. The effort spans multiple departments and needs several distinct permission schemes. Which Jira project type is the best fit for these requirements?

• ❏ A. Team-managed project

• ❏ B. Company-managed project

In a team owned project users can adjust the issue view per issue type and the layout is split into two areas named Details fields and Context fields. Which field cannot be removed from the Context fields section?

• ❏ A. Reporter

• ❏ B. Issue Type

• ❏ C. Summary

• ❏ D. Description

• ❏ E. Status

Elena is both the reporter and the assignee of issue “NVA-203” and she also serves as the project lead and the project administrator for the company managed project “NOVA”. The project notification scheme sends emails on Issue Updated to the Reporter Current Assignee Project Lead and Project Administrator. The issue “NVA-203” was just modified by Carlos. How many email notifications will Elena receive?

• ❏ A. Two notifications

• ❏ B. One notification

• ❏ C. Four notifications

• ❏ D. Three notifications

What minimum project permissions must a user have to complete an active sprint by handling the remaining issues? (Choose 3)

• ❏ A. Edit Issues

• ❏ B. Manage Sprints

• ❏ C. Schedule Issues

• ❏ D. Browse Projects

SprintBoard Cloud includes an internal mail handling pipeline that accepts issue requests sent by email and processes them in stages. The pipeline polls the linked inbox every 90 seconds and copies messages smaller than 30MB into the mail database while filters remove auto replies and spam and a cleanup job purges messages older than 30 days with configurable retention from 21 to 150 days. Which component retrieves unread messages from the connected inbox?

• ❏ A. Email processor

• ❏ B. Cloud Pub/Sub

• ❏ C. Mail retriever

• ❏ D. Mail handler

• ❏ E. Inbound mail gateway

Priya manages a team-managed project and she has eight issues assigned to version v2.0 and one issue assigned to version v2.0beta because of a naming mistake. She wants to consolidate v2.0beta into v2.0. Which actions must she perform to accomplish this? (Choose 2)

• ❏ A. Move issues

• ❏ B. Rename version

• ❏ C. Archive version

• ❏ D. Remove version

• ❏ E. Merge versions

• ❏ F. Swap versions

Lena created a new project named “ORBIT” that reuses the shared configuration from the project “VOYAGER”. The “VOYAGER” project has these role assignments. The Administrators role contains Lena and the Scrum Team role contains Mateo and Priya. The notification scheme used by “VOYAGER” sends notifications on the “Create issue” event to the Project Role Scrum Team the current assignee watchers and the reporter. You must ensure Lena Mateo and Priya receive notifications when issues are created in the project “ORBIT” while leaving all shared configurations unchanged. What is the correct way to achieve this?

• ❏ A. Assign Lena Mateo and Priya to the project role Scrum Team in the project “ORBIT”

• ❏ B. Add Lena Mateo and Priya directly to the “Create issue” event in the notification scheme used by “ORBIT”

• ❏ C. Add the Administrators project role to the “Create issue” event in the notification scheme used by “ORBIT”

• ❏ D. Assign Lena Mateo and Priya to the Administrators role in the project “ORBIT”

• ❏ E. Assign only Lena to the Scrum Team role in the project “VOYAGER”

A product team at InsightWorks needs to capture a new attribute for issues. In which scenarios should they pick a custom field instead of a component? (Choose 2)

• ❏ A. Selecting a value will automatically assign the issue to a specific user

• ❏ B. The field must be reusable across many projects

• ❏ C. Project administrators will configure and manage the field within each project

• ❏ D. Users must be limited to choosing a single value from the field

Which behaviors are supported by a team owned project board? (Choose 3)

• ❏ A. Users can create multiple issues at once from the board

• ❏ B. Users can add a new status directly from the board

• ❏ C. Boards sync automatically across projects

• ❏ D. Users can group issues by priority

A developer at Relaybox created an automation to email the support staff when a ticket changes and she wants the message to include the ticket status. What is the correct smart value format to use?

• ❏ A. {issue.status}

• ❏ B. {{issue.statusName}}

• ❏ C. {{issue.status}}

• ❏ D. {{issue.status.name}}

• ❏ E. $issue.status

Marco has just deactivated a managed user account for Priya at BrightBeam. Which statement is definitely false?

• ❏ A. Assigned issues that referenced Priya will remain in the project

• ❏ B. Priya’s account can be reactivated later if necessary

• ❏ C. Priya’s deactivated account will continue to count toward the organization license limit

• ❏ D. Priya will be removed from all Jira Cloud sites in every organization where she had access before deactivation

The support group at Meridian Labs needs to list all unresolved tickets that are past their due date as well as tickets with due dates falling from Monday through Saturday of the current week. Which JQL expression will return those issues?

• ❏ A. duedate < now( OR (duedate >= startOfWeek() AND duedate ⇐ endOfWeek(-1))) AND resolution is EMPTY

• ❏ B. (duedate < now() AND resolution = Unresolved) OR (duedate >= startOfWeek(24h) AND duedate ⇐ endOfWeek())

• ❏ C. (duedate < now() AND resolution = Unresolved) AND (duedate >= startOfWeek(24h) AND duedate ⇐ startOfWeek())

• ❏ D. (due < now() AND resolution = Unresolved) OR (due >= startOfWeek(24h) AND due ⇐ endOfWeek())

Which file formats does the IssueHub import wizard accept when bringing in external data? (Choose 3)

• ❏ A. HAR file

• ❏ B. JSON file

• ❏ C. Microsoft Excel XLSX

• ❏ D. Trello board export

• ❏ E. ZIP archive

• ❏ F. CSV file

A particular issue type is creating unassigned issues even though its components have component leads. What is the most likely cause?

• ❏ A. A workflow post function or automation clears the assignee

• ❏ B. Components field is hidden in that issue type’s field configuration

• ❏ C. A suspended user is set as the component default assignee

• ❏ D. The issue type uses a different create screen that excludes Components

The correct answer is Marta is not a member of the “Recruiters” project role in the “Staffing” project.

When you share a filter to a project role, Jira only lists project roles that you are a member of in the selected project. If you are not a member of a given role it will not appear in the sharing drop down. Marta can create the filter because she has the necessary project permissions, but she must also belong to the target project role to share the filter directly with that role.

Marta does not have the global Share filters and dashboards permission is incorrect because a complete lack of the global share permission would prevent initiating or completing the share at all. The scenario describes being able to create the filter and open sharing options, so the missing entry is more likely due to role membership.

Marta must first share the filter with all project roles in the Staffing project and then she will be able to pick the “Recruiters” role is incorrect because Jira does not require or support a cascading share step like that. The sharing dialog simply lists roles you belong to and you do not need to share with other roles first.

Jira Cloud does not support sharing filters with project roles is incorrect because Jira Cloud does support sharing filters with project roles. Project roles are a standard sharing target when you have the appropriate membership and permissions.

When a role is missing from the sharing drop down first check your project role membership in the target project and then check your global sharing permission if sharing is disabled.

Site favicon, Date and time display format, and Site logo are the correct options.

The global Look and feel configuration in Jira is intended to control visible branding elements so administrators can upload a custom Site logo and set a Site favicon to match the company identity. The settings also include display preferences such as the Date and time display format so that timestamps and dates appear consistently for users.

The Site logo appears in the product header and the Site favicon appears in browser tabs and bookmarks which makes them primary branding items. The Date and time display format affects how dates and times are shown across issues and activity feeds and helps keep the user experience consistent.

Application background color is incorrect because the standard Look and feel screen does not provide a global background color setting in Jira administration. Branding is handled through logo, favicon and related display options instead.

System default language is incorrect because language and locale are managed under general system or user settings rather than the Look and feel configuration.

Application title text is incorrect because changing the product title or metadata is not part of the Look and feel page in standard Jira administration and is handled elsewhere depending on the deployment.

When you see a question about Look and feel think about elements users see immediately such as the logo, the favicon, and how dates are displayed rather than internal system defaults.

The correct option is She must first convert any existing Sub-item issues into a standard issue type before she updates the issue type scheme.

This is correct because Jira does not allow you to remove a sub-task issue type from a project’s issue type scheme while issues of that sub-task type still exist in the project. You must convert or delete those sub-task issues so they become standard issues before the scheme can be updated. Converting the existing She must first convert any existing Sub-item issues into a standard issue type before she updates the issue type scheme entries removes the dependency that prevents removal of the sub-task type.

Jira will automatically map Enhancement and Sub-item issues to the project’s default standard issue type is incorrect because Jira will not silently remap issues when you remove an issue type. Automatic remapping does not occur and the system requires an explicit conversion or mapping action when relevant.

She will be required to choose a destination issue type for each Enhancement when removing it from the scheme is incorrect because Jira does not require selecting a destination for each individual issue. When removing a standard issue type that has existing issues you are prompted to map that issue type to another type at the scheme level, not to choose a destination for every single issue one by one.

She must reassign all existing Enhancement issues to another standard issue type before making changes to the scheme is incorrect because you do not have to manually reassign every Enhancement issue beforehand. When you remove a standard issue type from a scheme and there are existing issues, Jira prompts you to choose a replacement issue type for that issue type across the project so manual reassignment is not required.

If multiple sub task types existed she could remove one and Jira would prompt to move existing sub tasks to the other sub task type is incorrect because Jira will not prompt to migrate existing sub-tasks to another sub-task type. Sub-task types cannot be automatically remapped that way and you must convert or handle those sub-tasks before removing the sub-task type.

When a question mentions removing an issue type that still has issues, think about whether Jira requires conversion or mapping at the type level and not per issue. Remember that sub-task types often need conversion to standard issues before they can be removed.

The correct answers are: Administer Projects, Manage Sprints, Edit Issues and Schedule Issues.

The Administer Projects permission grants project administrators the ability to configure project settings and to create and edit project versions and components, and that is why it is required to manage versions and components.

The Manage Sprints permission specifically allows creating and managing sprints, so it is required to create a new sprint and to control sprint lifecycle actions in the project.

Both Edit Issues and Schedule Issues are needed for updating issue dates and related fields. The Edit Issues permission allows changing issue content and fields in general, and the Schedule Issues permission covers modifications to scheduling fields such as start dates and due dates in boards and planning views.

Manage Project Roles is incorrect because that permission only controls role membership and role assignment and it does not grant rights to manage versions components sprints or edit issue scheduling fields.

Manage Components is incorrect in this scenario because component management is covered by the project administration role provided by Administer Projects, so it is not separately required when that permission is granted.

When mapping tasks to permissions identify whether the action affects project configuration or individual issues and then pick the permission that matches the scope. Pay attention to project administration versus issue and sprint permissions.

filter = “ACP-125 Practice” AND resolution is NOT EMPTY, filter = “ACP-125 Practice” AND resolution is NOT NULL and filter = ‘ACP-125 Practice’ AND resolution = Done are correct.

Both filter = “ACP-125 Practice” AND resolution is NOT EMPTY and filter = “ACP-125 Practice” AND resolution is NOT NULL return issues where the resolution field has a value. These forms are equivalent for the purpose of finding resolved issues because they check that the resolution is set rather than empty.

The expression filter = ‘ACP-125 Practice’ AND resolution = Done is also correct when Done is a resolution value in your Jira instance. This query matches issues whose resolution field exactly equals the value Done and so it returns resolved issues that use that resolution.

filter = ‘ACP-125 Practice’ AND status = Done is incorrect. The status field reflects workflow state and not the resolution field. A status named Done does not always guarantee that the resolution field is set and therefore it is not a reliable way to find resolved issues.

When you need resolved issues focus on the resolution field rather than status. Use resolution is not empty to find any resolved issues or use resolution = value when you need a specific resolution.

The correct option is Issue security levels.

Issue security levels determine which users or groups can view a specific issue. If a user is not allowed to view an issue because of its security level they will not receive email notifications for events on that issue. Notification delivery requires both being listed as a recipient and having permission to see the issue so security levels can effectively prevent emails from being sent to some users.

Permission schemes define what actions users can perform and whether they can browse issues and while they affect who can do what they do not directly configure which events trigger emails or which recipients get notified. Sending notifications is governed by notification schemes and by visibility rules.

Screens control which fields are shown when creating editing or viewing issues and they do not affect who receives email notifications for issue events.

Agile boards determine how issues are displayed and managed within boards and sprints and they do not change notification behavior for issue events.

Dashboards are composed of gadgets and provide a presentation view for users and they do not control the delivery of notification emails.

When a question asks who receives emails focus on settings that change who can see the issue or who is on the recipient list. Settings that affect visibility often influence whether notifications are delivered.

Global permission to browse users and groups is correct because the user picker only returns accounts that the person performing the pick is allowed to view and that visibility is granted by this global permission.

The setting that controls whether a user can see and select other accounts is the Global permission to browse users and groups and site administrators grant it on the global permissions screen. Without that permission the picker will not return matches even when accounts exist in the directory.

Issue security scheme is incorrect because issue security controls who can view specific issues and it does not determine whether accounts appear in the user picker.

User directory settings is incorrect because directory settings manage where accounts come from and how they are synced and they do not by themselves grant the right to browse users across the site.

Project permissions is incorrect because project permissions control actions within a project and they do not enable or disable the global ability to browse users and groups for the user picker.

When the user picker returns no accounts first verify the account doing the pick has the Browse users and groups global permission and then check directory sync and membership if needed.

The correct option is project = “Bluewave” AND (fixVersion != ‘Release 2.0’ OR fixVersion is EMPTY).

The discrepancy is explained by how JQL treats the != operator. The project query returns 130 issues and 20 issues have fixVersion = ‘Release 2.0’. The query using fixVersion != ‘Release 2.0’ returned 40 issues because that test excludes issues where fixVersion is empty. The missing issues are those with no fixVersion set and they account for the difference.

By adding OR fixVersion is EMPTY you explicitly include the issues that have no fixVersion so the counts add up to the full 130.

Maya must reindex Jira to obtain the correct counts is incorrect because reindexing would not change the semantics of the != operator or whether empty values are returned. The numbers here match JQL behavior rather than an indexing fault.

Change the single quotes around the fixVersion value to double quotes is incorrect because JQL accepts either single or double quotes for string literals and the quotes do not affect whether empty values are excluded by !=.

Some issues are not visible because Maya does not have Browse Projects permission is incorrect because Maya can run project = “Bluewave” and see 130 issues in that result. A missing browse permission would reduce visibility across queries and would not produce the specific pattern caused by empty fixVersion values.

An issue security level has been applied that limits which issues Maya can see is incorrect because an issue security level would restrict visibility across queries in a way that would not explain why fixVersion != ‘Release 2.0’ returns 40 while fixVersion = ‘Release 2.0’ returns 20. The pattern here is explained by empty fixVersion fields rather than security settings.

When you see a JQL using != remember that it excludes empty values so include an is EMPTY clause when you need to count issues with no value set.

The correct answer is 2.

Marisol needs to create two separate screen schemes because there are two distinct per-issue-type differences in create and edit screens that must not affect other issue types. One screen scheme is required for the Task issue type so that the Create and Edit screens include the Affects Versions field for Task only. The second screen scheme is required for the existing Sub task issue type so that the Create screen keeps Summary while the Edit screen omits Summary to prevent post-creation edits. Mapping these two screen schemes to only the targeted issue types preserves the default configuration for the new Infrastructure Sub task and for all other issue types.

4 is incorrect because four screen schemes would be more than needed given only two distinct screen mapping differences are required.

0 is incorrect because at least one new screen scheme is required for Task and one is required for the Sub task so doing nothing would not meet the requirements.

1 is incorrect because a single screen scheme cannot implement two different sets of create and edit field configurations for two different issue types without impacting other types.

3 is incorrect because three screen schemes would be unnecessary since only two unique screen mappings are needed to satisfy the task for Task and for the existing Sub task.

When a question asks about screen schemes count how many distinct create or edit screen configurations must be applied only to specific issue types. Create one screen scheme for each unique mapping so you do not alter defaults for other types. Count the differences per issue type rather than per field.

The correct option is Post function.

Post function is a workflow element that runs automatically when a transition completes. It can update system fields such as the assignee without requiring a user to enter values, so it is the workflow configuration used to set the issue assignee automatically during a transition.

Transition screen is incorrect because a transition screen is shown to the user to collect or edit field values during the transition and it does not itself set the assignee automatically.

Automation rule is incorrect for this question because automation rules operate outside the core workflow transition configuration. Automation can change the assignee but it is not the workflow post transition mechanism the question asks about.

Focus on whether the change happens as part of the transition or outside it. The term post function indicates the change runs automatically during the workflow transition.

The original key “APP” will remain reserved and cannot be reused.

When you change a project key in Jira Cloud the system reserves the old key to avoid collisions and to preserve historical links and references. This means the old identifier is not available for assignment to another project and the behavior described by The original key “APP” will remain reserved and cannot be reused is correct even when the project has only a few issues.

All saved JQL filters that mention the old key “APP” must be updated to reference the new key “MOB” is incorrect. Jira Cloud updates many references such as saved filters, boards, and dashboards when a project key changes so manual updates are not required for every saved filter.

No background project reindex will be triggered because this instance is Jira Cloud is incorrect. Changing a project key affects issue keys and search indexes and Jira runs background processes to reindex affected data so reindexing can occur in Cloud.

The rename will only become visible after 48 hours have passed is incorrect. The new key appears promptly across the product or shortly after background processing rather than being delayed by two days.

After a project key change check important places such as boards, filters, dashboards, and automation rules because many references are updated automatically but it is good practice to verify everything behaved as expected.

A new comment will be added to the existing issue.

When the resent email is processed the mail handler recognizes that the message belongs to the original conversation by using threading cues such as the ticket identifier in the subject or email headers. Because of that detection a new comment will be added to the existing issue rather than creating a separate record.

A new issue will be created in the project is incorrect because the handler matches the incoming message to the existing thread and does not open a fresh issue when it can attach the content to the original one.

A new issue will be created and linked to the original issue is incorrect because the system does not create a second issue and then link it when the message clearly belongs to the initial conversation.

A new subtask will be added under the original issue is incorrect because incoming emails are treated as comments or new issues and are not converted into subtasks automatically.

The mail handler will ignore the forwarded message as a duplicate is incorrect because the message is still processed and recorded on the original issue as a comment rather than being silently dropped.

For email related questions look for clues about threading and identifiers in the subject or headers. Those clues usually tell you whether the system will append a comment or create a new issue.

The correct option is Send notifications to the chosen component lead.

Company managed projects provide the traditional components feature and the associated component lead field. This allows notifications and automation to be targeted to the component lead as part of project configuration and project level workflows. That capability relies on the components model that is only present in company managed projects.

Show subtasks grouped on the project board is incorrect because grouping and board card layout are board configuration options. Boards in both project types can be configured to show subtasks or parent relationships and this is not exclusive to company managed projects.

Add the issue navigator to the project sidebar is incorrect because the issue navigator is a global Jira interface and links or shortcuts to it can be added without requiring the company managed components model.

Turn on a backlog for a Kanban board is incorrect because backlog support for Kanban boards is a board feature and can be enabled in board settings for the appropriate project types. It is not a capability that only company managed projects can provide.

Change the color assigned to an epic is incorrect because epic coloring and card appearance are board and issue presentation settings. Those visual settings are managed at the board or project level and are not restricted to company managed projects.

When a question mentions component leads or component based notification routing pick the company managed option. Look for features tied to the classic components and global administration when deciding between project types.

The correct option is Atlassian Access.

Atlassian Access is an organization level product that adds SAML single sign on, SCIM user provisioning, and security controls across Atlassian Cloud. It is not itself a site-level method for granting a person membership to a specific Jira site because invitations, domain allowlisting, or direct invites are the mechanisms that actually add users to a site.

Allow any domain signups is a supported approach because a site can be configured to allow signups from any email domain when you want open access or when you manage access with other controls.

Invitation links are supported since administrators can create invitation links for users to join a site and these links are a direct way to grant site access.

Approve multiple domains is supported because you can verify and approve multiple corporate email domains so users from those domains can be granted access or sign up.

User invites are supported because administrators can invite individual users directly to the Jira site and those invites grant membership.

Read each option carefully and ask whether the item directly grants membership to a site or whether it is a management or security layer that sits above site membership.

Issue Security Levels and Issue Links cannot be translated using the built in translation feature in the Jira interface.

Issue Links are defined as system level link types that are part of Jira configuration and they are not surfaced as localizable UI strings in the translation interface. The translation tools in Jira focus on user facing labels rather than internal relationship types so link types remain untranslatable there.

Issue Security Levels are also configuration entities that control access and are stored as part of project security schemes. They are not exposed to the built in translation workflow as translatable labels in the interface so you cannot translate them with that feature.

Statuses are incorrect because status names are user facing workflow labels and they are included in Jira translation capabilities so they can be localized via the translation interface or language packs.

Custom Field Names are incorrect because custom field labels are part of the UI text that the translation feature is intended to handle and they can be translated through the interface or by using language overrides.

When deciding which items are translatable think about whether the item is a user facing UI label or a system configuration entity. Items that act as UI labels are usually translatable while system level types and security configuration are often not.

All exam questions come from my Jira ACP-120 Udemy course and certificationexam.pro

The correct option is Private access.

This option restricts the project so that only administrators and the people explicitly added to the project can search for view create or edit its issues. Choosing this setting keeps the project out of site searches and the project directory so only the selected members and admins can interact with it.

Limited access is incorrect because it implies a narrower restriction than open settings but it can still allow broader visibility to other site members or to specific groups depending on configuration. It does not guarantee that only admins and explicitly added people can search for and edit issues.

Site visible is incorrect because that setting makes the project visible to everyone on the site so all site users can search for and view the project and its issues.

Open access is incorrect because it grants broad access and removes restrictions so users beyond the administrators and explicitly added members can find and interact with the project.

When an exam question asks who can see or search for issues look for options that include the word Private or describe explicit member lists. Eliminate choices that mention site or open visibility.

The correct answer is All members of the executive-board group.

The subscription was sent to the specified group so every member of that group will receive the scheduled emails. The JQL selects issues whose assignee is a member of that group and the group members will be delivered the results they have permission to view.

All users assigned the board project role and members of the executive-board group is incorrect because the subscription was addressed only to the group. Membership in the project role was not included as a recipient so project role users do not automatically get the emails unless they are also in the group.

All users assigned the board project role is incorrect because the recipient list did not include the project role. Being assigned a project role does not make someone a recipient unless that role was explicitly selected.

Only Maya is incorrect because creating the subscription does not restrict delivery to the creator. Maya would receive messages only if she is a member of the recipient group or was otherwise added to the recipient list.

When a subscription lists a group as the recipient the emails go to all members of that group. Check that recipients have view permission for the issues in the filter to ensure they receive useful results.

The correct options are The connections between TASK-210 and APP-210 and UI-210 were removed and Issue linking was turned off at the site level.

If The connections between TASK-210 and APP-210 and UI-210 were removed then the link relationships would no longer be shown on TASK-210 even though the target issues still exist and can be opened from their projects. Links can be deleted by another user or by an automation and that removal explains why the links disappeared from the issue view.

If Issue linking was turned off at the site level then the system will not display link relationships in the issue UI across projects even though the issues themselves remain. This is a global setting that hides or disables the link feature for all issues.

“Link Issues” project permission was revoked for Maya in the TASK APP and UI projects is unlikely because revoking that permission prevents creating or modifying links but it does not remove existing link relationships or hide them from view.

Maya has been excluded from a global permission is unlikely because global permission exclusions typically affect administrative or global actions and do not cause existing issue links to vanish from the issue UI.

Maya is no longer a project administrator for TASK APP and UI projects is incorrect because losing project admin status changes administrative abilities and roles but it does not delete or hide links between issues.

“Edit Issues” project permission was revoked for Maya in the TASK APP and UI projects is not the best explanation because losing edit permissions would prevent changing fields or adding comments but it would not by itself remove or hide existing links from the issue view.

When links disappear think first about whether the relationships were deleted or whether the linking feature is disabled globally. Check visibility and then check permissions only if actions are blocked rather than items being missing.

Marina Evan and Sara will be notified and The updated date of QA-31 and QA-58 is changed are correct.

The project is configured to send notifications to the Assignee and the Reporter when an issue is changed, so the bulk edit triggers those notifications and Marina Evan and Sara will be notified because they are the Assignee and Reporter for the issues that were changed.

Only issues whose fields are actually modified get their updated timestamp changed, so the bulk edit altered the Component on two issues and therefore The updated date of QA-31 and QA-58 is changed is correct while the third issue was not modified.

The Resolution of QA-31 is updated is incorrect because changing the Component does not change the Resolution field unless the Resolution was explicitly edited.

The updated date of QA-31 QA-58 and QA-62 is changed is incorrect because not all three issues were modified by the bulk edit and only the actually changed issues have their updated date changed.

Marina is assigned to all three issues is incorrect because the bulk operation only changed the Component field and did not assign Marina as the Assignee for every issue.

Marina Evan Sara and Liam will be notified is incorrect because notifications go to the Assignee and Reporter of the changed issues and Liam is not an affected Assignee or Reporter.

When you evaluate bulk edit scenarios remember that only issues with a real field change update their Updated timestamp and notifications go to the issue’s Assignee and Reporter.

The correct answer is Hide “Time tracking” in each Field Configuration.

Time tracking is a system field in Jira Cloud and when company managed projects share the same configuration you should hide the field at the configuration level so it stops appearing across all those projects. Hiding the field in the Field Configuration prevents the Time tracking field from being shown in create edit or view screens for any project using that configuration while leaving the underlying system behavior intact.

Disable “Time tracking” as a global feature is not correct because Jira does not provide a supported global toggle that removes the Time tracking field from only a subset of company managed projects that share configuration. Disabling a global feature would affect all projects and it is not the proper way to hide the field for projects that share a Field Configuration.

Remove “Time tracking” from all screens is not correct because removing the field from screens only affects those screens and may not cover all create edit or view contexts. Screens can be shared across many projects and you would have to remove the field from every relevant screen to achieve the same effect. The supported and central way to hide the field across company managed projects that share configuration is to hide it in the Field Configuration.

When asked how to remove a system field across multiple company managed projects check the Field Configuration first because hiding a field there applies to every project that uses the configuration.

Company-managed Kanban board project is the correct choice for this scenario.

This option combines centralized configuration and governance with a Kanban workflow that supports continuous flow of work and rapid handling of issues.

Company-managed projects provide shared schemes, permissions, and reporting which help when overseeing several concurrent initiatives. The Kanban approach avoids fixed length sprints and lets teams pull work as capacity allows which is well suited to a steady stream of ongoing bug fixes.

Team-managed Scrum board project is incorrect because team-managed projects are designed for single autonomous teams and they lack the centralized controls needed to coordinate multiple initiatives. Scrum boards are sprint based which does not align well with a continuous stream of bug fixes.

Company-managed Scrum board project is incorrect because although company-managed gives the required governance the Scrum workflow uses fixed sprints and is less appropriate for ongoing ad hoc bug work that benefits from continuous flow.

Team-managed Kanban board project is incorrect because while Kanban supports continuous flow the team-managed model does not provide the cross project control and shared configuration needed to oversee several concurrent initiatives.

When you choose a project type look for clues about centralized governance or a single team and whether the work is sprint based or continuous. Choose company managed when multiple initiatives need oversight and choose Kanban when work is ongoing rather than organized in sprints.

Request the Transition Issues project permission, Use the bulk change feature and select the Transition Issues operation to set the new status, Ensure there are no Validators that block the transition, and Confirm there are no workflow status properties restricting changes to that status are correct.

Use the bulk change feature and select the Transition Issues operation to set the new status is correct because the bulk change workflow provides a specific Transition Issues operation that performs status transitions on many issues at once. This is the supported way to move multiple issues into a new workflow status in one action.

Request the Transition Issues project permission is correct because a user must have the Transition Issues permission in the project to perform either single or bulk transitions. Without that permission the transition operation will be blocked even if the bulk change is initiated.

Ensure there are no Validators that block the transition is correct because workflow validators can prevent a transition from completing if required conditions are not met. You must verify that no validators on the transition are rejecting the move to the new status.

Confirm there are no workflow status properties restricting changes to that status is correct because workflow status properties can restrict which transitions or users can move issues into a particular status. Those properties need to be checked and removed or adjusted if they prevent the bulk transition.

Use the bulk change Move Issues operation to alter the status is wrong because the Move Issues operation is intended to change an issue’s project or issue type and it does not itself transition issues into a workflow status.

Request the Edit Issues project permission is wrong because Edit Issues allows modifying issue fields but it does not grant the ability to perform workflow transitions. The specific Transition Issues permission is required for that action.

Always check the Transition Issues permission first and then verify that no validators or workflow status properties will block the bulk transition before you run a bulk change.

Jira Software product access is the correct option because reordering issues in a Scrum backlog is a feature of the Jira Software product access entitlement and requires the user to have access to Jira Software in the site product settings.

The Scrum backlog ranking feature is provided by Jira Software product access so even when a user has extensive project permissions such as creating, editing, assigning and setting due dates they still need the product license to interact with the backlog and perform drag and drop ranking.

Board administrator role is incorrect because being a board administrator controls board configuration and permissions for that board but it does not grant the Jira Software product entitlement that enables backlog ranking.

Schedule issues project permission is incorrect because that permission only allows editing scheduling fields such as due dates and does not control the ability to reorder or rank issues on a board.

Jira Administrator product access is incorrect because having Jira administration rights or an admin product label is not the same as granting the Jira Software product access license that is required for using boards and backlog ranking.

When a user can edit issues but cannot reorder the backlog check their product access in the Atlassian admin console before changing project permissions.

A board column was renamed inside the team-managed project is correct.

Team-managed projects create project local statuses that are tied to the board columns and renaming a column will rename the underlying status for that project. The filter uses status = Done so if the team-managed project changed its column name away from Done the Task issues in that project no longer match the status clause even though their resolution may still be Done.

A status was renamed via the Statuses administration page is unlikely because statuses changed in the global Statuses administration apply to company managed projects and global statuses do not rename the project local statuses used by team-managed projects.

The project key was changed in the team-managed project is not the best explanation because changing a project key would remove issues from a Project IN clause until the new key was used, and it would not selectively remove only Task issue types while leaving other types visible in the same project.

A resolution was renamed via the Resolutions administration page is unlikely because resolutions are global and renaming a resolution would not normally affect whether a status equals Done. The reported symptom points to a status name change rather than a resolution change.

When a question mixes team-managed and company-managed projects remember that columns in team-managed projects map to project local statuses and renaming a column can change the status name used by JQL.

The correct answers are summary ~ “Skillwise”, summary ~ “\[Skillwise\]”, and summary ~ “[Skillwise]”.

summary ~ “Skillwise” is correct because the tilde operator performs a text search and finds issues whose summary contains the token or phrase Skillwise rather than requiring an exact full field match.

summary ~ “\[Skillwise\]” is correct because the backslashes escape the square brackets so the search looks for the literal characters and the word inside them. Quoting the pattern keeps the brackets part of the searched phrase.

summary ~ “[Skillwise]” is also correct because when the phrase is quoted the brackets are treated as literal characters by the query parser and the search will match summaries containing the bracketed token or the token itself depending on how the text is indexed.

summary is “Skillwise” is wrong because the is operator requires the summary field to equal Skillwise exactly and it will not match summaries that only contain the token or that include additional text.

Remember that the ~ operator does text contains searches and the is operator requires an exact match of the whole field. Use quoting and escaping when you need to include special characters in the search.

All exam questions come from my Jira ACP-120 Udemy course and certificationexam.pro

The correct option is Add all company domain names as approved domains.

Add all company domain names as approved domains lets the organization recognize and control accounts that use those email domains so access can be scoped to company addresses and granted consistently. This approach reduces administrative overhead because users who sign in with an approved company email are covered by the organization settings rather than requiring manual invites for each person.

Add all company domain names as approved domains also supports multiple domains such as example.com and hr.example.com so you can enforce company-only accounts across the different domains your company uses. It is the simplest way to ensure all employees receive product access at once while keeping access limited to corporate accounts.

Enable user invites so employees can invite colleagues is not ideal because it relies on individuals to invite others and it does not centrally enforce that only company accounts receive access. That approach is harder to scale for a large hiring drive and gives less administrative control.

Enable Atlassian Access and configure automatic provisioning is not the best choice for this question because Atlassian Access is an enterprise feature for SSO and SCIM based provisioning and it is more complex to set up. It is useful for automated provisioning from an identity provider but it is not the minimal configuration needed to quickly grant company-wide access based on email domains.

Set the site to Public and use IP allowlisting is incorrect because making the site public would not restrict access to company accounts and IP allowlisting is about network restrictions rather than enforcing email domain membership. That combination would not meet the requirement to limit access to company accounts in a simple way.

Verify all company domain names is not sufficient on its own because verification only proves ownership of domains. Verification is often a prerequisite for other settings but it does not by itself grant or enforce product access for all users on those domains.

When a question asks about granting access across the whole company and minimizing admin work think about organization settings such as approved domains first. These settings often solve domain based access controls more directly than individual invites or more complex enterprise products.

Do not follow your team’s recommendation and create a Cloud backup of the Jira site https://acme-systems.example.com then provision a new Jira Cloud site with Jira Software and restore the Cloud backup to that new site. This Cloud-to-Cloud restore is the correct approach because a Cloud backup preserves the Cloud site configuration and is designed to be restored into another Cloud site so you can replicate the exact site state for staging.

The Cloud backup contains both company managed and team managed project configurations and can be restored into a newly provisioned Jira Cloud site so the staging environment will match the original Cloud instance. Restoring a Cloud backup into a new Cloud site keeps Cloud-specific settings and features intact and is the supported path for making a full staging copy of a Cloud site.

Follow your team’s recommendation and take a Cloud backup of the Jira site https://acme-systems.example.com and attempt to restore that backup to your on premises server after installing Jira 9 is incorrect because Cloud backup files are not compatible with Jira Server installations. The Cloud export format and Cloud-specific configuration cannot be directly restored into an on premises Server instance such as Jira 9.

Do not follow your team’s recommendation and produce a Server backup of the Jira site https://acme-systems.example.com then create a new Jira Cloud site with Jira Software and try to restore the Server backup into the new Cloud site is incorrect because Jira Server backup files use a different format and contain Server specific data that cannot be restored into Jira Cloud. Cloud imports do not accept Server backups as a restore source.

Follow your team’s recommendation and create a Server backup of the Jira site https://acme-systems.example.com then restore that backup to your on premises server after installing Jira 9 is incorrect because you cannot generate a Server backup from a Jira Cloud site. Cloud does not provide a Server-compatible site backup, so you cannot create a Server backup on the Cloud site for restoring into an on premises Server instance.

Cloud-to-Cloud restores preserve Cloud configuration and are the supported way to make a full staging copy of a Jira Cloud site. If you need an on premises environment you must plan a supported migration path and verify which data will transfer.

Administrators can turn off the Sub-Task feature when no sub-tasks exist in the instance, Sub-tasks can be converted into standard issue types and standard issues can be converted into sub-tasks and Sub-task names and descriptions can be localized for the installed languages are correct.

The statement about administrators turning the feature off is correct because the Sub-Task feature is managed in site administration and it can only be disabled when there are no existing sub-task issues to prevent data loss and inconsistency.

The statement about conversion is correct because Jira provides issue type conversion tools that let you convert sub-tasks to standard issue types and convert standard issues into sub-tasks, subject to available issue types and field and workflow mappings during the conversion process.

The statement about localization is correct because Jira Cloud supports multiple installed languages and you can provide localized names and descriptions for issue types, which includes sub-task issue types so they appear in the selected language for users.

Sub-tasks can hold additional sub-tasks beneath them is incorrect because Jira only supports a single sub-task level and does not allow nested sub-tasks under sub-tasks.

Sub-tasks cannot be moved to different projects is incorrect because sub-tasks can be moved between projects, although you must ensure the target project has an appropriate sub-task issue type and you may need to remap fields and settings.

Sub-tasks automatically count in board sprint capacity the same as their parent issues is incorrect because sprint and board capacity calculations treat parent issues and sub-tasks according to how estimates are configured and recorded, and sub-tasks do not automatically inherit the parent issue estimate for sprint capacity.

Read each option carefully and watch for Jira specifics such as no nested sub-tasks and admin actions that require no existing items. Think about what the Jira UI and admin screens actually allow before choosing answers.

The correct answers are issuetype in subTaskIssueTypes() AND labels is EMPTY and type in subTaskIssueTypes() AND labels is EMPTY.

Both issuetype in subTaskIssueTypes() AND labels is EMPTY and type in subTaskIssueTypes() AND labels is EMPTY return subtask issues and filter for those that have no labels. The function subTaskIssueTypes() matches the issue types that are used for subtasks and the labels is EMPTY condition is the proper JQL way to find issues without any labels.

issuetype in standardIssueTypes() AND labels is EMPTY is incorrect because standardIssueTypes() returns non‑subtask issue types and will not select subtasks. This does not meet the requirement to retrieve only subtasks.

issuetype in subTaskIssueTypes() AND labels = “” is incorrect because JQL does not use an empty string with the equals operator to find missing values. The correct syntax to find no labels is to use is EMPTY.

labels in (NULL) is incorrect because JQL does not support querying labels with NULL in that way. The labels field should be tested with is EMPTY to find issues that have no labels.

issuetype in subTaskIssueTypes() AND labels = NULL is incorrect because labels = NULL is not valid JQL syntax. Use labels is EMPTY to check for the absence of labels.

When you need to find fields with no value use is EMPTY. Remember that type is a shorthand for issuetype in JQL so either form can be used.

The correct answer is Change group memberships.

Adding a user to the appropriate groups grants them the collection of project and global permissions needed to perform bulk edits, delete issues, create and share filters and dashboards, and make fields required in a company managed project.

Permission schemes and global permissions typically reference groups when deciding who can perform actions like Bulk Change or share filters and dashboards. Updating group membership is the practical way to give a user all of those rights without changing the underlying schemes and configurations.

Modify project role assignments is incorrect because project roles are scoped per project and they may not be the object that permission schemes or global features reference. Changing a role assignment may not grant the global or scheme level permissions required to share filters or administer field configurations.

Update field configuration scheme is incorrect because modifying a field configuration changes how fields behave and whether they are required. That change does not by itself grant a user the permissions to perform bulk edits, delete issues, or create and share filters and dashboards.

When a question lists several actions that span project and global features, check who the system grants permissions to. Look at group membership and permission schemes first because adding a user to the right groups often grants multiple capabilities at once.

All exam questions come from my Jira ACP-120 Udemy course and certificationexam.pro

Mark is missing the global permission “Browse users and groups” is correct.

Mark is missing the global permission “Browse users and groups” explains the behaviour because mention notifications require the system to resolve the commenter as a valid user in the user directory. If a commenter cannot browse users and groups the mention may not be resolved and it will not generate the mention notification for the target user. Oscar can mention and trigger notifications because he has the necessary global permission while Mark cannot.

The notification scheme was modified so the “Issue Commented” event does not include mentioned users is not correct because if the notification scheme removed mentioned users from the Issue Commented event then Lucy would not receive mention alerts from anyone. She does receive alerts when Oscar mentions her so the notification scheme is not the cause.

Lucy has disabled the personal setting “Someone mentions you” is not correct because that setting would stop all mention notifications to Lucy. She still gets notifications from Oscar so her personal mention setting must be enabled.

Mark lacks the project permission “Add Comments” is not correct because Mark is clearly making comments. If he did not have Add Comments he would not be able to post the comment at all.

A security level on the issue prevents Lucy from seeing the issues where she is mentioned is not correct because if Lucy could not see the issues she would not receive mention alerts from Oscar either. Since she receives alerts from Oscar she can view the issues and the problem is specific to Mark resolving mentions.

When only one commenter fails to trigger mention notifications check that the commenter can resolve users. Verify global permissions such as Browse users and groups before changing notification schemes or user settings.

The correct answer is: Use a trigger When value changes for “Due Date” and add a condition If parent exists then branch For parent and check that the parent “Due date” is before the “Due Date” from the trigger issue and then edit the parent “Due Date”.

The When value changes for “Due Date” trigger is appropriate because it fires only when the due date field actually changes and it avoids running on unrelated updates. The rule then checks that a parent exists so that the logic only applies to sub tasks that have a parent issue.

The branch For parent step switches the rule context to the parent issue so the rule can compare the parent’s due date with the sub task due date and then perform an edit on the parent. The comparison should verify that the parent due date is before the sub task due date and only then update the parent to match the later date.

Configure a trigger When issue updated and add a condition If parent exists then branch For parent and verify that the parent “Due date” is after the “Due Date” from the trigger issue and then edit the parent “Due Date” is incorrect because the generic When issue updated trigger fires for any update and is less precise. It also checks whether the parent is after the sub task which is the reverse of the required logic and would not trigger the needed parent update.

Create a trigger When value changes for “Due Date” add a condition If parent exists and then verify that the current issue “Due date” is after the parent “Due Date” before editing the “Due Date” is incorrect because it does not branch to the parent issue before editing. That means the edit would apply to the current sub task and not the parent, so it will not accomplish updating the parent due date.

Set a trigger When value changes for “Due Date” and add a condition If parent exists then branch For sub tasks and check that the sub task “Due date” is after the “Due Date” from the trigger issue and then edit the sub task “Due Date” is incorrect because it branches to sub tasks and edits the sub task rather than the parent. The rule must branch to the parent and edit the parent issue to propagate the later due date.

When you need to compare and update parent and sub task fields look for a trigger that targets the specific field and a branch that changes context to the parent. Use the When value changes trigger and a Branch rule / related issues to the parent when you intend to edit the parent issue.

Site administrators are able to create and modify user groups in an organization managed project at Riverton Systems.

Site administrators manage global user and group settings across the site and they can create, edit, and delete groups as well as assign product access and permissions that apply to organization managed projects.

Project administrators are incorrect because they manage settings and configurations within a specific project and they do not have the global permissions required to create or modify site level user groups.

Jira administrators is incorrect because Jira admin roles focus on product configuration and schemes within Jira and do not inherently grant the site wide ability to manage user groups unless those admins also have site administrator rights.

Organization administrators is incorrect because organization admins manage organizational settings and user access at the organization level but they do not automatically have the site level capability to create and maintain groups for the site unless they also hold site administrator privileges.

Remember that creating and editing global groups is a site level capability. When answering, identify whether the task is scoped to a project or to the whole site and choose the admin role that matches the scope.

Saved filters and JQL queries will return different results in company-managed projects is correct.

Renaming the resolution changes the visible name that queries and saved filters may match against. Company-managed projects use the shared resolution configuration and text based JQL that referenced Done will no longer match the same issues if the name is changed to Finished until the saved filters or queries are updated to use the new name or to use an identifier that is not name dependent.

Dashboards will show errors in team-managed projects is incorrect because dashboards do not typically error just from a resolution name change. The dashboard gadgets will continue to render but the underlying saved filters may return different result sets if those filters rely on the old name.

Some automation rules in the company-managed project will stop working is incorrect as stated for the exam. Automation rules that explicitly check for a resolution name may need updating, but many automations use internal identifiers or conditions that are not broken by a simple display name change. The primary, immediate impact called out in the question is on saved filters and JQL.

Reports will error only in company-managed projects is incorrect because reports will not generally produce errors from a resolution rename. Reports may show different data if they rely on filters that used the old resolution name, but they will not fail outright just because the resolution label changed.

When a question involves renaming fields or values think about whether the system uses the visible name in queries or an internal id and whether the configuration is shared across projects or is project specific.

The correct options are Send monthly resolved issues to the group “ops managers” and Send a weekly list of issues she resolved to herself.

Send monthly resolved issues to the group “ops managers” is valid because Jira users can subscribe a saved filter to deliver search results to a group on a recurring schedule such as monthly. If the user creates and owns the filter and they have the necessary permissions to target that group they can configure the subscription themselves without you accessing their site.

Send a weekly list of issues she resolved to herself is valid because an individual can subscribe to a filter that returns issues they resolved and set a weekly delivery to their own email. This requires only the user to create and manage the subscription on their site.

Send unresolved Highest priority issues each morning to the project role Engineers is not correct because standard filter subscriptions accept users or groups as recipients and do not target project roles as recipients in the same way. Project role notification typically requires different configuration or administrative access.

On the final Friday each month email released fix versions to the group “administrators” is not correct because built in filter subscriptions do not support complex schedules such as the final weekday of the month tied to release events. Sending release based notifications to a group usually requires automation or release hooks that need site access to configure.

When you cannot access a Jira site focus on what standard filter subscriptions support and whether the target is a group or the filter owner. If the recipient or schedule is outside that scope then the user will need site level automation or admin help.

The ‘Project Cost’ field is set to hide when empty is correct.

When a custom field is configured to hide when empty it does not appear on the issue view unless it contains a value. This explains why Rita sees the field on some issues that already have a value and does not see it on other issues where the field is blank. The field can still be present on edit screens so it can be filled in and then it will appear on the issue once a value is saved.

The field has a context that limits it to particular issue types or screens is incorrect because a field context usually prevents the field from being available to certain projects or issue types at all. If context were the cause the field would be missing for all issues of the excluded type or project rather than only for empty instances within the same project.

Issue security levels are preventing the field from being visible on some issues is incorrect because issue security controls access to entire issues or to viewing issue details per user role. It does not hide individual fields on an otherwise visible issue based on whether the field has a value.

The user does not have Browse Projects permission on those particular issues is incorrect because lacking Browse Projects permission would prevent the user from seeing the issues themselves. The user would not be able to open the issues at all rather than seeing the issues with some fields missing.

When a field is missing check the field’s visibility settings and whether it is configured to hide when empty before changing contexts or permissions.

Create a fresh invitation link and replace the expired link on the company intranet is correct.

Invitation links for Atlassian cloud sites can expire or be invalidated so generating a new invitation link and replacing the broken link on the intranet restores a single, working entry point for staff and stops the support requests.

Resend individual email invitations to the affected staff from the user management console is not the best choice because sending individual emails is slower and it does not address the broken public link on the intranet that many employees are using.

Create a new invitation link and place it next to the previous link on the intranet is not correct because leaving the expired link in place will continue to cause confusion and failed attempts. It is better to replace the invalid link so staff always see the active invitation.

Open an Atlassian support case and provide the invitation link and site address is unnecessary for this situation because expired invitation links are expected behavior and administrators can create new links themselves from the user management console without contacting support.

When links posted publicly stop working, think about expiration and admin settings first. Generating and replacing the broken link is usually faster than emailing individuals or opening a support case.

Delete the component “TaskService Red” and reassign its issues to “TaskService Blue” is the correct option.

When you Delete the component “TaskService Red” and reassign its issues to “TaskService Blue” the project administration workflow provides a reassignment step that moves all issues from the deleted component to the chosen component in one operation. This prevents issues from remaining linked to a component that no longer exists and avoids the need to edit each issue individually.

Using the delete and reassign workflow keeps the component list clean and preserves issue history and links. It is the simplest and safest way to consolidate component ownership when both components already have assigned issues.

Use a bulk edit to update issues from “TaskService Red” to “TaskService Blue” and then delete the “TaskService Red” component is not the best approach because it forces you to search for and update every issue manually and it increases the chance of missing issues or making inconsistent updates. The built in delete and reassign action handles this in one step.

Merge the component “TaskService Red” into “TaskService Blue” is not correct because Jira does not offer a native component merge feature. You must reassign or delete components rather than perform a single merge operation.

Rename the component “TaskService Red” to “TaskService Blue” is not correct because renaming to an existing component name will cause a conflict and may be blocked by the system. Renaming does not provide the explicit reassignment handling that deleting with reassignment does.

When removing a component use the reassign option to move all issues in one step and always verify the issue count before you confirm.

The correct answers are Users who are suspended cannot sign in to your organization or access its products and Removed users no longer occupy a ProjectBoard Cloud seat.

Users who are suspended cannot sign in to your organization or access its products is correct because suspending an account blocks authentication and product access while keeping the account record available for administrators to review or reinstate.

Removed users no longer occupy a ProjectBoard Cloud seat is correct because removing a user detaches them from your organization which releases the billable seat and stops charging your project for that user.

Deleting a user permanently removes their global account is incorrect because deleting a user from your organization does not always erase the underlying global identity and some systems require separate steps to remove a global account.

Suspended users continue to occupy a ProjectBoard Cloud license is incorrect because suspension prevents sign in and access and does not automatically mean the user will continue to consume a billable seat in the same way an active assignment does.

A disabled managed account cannot be reinstated is incorrect because disabled managed accounts can generally be restored by an administrator according to the product’s restoration policies.

A disabled managed account can only be restored within 30 days is incorrect because the arbitrary 30 day restoration window is not a universal rule and actual restoration windows vary by product and settings.

When evaluating account state and billing questions focus on whether the action detaches the account from the organization which affects seat billing and whether the account is merely suspended or fully removed.

1 Condition 1 Validator 2 Post Functions 1 Status Property is correct.

1 Condition 1 Validator 2 Post Functions 1 Status Property maps to the needed workflow elements. The single Condition limits who can see or execute the transition so it can be shown only to the appsec group. The single Validator enforces that required fields are present before the transition completes. The two Post Functions handle separate actions after the transition so one can set the resolution and the other can send the email notification. The single Status Property is used to restrict attachment permissions when the issue is in that status.

1 Condition 2 Validators 1 Post Function 1 Status Property is incorrect because it specifies two Validators while only one is needed to enforce required fields and it lists only one Post Function while two are necessary to both set the resolution and send the email after the transition.

2 Conditions 1 Validator 1 Post Function 1 Status Property is incorrect because it includes two Conditions even though a single Condition can restrict the transition to the appsec group and it again lists only one Post Function while two are needed to perform both the resolution update and the notification.

When you see multiple required behaviors map each behavior to a workflow element. Conditions control visibility, Validators enforce input, Post Functions perform changes or notifications after a transition, and Status Properties adjust permissions.

The correct options are Administer sprints, Modify issues, View the project and Schedule issues into sprints.

Administer sprints is required because closing an active sprint and performing sprint level operations on the board requires the permission to manage or administer sprints for the project or board. Without this permission a project administrator cannot complete the sprint workflow even if they can edit issues.

Modify issues lets Riya update issue fields, set resolutions, or change statuses as needed to clear or prepare the remaining work before the sprint finishes. Being able to edit the issues that remain is a core requirement for finishing the sprint cleanly.

View the project is needed so Riya can access the project, open the sprint board, and see the issues that need action. You cannot administer sprints or modify issues in a project you cannot view.

Schedule issues into sprints allows Riya to move unresolved work into the backlog or into a future sprint when closing the current sprint. Scheduling is a distinct permission that controls placing issues into sprint containers and is necessary for resolving the three remaining issues without moving them across projects.

Transition issue workflow is incorrect because altering workflow configuration or the scheme is not required to close a sprint or to move issues into different sprint states. Closing a sprint usually requires scheduling and edit permissions rather than changing the workflow itself.

Allow moving issues between projects is incorrect because moving issues across projects is not a minimum requirement for finishing a sprint inside the same project. That permission grants a higher level capability that is not needed to resolve or reschedule the remaining issues for sprint closure.

When you read permission names focus on the specific task you must perform. For sprint closure look for permissions that let you manage sprints, edit or schedule issues, and view the project.

Company-managed project is the best fit for these requirements.

Company-managed projects support shared configuration at the application level so a single workflow can be created once and reused across several projects. This makes it straightforward to give every developer uniform permissions across projects because permission schemes and roles can be managed centrally.

Company-managed projects also allow boards to be created with filters that span multiple projects so teams can maintain multiple boards that cover different project combinations. The model supports distinct permission schemes and schemes for different departments while still providing global administration and consistency.

Team-managed project is not suitable because team-managed projects are designed for per project autonomy and local configuration. They do not provide the same ability to share workflows, permission schemes, or other schemes across many projects so they will not meet the requirement for uniform permissions and reusable cross project workflows.

Look for keywords like shared workflows, uniform permissions across projects, or multiple boards spanning projects and choose company managed projects since they provide global schemes and cross project configuration.

The correct answer is Status.

The Status field reflects the issue workflow state and the available transitions for that issue. Because it is tied to the workflow and to how issues progress it must remain visible in the Context fields area and cannot be removed from that section.

Other common fields can be rearranged or hidden in the issue layout per issue type. For example you can move or remove Reporter, Issue Type, Summary and Description from the Context fields area when configuring the view for a project.

Reporter is incorrect because reporter is a configurable field and you can choose whether it appears in Context fields or Details fields depending on your layout choices.

Issue Type is incorrect because the issue type display can be adjusted and it is not locked into the Context fields area in the same way that status is.

Summary is incorrect because although it is an important identifier for the issue you can control where it appears in the layout and it is not the immutable field that enforces workflow state.

Description is incorrect because the description is a standard editable field that can be moved or hidden in the issue view configuration.

When a question asks which field cannot be removed think about fields that represent workflow state and system behavior such as Status rather than descriptive or metadata fields.

One notification is correct.

Elena occupies all four recipient roles for the Issue Updated event as Reporter, Current Assignee, Project Lead, and Project Administrator. Notification systems such as Jira deduplicate recipients so a single user will receive only one email per event even when they match multiple roles. Because of that deduplication Elena will receive only one email for the update.

Two notifications is wrong because matching two roles does not cause two separate emails to be sent to the same user for a single event.

Three notifications is wrong because having three matching roles still results in a single deduplicated email rather than multiple messages.

Four notifications is wrong because even though Elena fills four recipient roles she will not receive four separate emails for the same Issue Updated event.

When an exam question lists multiple notification roles for the same user remember that the system normally sends a single email per event to that user rather than one email per role.

The correct options are Edit Issues, Schedule Issues, and Browse Projects.

A user needs Browse Projects to view the project and the board where the sprint and issues live. The user also needs Edit Issues so they can transition issues, update statuses, and change fields as they resolve remaining work. Finally the user needs Schedule Issues to move issues between sprints or to the backlog and to update dates as part of handling the remaining items when the sprint is completed.

Manage Sprints is not required for the minimal task described because that permission grants higher level board and sprint management capabilities. It is typically used to create, start, or fully manage sprints and is not necessary if the user only needs to view the project and update or reschedule the remaining issues.

When a question asks for the minimum permissions focus on the actions the user must perform and choose permissions that allow those actions without selecting broader administrative rights.

All exam questions come from my Jira ACP-120 Udemy course and certificationexam.pro

The correct option is Mail retriever.

The Mail retriever is the component that connects to the linked inbox and polls for unread messages. It performs the periodic retrieval that copies messages into the mail database so that subsequent stages can apply filters for auto replies and spam and the cleanup job can enforce retention.

The Email processor is not correct because that term refers to processing logic that runs after messages are already in the system rather than the component that polls an external inbox.

The Cloud Pub/Sub option is not correct because Pub/Sub is a messaging service used to deliver events inside cloud architectures and it does not itself poll or retrieve email from a mailbox.

The Mail handler is not correct because a handler typically operates on messages once they have been retrieved and stored rather than performing the external retrieval from the connected inbox.

The Inbound mail gateway is not correct because a gateway normally accepts incoming SMTP deliveries or routes mail into the system and does not match the described polling retriever that fetches unread messages from a remote mailbox.

Focus on keywords in the stem such as polls and inbox to distinguish the component that retrieves messages from those that process or route them.

The correct options are Move issues and Remove version.

Move issues is required because you must reassign the issue that was mistakenly given to v2.0beta over to v2.0 so the work is tracked under the correct release. Moving the issue updates its version field so it appears under the intended release.

Remove version is required because after you have moved the issue you should delete or remove the now empty v2.0beta to clean up the project version list and avoid confusion. Removing the empty version finalizes the consolidation.

Rename version is not correct because renaming only changes the version name and does not transfer or consolidate issue assignments into the existing v2.0 version.

Archive version is not correct because archiving hides a version but does not move issues into another version and therefore does not consolidate v2.0beta into v2.0.

Merge versions is not correct because team managed projects do not offer a single merge action that automatically combines two versions and reassigns issues for you.

Swap versions is not correct because swapping is not an action that consolidates version assignments and it would not move the issue from v2.0beta into v2.0.

Move issues first and then remove the now empty version to avoid leaving orphaned assignments and to keep your project release list tidy.

The correct answer is Assign Lena Mateo and Priya to the project role Scrum Team in the project “ORBIT”.

This is correct because the notification scheme sends the Create issue event to the project role Scrum Team and project role membership is maintained at the project level. By adding Lena Mateo and Priya to the Scrum Team role in the ORBIT project they will be included in the notification recipients without altering any shared configuration.

Add Lena Mateo and Priya directly to the “Create issue” event in the notification scheme used by “ORBIT” is incorrect because changing the notification scheme would modify a shared configuration and the requirement is to leave shared configurations unchanged. Editing the scheme could affect other projects that use the same scheme.

Add the Administrators project role to the “Create issue” event in the notification scheme used by “ORBIT” is incorrect because the Administrators role does not include Mateo and Priya and altering the shared notification scheme is not allowed. This change would not guarantee notifications for the two users and would change shared configuration.

Assign Lena Mateo and Priya to the Administrators role in the project “ORBIT” is incorrect because assigning elevated administrator permissions is unnecessary and excessive just to receive notifications. The notification scheme targets Scrum Team so adding them to that role is the minimal and correct approach.

Assign only Lena to the Scrum Team role in the project “VOYAGER” is incorrect because modifying membership in VOYAGER does not add Mateo or Priya to ORBIT and the goal is to ensure notifications in ORBIT while leaving shared settings unchanged. Project role membership must be set in the ORBIT project.

When a notification scheme sends to a project role add users to that role in the affected project rather than editing a shared notification scheme.

The correct options are The field must be reusable across many projects and Users must be limited to choosing a single value from the field.

The field must be reusable across many projects points to a custom field because custom fields can be defined globally and then applied across many projects and contexts. Components are project scoped so they are not suitable when the attribute must be shared and managed across multiple projects.

Users must be limited to choosing a single value from the field describes a single-select custom field option which enforces a one‑choice selection. Custom fields can be created as single choice fields so users can pick only one value while keeping that same field available in many projects.

Selecting a value will automatically assign the issue to a specific user is incorrect because automatic assignment is a behavior provided by components through a component lead or default assignee and by automation rules, not an inherent reason to prefer a custom field.

Project administrators will configure and manage the field within each project is incorrect because custom fields are created and configured at the global administration level and then associated to projects through contexts and screens, while components are what project administrators manage per project.

Scope is the quickest way to choose. If the attribute needs to be reused across projects pick a custom field, and if you need project scoped assignment behaviors consider components or automation.

The correct answers are Users can create multiple issues at once from the board, Users can add a new status directly from the board, and Users can group issues by priority.

Users can create multiple issues at once from the board is correct because team owned project boards provide board level creation and bulk entry flows so users can add several issues quickly while planning without leaving the board interface.

Users can add a new status directly from the board is correct because boards allow teams to extend or adjust their workflow by adding new columns or statuses on the fly to reflect how work progresses.

Users can group issues by priority is correct because boards support grouping and filtering by fields such as priority so teams can surface and organize high impact work during planning and execution.

Boards sync automatically across projects is incorrect because boards are typically scoped to a specific project or team and do not automatically mirror state across different projects. Cross project synchronization requires explicit configuration or tooling and is not a default board behavior.

Focus on verbs that describe direct board actions such as create, add, and group. Be cautious of options that claim automatic cross project behavior since that is not usually a default feature.

{{issue.status.name}} is the correct smart value to include the ticket status in the email.

In Jira Automation the status is represented as an object and you need to access its name property to get the human readable status. Using {{issue.status.name}} returns the status label such as To Do or In Progress instead of an object reference.

{issue.status} is wrong because it uses single braces and does not follow the required double curly smart value syntax.

{{issue.statusName}} is wrong because there is no top level statusName property on the issue smart value. The status label is available as the name property of the status object.

{{issue.status}} is wrong because it references the full status object and will not directly yield the readable name unless you access a specific field like {{issue.status.name}}.

$issue.status is wrong because Jira Automation does not use dollar prefixed variables and instead requires double curly brace smart values.

Remember to use double curly braces for smart values and access object properties with a trailing .name when you need the human readable field value.

Priya’s deactivated account will continue to count toward the organization license limit is the correct statement.

This is correct because deactivating a managed Atlassian account does not immediately free the organization s license seat. The user remains associated with the organization until they are removed from the organization or product access is changed, and that means the deactivated account continues to count toward license totals.

Assigned issues that referenced Priya will remain in the project is not the definitely false statement because issues that reference or were assigned to a user generally remain in the project even after the user is deactivated. The assignee field may show a deactivated user but the issues themselves typically persist rather than being deleted.

Priya’s account can be reactivated later if necessary is not the definitely false statement because managed accounts can often be reactivated by organization administrators. Reactivation depends on the organization s user management policies but it is a supported outcome in many cases.

Priya will be removed from all Jira Cloud sites in every organization where she had access before deactivation is not the definitely false statement because deactivation in one organization does not automatically remove a user from sites or organizations that are managed separately. Site and organization membership are managed independently so removal behavior depends on where and how the account was deactivated.

When you see statements about user deactivation and licenses remember that a deactivated managed user often still counts toward license limits until they are removed from the organization or product access is revoked.

The correct option is (duedate = startOfWeek(24h) AND duedate ⇐ endOfWeek()).

The first part of the expression checks for unresolved issues that are past their due date. Using duedate < now() AND resolution = Unresolved returns items whose due date is before the current time and whose resolution is not set, which matches the requirement for unresolved past due tickets.

The second part of the expression selects issues with due dates in the current week range. Using duedate >= startOfWeek(24h) AND duedate ⇐ endOfWeek() confines results to the week boundaries so that you get issues whose due dates fall within the current week window. The OR between the two clauses ensures you get either unresolved past due items or issues with due dates in the specified week.

duedate < now( OR (duedate >= startOfWeek() AND duedate ⇐ endOfWeek(-1))) AND resolution is EMPTY is incorrect because it uses endOfWeek(-1) which refers to the previous week and it wraps the resolution filter outside the intended grouping so the date range will not match the current week as required.

(duedate < now() AND resolution = Unresolved) AND (duedate >= startOfWeek(24h) AND duedate ⇐ startOfWeek()) is incorrect because it combines the past due condition and the current week condition with AND which requires an issue to be both past due and also inside the week range. That produces a contradictory filter and the date range to start and end at the same boundary makes the second clause effectively empty.

(due < now() AND resolution = Unresolved) OR (due >= startOfWeek(24h) AND due ⇐ endOfWeek()) is incorrect because it uses the due field name which is not the standard JQL field for issue due dates in most Jira instances. That makes the query fail to reliably target the issue due date field.

When evaluating JQL choices look for correct field names and logical grouping. Pay attention to whether clauses are combined with OR or AND and make sure date functions reference the intended week boundaries.

All exam questions come from my Jira ACP-120 Udemy course and certificationexam.pro

The correct options are JSON file, Trello board export, and CSV file.

The import wizard accepts JSON file because JSON is a structured data format that can represent issue fields and metadata and the wizard can parse those structures to recreate issues during import.

The wizard also accepts CSV file because CSV is a common interchange format for bulk data and the import maps columns to issue properties to create multiple issues at once.

The tool supports Trello board export because Trello provides exports that contain cards lists and related metadata and the import converts those items into issues while preserving labels and comments when possible.

HAR file is incorrect because a HAR file stores network traffic details and does not contain issue data in a format the import wizard can use.

Microsoft Excel XLSX is incorrect because the wizard does not accept native Excel workbook files directly and you would first export or save the sheet as a supported format such as CSV.

ZIP archive is incorrect because a generic compressed archive is not a supported import format on its own unless it contains one of the supported file types and you provide the contained supported file to the wizard.

When choosing answers think about common interchange formats that represent structured data such as JSON and CSV and remember that service exports like Trello are often supported directly by import wizards.

Components field is hidden in that issue type’s field configuration is correct.

If the Components field is hidden in that issue type’s field configuration then the component picker will not be available when creating or editing that issue type. The automatic assignment that uses a component lead only runs when a component is selected so if the field is not present no component can be chosen and the assignee remains unassigned.

A workflow post function or automation clears the assignee is unlikely because that would actively remove or change the assignee and you would normally see the behavior across transitions or in automation audit logs. It also would not specifically explain why only one issue type is producing unassigned issues when components and leads exist.

A suspended user is set as the component default assignee is not the most likely cause because a suspended default assignee would affect all issues that select that component rather than only a single issue type. The scenario describes a visibility problem that points to the field configuration instead.

The issue type uses a different create screen that excludes Components is possible but less likely than a hidden field configuration. Screens determine which fields appear for create or edit but field configuration controls per issue type visibility. The common root cause for one issue type missing the Components picker is that the field was hidden in its field configuration.

When a field is missing check the field configuration for that specific issue type first before assuming a workflow or automation is the cause.