Free Jira ACP-120 Certification Practice Exams

Asha at Lumen Labs needs to retrieve issues whose summary contains the literal string “[CodeSchool]”. Which JQL will return those results?

• ❏ A. summary ~ “\\[CodeSchool\\]”

• ❏ B. summary = “[CodeSchool]”

• ❏ C. Special characters are not indexed in Jira Cloud so they cannot be searched

• ❏ D. summary ~ “[CodeSchool]”

IssueFlow Cloud users can assign an access level to their dashboards in order to control who may view or edit them. Which of the following statements about dashboard access levels is not true?

• ❏ A. Open dashboard to every account on the site

• ❏ B. Make the dashboard publicly available on the internet

• ❏ C. Share access with a specific project and its roles

• ❏ D. Only the original dashboard owner can access and edit it

• ❏ E. Grant dashboard access to specified user groups

• ❏ F. All of the above statements are correct

After moving a ticket from ‘Under Review’ to ‘Signoff’ at Atlas Systems, Marcus can no longer change the ticket details. Which configuration should Marcus update?

• ❏ A. Field configuration

• ❏ B. Workflow status property

• ❏ C. Transition screen

• ❏ D. Issue security level

• ❏ E. Project permission scheme

Which statements about IssueTrack Cloud backup and import are not correct? (Choose 3)

• ❏ A. Users are unable to merge imported user accounts with existing cloud users

• ❏ B. Generated backup archives are automatically deleted after 18 days

• ❏ C. Importing a backup file unconditionally replaces every piece of data on the IssueTrack Cloud instance

• ❏ D. Only site administrators have the ability to run exports and import data in IssueTrack Cloud

• ❏ E. Users can only export backups for business managed projects and not for team managed projects

A team maintains the project “Helio” and the project lead is Aisha. The project default assignee is set to the Project Lead. The components are configured as follows UI component lead is Lena and the component default assignee is the Project Lead. Auth component lead is Ethan and the component default assignee is the Component Lead. Service-X47 component lead is Sophia and the component default assignee is Project Default. You create a new issue and select the components “UI” “Auth” and “Service-X47” while leaving the assignee set to Automatic. To whom will the newly created issue be assigned?

• ❏ A. Lena

• ❏ B. Sophia

• ❏ C. Aisha

• ❏ D. Ethan

An Account Success group at Meridian Solutions uses company-managed Jira projects to track client work. They can create issues and update most fields and they build filters and dashboards, but they cannot set or change the due date on issues in their ACCOUNTS project. What project permission allows them to do that?

• ❏ A. Grant the Account Success team “Manage sprints” project permission

• ❏ B. Grant the Account Success team “Edit issues” project permission

• ❏ C. Grant the Account Success team “Assign issues” project permission

• ❏ D. Grant the Account Success team “Schedule issues” project permission

Mira at Silverline Solutions compiled requirements for new custom fields. The fields must be available across all projects and must restrict users to a single selection. They must support a predefined default option and allow different option lists per project. Which field types satisfy these needs? (Choose 2)

• ❏ A. Checkbox

• ❏ B. Components

• ❏ C. Select List (single choice)

• ❏ D. Labels

• ❏ E. Radio Button

The DevSprint Jira project uses a radio button custom field called “Deployment Model” with the values “Cloud” “DataCenter” and “Server”. A teammate needs a JQL expression that finds all issues that have either “Cloud” or “DataCenter” as the deployment model and that are due during the next month. What JQL will return those issues?

• ❏ A. “Deployment Model” = “Cloud” OR “Deployment Model” = “DataCenter” AND due ⇐ endOfMonth(+1m) AND due >= startOfMonth(+1m)

• ❏ B. (“Deployment Model” = “Cloud” OR “Deployment Model” = “DataCenter”) AND (due ⇐ endOfMonth(+1m) AND due >= startOfMonth(+1m))

• ❏ C. “Deployment Model” in (“Cloud”,”DataCenter”) AND due >= startOfMonth(+1) AND due ⇐ endOfMonth(+1)

• ❏ D. “Deployment Model” in (“Cloud”,”DataCenter”) AND (due ⇐ endOfMonth(+1) OR due >= startOfMonth(+1))

• ❏ E. “Deployment Model” in (“Cloud”,”DataCenter”) AND due ⇐ endOfMonth(+1m) AND due >= startOfMonth(+1m)

A product team at NimbusApps needs a JQL expression that returns all issues with the top priority that were created from the start of the current week up to the present moment. Which JQL statement will produce that result? (Choose 2)

• ❏ A. priority = Highest AND createdDate equals startOfWeek() AND createdDate < now()

• ❏ B. priority > High AND createdDate > startOfWeek() AND createdDate < now()

• ❏ C. priority = Highest AND createdDate = startOfWeek() AND createdDate < now()

• ❏ D. priority = Highest AND createdDate is startOfWeek() AND createdDate < now()

• ❏ E. priority = Highest AND createdDate > startOfWeek() AND createdDate > now()

• ❏ F. priority = 1 AND createdDate > startOfWeek() AND createdDate < now()

At Meridian Labs you administer a single site that hosts both Jira Software Cloud and Confluence Cloud and you recently suspended a Jira user successfully. Which statement about that suspended account is correct?

• ❏ A. The suspended account will still appear in the user directory

• ❏ B. The suspended user will still be able to sign in to the Confluence site

• ❏ C. Other users can still mention the suspended account with an at sign

• ❏ D. The suspended account can still be chosen as an issue assignee

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

Marta set up an automation to send a notification to her engineering team and she wants the issue assignee to appear in the message template. What is the correct smart value syntax to reference the assignee in the template?

• ❏ A. issue.assignee

• ❏ B. [issue.assignee]

• ❏ C. {{issue.assignee}}

• ❏ D. $issue.assignee

• ❏ E. {issue.assignee}

Marisol is the Jira administrator and she leads the Kanban style team at Flowline for the company managed project “PTM” which uses a single issue type named “DataMove”. The project uses the default notification scheme and no custom events are defined. Evan handles approvals for DataMove tickets and he reports that he receives too many email alerts so Marisol must change the project settings to meet these requirements Send Evan an email only when an issue transitions into the status “AWAITING APPROVAL” Do not send any other email notifications to Evan outside of that single alert Note that a single transition targets the status “AWAITING APPROVAL” and that this status is only used by the project “PTM”. Also note that the DataMove workflow contains more than twelve statuses. How should Marisol update the PTM project configuration to satisfy these requirements?

• ❏ A. Create a custom event Add Evan to the new custom event in the PTM notification scheme Add a new post function on the transition that fires the new custom event

• ❏ B. Evan must update his Jira personal settings Create a custom event Add Evan to the new custom event in the PTM project notification scheme Edit the transition to “AWAITING APPROVAL” so it fires the custom event

• ❏ C. Identify the event currently fired by the transition to “AWAITING APPROVAL” and add Evan to that event in the PTM notification scheme

• ❏ D. Add Evan to the PTM notification scheme for the Issue Updated event so he will receive updates whenever an issue changes

After verifying its domain a regional startup named CedarByte turned on Atlassian Access and pointed the Jira Cloud organization to Azure AD as the identity provider and a subset of employees report they can no longer sign in with their Atlassian account while others still succeed. What is the most likely cause?

• ❏ A. Users must be added to the Azure AD group assigned to the organization

• ❏ B. Users must sign in with their Azure AD credentials rather than their Atlassian account

• ❏ C. Users must reset their Atlassian account passwords after Atlassian Access is enabled

• ❏ D. Administrators must wait 72 hours for DNS domain verification to finish propagating

A Jira project at Acme Labs uses three workflow states Backlog In Development and Completed. Which JQL will return issues that have never been in “Completed” status?

• ❏ A. resolution is EMPTY

• ❏ B. status was in (“Backlog”, “In Development”)

• ❏ C. status != Completed

• ❏ D. status was not Completed

• ❏ E. resolution != null

At BeaconSoft the security team asked Aria to add a custom field so team members can list software vulnerabilities and reuse the same values across tickets and Aria has permission to add new entries. Which field type should she choose?

• ❏ A. Components

• ❏ B. Labels

• ❏ C. Cloud Identity

• ❏ D. Text Area

• ❏ E. Radio

• ❏ F. Checkbox

A regulatory team at Horizon Audit uses Jira to manage validation of compliance records and they attach several files to each ticket. Team members upload and download attachments at multiple workflow stages and they cannot retrieve every file for a ticket in a single action which prompted the compliance lead to request a solution. What configuration change allows users to download all attachments for an issue at once?

• ❏ A. Use the Jira REST API to script bulk attachment downloads

• ❏ B. Enable the System Attachment setting “Enable zip support” by setting it to ON

• ❏ C. Turn on a global setting named “Download all attachments”

• ❏ D. Assign a project permission called “Download all attachments” to every user

You provisioned a new site for Meridian Software and enabled Jira Software Cloud and Jira Work Management Cloud while leaving all default settings unchanged. You assigned Riley the product role “Users” for the Jira Software product and the product role “Product Admin” for the Jira Administration product. What can Riley definitely do?

• ❏ A. Verify organization domains

• ❏ B. Create a team managed project in Jira Software

• ❏ C. Grant product access to users for Jira Software

• ❏ D. Add users to site groups

Which of the following statements about a team managed project board is not accurate?

• ❏ A. Issues can be grouped by subtasks

• ❏ B. Team members must manually add a status to the project workflow after adding a new column

• ❏ C. Board users can rename statuses directly from the board

• ❏ D. A single column may contain multiple statuses at once

• ❏ E. Issues can be grouped by assignee

While filing a new issue at a retail tech firm, Maya can see the custom field “TrainingPortal” on the create screen but when she opens the same issue to edit it the field does not appear on the edit screen. Which configuration could cause a custom field to be present for one operation and absent for another?

• ❏ A. Issue security level

• ❏ B. Field configuration scheme

• ❏ C. Project permissions

• ❏ D. Screen scheme association

• ❏ E. Global permissions

A small company called NovaWorks shows these user group memberships for three employees. User Group Membership Aaron mobile team , jira software users east Priya mobile team , jira software users east Elena administrators , jira software users east The same permission scheme is applied to every project and all project roles currently have no members The permission scheme maps permissions as follows Administer Project Project Role Administrators Browse Projects Project Role Developers Project Role Administrators Project Role Scrum Team Modify Reporter Any logged in user Assignable User Project Role Developers Project Role Administrators Edit issues Project Role Developers Project Role Administrators Project Role Scrum Team Assign issues Project Role Administrators Project Role Scrum Team An excerpt from global permissions shows Make bulk changes Public Share dashboards and filters administrators Manage group filter subscriptions administrators Aaron Priya and Elena already have Jira Software product access and they need to be able to edit the assignee across all projects edit the reporter across all projects and create edit and share filters All users must be given the minimum permissions required What configuration changes are required to meet these needs? (Choose 2)

• ❏ A. Add Aaron Priya and Elena to the Developers project role in every project

• ❏ B. Add the group “jira software users east” to Share dashboards and filters and Manage group filter subscriptions global permissions

• ❏ C. Add Aaron Priya and Elena to the Scrum Team project role in every project

• ❏ D. Add the group “mobile team” to the Share dashboards and filters global permission

• ❏ E. Add Aaron Priya and Elena to the Administrators project role in every project

• ❏ F. Global permissions are already sufficient no changes are required

Ava must restrict the workflow transition button ‘Executive Approved’ so only members of the directors group can see it on the view issue screen. Which workflow element does she need to change?

• ❏ A. Validator

• ❏ B. Issue Security Level

• ❏ C. Post Function

• ❏ D. Condition

• ❏ E. Trigger

Ravi needs to produce a list of issues he filed where the summary contains both the words urgent and critical. Which JQL statements will return those issues? (Choose 2)

• ❏ A. reporter = Ravi AND summary in (urgent, critical)

• ❏ B. reporter = Ravi AND summary ~ “\\[urgent, critical\\]”

• ❏ C. reporter = Ravi AND summary ~ “urgent” AND summary ~ “critical”

• ❏ D. reporter = Ravi AND summary = “urgent” AND summary = “critical”

• ❏ E. reporter = Ravi AND summary ~ (“urgent, critical”)

• ❏ F. reporter = Ravi AND (summary ~ “urgent” OR summary ~ “critical”)

A site administrator at HarborTech needs to export a Jira Cloud snapshot and restore it into a different Jira Cloud tenant. Which item will they have to import manually?

• ❏ A. Project configuration and workflow schemes

• ❏ B. Automation rules

• ❏ C. Boards and sprint records

• ❏ D. User accounts and group memberships

A support team at Nimbus Solutions needs to find every Jira issue that contains the token “Profile” or the literal “[Profile]” and that had Priority set to High at any point in the past. Which JQL will return those issues?

• ❏ A. summary = “[Profile]” AND Priority = “High”

• ❏ B. text ~ “\\[Profile\\]” AND Priority was “High”

• ❏ C. text ~ “[Profile]” AND Priority was “High”

• ❏ D. all ~ “[Profile]” AND Priority was “High”

• ❏ E. summary ~ “\\[Profile\\]” AND Priority = “High”

Issue level security has been configured for the company managed project “ACME-PROJ” and the scheme includes a “Standard (default)” level and a “Restricted” level with different project roles assigned to each level. Marta is working on a highly sensitive ticket “ACME-42” that is set to the “Restricted” level and she has the project permissions required to change security levels. Marta will create subtasks under “ACME-42” and she wants to know which security level those subtasks will have and whether she can change the subtasks’ security level. What is true?

• ❏ A. Subtasks will get the “Standard (default)” security level and Marta will be able to alter their security level

• ❏ B. Subtasks will default to no security level and Marta will be able to set their security level

• ❏ C. Subtasks will inherit the “Restricted” security level and Marta will not be able to modify their security level

• ❏ D. Subtasks will get the “Standard (default)” security level and Marta will not be able to alter their security level

• ❏ E. Subtasks will inherit the “Restricted” security level and Marta will be able to modify their security level

• ❏ F. Subtasks will default to no security level and Marta will not be able to change their security level

After a reorganization at Horizon Analytics, Mira’s support group will be divided into two teams and many Jira tasks remain assigned to former staff. Mira must reassign those issues and ensure the new assignees are informed. What actions should Mira perform?

• ❏ A. Create an automation rule to reassign issues and notify the new users

• ❏ B. Add a workflow transition screen that prompts for a new assignee

• ❏ C. Use the bulk Edit issues operation to update the assignee and add a comment to notify them

• ❏ D. Create a visible announcement banner for all users

• ❏ E. Add a post function to a workflow transition that assigns the ticket to a new user

A support group at Nimbus Labs is evaluating a team managed project template for a small product and they need to know which features are not available in that project type? (Choose 2)

• ❏ A. Manage releases and versions from the project features

• ❏ B. Restrict custom Resolution field values in project settings

• ❏ C. Create cascading select custom fields that depend on another field

• ❏ D. Restrict a workflow transition to members of a group type custom field

• ❏ E. Set a Timestamp custom field to default to the current time

Which custom field types allow the field description to include bold and italic formatting?

• ❏ A. Labels

• ❏ B. Number Field

• ❏ C. Paragraph field with rich text enabled

• ❏ D. Select List single choice

• ❏ E. Text Field single line

Leah can edit every field except the Fix version field in all projects at SolaraApps. Which project permission should Leah request from the administrators?

• ❏ A. “Edit Issues”

• ❏ B. “Issue Security Level”

• ❏ C. “View Development Tools”

• ❏ D. “Resolve Issues”

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

A product squad at Maren Software uses team managed projects in Jira Cloud and they want to confirm which behaviors are provided by that project type? (Choose 2)

• ❏ A. The issue navigator cannot be enabled for team managed projects

• ❏ B. Multiple issues can be added at once to a team managed project

• ❏ C. Team managed projects support sharing of workflow and field schemes with other projects

• ❏ D. Clearing a parent issue from the board also clears all of its subtasks regardless of each subtask’s status

• ❏ E. You can configure a default issue security level at the project level

A project administrator at Velora Tech noticed many tickets are in Closed status yet the resolution field is unset. What steps should the administrator take so the resolution value is populated when those tickets are closed? (Choose 2)

• ❏ A. Move the tickets to another project with the bulk move operation

• ❏ B. Add a post function to the Closed transition to set the resolution

• ❏ C. Edit the tickets with a bulk edit to populate the resolution field

• ❏ D. Add the Resolution field to the issue screens so users can fill it manually

• ❏ E. Use the bulk transition operation so workflow post functions execute for each ticket

A team lead assigned a task to Lena in a company-owned project with an estimated duration but Lena cannot locate a way to record her work. What could explain this situation?

• ❏ A. Missing Edit Own Worklogs permission

• ❏ B. Time tracking disabled in global settings

• ❏ C. Missing Schedule Issues permission

• ❏ D. Missing Work On Issues permission

Which visual elements in a Jira Cloud site allow you to modify color settings for the interface and navigation? (Choose 2)

• ❏ A. Overall Jira application background

• ❏ B. Create button and the highlight color for the active navigation item

• ❏ C. Link text color

• ❏ D. Background color of the main navigation bar

• ❏ E. Issue action menu background color

Marina is expanding her support team across regions that speak different languages and she wants to know which field types can be translated inside a company managed project? (Choose 3)

• ❏ A. Priority field

• ❏ B. Radio button custom field

• ❏ C. Resolution field

• ❏ D. Issue security level

• ❏ E. Status field

• ❏ F. Issue type

Leila creates a new Kanban board that covers several company managed projects at Atlas Tech and finds that some issues are missing from the board. What might explain why those issues do not appear? (Choose 2)

• ❏ A. A saved filter or the board subfilter excludes the missing issues

• ❏ B. Some issues have “Issue Security Level” applied

• ❏ C. A work in progress limit is set on a board column

• ❏ D. The viewer does not have Browse Projects permission for some of the included projects

Acme Tools has a company managed project named “SHIFT” and it uses project roles and permissions arranged as follows. The project role “Reviewers” has the Browse Projects permission and the project role “Auditors” has the Create issues and Edit issues permissions. The permission scheme is shared across all company projects. Members of the “aud-grp” group report that they can create issues in the “SHIFT” project but they cannot edit those issues even though they can view and edit issues in other company projects. What change will allow all members of aud-grp to edit issues in the “SHIFT” project without changing permissions for other projects?

• ❏ A. Add the aud-grp group to the Reviewers project role in the project “SHIFT”

• ❏ B. Add the Auditors project role to the Browse Projects permission

• ❏ C. Add the rev-grp group to the Auditors project role in the project “SHIFT”

• ❏ D. Set aud-grp as a default member of the Reviewers project role in system configuration

At Nimbus Software the support team is configuring notification recipients for a team-managed board and they need to know which recipient type cannot be added to the team-managed project notification settings?

• ❏ A. Signed In User

• ❏ B. Project Role

• ❏ C. Project Manager

• ❏ D. Individual Email Address

The governance group at Northbridge Consulting uses a saved filter subscription with the JQL project = AUDIT AND created > startOfYear() AND resolution = Unresolved and members report that the subscription sometimes sends emails that contain no issues. What is the most likely reason for the empty email notifications?

• ❏ A. Some members of the governance group lack permission to view the issues returned by the filter

• ❏ B. The JQL expression contains a syntax or logical mistake

• ❏ C. The subscription is configured to send emails even when the filter finds no issues

• ❏ D. The query matches more issues than Jira will list in an email causing the notification to appear blank

The permission scheme and the issue security mapping for the company managed project “PeopleCare” are shown in the example below. The permission mappings are Browse Projects Any logged in user Set issue Security Any logged in user Edit issues Any logged in user Create issues Any logged in user. The security level mappings show Confidential default Project Role (PeopleCare Team) Level1 Project Role (PeopleCare Team) Assignee. The PeopleCare project is used by all employees to send requests to the PeopleCare Team. The issue security scheme is intended to restrict new issues so only members of the PeopleCare Team role can view them. Despite this, all users on the Jira site report that they can view newly created issues even though they are not members of the PeopleCare Team role. Which configuration is most likely causing this behavior?

• ❏ A. Issue Type Screen Scheme of the project “PeopleCare”

• ❏ B. Issue Security Scheme of the project “PeopleCare”

• ❏ C. Global permissions

• ❏ D. Field Configuration of the project “PeopleCare”

• ❏ E. Permission Scheme of the project “PeopleCare”

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

A project administrator at BeaconTech is configuring an issue collector to capture feedback from website visitors. Which fields can be automatically populated when the collector is set up? (Choose 3)

• ❏ A. Priority

• ❏ B. Reporter

• ❏ C. Assignee

• ❏ D. Issue type

• ❏ E. Project

Nina manages two company managed projects at Orion Systems that share the same setup. Which modifications impact only the field configuration? (Choose 2)

• ❏ A. Assign differing default values for each issue type within a project for a radio button field

• ❏ B. Limit available options for a radio button custom field per project

• ❏ C. Remove the priority field from all screens

• ❏ D. Make a custom field required on issue creation

MeridianSoft IT is reviewing how Jira Cloud handles backups and restores. Which statement accurately describes how Jira Cloud backup files are managed?

• ❏ A. Only site administrators can generate backup exports and import Jira Cloud data

• ❏ B. Imported user accounts cannot be merged with existing cloud users during a data import

• ❏ C. A newly created backup will replace the existing backup file on the Backup Manager page

• ❏ D. Team managed projects are excluded from backups and cannot be restored from a backup file

Elena at Atlas Systems is attempting a bulk status update across many issues but the process fails. Which statement below is false?

• ❏ A. The workflow contains a condition that prevents the status transition

• ❏ B. A validator on the transition is blocking the status change

• ❏ C. The user does not have the Transition Issues project permission

• ❏ D. The user is not a member of the required group for this operation

• ❏ E. Edit restrictions are applied through a transition property

Carlos is creating a new team managed project for Alder Labs and needs the following setup. Anyone who can sign in to his Jira site must be able to search for view and comment on issues. Only users he explicitly adds to the project should be able to create or edit issues. Which project access level should he select?

• ❏ A. Restricted

• ❏ B. Personal

• ❏ C. Private

• ❏ D. Limited

A project administrator at NovaSoft is using the bulk edit feature to apply changes across many tickets. Which of the following assertions about bulk edit operations is not true? (Choose 2)

• ❏ A. Users can revert any bulk edit they perform

• ❏ B. The Transition Issues project permission is required to change an issue status

• ❏ C. You can change an issue type using either the Edit Issues action or the Move Issues action

• ❏ D. The Edit Issues bulk operation can modify custom field values

• ❏ E. Bulk edit can set the resolution field directly for multiple issues

In a team-owned project team members can modify the issue view per issue type and the view divides fields into Description fields and Context fields. Which fields cannot be removed from the Description fields section? (Choose 2)

• ❏ A. Issue Type

• ❏ B. Status

• ❏ C. Priority

• ❏ D. Assignee

• ❏ E. Description

• ❏ F. Summary

You are the release lead at MeridianSoft and you use the vote and watch features frequently. You need to change the list of watchers so your team receives updates on priority stories but you cannot add or remove watchers at the moment. Which configuration must be changed to allow updating the watcher list?

• ❏ A. Enable the global setting “Allow users to watch issues”

• ❏ B. Grant the project permission “Manage watchers”

• ❏ C. Grant the global permission “Browse users and groups”

• ❏ D. Grant the project permission “View voters and watchers”

Two product squads at Meridian Systems asked you to set up a Jira project for each squad and each squad provided a list of requirements. Your lead prefers to reduce administrative overhead and suggests reusing configuration where feasible. For which requirements can both projects share the same scheme while still meeting the squads needs? (Choose 3)

• ❏ A. Different users should be able to delete issues

• ❏ B. The default issue security level must differ between the projects

• ❏ C. Each project should have its own outgoing email address for notifications

• ❏ D. The priority field must show a different list of choices in each project

• ❏ E. A shared custom field must present a different option set depending on the project

Ethan configured a new email handler for HarborTech and a client reports they sent a message but no Jira issue was created. Ethan confirmed that emails from other clients still generate issues. What is most likely preventing that particular customer email from creating a new Jira issue?

• ❏ A. The mail handler has been removed or disabled

• ❏ B. No default reporter is set in the mail handler configuration

• ❏ C. The issue type referenced by the handler was deleted from the target project

• ❏ D. The handler is pointing to a different mailbox so the inbox checked is empty

Maya is in charge of assigning all critical tickets to engineers and she wants a personal filter subscription to review them each morning. What steps must she take to enable the subscription to display those issues and to allow her to assign them? (Choose 3)

• ❏ A. ‘Assignable Issues’ project permission

• ❏ B. ‘Assign Issues’ project permission

• ❏ C. ‘Manage group filter subscriptions’ global permission

• ❏ D. ‘Browse Projects’ project permission

• ❏ E. Access to the relevant issue security levels

Maya created a filter subscription and set the recipients to anyone who can access the site. The saved JQL for the subscription is (project = “Platform” AND assignee = membersOf(“engineers”)) OR assignee=currentUser(). Assuming every recipient has permission to receive these emails who will be sent this subscription? (Choose 2)

• ❏ A. All users who can access the Platform project

• ❏ B. Any user who currently has an issue assigned to them

• ❏ C. Members of the engineers group who are assigned issues in the Platform project and have access to that project

• ❏ D. All users who have access to the site

• ❏ E. All members of the engineers group regardless of whether they are assigned issues

Marcus was asked to ensure only members of the InfoSec group can move an issue into the Authorized status within the project. Which workflow or configuration elements must he adjust to enforce this restriction? (Choose 2)

• ❏ A. Permission Scheme

• ❏ B. Validator

• ❏ C. Issue Security Level

• ❏ D. Post Function

• ❏ E. Condition

Maya renamed a workflow status in the team project from “To Do” to “To Do Training”. What changed after she modified the status name? (Choose 3)

• ❏ A. You must run a manual reindex for the cloud instance

• ❏ B. Automation rules that refer to the original status name require edits

• ❏ C. Saved issue filters that reference the previous status must be updated

• ❏ D. All built in reports will automatically update to the new status without any changes

• ❏ E. Boards and dashboards that rely on those filters must be updated

• ❏ F. You must update the workflow scheme to reflect the new status label

You administer a Jira Cloud instance that contains several projects including a team-managed project named “ORB” and a company-managed project named “CAS”. Each project uses a single workflow for all issue types. The workflow for “ORB” uses the statuses To do, In progress and “Done”. The workflow for “CAS” uses the statuses To do, In progress and “Done”. The project “CAS” shares its configuration with every other company-managed project. Which statement is true?

• ❏ A. Renaming the status “Done” in the workflow for project “ORB” will only affect that team-managed project

• ❏ B. Renaming the status “Done” in the workflow for project “ORB” will propagate to both team-managed and company-managed projects

• ❏ C. Changing the name of the status “Done” in the workflow used by the project “CAS” will have an impact in all company-managed projects only

• ❏ D. Changing the status name “Done” in the workflow for project “CAS” will impact every team-managed project

• ❏ E. Renaming the status “Done” in the workflow for project “CAS” will affect all company-managed projects and all team-managed projects

• ❏ F. Only site administrators can rename statuses at the global level through the administration console

A mid sized company uses NovaSuite and its NovaAccess offering to manage who can reach company applications. Which of the following statements is definitely true?

• ❏ A. An organization domain must be approved before NovaAccess can be enabled

• ❏ B. Invitation links remain valid indefinitely while they are enabled

• ❏ C. The two methods to approve a domain are HTTPS validation and DNS records

• ❏ D. Accounts with any verified email address from a nonpublic domain may be granted product access

• ❏ E. Existing users can only invite people who share the same organization domain to join a product

Special characters are not indexed in Jira Cloud so they cannot be searched is correct.

Jira Cloud does not index many punctuation and special characters so queries that look for literal brackets or similar characters will not return results. The indexed tokens omit those characters and the text search operator cannot match the raw punctuation. Therefore you cannot reliably search for the literal string [CodeSchool] using JQL.

summary ~ “\[CodeSchool\]” is incorrect because escaping the brackets in a text search does not force Jira Cloud to index those characters. Escape sequences cannot make unindexed punctuation searchable.

summary = “[CodeSchool]” is incorrect because the equals operator performs exact matches and it will not match when the punctuation is not indexed. The equality operator is also not suitable for free text searches with punctuation.

summary ~ “[CodeSchool]” is incorrect because searching with the tilde and including the punctuation will not find the literal brackets. The brackets are treated as special characters and are not part of the indexed text in Cloud.

Special characters are often not searchable in Jira Cloud so try searching for the words without punctuation when you evaluate JQL options.

All of the above statements are correct is the correct choice.

Each of the other options describes a valid dashboard access behavior in IssueFlow Cloud, and because all of those behaviors exist the combined statement that all are correct is the right answer.

Open dashboard to every account on the site is incorrect as a standalone choice because you can make a dashboard visible to all site accounts but that is only one possible access level and does not represent the full set of options.

Make the dashboard publicly available on the internet is incorrect by itself because public internet sharing is supported yet it is only one sharing mode among others and so the single statement is incomplete.

Share access with a specific project and its roles is incorrect when chosen alone because project and role scoping is a supported method of sharing but it does not exclude the other methods of access control.

Only the original dashboard owner can access and edit it is incorrect as a sole answer because ownership-only restriction can be applied in some cases but dashboards can also be shared with other users, groups, and projects.

Grant dashboard access to specified user groups is incorrect on its own because group-based access is available but it is one of several mechanisms for controlling who can view or edit a dashboard.

When a question lists multiple possible behaviors consider whether each individual statement can be true at the same time and favor All of the above when every listed item is accurate.

The correct option is Workflow status property.

Workflow status property controls behaviors and restrictions that apply to an issue based on its current status. Administrators can set properties on a status that prevent edits or restrict specific operations when the issue enters that status. If Marcus can no longer change ticket details after moving the ticket to Signoff then a status property on Signoff is the most likely cause.

Field configuration is incorrect because field configurations control whether fields are required, hidden, or have specific behaviors, and they do not generally lock editing of the entire issue when the status changes.

Transition screen is incorrect because transition screens determine which fields are shown or required during a specific transition, and they do not prevent further edits after the transition completes.

Issue security level is incorrect because issue security levels limit who can view an issue, and they do not by themselves stop a user who can view the issue from editing it.

Project permission scheme is incorrect because project permissions manage who can perform actions across the project, and if Marcus could edit before the status change then a project permission change is not the cause of edit restrictions tied to a specific status.

When an issue becomes non editable after a status change first check the workflow status properties. They often enforce status specific restrictions and are faster to verify than permission schemes or screens.

Users are unable to merge imported user accounts with existing cloud users, Importing a backup file unconditionally replaces every piece of data on the IssueTrack Cloud instance, and Users can only export backups for business managed projects and not for team managed projects are correct.

Users are unable to merge imported user accounts with existing cloud users is correct because cloud user identities are managed separately and an import does not automatically reconcile or merge those accounts. Imported users will typically be created or referenced as distinct identities and any consolidation requires manual mapping or administrative intervention outside the automated import.

Importing a backup file unconditionally replaces every piece of data on the IssueTrack Cloud instance is correct because a full-site restore from a backup is an overwrite operation. The import process does not perform an intelligent merge of all existing issues projects settings and attachments and the restore will replace the current instance state with the backup contents.

Users can only export backups for business managed projects and not for team managed projects is correct because the project export capabilities differ by project type. Business managed projects support the full project export formats that are used for backups while team managed projects do not support the same full project export and typically require other export methods such as CSV for issues.

Generated backup archives are automatically deleted after 18 days is incorrect because there is no universal automatic deletion at exactly 18 days and retention or availability windows vary by product and provider. Backups are generally subject to the platform retention policy and administrators are expected to manage downloaded archives rather than rely on a fixed 18 day deletion rule.

Only site administrators have the ability to run exports and import data in IssueTrack Cloud is incorrect because export and import capabilities are scoped by role and permission and are not limited solely to site administrators. Some project level exports can be performed by project administrators or users with specific product permissions while full site restores require site level administration.

When answering backup and import questions focus on whether the operation is a full site restore or a project export and note which project types are supported and which permission scopes are required.

The correct option is Ethan.

The project default assignee is the project lead Aisha and the components were configured so that the UI component default is Project Lead, the Auth component default is Component Lead, and the Service-X47 component default is Project Default. When multiple components are selected Jira will use the most specific component-level default assignee rule and an explicit Component Lead setting takes precedence over project-level defaults. Because the Auth component is set to assign to its Component Lead the new issue is assigned to Ethan.

Lena is incorrect because the UI component is configured to use the Project Lead as its default assignee rather than the component lead, so UI would route to the project lead not to the component lead.

Sophia is incorrect because Service-X47 is set to Project Default so that component would resolve to the project default assignee, which is Aisha, rather than to the component lead.

Aisha is incorrect because although she is the project default assignee one of the selected components specifically assigns to its Component Lead and that more specific rule overrides the project default, so the issue goes to Ethan.

When multiple components are selected on an exam question look for any component configured to assign to the Component Lead because that setting often takes precedence over project level defaults.

Grant the Account Success team “Schedule issues” project permission is the correct choice.

“Schedule issues” is the project permission that controls the ability to set and change scheduling fields on an issue such as the due date and start date and time estimates. If a team can edit most fields but cannot change the due date then they are missing the “Schedule issues” permission and granting it will allow them to update those scheduling fields without granting broader administrative rights.

Grant the Account Success team “Manage sprints” project permission is incorrect because managing sprints only gives rights to create and edit sprints on Scrum boards and does not control issue due dates or scheduling fields.

Grant the Account Success team “Edit issues” project permission is incorrect because while Edit issues allows editing general issue content it does not grant the specific scheduling controls that the “Schedule issues” permission provides.

Grant the Account Success team “Assign issues” project permission is incorrect because Assign issues only governs the ability to change the assignee field and it does not affect due dates or other scheduling fields.

When an exam question mentions changing a specific field look for a permission with the same action word. The word schedule in a permission name likely maps to due dates and other scheduling fields.

The correct answer is Select List (single choice) and Radio Button.

A Select List (single choice) is a single select dropdown that supports a predefined default and uses custom field contexts so you can provide different option lists per project while keeping the field available across all projects.

A Radio Button field also enforces a single selection and supports a default value and per project contexts, so it meets the requirements when you prefer inline visible choices instead of a dropdown.

Checkbox is a multi select control that allows users to choose more than one option and therefore does not enforce a single selection, so it does not meet the requirement.

Components is a project scoped system field tied to individual projects and it does not function as a single global custom field with configurable per project option contexts, so it does not satisfy the stated needs.

Labels accepts freeform, multi valued tags and does not restrict users to a single predefined option nor provide a predefined default in the way single choice custom fields do, so it is not suitable.

When a question mentions single selection, default option and different option lists per project look for single choice custom field types and verify that the product supports field contexts or per project option sets.

The correct answer is *”Deployment Model” in (“Cloud”,”DataCenter”) AND due >= startOfMonth(+1) AND due = startOfMonth(+1) AND due = for the start and = startOfMonth(+1m)_ option is incorrect because without parentheses the logical operators interact in a way that causes the first equality to be evaluated separately so that all issues with “Cloud” may match regardless of the due date. That yields results outside the intended month.

The (“Deployment Model” = “Cloud” OR “Deployment Model” = “DataCenter”) AND (due = startOfMonth(+1m)) option groups the deployment checks correctly but it uses the +1m suffix in the date functions which is not the standard parameter form used in the documented examples and could lead to a syntax error or unexpected behavior. That makes it less reliable than the version using the documented +1 form.

The “Deployment Model” in (“Cloud”,”DataCenter”) AND (due = startOfMonth(+1)) option is incorrect because the date clause uses OR which is far too permissive. That condition will match dates that are either before the end of next month or after the start of next month and will not restrict issues to only those due during the next month.

The “Deployment Model” in (“Cloud”,”DataCenter”) AND due = startOfMonth(+1m) option looks similar to the correct form but it also uses the nonstandard +1m parameter. Using the documented parameter format ensures the functions behave as expected so this variant is considered incorrect.

When writing JQL pay attention to operator precedence and use parentheses to group logical expressions. Prefer in() for matching multiple values and use documented date functions like startOfMonth(+1) and endOfMonth(+1) to target the next month.

The correct options are priority > High AND createdDate > startOfWeek() AND createdDate < now() and priority = 1 AND createdDate > startOfWeek() AND createdDate < now().

The expression priority > High AND createdDate > startOfWeek() AND createdDate < now() works because the priority comparison returns priorities that rank above High which includes the top priority and because the createdDate range uses the function startOfWeek() as the lower bound and now() as the upper bound so it returns issues from the start of the current week up to the present moment.

The alternative priority = 1 AND createdDate > startOfWeek() AND createdDate < now() is equivalent in many Jira configurations because numeric priority identifiers are often used and 1 commonly represents the highest priority, so the date range logic is the same and it also returns issues from the start of the week through now.

priority = Highest AND createdDate equals startOfWeek() AND createdDate < now() is incorrect because the word equals is not the proper JQL operator for date comparisons and because comparing equality to a function would match only an exact timestamp rather than the desired range.

priority = Highest AND createdDate = startOfWeek() AND createdDate < now() is incorrect because using = against a date function matches only a single instant which will almost never return the intended set of issues created throughout the week.

priority = Highest AND createdDate is startOfWeek() AND createdDate < now() is incorrect because is is not the appropriate operator for date ranges in JQL and it would not express the range from the start of the week to now.

priority = Highest AND createdDate > startOfWeek() AND createdDate > now() is incorrect because it requires createdDate to be after now which excludes all current issues and so it cannot return issues created up to the present moment.

When you need a time range prefer using startOfWeek() and now() with comparison operators rather than equality. Also check whether your Jira instance uses numeric priority IDs when you see expressions like priority = 1.

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

The correct option is The suspended account will still appear in the user directory.

Suspending a user removes their ability to sign in and stops their access to products while keeping their account record intact. The account remains in the site user directory and historical content such as comments and issue history still reference that user.

The suspended user will still be able to sign in to the Confluence site is incorrect because suspension prevents sign in across the site and across products linked to that account. A suspended user cannot authenticate to Confluence or Jira.

Other users can still mention the suspended account with an at sign is incorrect because suspended users are typically excluded from user pickers and mention autocomplete. Users cannot be newly mentioned via the at sign once they are suspended.

The suspended account can still be chosen as an issue assignee is incorrect because suspended users cannot be selected for new assignments. Existing assignments that reference the suspended account remain visible, but you cannot pick a suspended account as an assignee for new or reassigned issues.

When answering these questions focus on the difference between removing access and deleting an account. Remember that suspending revokes access but usually keeps the user record and history visible.

The correct option is {{issue.assignee}}.

Jira automation uses smart values that must be wrapped in double curly braces so {{issue.assignee}} is evaluated at runtime and replaced with the issue’s assignee. You can also reference subfields if needed for a specific property such as {{issue.assignee.displayName}}.

issue.assignee without any braces will be treated as literal text and the automation engine will not substitute the assignee value.

[issue.assignee] uses square brackets and is not valid smart value syntax so it will not be resolved to the assignee.

$issue.assignee with a dollar sign is not the smart value format used by Jira automation and it will remain as plain text.

{issue.assignee} uses only a single pair of curly braces and that is not the correct smart value syntax so it will not be interpreted as the assignee.

When building automation templates always wrap smart value field names in double curly braces and test the rule using the audit log so you can confirm the substitution works as expected.

Evan must update his Jira personal settings Create a custom event Add Evan to the new custom event in the PTM project notification scheme Edit the transition to “AWAITING APPROVAL” so it fires the custom event is correct.

The user must have email notifications enabled in their personal settings or they will not receive project notification emails even when a notification scheme is configured. Creating a custom event and adding Evan to that event in the PTM notification scheme scopes the recipient to a single, project level event. Editing the single transition so it fires the custom event as a post function ensures Evan is notified only when the issue transitions into AWAITING APPROVAL and not for any other workflow activity.

Create a custom event Add Evan to the new custom event in the PTM notification scheme Add a new post function on the transition that fires the new custom event is incorrect because it omits the step for Evan to enable or verify his personal email notification settings. If Evan has turned off email notifications in his profile he still will not receive the alert even when the event and post function are configured.

Identify the event currently fired by the transition to “AWAITING APPROVAL” and add Evan to that event in the PTM notification scheme is incorrect because the event currently fired by that transition is likely a shared workflow event. Adding Evan to a shared event will cause him to receive notifications for every transition that fires that same event, which would not satisfy the requirement to send only a single alert when the issue moves into AWAITING APPROVAL.

Add Evan to the PTM notification scheme for the Issue Updated event so he will receive updates whenever an issue changes is incorrect because the Issue Updated event triggers on many changes and would produce the excessive emails Evan is trying to avoid. That approach cannot restrict notifications to only the transition into AWAITING APPROVAL.

Before changing schemes check that the recipient has email notifications enabled in their profile. Use a custom event plus a workflow post function when you need a single notification tied to one specific transition.

Users must sign in with their Azure AD credentials rather than their Atlassian account is the correct answer.

When a Jira Cloud organization is configured to use Azure AD as the identity provider and Atlassian Access enforces single sign on, Users must sign in with their Azure AD credentials rather than their Atlassian account. Authentication is redirected to the IdP so users who try to use the old Atlassian username and password will be unable to authenticate while users who authenticate via Azure AD will succeed.

Users must be added to the Azure AD group assigned to the organization is incorrect because group membership may control provisioning or access entitlements but it is not the fundamental reason some users cannot sign in. The immediate cause of sign in failure in this scenario is the enforced IdP authentication method rather than missing group membership.

Users must reset their Atlassian account passwords after Atlassian Access is enabled is incorrect because once SSO is enforced authentication is handled by the IdP and Atlassian account passwords are no longer used for sign in. Forcing password resets on Atlassian accounts does not resolve IdP authentication requirements.

Administrators must wait 72 hours for DNS domain verification to finish propagating is incorrect because domain verification does not typically require a fixed 72 hour wait and it would not selectively block only a subset of users from signing in. Domain verification affects ownership confirmation and organization settings rather than whether users must authenticate through the configured IdP.

When an organization points to an IdP assume users must use SSO credentials. If only some users fail to sign in check whether their accounts are properly linked or provisioned to the IdP.

The correct answer is status was not Completed.

The JQL status was not Completed uses the history operator was not to find issues whose status field has never been the value Completed at any point in their change history. This query therefore returns issues that have never been in the Completed state, which matches the question requirement.

resolution is EMPTY is incorrect because it checks whether the current resolution field is empty and it does not inspect the status history. An issue can have no resolution and still have been in Completed, or it can never have been Completed and still have a resolution set.

status was in (“Backlog”, “In Development”) is incorrect because it finds issues that were at some time in Backlog or In Development but it does not exclude issues that were also in Completed at some point. It does not answer whether Completed was ever used.

status != Completed is incorrect because it only filters the current status and will return issues that are not currently Completed. It will return issues that were Completed in the past but have since moved to another status.

resolution != null is incorrect because it tests the resolution field and not the status history. This does not guarantee anything about whether the issue was ever in the Completed status.

When the question cares about what happened at any time in the past look for JQL history operators such as was or was not instead of current state operators.

The correct option is Labels.

Labels act as tag like fields that allow multiple, reusable values to be attached to issues and they are easy to search and filter across tickets. They also allow authorized users to add new entries on the fly which matches the requirement to list software vulnerabilities and reuse the same values across tickets.

Components is not correct because components are project level entities that are typically configured and managed by project administrators rather than used as ad hoc, reusable tags by all team members.

Text Area is not correct because a text area is for freeform, long form input and it does not provide discrete, reusable values that can be consistently selected or searched across many tickets.

Radio is not correct because a radio field forces a single predefined choice and it does not support multiple tag like entries or ad hoc additions by users.

Checkbox is not correct because checkboxes offer selection from a set of predefined options and they do not provide the freeform, reusable tagging experience that labels do.

Cloud Identity is not correct because Cloud Identity is not a standard issue field type and it refers to an identity management product rather than a ticket field for listing vulnerabilities.

When a prompt mentions reusable or tag like values think about a tagging field that supports ad hoc entry and reuse across issues rather than long text or fixed choice fields.

The correct option is Enable the System Attachment setting “Enable zip support” by setting it to ON.

Enable the System Attachment setting “Enable zip support” by setting it to ON turns on Jira’s built in ability to package all attachments for an issue into a single ZIP archive so users can download every file in one action from the issue view. This is a system attachment configuration change that affects the UI and does not require scripting or custom permissions.

Use the Jira REST API to script bulk attachment downloads is technically possible but it is not a configuration change and it requires development work and access to the API rather than enabling a native UI feature. The question asks for a configuration change that lets users download all attachments at once.

Turn on a global setting named “Download all attachments” is incorrect because Jira does not provide a global setting with that exact name. The actual setting to enable the single ZIP download is the attachment zip support option in system settings.

Assign a project permission called “Download all attachments” to every user is wrong because there is no specific project permission by that name. Downloading all attachments is controlled by the attachment system setting and by existing attachment permissions rather than a dedicated project permission.

When a question asks for a simple UI capability look first in the system or administration settings. Check the Attachments configuration for an Enable zip support option to allow a single ZIP download of all issue attachments.

The correct option is Create a team managed project in Jira Software.

A user assigned the Jira Software product role of Users can perform normal product activities and that includes creating team managed projects in Jira Software. Team managed projects are created and managed at the product level and do not require site or organization administration privileges, so a user with product access can Create a team managed project in Jira Software.

Verify organization domains is incorrect because verifying domains is an organization or site administration task and requires organization admin or site admin rights, not a product role in Jira Software.

Grant product access to users for Jira Software is incorrect because granting product access is controlled from the site or organization administration interfaces and requires higher level admin permissions rather than the Jira Software product role of Users.

Add users to site groups is incorrect because managing site groups is a site administration function and is not allowed by a product role alone.

When answering, decide if the action is at the product level or at the site or organization level. Product roles let you act inside the product and not perform site wide administration tasks.

The correct answer is Team members must manually add a status to the project workflow after adding a new column.

Team members must manually add a status to the project workflow after adding a new column is not accurate because in a team managed project the board and workflow are tightly integrated and adding a column will create or map a status automatically. You do not have to separately add a status in the workflow after creating a column on the board.

Issues can be grouped by subtasks is an incorrect choice because it describes a real board capability. Team managed boards let you view and group issues using hierarchy or related task relationships so subtasks can be used as a grouping dimension.

Board users can rename statuses directly from the board is an incorrect choice because it reflects how team managed boards work. Renaming a column on the board updates the associated status name so users can effectively rename statuses from the board interface.

A single column may contain multiple statuses at once is an incorrect choice because it correctly describes board configuration. Boards can map one or more workflow statuses to a single column so a column can represent multiple statuses that are treated equivalently on the board.

Issues can be grouped by assignee is an incorrect choice because it states a standard and available grouping option. Grouping by assignee is a common way to organize work on team managed boards and is supported by the interface.

When answering board configuration questions focus on how columns map to workflow statuses and on common default behaviors. Remember that team managed projects often automatically create or map statuses when you add or rename columns on the board.

Screen scheme association is the correct option.

Screen scheme association controls which screens are used for create, edit and view operations. If the create screen includes the TrainingPortal custom field but the edit screen uses a different screen that does not include that field then the field will appear on create but not on edit. Administrators set screen associations per project and issue type and a mismatched association is the common cause of this behavior.

Issue security level controls which users can view an entire issue or set of issues rather than which fields appear on specific operation screens. It would not normally make a field show on create but hide on edit.

Field configuration scheme defines settings such as required or hidden for fields across projects and issue types. Those settings apply consistently and do not by themselves cause a field to appear on the create screen and be absent on the edit screen for the same issue type.

Project permissions determine what actions users can take in a project such as creating or editing issues. They do not select which specific fields are included on create or edit screens. The screen configuration controls the visible fields.

Global permissions are site wide rights that grant broad capabilities across the instance. They do not control per operation field visibility on screens and are not the reason a field appears on create but not on edit.

When a custom field appears on create but not on edit first check the screen scheme association and then compare the create and edit screens for the project and issue type.

Add Aaron Priya and Elena to the Scrum Team project role in every project and Add the group “mobile team” to the Share dashboards and filters global permission are correct.

The Add Aaron Priya and Elena to the Scrum Team project role in every project option grants the Assign issues permission through the Scrum Team role so the three users can change the assignee across all projects. The permission scheme maps Assign issues to Scrum Team and Administrators, and choosing Scrum Team provides the required project level permission without giving full administrative rights.

The Add the group “mobile team” to the Share dashboards and filters global permission option gives Aaron and Priya the ability to share filters and dashboards globally. Elena already belongs to the administrators group which already has that global permission so adding the mobile team group meets the sharing requirement for all three while keeping global permissions as limited as possible.

Add Aaron Priya and Elena to the Developers project role in every project is incorrect because the Developers role does not grant the Assign issues permission that is needed to change assignees across all projects.

Add the group “jira software users east” to Share dashboards and filters and Manage group filter subscriptions global permissions is incorrect because granting those global permissions to the entire jira software users east group is broader than required and Manage group filter subscriptions is not needed to satisfy the create edit and share filters requirement.

Add Aaron Priya and Elena to the Administrators project role in every project is incorrect because that would give excessive privileges and Administer Project is not required to allow assigning issues or sharing filters.

Global permissions are already sufficient no changes are required is incorrect because Aaron and Priya do not currently have the Share dashboards and filters global permission and the three users are not in the Scrum Team role so they cannot assign issues across all projects under the current configuration.

When you answer check whether a right is granted by a project role or by a global permission and assign the smallest role or group that provides the required capability.

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

The correct option is Condition.

A Condition on a workflow transition determines whether the transition button is shown on the issue view for a particular user. You can add a condition that checks group membership so only members of the directors group will see the ‘Executive Approved’ button.

Validator is wrong because validators run when a user attempts to complete a transition and they validate input or block the transition during submission. Validators do not hide or show the transition button on the view screen.

Issue Security Level is wrong because issue security controls who can view the entire issue rather than which workflow transitions are visible on the screen. Changing issue security would affect issue visibility not the transition button visibility.

Post Function is wrong because post functions execute after a transition completes to perform actions like updating fields or firing events. They cannot prevent or hide the transition button before a user clicks it.

Trigger is wrong because triggers automate transitions in response to external events. Triggers do not control whether a user sees a transition button on the issue view.

When a question asks about hiding or showing a transition button focus on conditions and group or role checks rather than validators, post functions, or triggers.

The correct answers are reporter = Ravi AND summary ~ “\[urgent, critical\]” and reporter = Ravi AND summary ~ “urgent” AND summary ~ “critical”.

reporter = Ravi AND summary ~ “urgent” AND summary ~ “critical” uses two separate text search clauses that each require a word to appear in the summary. Each summary ~ “urgent” and summary ~ “critical” clause matches the given word anywhere in the free text summary and combining them with AND ensures both terms must be present in the same issue.

reporter = Ravi AND summary ~ “\[urgent, critical\]” is correct when the summary contains that exact bracketed phrase. The backslashes escape the brackets so JQL treats the brackets and the comma as literal characters and the quoted string matches that exact sequence in the summary.

reporter = Ravi AND summary in (urgent, critical) is incorrect because the in operator does not perform free text matching on the summary field. The in operator is for fields that have a predefined set of values and it will not search for words inside a free text field.

reporter = Ravi AND summary = “urgent” AND summary = “critical” is incorrect because the equality operator requires the summary to exactly equal a single string and a single summary cannot equal two different exact strings at the same time. Use text search operators when you need to find words inside a field.

reporter = Ravi AND summary ~ (“urgent, critical”) is incorrect because a single quoted string with a comma is treated as one literal phrase and will not match the two words separately or in any order. The comma inside the quotes does not mean both words are matched independently.

reporter = Ravi AND (summary ~ “urgent” OR summary ~ “critical”) is incorrect because OR returns issues that contain either word but not necessarily both. Use AND when both terms must appear.

Use multiple summary ~ clauses joined with AND to require all words to appear in a free text field. Escape brackets or other punctuation when you want to match them literally.

The correct option is Automation rules.

Automation rules must be recreated or imported separately when moving a Jira Cloud site snapshot to another Cloud tenant because automated rules are stored and executed by the Automation service and they are not included in the standard site backup and restore process. This means administrators need to export rules using the automation product features or rebuild them in the target tenant after restoring the snapshot.

Project configuration and workflow schemes are included in the Jira Cloud backup and restore data set so they are carried across when you restore a snapshot into the target tenant and do not require a separate manual import.

Boards and sprint records are part of the project and issue data that the site snapshot captures, so boards and sprint history are restored from the snapshot rather than needing manual import.

User accounts and group memberships are managed at the Atlassian Cloud account and directory level and the snapshot preserves references and membership data for restore. Administrators may need to reconcile accounts if emails differ, but user and group data are not the one-off item that must be manually imported like automation rules.

When a question asks which item must be moved separately, think about services that run outside the core issue and project data. In practice automation rules and many app configurations often require manual export or recreation during migrations.

The correct JQL is text ~ “\\[Profile\\]” AND Priority was “High”.

This query uses the full text search field so it will look through all searchable text fields for the token or the bracketed phrase. The square brackets must be escaped with backslashes so the search matches the literal characters rather than being interpreted as special Lucene syntax.

The use of Priority was “High” ensures the query returns issues that had Priority set to High at any point in the past. Using the = operator would only check the current priority and would miss issues that were High previously.

summary = “[Profile]” AND Priority = “High” is incorrect because the equality operator on summary requires an exact match of the whole field and it only checks the current priority. That will not find issues that merely contain the token or that had High in the past.

text ~ “[Profile]” AND Priority was “High” is incorrect because the square brackets are not escaped. Unescaped brackets are treated as special characters in the underlying search syntax and will not match the literal “[Profile]” reliably.

all ~ “[Profile]” AND Priority was “High” is incorrect because there is no JQL field named all. You must use a valid field such as text or specific fields like summary, description, or comment.

summary ~ “\\[Profile\\]” AND Priority = “High” is incorrect because although the escaped brackets would match the literal in the summary, the query only searches the summary field and it checks the current priority rather than historical values, so it will miss issues that had High in the past or that contain the token outside the summary.

When you need to match literal special characters in JQL remember to escape them with backslashes and use was to query historical values rather than = for current values.

Subtasks will inherit the “Restricted” security level and Marta will not be able to modify their security level. Subtasks inherit the security level from their parent issue so the same restricted access applies to any subtasks created under that parent.

In this case the project has an issue security scheme and the parent issue ACME-42 is set to the “Restricted” level. Subtasks inherit the parent issue security level so they will also be restricted. The security level on those subtasks is not independently editable so Marta cannot change the subtasks to a different level even if she has broader project permissions for other issues.

Subtasks will get the “Standard (default)” security level and Marta will be able to alter their security level is incorrect because subtasks do not revert to the project default when the parent has a restricted level. They inherit the parent level instead.

Subtasks will default to no security level and Marta will be able to set their security level is incorrect because subtasks do not start with no level in this scenario. They inherit the parent issue security level and are not independently adjustable.

Subtasks will get the “Standard (default)” security level and Marta will not be able to alter their security level is incorrect because the issue is not about the ability to edit in this case. The subtasks would not receive the standard default when the parent is restricted.

Subtasks will inherit the “Restricted” security level and Marta will be able to modify their security level is incorrect because even though Marta may have permissions to change security levels on some issues, subtasks inherit the parent level and the security field is not independently changeable for those subtasks.

Subtasks will default to no security level and Marta will not be able to change their security level is incorrect because subtasks inherit the parent security level rather than defaulting to no level.

When you see questions about subtasks and issue security remember that subtasks inherit the parent issue security level. Focus on inheritance and whether a field can be edited on a subtask when you choose the correct answer.

The correct option is Use the bulk Edit issues operation to update the assignee and add a comment to notify them.

Use the bulk Edit issues operation to update the assignee and add a comment to notify them lets Mira change the Assignee field on many issues at once and add a comment that can mention the new user to generate an in context notification. This approach is scalable for a large set of existing issues and it applies immediately so the new assignees see the change on the issue itself.

Create an automation rule to reassign issues and notify the new users is not the best choice because automation usually needs a suitable trigger and configuration to act on existing issues and it can be more complex to ensure it only runs once for a bulk migration.

Add a workflow transition screen that prompts for a new assignee is not correct because a transition screen only runs when an issue is moved through that transition and it requires performing the transition for each issue rather than updating them all at once.

Create a visible announcement banner for all users is not correct because a banner is only a broadcast message and it does not change issue assignees or create issue level notifications for the new owners.

Add a post function to a workflow transition that assigns the ticket to a new user is not correct because a post function only executes when the issue goes through that transition and it will not reassign existing issues unless each issue is transitioned.

For questions about moving many existing issues choose an option that performs a bulk update and creates in context notifications. Look for answers that mention Bulk Edit or bulk change.

The correct options are Restrict custom Resolution field values in project settings and Restrict a workflow transition to members of a group type custom field.

Team-managed projects use simplified project settings and do not provide project-level controls to restrict Resolution field values. The Resolution field and its allowed values are managed at a broader scope and you cannot configure allowed Resolution values from within a team-managed project.

Team-managed projects also provide simplified workflow capabilities and do not support restricting a transition based on membership in a group-type custom field. Conditions that reference group custom fields for transition restrictions require the more advanced controls found in company-managed projects.

Manage releases and versions from the project features is incorrect because team-managed projects include a Releases feature that lets teams create and manage versions and track releases within the project.

Create cascading select custom fields that depend on another field is incorrect because team-managed projects allow creating custom fields and support dependent or cascading field configurations through the simplified field settings available to the project team.

Set a Timestamp custom field to default to the current time is incorrect because the field configuration in team-managed projects supports default values for date and time fields and you can set a timestamp to default to the current time or to a specified value.

When deciding between team-managed and company-managed projects focus on whether you need simplified, per-project controls or advanced, global configuration options. Look for wording that implies project-level restrictions or advanced transition conditions to pick company-managed features.

Paragraph field with rich text enabled is the correct option.

The Paragraph field with rich text enabled provides a rich text editor for its description so authors can apply bold and italic styles and other rich formatting. It is a multi line text type that is explicitly designed to render styled content in descriptions and comments.

Labels are tag style metadata and they do not support rich formatting in their descriptions so you cannot use bold or italic there.

Number Field stores numeric values and its description is plain text only so it does not allow bold or italic formatting.

Select List single choice offers a single choice from options and its description remains plain text so it cannot include bold or italic styling.

Text Field single line is intended for short, single line input and its description does not support rich text formatting.

When a question asks about formatting in field descriptions look for field types that explicitly state rich text or a rich text editor because simple or numeric fields will usually only allow plain text.

The correct option is “Resolve Issues”.

“Resolve Issues” is the permission that allows users to perform resolve transitions and to set resolution related fields that are often shown only on transition or resolution screens. The Fix Version field is commonly updated as part of a resolve workflow step or on screens that require the resolve permission, so requesting “Resolve Issues” lets Leah set the Fix Version where it is restricted to resolution or transition operations.

“Edit Issues” is incorrect because that permission controls general editing via the edit issue operation and Leah already can edit every other field, so lack of “Edit Issues” would prevent broader editing rather than only the Fix Version field.

“Issue Security Level” is incorrect because that permission only affects who can view issues or their security levels and it does not grant rights to change specific fields like Fix Version.

“View Development Tools” is incorrect because that setting only exposes development information such as commits and pull requests and it does not influence the ability to edit issue fields or perform resolve transitions.

When a field is editable only during a workflow transition look at the permissions tied to resolving or transitioning issues. Check the Resolve Issues permission and the transition screens before asking administrators to change permissions.

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

Multiple issues can be added at once to a team managed project and Clearing a parent issue from the board also clears all of its subtasks regardless of each subtask’s status are correct.

The ability to add multiple issues at once is supported in team managed projects through bulk create or import flows and through the simplified issue creation tools that let a team quickly create several issues in one operation. This makes it easier for small teams to populate their backlog without needing shared schemes or complex administration.

The board behavior where clearing a parent also clears its subtasks reflects the simpler, project scoped board rules in team managed projects. The board treats the parent and its subtasks together for visibility on that board so removing or clearing the parent from the view will also remove its subtasks regardless of the individual subtask status.

The issue navigator cannot be enabled for team managed projects is incorrect because issues from team managed projects can be searched and viewed in the global issue navigator and issue search is not blocked for this project type.

Team managed projects support sharing of workflow and field schemes with other projects is incorrect because team managed projects use project specific, non shareable schemes. Workflows and fields in team managed projects are configured inside the project and are not intended to be shared across projects the way company managed schemes are.

You can configure a default issue security level at the project level is incorrect because issue security schemes and project level default security are not provided in team managed projects. Issue security levels are part of shared schemes in company managed projects and are not available in the simplified team managed model.

When you see a question that contrasts team managed and company managed projects focus on whether the feature is project local or shareable and remember that team managed projects keep schemes local and favor simplified board behaviors.

The correct answers are Add a post function to the Closed transition to set the resolution and Use the bulk transition operation so workflow post functions execute for each ticket.

Add a post function to the Closed transition to set the resolution is correct because a workflow post function runs when an issue goes through that transition and it can set the system Resolution field automatically. Adding the post function ensures that every time issues are transitioned to Closed the resolution value is populated by the workflow rather than relying on users to set it manually.

Use the bulk transition operation so workflow post functions execute for each ticket is correct because a bulk transition performs the actual workflow transition for each selected issue and that causes the transition post functions to run. A plain bulk edit or a move will not trigger those transition post functions so they will not populate resolution via the workflow.

Move the tickets to another project with the bulk move operation is incorrect because moving issues to another project does not execute the Closed transition post functions and it will not automatically set resolution on issues that are already closed. The move operation does not trigger the same workflow transition logic that running the Close transition does.

Edit the tickets with a bulk edit to populate the resolution field is incorrect because a bulk edit that simply changes fields does not run workflow transition post functions and it can bypass workflow rules. The Resolution field is often intended to be set during a transition and it may not be available or appropriate for arbitrary bulk edits.

Add the Resolution field to the issue screens so users can fill it manually is incorrect because exposing the field lets users set it manually but it does not ensure the field is set when issues are closed and it allows inconsistent or missing values. The recommended approach is to set resolution during the Close transition with a post function so the value is enforced.

When you need to ensure Resolution is set on close prefer workflow automation. Add a post function to the closing transition and use the bulk transition operation to apply it to many issues so the transition logic and post functions run for each ticket.

The correct answer is Missing Work On Issues permission.

The Work On Issues permission controls whether a user can perform active work on issues in the project and that includes the ability to log work when time tracking is enabled. If Lena lacks the Work On Issues permission she will not see controls to record time even though the issue has an estimated duration.

Missing Edit Own Worklogs permission is not correct because that permission only controls the ability to modify worklog entries that the user has already created and it does not prevent the user from creating new worklogs.

Time tracking disabled in global settings is not correct because if global time tracking were disabled there would generally be no estimated durations or log work interface visible on the issue. The presence of an estimated duration implies time tracking is enabled.

Missing Schedule Issues permission is not correct because that permission governs scheduling fields such as start and due dates and it does not control the ability to log work on an issue.

When you see a question about not being able to record time check project permissions that mention Work or Work On Issues first and use clues like visible estimates to rule out global time tracking being disabled.

Create button and the highlight color for the active navigation item and Background color of the main navigation bar are correct.

These color settings are controlled by the site branding and look and feel options in Jira Cloud which let administrators set the accent color that applies to prominent interactive elements and the header or navigation background that applies to the main nav bar.

Overall Jira application background is incorrect because Jira Cloud does not expose a single global application background color setting in its branding controls in the same way it exposes the accent and header colors.

Link text color is incorrect because link colors are not offered as a separate configurable field in the standard Jira Cloud look and feel options and they typically inherit from the chosen theme and accent styles.

Issue action menu background color is incorrect because the background of specific menus and component-level UI elements is not provided as an individual color control in the main branding settings.

When a question asks about interface color options think about the branding or look and feel settings that apply globally rather than settings for individual components.

Radio button custom field, Status field, and Issue type are correct.

These field types are configurable at the project or scheme level so their labels and option values can be localized. The system stores their names and option entries as configurable metadata which allows different language labels to be shown in a company managed project.

Radio button custom field options are explicit selectable values and those option labels can be translated so users in different language regions see localized choices.

Status field names are part of workflow configuration and can be presented with localized labels so status names appear in the user interface in the chosen language.

Issue type names are part of the issue type scheme and those names can be localized so the same issue type appears with translated labels for different language users.

Priority field is incorrect because priority values are typically global system values and they are not translated per company managed project.

Resolution field is incorrect because resolution is a system level field with a predefined set of outcomes and it is not provided as a per project translatable field.

Issue security level is incorrect because security levels control visibility and are not intended to provide localized option labels per company managed project.

When you see a question about which fields can be translated look for fields whose labels or option values are stored as project or scheme configurable metadata. Fields that are global or system wide are less likely to be translatable.

Some issues have “Issue Security Level” applied and The viewer does not have Browse Projects permission for some of the included projects are correct.

Some issues have “Issue Security Level” applied is correct because issue security schemes limit who can view individual issues even when those issues match the board filter. An issue with a security level that excludes the viewer will not appear on the board for that person.

The viewer does not have Browse Projects permission for some of the included projects is correct because a user must have Browse Projects permission on each project that the board includes in order to see that project’s issues. If the viewer lacks that permission for some projects then those projects’ issues will be hidden from them on the shared Kanban board.

A saved filter or the board subfilter excludes the missing issues is not the best answer in this scenario because although filters and subfilters can exclude issues they would not explain issues disappearing for some viewers while remaining visible to others. The question points to visibility restrictions that affect users differently so permissions and security levels are the likelier causes.

A work in progress limit is set on a board column is incorrect because work in progress limits control how many issues can be placed in a column and they do not remove issues from the board. A WIP limit will not cause issues to be missing from the board view.

When you troubleshoot missing issues check issue security and the viewer’s Browse Projects permissions first. If those are correct then review the board filter and subfilter and remember that WIP limits affect workflow and not visibility.

The correct answer is Add the aud-grp group to the Reviewers project role in the project “SHIFT”.

Adding Add the aud-grp group to the Reviewers project role in the project “SHIFT” gives the aud-grp the Browse Projects permission for that specific project. The Auditors project role already grants Create issues and Edit issues in the shared permission scheme. Once aud-grp has Browse Projects for the SHIFT project they will be able to edit issues there because they will have both the browse and edit permissions within that project.

Add the Auditors project role to the Browse Projects permission is incorrect because changing which role holds Browse Projects in the shared permission scheme would affect every project that uses that scheme. The requirement is to enable editing only for aud-grp in the SHIFT project without changing permissions for other projects.

Add the rev-grp group to the Auditors project role in the project “SHIFT” is incorrect because rev-grp is a different group and adding it to Auditors does not grant aud-grp any additional rights. The problem is that aud-grp lacks the Reviewers role membership in SHIFT.

Set aud-grp as a default member of the Reviewers project role in system configuration is incorrect because making aud-grp a default member applies that membership across all projects. The question asks for a change scoped only to the SHIFT project so a project level role assignment is the right approach.

When a permission scheme is shared prefer adding a group to a project role for a single project to avoid affecting other projects. Project roles are the way to scope permission changes per project.

The correct option is Individual Email Address.

Individual Email Address cannot be added to team-managed project notification settings because team-managed projects only let you choose recipients that are defined inside the product such as users, roles, and groups. Team-managed notification configuration does not accept arbitrary external or freeform email addresses as recipients.

Signed In User is incorrect because team-managed projects allow you to notify users who are signed into the site and who are part of the project.

Project Role is incorrect because roles defined in the project can be selected as notification recipients in team-managed projects.

Project Manager is incorrect because the project manager or project lead role can be used as a recipient in the project notification settings.

When a question contrasts team-managed and company-managed projects focus on whether the setting accepts freeform email addresses or only in-product recipients such as users and roles.

The subscription is configured to send emails even when the filter finds no issues is the correct answer.

The filter subscription is driven by a scheduled job and has a setting that controls whether notifications are sent when the query returns no results. If that option is set to send regardless of results then subscribers will receive an email that contains no issues when the filter finds nothing.

Some members of the governance group lack permission to view the issues returned by the filter is not the best explanation in this case. Permission problems can hide specific issues from individual users but they do not explain why the subscription sometimes sends completely empty notifications for multiple recipients when the subscription itself is configured to always send.

The JQL expression contains a syntax or logical mistake is unlikely because a syntax error would typically prevent the filter from running or would return a predictable result. The reported behavior is intermittent empty emails which matches a sending option rather than invalid JQL.

The query matches more issues than Jira will list in an email causing the notification to appear blank is incorrect because Jira will truncate results but still show information or a summary rather than producing an empty message. A too-large result set would not normally render the notification blank.

When scheduled filter emails are empty check the subscription configuration first and enable Only send when results exist if you want to suppress empty notifications.

Field Configuration of the project “PeopleCare” is correct.

The most likely cause is that the Issue Security field has been hidden or its visibility altered in the project field configuration so the security level is not being set on new issues. When the Issue Security field is hidden by the field configuration the create screen cannot apply the intended security selection and issues may therefore be created without the confidential level and become visible to all users.

Field configurations control whether a field is visible or hidden for a project and this can override what appears on screens. If the Issue Security field is hidden at the field configuration level then the issue security scheme cannot enforce the intended restriction for new issues even though the scheme and permissions are configured correctly.

Issue Type Screen Scheme of the project “PeopleCare” is incorrect because screen schemes only associate screens with issue types and do not by themselves hide a field that has been turned off in the field configuration. A missing field on a screen could be caused by the screen, but the symptom described is more consistent with the field being hidden by configuration.

Issue Security Scheme of the project “PeopleCare” is incorrect because the security scheme and its levels are already defined and mapped. The scheme would not allow everyone to see issues if the security level was actually being applied to new issues as intended.

Global permissions is incorrect because global permissions control broad actions like logging in or creating projects and they do not directly make every newly created issue visible regardless of issue security levels.

Permission Scheme of the project “PeopleCare” is incorrect because the permission scheme shown grants Browse Projects to any logged in user which is expected for the project, but issue visibility is governed by issue security levels and field visibility rather than the project permission scheme.

When issue security seems to be ignored check whether the Issue Security field is hidden in the project field configuration before changing screens or schemes.

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

The correct options are Reporter, Issue type, and Project.

An issue collector can be configured to prefill the Project where feedback issues are created and to set the default Issue type for those submissions. The collector can also capture or populate the Reporter field so the issue records who submitted the feedback when it is created.

Priority is incorrect because the collector does not typically set the issue priority at creation time and priority is usually determined by project workflows or set manually after the issue is created.

Assignee is incorrect because the collector does not automatically assign the issue to a user by default and assignment is normally handled by workflow post functions or automation rules rather than the collector configuration.

When answering configuration questions focus on which fields the tool can predefine at creation time and which fields are applied later by workflows or users. Verify the behavior against the product documentation for the specific Jira deployment you are testing.

Limit available options for a radio button custom field per project and Make a custom field required on issue creation are correct.

The option to Limit available options for a radio button custom field per project is implemented by configuring a custom field context for the field. Custom field contexts allow you to scope which options are available on a per project or per issue type basis and that change only affects the field definition and its option set rather than screens or workflows.

The option to Make a custom field required on issue creation is done through the field configuration or field configuration scheme. Marking a field as required changes its validation and behavior when issues are created or edited and this is a field configuration level change rather than a screen layout change.

Assign differing default values for each issue type within a project for a radio button field is incorrect because setting different defaults per issue type usually requires creating separate contexts or adjusting screen defaults. That means you are not making a simple single field configuration change and you may also be changing contexts or screens to achieve the per issue type defaults.

Remove the priority field from all screens is incorrect because removing a field from screens modifies screen configurations and screen schemes. That action controls where a field appears and not the field configuration itself.

When you decide if a change affects only field configuration ask whether you would edit a custom field context or the field configuration scheme versus editing screens or workflows. Focus on whether the change alters field validation or option sets rather than where the field is displayed.

The correct answer is A newly created backup will replace the existing backup file on the Backup Manager page.

A newly created backup will replace the existing backup file on the Backup Manager page is correct because Jira Cloud presents the most recent site export on the Backup Manager page and initiating a new export overwrites the previously stored backup. You should download or move the export to your own storage if you need to keep multiple historical copies or older snapshots.

Only site administrators can generate backup exports and import Jira Cloud data is incorrect because permissions for exports and imports depend on product and admin roles and are not strictly limited to a single site admin role in every scenario. Jira and cloud admin permissions determine who can perform these actions so the statement is too absolute.

Imported user accounts cannot be merged with existing cloud users during a data import is incorrect because the import process supports mapping imported users to existing cloud accounts so user associations like reporters and assignees can be preserved by mapping to current users.

Team managed projects are excluded from backups and cannot be restored from a backup file is incorrect because team managed projects are included in Jira Cloud site backups and can be restored from an XML site export subject to the usual import limitations for attachments and app data.

When you create a Jira Cloud site export make sure to download the file immediately because the Backup Manager retains only the latest export which will be replaced by a new one.

The correct answer is Edit restrictions are applied through a transition property.

This statement is false because edit restrictions are normally enforced by the project permission scheme and by issue security levels rather than by a transition property. Transition properties can control certain transition behaviours but they are not the standard mechanism for applying broad edit restrictions across issues.

The workflow contains a condition that prevents the status transition is not the false statement because a workflow condition can indeed stop a transition from occurring for certain issues or users and that will cause bulk updates to fail on the affected issues.

A validator on the transition is blocking the status change is not the false statement because validators run during a transition and will block the transition if required data or rules are not satisfied, which can cause bulk transitions to fail.

The user does not have the Transition Issues project permission is not the false statement because lacking the Transition Issues permission will prevent a user from moving issues and will cause bulk transitions to fail for issues where the permission is required.

The user is not a member of the required group for this operation is not the false statement because group membership can be required by conditions or by permission schemes and will therefore block the transition for users who are not in the required group.

When you see questions about failed transitions map each option to Jira concepts such as conditions, validators, permissions, and issue security. Give extra weight to permissions and security levels when the question mentions edit rights.

The correct option is Limited.

Limited access allows anyone who can sign in to the Jira site to search for, view, and comment on issues while limiting issue creation and editing to users who are explicitly added to the project. This matches the requirement that site users can see and comment but only project members can create or modify issues.

Restricted is incorrect because restricted projects block access to most site users and typically allow only explicitly added users or admins to view and interact with issues, so it does not let anyone who can sign in search and comment.

Personal is incorrect because personal projects are intended for individual use and do not expose issues to all site users for searching and commenting.

Private is incorrect because private projects require explicit membership for viewing and commenting, so they do not permit all site users to search for and comment on issues.

When answering access level questions focus on whether the setting grants rights to all site users or only to project members. Match the wording about viewing and commenting separately from creating and editing.

The correct answers are Users can revert any bulk edit they perform and Bulk edit can set the resolution field directly for multiple issues.

The statement Users can revert any bulk edit they perform is not true because bulk change operations do not provide a single undo button. Changes made by a bulk edit are committed and you must run additional bulk operations, use automation or restore from backups to reverse them. The issue history and audit log record the changes but they do not automatically revert the edits.

The statement Bulk edit can set the resolution field directly for multiple issues is not true because the Resolution field is normally set by workflow transitions rather than by the plain Edit bulk action. To set resolution for many issues you typically perform a bulk Transition that sets the resolution or use automation, scripting, or apps that explicitly allow changing resolution in bulk.

The Transition Issues project permission is required to change an issue status is not a valid choice because that statement is actually correct. Project participants need the Transition Issues permission to perform transitions and change an issue status.

You can change an issue type using either the Edit Issues action or the Move Issues action is not a valid choice because that statement is correct in practice. You can edit the Issue Type field when it is available on the edit screen and you can also use Move Issues to change type when moving between projects or when scheme restrictions apply.

The Edit Issues bulk operation can modify custom field values is not a valid choice because that statement is correct. The Edit Issues bulk operation can update custom fields that are present on the edit screen and are applicable to the selected issue types.

Read each statement literally and match it to product behavior. Remember that bulk change has no single undo and that resolution is usually set through workflow transitions rather than the plain Edit bulk action.

The correct options are Description and Summary.

Description is the main free text field that holds the full issue details and it is considered a core content field so it cannot be removed from the Description fields section.

Summary is the short, required title for the issue and it is mandatory for issue identification so it also cannot be removed from the Description fields section.

Issue Type is not correct because it can be moved to the context fields or adjusted in the project layout and is not an immutable Description field.

Status is not correct because workflow status is part of the issue metadata and can be shown outside the Description fields section.

Priority is not correct because priority is a contextual metadata field and can be removed from the Description fields area.

Assignee is not correct because the assignee field is part of the issue context and can be relocated outside the Description fields section.

Focus on which fields are required for the issue content and identity and remember that Summary and Description are core and cannot be removed.

Grant the project permission “Manage watchers” is correct. Manage watchers is the project permission that controls who can add or remove users from an issue’s watcher list and you must have that permission at the project level to update the watcher list.

Enable the global setting “Allow users to watch issues” is incorrect. That global setting only enables or disables the watching feature across the site and it does not grant the ability to modify a specific issue’s watcher list when the project permission is missing.

Grant the global permission “Browse users and groups” is incorrect. Browsing users and groups only lets users search for and view user or group accounts and it does not allow adding or removing watchers on issues.

Grant the project permission “View voters and watchers” is incorrect. That permission only allows users to see the list of voters and watchers and it does not permit editing or managing the watcher list.

When a task requires changing who can do something look for permissions with manage or edit in the name and remember that view permissions usually only allow reading.

The correct options are Different users should be able to delete issues, Each project should have its own outgoing email address for notifications, and A shared custom field must present a different option set depending on the project.

The reason Different users should be able to delete issues can be satisfied while sharing a permission scheme is that the scheme can grant delete permissions to project roles or groups rather than to individual users. You can use the same permission scheme for both projects and then assign different people to the relevant project roles so each project ends up with a different set of users who can delete issues.

The requirement Each project should have its own outgoing email address for notifications does not force a separate notification scheme because the notification scheme controls who gets notified rather than the mail sender address. The outgoing or project email address is configured outside of the notification scheme so you can reuse the same notification scheme and still configure different outgoing addresses at the project level or via project specific mail settings.

The requirement A shared custom field must present a different option set depending on the project is supported by custom field contexts. You can create a single custom field and then define separate contexts or option lists that are scoped to each project so the same field appears with different choice sets in each project.

The default issue security level must differ between the projects is not something you can satisfy while sharing the same issue security scheme. Default security levels are defined as part of the issue security scheme usage, so if each project needs a different default you must use separate issue security schemes or change the scheme mapping per project.

The priority field must show a different list of choices in each project is not possible because priorities are a global system concept in Jira. The priority list is managed globally and cannot be scoped per project, so you would need a custom field to provide project specific priority choices.

When deciding which schemes to share, check whether the setting uses project roles or custom field contexts because those let you reuse schemes while keeping per project differences.

No default reporter is set in the mail handler configuration is correct.

This is the most likely cause because the mail handler is clearly working for other clients so the handler and mailbox are functioning. When an incoming message arrives from an email address that is not mapped to a Jira user the mail handler requires a fallback reporter to assign the new issue. If no default reporter is configured the handler will skip creating an issue for that sender even though it processes messages from addresses that are mapped to users.

Setting a default reporter or adding the customer email as a Jira user will allow their messages to create issues. Check the handler configuration for the default reporter field and send a test email from the customer address to confirm.

The mail handler has been removed or disabled is incorrect because other clients are still generating issues. If the handler had been removed or disabled it would not be processing any incoming mail.

The issue type referenced by the handler was deleted from the target project is incorrect because that would typically cause errors for all processed emails or prevent issue creation across the board. It does not explain why some clients still create issues.

The handler is pointing to a different mailbox so the inbox checked is empty is incorrect because other clients messages are producing issues which shows the handler is reading the intended mailbox. If the mailbox were empty no issues would be created for any sender.

When troubleshooting incoming mail handlers verify the handler is enabled and then confirm whether the sender maps to a Jira user and whether a default reporter is configured so unknown addresses can still create issues.

The correct options are ‘Assign Issues’ project permission, ‘Browse Projects’ project permission, and Access to the relevant issue security levels.

Maya needs the ‘Assign Issues’ project permission so she can change the assignee on tickets. If she lacks this permission she may see issues but she will not be able to assign them to engineers.

The ‘Browse Projects’ project permission is required for her personal filter subscription to return issues from that project. If she cannot browse the project the subscription will not show the project issues in her morning review.

Access to the relevant issue security levels is necessary because issue security schemes can restrict who can see particular issues. She must have the appropriate security level access to both view those issues in the subscription and to assign them.

The ‘Assignable Issues’ project permission is incorrect because Jira does not use that exact permission name and it is likely a confusion with the real ‘Assign Issues’ project permission.

The ‘Manage group filter subscriptions’ global permission is incorrect because that permission controls creating or editing group subscriptions rather than a user creating a personal filter subscription and being able to assign issues.

When you answer permissions questions verify that the user can both see and act on the issues. Check Browse Projects and issue security first and then confirm assignment permissions.

The correct answers are Any user who currently has an issue assigned to them and Members of the engineers group who are assigned issues in the Platform project and have access to that project.

The clause Any user who currently has an issue assigned to them is selected because the JQL contains assignee=currentUser(). When the filter subscription runs for a broad recipient set the currentUser function is evaluated for each recipient. Any recipient who is the assignee on at least one issue will match that part of the query and receive the email.

The clause Members of the engineers group who are assigned issues in the Platform project and have access to that project is selected because the JQL also includes project = “Platform” AND assignee = membersOf(“engineers”). That portion only matches engineers who are assigned to issues in the Platform project and who have permission to receive the subscription.

All users who can access the Platform project is wrong because the query does not select every user with project access. The project filter is combined with assignee = membersOf(“engineers”) which restricts recipients to engineers who are assignees.

All users who have access to the site is wrong because a broad recipient list does not bypass the JQL. Each recipient must match the query either by being the assignee on an issue or by being an engineers member assigned in the Platform project.

All members of the engineers group regardless of whether they are assigned issues is wrong because the membersOf function is coupled with assignee and project. Engineers who are not assigned issues in Platform will not satisfy the query and will not receive the subscription.

Remember that currentUser() is evaluated for each recipient when a subscription targets many users. Read the JQL carefully to see which clauses require assignment or project membership and which apply to the recipient.

Condition and Validator are correct.

A Condition is applied to a workflow transition to prevent the transition action from appearing or being available unless the user meets the specified criteria such as membership in the InfoSec group. This stops users from even seeing or attempting the transition when they are not authorized.

A Validator runs when a transition is executed and enforces rules at runtime by rejecting the transition if the user does not meet the required checks. Using a validator ensures that even if the transition is triggered by an API or an unexpected route the membership requirement is still enforced.

Permission Scheme is incorrect because permission schemes control broad project level permissions like who can browse or edit issues and they do not restrict individual workflow transitions.

Issue Security Level is incorrect because issue security controls who can view an issue and it does not control who is allowed to move issues through workflow statuses.

Post Function is incorrect because post functions perform actions after a transition has completed and they cannot prevent a transition from occurring or validate the user before the transition runs.

When you need to restrict who can perform a transition use Conditions to hide or disable the transition and use Validators to enforce the rule at runtime so the restriction cannot be bypassed.

The correct options are Automation rules that refer to the original status name require edits, Saved issue filters that reference the previous status must be updated, and Boards and dashboards that rely on those filters must be updated.

Automation rules that refer to the original status name require edits is correct because automations often match the status by its exact label and any condition or action that references the old name will no longer behave as expected. You should update the rule conditions or actions to use the new label or the underlying status identifier so the automations continue to run.

Saved issue filters that reference the previous status must be updated is correct because many saved searches and JQL queries explicitly use the status name. When the label changes the queries that reference the old text will return different results or no results until they are updated to the new name.

Boards and dashboards that rely on those filters must be updated is correct because boards and dashboard gadgets often use saved filters to display issues. If those filters still point at the old status name the board and gadget views will not reflect the renamed status until the underlying filters or gadgets are adjusted.

You must run a manual reindex for the cloud instance is incorrect because a manual reindex is not usually required for a status label change in cloud products. The platform updates indexes and mappings automatically for simple label edits so a full manual reindex is not needed in most cloud cases.

All built in reports will automatically update to the new status without any changes is incorrect because not every report or gadget references status labels in the same way. Some reports rely on saved filters or exact status names and those will need review, so you cannot assume every built in report will update correctly without any work.

You must update the workflow scheme to reflect the new status label is incorrect because workflow schemes and transitions are tied to status identifiers rather than the displayed label. Renaming the label does not change the workflow scheme configuration so the scheme itself does not need to be updated for a simple label change.

When a status label is renamed check your automation rules, saved filters, and boards and dashboards because these components commonly reference the exact status name and are the most likely to need updates.

Changing the name of the status “Done” in the workflow used by the project “CAS” will have an impact in all company-managed projects only.

Changing the name of the status “Done” in the workflow used by the project “CAS” will have an impact in all company-managed projects only is correct because the project CAS is company-managed and it shares its workflow configuration with every other company-managed project. When you change a status name in a shared company-managed workflow that change is applied to all projects that use that shared workflow. Team-managed projects use their own project-scoped workflows and are not affected by changes to company-managed shared workflows.

Renaming the status “Done” in the workflow for project “ORB” will only affect that team-managed project is incorrect because the question context highlights shared configurations and the safe conclusion is about changes to the shared company-managed workflow. Team-managed projects do have local configuration but this option does not address the shared company-managed scope described in the question.

Renaming the status “Done” in the workflow for project “ORB” will propagate to both team-managed and company-managed projects is incorrect because a change made inside a team-managed project does not propagate to company-managed projects. Team-managed workflows are project scoped and are not used to update company-managed project configurations.

Changing the status name “Done” in the workflow for project “CAS” will impact every team-managed project is incorrect because CAS is company-managed and its shared workflow only affects other company-managed projects. Team-managed projects maintain separate, project-level workflows so they are not impacted by changes to company-managed shared workflows.

Renaming the status “Done” in the workflow for project “CAS” will affect all company-managed projects and all team-managed projects is incorrect because while the change will affect company-managed projects that use the shared workflow it will not reach team-managed projects which keep independent workflow configurations.

Only site administrators can rename statuses at the global level through the administration console is incorrect because renaming or managing statuses depends on Jira administration permissions and on whether the workflow is company-managed or team-managed. Project-level administrators can change project-scoped statuses in team-managed projects and Jira administrators manage global workflow elements for company-managed projects, so it is not solely a site administrator action in all cases.

When you see wording about shared configuration think “company-managed”. Company-managed workflows are shared across projects while team-managed workflows stay local to the project.

Accounts with any verified email address from a nonpublic domain may be granted product access is the correct statement.

This statement is correct because NovaAccess is designed to grant product access based on the presence of a verified email from a nonpublic domain, so administrators can allow accounts that present such verified addresses to access the product without requiring every domain to be preapproved.

An organization domain must be approved before NovaAccess can be enabled is incorrect because domain approval is not necessarily a prerequisite for enabling or using NovaAccess when access can be granted to accounts with verified nonpublic email addresses.

Invitation links remain valid indefinitely while they are enabled is incorrect because invitation links are typically subject to expiration or can be revoked and are not guaranteed to remain valid indefinitely even if they are enabled.

The two methods to approve a domain are HTTPS validation and DNS records is incorrect because domain verification methods vary and commonly include different approaches such as DNS TXT records or file based HTTP verification rather than the exact pair stated.

Existing users can only invite people who share the same organization domain to join a product is incorrect because invitations can be extended to accounts with verified emails from other nonpublic domains when policies and settings permit it.

Read each option for absolute wording and key terms and focus on what the system accepts as a verified identity. Verified email and nonpublic domain are the critical phrases to watch for.