ACP-120 Jira Certification Practice Tests on all Exam topics

Orion Solutions manages a company project named “Atlas” and the project permission scheme and issue security tiers are configured in this way. Any logged in user can Browse Projects. The Set issue security permission is granted to the Project Role “Developers”. Any logged in user can Edit issues. The security tiers are defined as Tier1 default which includes Reporter Assignee and Project Role “Developers”. Tier2 includes Reporter Assignee Project Role “Developers” and Project Role “Analysts”. Tier3 includes Reporter Project Role “Analysts” and Project Role “Compliance”. Tier4 includes Project Role “Compliance” Project Role “Developers” and the single user “alex”. Which statement is correct?

• ❏ A. Newly created issues will be visible to all members of the Atlas project role Analysts

• ❏ B. Every member of the Atlas project role Developers can assign any security tier to an issue

• ❏ C. Members of the Atlas project role Analysts can view issues across three security tiers

• ❏ D. Members of the Atlas project role Analysts can change an issue from Tier2 to Tier3

• ❏ E. The individual user alex will be restricted to viewing issues in a single security tier

When a development group rearranges parent tasks on their Scrum backlog how do the child sub-tasks behave and which statements about sub-task ordering are accurate? (Choose 2)

• ❏ A. Child sub-tasks move together with their parent issue when the parent is reordered

• ❏ B. All child items must be arranged before the parent task can be moved

• ❏ C. Individual sub-tasks can be reordered relative to other sub-tasks under the same parent

• ❏ D. Sub-tasks always keep a ranking value that is different from their parent

Leah must satisfy several needs. She needs a way to group issues across multiple company managed projects. She also needs to quickly view the total number of issues and the number completed for each group without adding extra reporting or gadgets. She needs to be able to bulk edit every issue within a group with minimal effort. Which configuration element satisfies all of these requirements?

• ❏ A. Filters

• ❏ B. Components

• ❏ C. Boards

• ❏ D. Releases

• ❏ E. Epics

Which user interface elements can be recoloured using the global Look and Feel settings in a project management instance? (Choose 2)

• ❏ A. The background colour of the project sidebar

• ❏ B. The colour palette applied to every button across the application

• ❏ C. The background colour of the primary navigation bar

• ❏ D. The background colour of the issue detail view

• ❏ E. The colour of the create issue button and the highlight used for the currently selected navigation item

After a recent configuration update at Northbridge Labs some team members report that the “Comment” field no longer appears on transition screens in a company-managed project while other users still see it. What configuration change most likely caused this behavior?

• ❏ A. Introduced a workflow condition that restricts who can perform the transition

• ❏ B. Modified a post function on the transition

• ❏ C. Detached or removed the transition screen

• ❏ D. Revoked the project Add Comments permission for affected users

• ❏ E. Added a workflow validator that checks transition input

What configuration allows users whose email addresses end with @example.com to request access automatically to a Jira Cloud site?

• ❏ A. Enable invitation links for the site

• ❏ B. Add example.com to approved domains and require admin approval for access

• ❏ C. Configure Google Workspace SAML single sign on for example.com

Maya at Skylark Systems changed a company managed project key from NVT to RPL. Which statement about links reports saved filters and Confluence issue macros is correct?

• ❏ A. Users must edit their saved filters to use the new project key

• ❏ B. Some dashboards and reports will display errors

• ❏ C. URLs that contain the previous project key will redirect to the new project key

• ❏ D. A new project can be created using the previous project key

• ❏ E. You must manually update Confluence Jira issue macros to reference the new key

Ravi is the Jira administrator for the site scrumtuous.atlassian.net and he created a new company managed project called ASSET with custom settings and user access. After three weeks the project lead Maria asked Ravi to enable issue creation from inbound email. Ravi configured the Default Cloud Mail Server with the email address [email protected] and added a mail handler using the type “Create a new issue from each email message”. He set the handler to use the ASSET project and set the issue type to Task while selecting a default reporter. A test email created an issue successfully but after several days Maria reported that some incoming emails created issues as expected while others did not and she did not receive notifications for the ones that were not created. There is only a single incoming mail server and a single mail handler configured on the site. What best explains this behavior?

• ❏ A. The mail handler is set to add comments to matching issues instead of creating new issues

• ❏ B. The default reporter account does not have the “Create issues” project permission

• ❏ C. Some emails are ignored because they do not reference any issue key

• ❏ D. The mail handler has the Notify Users option turned off

Marisol needs to set the resolution field for every issue marked resolved since the start of the current quarter and after she applied the filters she cannot find the “Bulk change” button. Why is the button not visible?

• ❏ A. Marisol is not a Jira administrator

• ❏ B. Marisol does not have the “Resolve issue” project permission and she also lacks the “Make bulk changes” global permission

• ❏ C. Marisol does not have the “Make bulk changes” global permission

• ❏ D. Marisol does not have the “Edit issue” project permission and she also lacks the “Make bulk changes” global permission

• ❏ E. The filter returned more issues than the instance maximum for bulk operations so the Bulk change button is suppressed

A regional bank called Meridian Ledger uses a company managed project named “FINX” that has an issue security scheme intended to limit issue visibility to members of the “Compliance Team” and the “Compliance Managers” project roles. Hannah reports that she can open an issue she filed even though she is not part of either project role in project “FINX”. What is the most likely reason she can see the issue?

• ❏ A. Hannah is a member of the “atlassian-addons-project-access” project role

• ❏ B. Hannah holds the Administrators project role in project “FINX”

• ❏ C. Hannah is the site administrator for the cloud instance

• ❏ D. No default issue security level is configured for the project security scheme

• ❏ E. Hannah does not have the Set issue security project permission

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

In what situations is it preferable to use a project component instead of adding a global custom field in a Jira Cloud project? (Choose 2)

• ❏ A. The field must be usable across many projects site wide

• ❏ B. You want the issue assignee to be set automatically based on the selected component

• ❏ C. You need a single picklist value to support cross project reporting and filters

• ❏ D. The configuration should be maintained by the project administrator rather than a site administrator

Which configuration actions are not supported in team-managed projects when configuring issue types and workflows? (Choose 2)

• ❏ A. Insert a screen transition into a workflow

• ❏ B. Manage project roles

• ❏ C. Add the “Affects versions” field to an issue type’s field list

• ❏ D. Add the “Fix versions” field to an issue type’s field list

Which of the following statements about filter subscriptions are incorrect? (Choose 3)

• ❏ A. Recipients may receive different issue details from the same filter subscription

• ❏ B. Users can select a project role to receive the subscription email

• ❏ C. You can configure a Jira group as an email recipient for a subscription

• ❏ D. Creating any filter subscription requires the Manage group filter subscriptions global permission

• ❏ E. A filter subscription will never send an email when the query returns zero results

Sofia from Solstice Apps is auditing product access for Jira Software and she observes the groups with their sizes and which ones are defaults. The companyadmins group has 2 members and it is not a default group. The devomega group has 18 members and it is marked as a default group. The trackerteam group has 12 members and it is marked as a default group. The hrstaff group has 6 members and it is not a default group. Sofia then grants Jira Software access to Alex with a “User” product role. Which statement is definitely true?

• ❏ A. Alex will be added to three groups

• ❏ B. Alex will not be added to any existing groups and will still have Jira Software access

• ❏ C. Alex will become a company administrator

• ❏ D. Alex will be added to two groups

• ❏ E. Alex will be added to four groups

Which capability can only be implemented in a company-managed project rather than in a team-managed project?

• ❏ A. Automatically assign an issue during a workflow transition

• ❏ B. Configure notifications to be sent to the selected component lead

• ❏ C. Send notifications to the project lead

• ❏ D. Change the project key

• ❏ E. Enable or disable the Versions page in project navigation

Amira is the Jira administrator and also the project administrator for the company-managed project “HELPDESK” which is used by sales staff developers and QA analysts. The “HELPDESK” project shares its configuration with several other company-managed projects. The sales staff report that they are missing particular email alerts and they provided Amira a list of events for which they must receive notifications. Developers and QA analysts want their existing email notifications to remain unchanged. What is the best approach for Amira to satisfy all parties?

• ❏ A. Create a shared group for the sales staff and add that group to the requested events in the “HELPDESK” notification scheme

• ❏ B. Add each sales staff member individually to the requested events in the “HELPDESK” notification scheme

• ❏ C. Create a new project role add sales staff to that role within the “HELPDESK” project and then include that role for the requested events in the project notification scheme

• ❏ D. Create a project role and make sales staff default members of that role then add the role to the requested events in the “HELPDESK” notification scheme

An excerpt from the permission matrix for the “ORBIT” project lists which project roles hold which permissions. The only global permission assigned is Administer Jira and all other global permissions are empty. Users in the group orbit_team_group must be able to log work and edit issues and also create and share filters. Which two actions together will provide these rights? (Choose 2)

• ❏ A. Add orbit_team_group to Project Role “Developers”

• ❏ B. Add orbit_team_group to Share dashboards and filters global permission

• ❏ C. Add orbit_team_group to Project Role “Analysts”

• ❏ D. Add orbit_team_group to Manage group filter subscriptions global permission

• ❏ E. Add orbit_team_group to Project Role “Scrum Team”

• ❏ F. Add the Project Role “Analysts” to Share dashboards and filters global permission

Which configuration should you change to set a different default option for a custom field in a single company managed project?

• ❏ A. Screen schemes

• ❏ B. Custom field context configuration

• ❏ C. Field configuration scheme

Maya verified she enabled “You are watching this issue” in her account preferences and she stopped receiving email notices when her project team updates issues. Which Jira configuration should she inspect?

• ❏ A. Mail Handler

• ❏ B. Outgoing Mail

• ❏ C. SMTP Mail Server

• ❏ D. Personal Settings

• ❏ E. Global Mail Settings

Maya’s group at HarborCloud needs a new Jira Software project. The group will plan work in weekly sprints and they want the board to group issues by assignee and to show the “due date” on all cards in the board. What type of project meets all of these requirements?

• ❏ A. Team-managed Kanban

• ❏ B. Team-managed Scrum

• ❏ C. Company-managed Scrum

• ❏ D. Company-managed Kanban

Lina must remove a managed user account for Carlos from her organization’s cloud tenancy. Which of the following statements are false? (Choose 2)

• ❏ A. Carlos’s account can be restored at any later time if required

• ❏ B. Content created by Carlos will remain and will not be removed

• ❏ C. Other users will still see Carlos’s username after his account has been deleted

• ❏ D. All personal information in Carlos’s managed account will be erased

• ❏ E. Carlos’s deletion can be undone during a 30 day grace period

Maya at Altair Systems is configuring an issue collector for a new project and she plans to include Summary Description Priority Due Date Components Attachments and Environment fields on the form. Which of these fields cannot be added to an issue collector?

• ❏ A. Components

• ❏ B. Description

• ❏ C. Attachments

• ❏ D. Due Date

• ❏ E. Priority

• ❏ F. Environment

• ❏ G. Summary

The custom field “Team Seniority” is shared across all company-managed projects at Solveta and Laura oversees one company-managed project that needs a unique set of choices for that field. Which configuration must she modify?

• ❏ A. Issue layout

• ❏ B. Permission scheme

• ❏ C. Custom field context

• ❏ D. Screen scheme

Return issues assigned to Sam or Maya that were created on or after Monday of the current week?

• ❏ A. assignee = Sam OR assignee = Maya AND created > startOfWeek(“Monday”)

• ❏ B. (assignee in (Sam, Maya)) AND created >= startOfWeek(“Monday”)

• ❏ C. assignee in (Sam, Maya) AND created > startOfWeek(“+1d”)

A few days ago Leah attached two important PDF files to ticket INC-789 that she is handling at Finora Labs and suddenly the attached files disappeared from INC-789 and Leah cannot attach them again, what are two plausible causes? (Choose 2)

• ❏ A. Site attachment storage quota has been exceeded

• ❏ B. Attachments have been disabled across the Jira site

• ❏ C. “Create attachments” project permission was revoked for Leah

• ❏ D. “Browse projects” project permission was revoked for Leah

• ❏ E. “Edit issues” project permission was revoked for Leah

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

Sophia manages the marketing operations team at HarborBank and she built a saved filter with the JQL Manager in membersOf(“marc-managers”) and project = MARCOM. She then shared the filter with every role in the MARCOM project and added a subscription that sends the filter results to the group “marc-escalate” whose members can view all MARCOM issues. Which issues will the subscription include and send to the “marc-escalate” group?

• ❏ A. Issues in project MARCOM where the group “marc-escalate” is entered in the Manager custom field

• ❏ B. Issues in project MARCOM where the user shown in the Manager custom field is a member of the “marc-managers” group

• ❏ C. Issues in project MARCOM where the group “marc-managers” is stored in the Manager custom field

• ❏ D. Issues in project MARCOM where Sophia is listed as the Manager in the custom field

Marta cannot see the Pending Review transition on the Issue details screen while her teammates can. What are the possible reasons? (Choose 3)

• ❏ A. She lacks Browse issues project permission

• ❏ B. She is missing the Transition issues project permission

• ❏ C. A workflow validator requires changes

• ❏ D. A workflow condition is blocking the transition for her

• ❏ E. She is not a member of the group or project role that has the permission

Ravi needs to set up a Jira project at EmberSoft to consolidate incident tickets and development work coming from the SRE group and he needs to decide which project type and template to use. His requirements include the ability to prioritize tasks each day on a Kanban board and the ability to work in timeboxed cycles with variable length and he needs project administrators to be able to clear the board’s last column on demand. The project must meet these needs immediately after creation without enabling extra features. Which project type and template should he create?

• ❏ A. Company-managed project with Bug tracking template

• ❏ B. Team-managed project with Bug tracking template

• ❏ C. Company-managed project with Kanban template

• ❏ D. Team-managed project with Kanban template

• ❏ E. Company-managed project with Scrum template

Ava is the team facilitator and the board administrator for a company managed Kanban board in the project “NOVA”. She notices issues stacking in the rightmost column and wants to release a new version. The project permission scheme shows the project permission “Administer projects” granted to the group atlassian_addons_project_access. The permissions Browse projects Edit issues and Resolve issues are granted to Any logged in user. No project roles are assigned in the “NOVA” project. Which statement is definitely true?

• ❏ A. Being the board administrator is sufficient to release a version from the Kanban board

• ❏ B. She must be assigned as the project lead to perform a release from the Kanban board

• ❏ C. She will be able to release a new version from the Kanban board without additional permissions

• ❏ D. She must have the “Administer projects” project permission to release a new project version from the Kanban board

Which schemes in Jira Cloud are not associated with specific issue types? (Choose 3)

• ❏ A. Workflow schemes

• ❏ B. Notification schemes

• ❏ C. Issue security schemes

• ❏ D. Permission schemes

Maya manages two Jira Cloud instances for a regional design agency and she needs to combine them into a single Jira Cloud instance. Which statement about Maya’s requirement is correct?

• ❏ A. Create site backups for both instances and restore them into a new Cloud instance

• ❏ B. You cannot merge two Jira Cloud instances into one using only site backup files

• ❏ C. Create a backup of one instance and restore it over the other instance

• ❏ D. Use the Jira Cloud Migration Assistant or perform a cloud to cloud migration

• ❏ E. Export issues from one instance and import them into the other using CSV

Amelia created a team managed Kanban project named FLX and she set it to limited access. She added users and she accidentally restricted the Story issue type so only the project role Administrator could view it. No other project configuration was changed and after a few days people reported they could not see Stories they created. Amelia then updated the Story issue type restriction and added the project role Viewer. Which statement is true?

• ❏ A. Users who hold the project role ‘Member’ in the FLX project will be able to access all stories

• ❏ B. Users who hold the project role ‘Viewer’ in the FLX project will be able to access all stories

• ❏ C. Users who hold the project role ‘Member’ in the FLX project will be able to access only stories they create after Amelia updated the restriction

• ❏ D. Members assigned the project role ‘Viewer’ in the FLX project will have access only to stories created after Amelia changed the restriction

Which statements accurately describe how issue statuses behave on a team-managed board in a scrumtuous.com project? (Choose 2)

• ❏ A. After you add a status in the workflow you must manually place it on the board or it will not be visible

• ❏ B. Adding a new column with a unique name on the board automatically creates a corresponding status

• ❏ C. Only a Jira global administrator can add new statuses for a team-managed project

• ❏ D. Creating a new status in the project workflow will automatically add a new column to the board

Maya set up a subscription from one of her saved filters in the issue tracker and she received notification emails from that subscription last week but she does not receive any emails from it today. Which of the following would not explain why she stopped receiving the notifications?

• ❏ A. The saved filter yields no results

• ❏ B. Someone removed Maya from a user group

• ❏ C. Project permissions were changed

• ❏ D. All of the listed reasons could cause the problem

• ❏ E. Someone removed Maya from a project role

A product team at Meridian Labs manages a company project and they want an automation so that when a new issue is created and it is linked to a parent epic the new issue receives the parent epic’s due date?

• ❏ A. Trigger When an issue is created Condition Issue type equals Epic Action Edit issue fields “Due Date”

• ❏ B. Trigger When an issue is created and associated to an epic Action Edit issue fields “Due Date”

• ❏ C. Trigger When an issue is created Branch rule For parent epic Action Edit issue fields “Due Date”

• ❏ D. Trigger When an issue is created Condition If an epic exists Action Edit issue fields “Due Date”

When global permissions remain at their default values, which project configuration tasks can a project administrator not perform? (Choose 2)

• ❏ A. Create components

• ❏ B. Show due date on every screen and in all issue layouts

• ❏ C. Create a Kanban board that shows only stories

• ❏ D. Modify issue layout to hide fields when empty

• ❏ E. Grant project lead the Delete issues permission

‘platform-admins’ group members Alex Maya ‘administrators’ group members Alex Leo Which issues are returned by this JQL? creator in membersOf(“platform-admins”) AND creator not in membersOf(“administrators”) OR creator=currentUser()?

• ❏ A. Issues created by Alex and the current user

• ❏ B. Issues authored by Maya and the currently signed in user

• ❏ C. Issues created only by Maya

• ❏ D. Issues reported by the currently signed in user

• ❏ E. Issues created by Alex Maya and the current user

• ❏ F. Issues where the creator is any member of platform-admins

Marco is growing his localization group across markets that use different languages and he wants to confirm which statements about translation in a company-managed project are incorrect? (Choose 3)

• ❏ A. Users can translate project components

• ❏ B. Users can translate the locked custom field

• ❏ C. Users are unable to translate the Resolution field

• ❏ D. Users can translate issue types

• ❏ E. Users can translate priorities

• ❏ F. Users can translate statuses

Maya at Northbridge Solutions set up a new inbound mail processor and it worked at first but now no customer emails create issues including messages from previous customers. What is causing this behavior? (Choose 3)

• ❏ A. The mailbox credentials expired

• ❏ B. The mail processor was deleted

• ❏ C. An issue type was removed from the mail processor configuration

• ❏ D. The mailbox location was modified and it is now empty

• ❏ E. The default reporter lost the Create Issues project permission

• ❏ F. An issue security level is missing from the project

A site administrator named Lucas plans to remove a Jira group and needs to discover where that group might be referenced across the instance. Where should Lucas look first? (Choose 2)

• ❏ A. Project roles

• ❏ B. System default dashboard

• ❏ C. Saved filters

• ❏ D. Issue type schemes

• ❏ E. Workflow conditions

Maya from Nimbus Solutions must decide whether to assign a Jira group or a project role for a set of users. In which situations is creating a Jira group the appropriate choice? (Choose 4)

• ❏ A. Site administrators will add and remove group members

• ❏ B. A project administrator will be in charge of changing the group membership

• ❏ C. The same users will be active contributors across several projects

• ❏ D. You need to assign permissions that apply across the entire Jira site

• ❏ E. Team members require the “Work On Issues” permission to be assigned via a global group

• ❏ F. Members must be able to perform bulk changes across many issues

When performing bulk edits across multiple projects why does the interface not display controls to enable or disable email notifications?

• ❏ A. Outgoing mail has been disabled at the site level

• ❏ B. They must be a Jira administrator or project administrator for every affected project

• ❏ C. They lack the ‘Make bulk changes’ global permission

Priya can set the Due Date field when she creates an issue but she cannot see that same field on the edit screen in her project. Which project setting does Priya need to change so the Due Date appears on the edit operation?

• ❏ A. Field Configuration

• ❏ B. Screen Scheme

• ❏ C. Issue Security Scheme

• ❏ D. Project Permissions

Diego administers a Jira instance for MapleTech and he changed the priority labels from Blocker PR11, High PR12, Normal PR13, Minor PR14, Trivial PR15 to Critical PR11, Major PR12, Standard PR13, Low PR14, Minimal PR15. What other Jira components might need to be adjusted as a direct result of renaming the priority values?

• ❏ A. Field configurations

• ❏ B. Automation rules

• ❏ C. Dashboards

• ❏ D. Workflow conditions

A website feedback widget enables visitors to file Jira tickets even if they do not have Jira accounts and it supports four trigger styles named Spotlight Inline Side and Custom. Which programming language is required to implement a custom trigger?

• ❏ A. HTML

• ❏ B. JQL

• ❏ C. Javascript

• ❏ D. CSS

• ❏ E. Java

Maya expected to receive an email when her team advanced a ticket to the next status but she did not get one. What is the most likely cause of the missing notification?

• ❏ A. Incoming mail handlers were removed

• ❏ B. A change in the workflow post function

• ❏ C. The global email processor has been disabled

• ❏ D. The default notification email prefix was changed

Marta sent an email to [email protected] which resulted in the creation of issue NV-5 in the company-managed project NV. She expected to receive an automated confirmation from Jira but she did not get any notification. She then forwarded her original message to [email protected] and the forwarded message did not include the issue key NV-5 in the subject. The instance has a single mail server and one mail handler configured with the Create a new issue or add a comment to an existing issue type. What will happen to Marta’s forwarded message?

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

• ❏ B. A comment will be appended to the issue “NV-5”

• ❏ C. Both a new issue will be created and a comment will be added to “NV-5”

• ❏ D. The forwarded email will be ignored by Jira

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

If team-group is configured as the default group for Jira Software which of the following statements is definitely true?

• ❏ A. Jira Service Management users also have Jira Software access

• ❏ B. You cannot delete team-group

• ❏ C. New Jira Software users will also need Jira Work Management to create issues in the SUP project

• ❏ D. You cannot delete confluence-users group

An administrator at Meridian Tech needs to confirm which backup or restore action is not possible from a Jira Cloud site. Which operation is not supported by a Jira Cloud site?

• ❏ A. Download a full site backup and upload it to Google Cloud Storage for long term retention

• ❏ B. Import attachments and other media from a Jira Cloud backup

• ❏ C. Restore a cloud site backup into another Jira Cloud site

• ❏ D. Create a site backup that can be restored to a Jira Server or Data Center instance

• ❏ E. Import issue and project data that originated from a Jira Server backup into the cloud site

A delivery team at Nimbus Systems asked you to create a new Jira project that must meet these conditions immediately after creation without turning on extra features. The project must allow the team to prioritize work daily with a backlog and an Agile board. The project must support working in seven day sprints. The project must permit creating multiple issues at once. Which project type and template should you create?

• ❏ A. Company-managed project using the Kanban template

• ❏ B. Team-managed project using the Kanban template

• ❏ C. Company-managed project using the Scrum template

• ❏ D. Team-managed project on the Scrum template

For which situations is applying an Issue Security Level appropriate in a Jira project? (Choose 2)

• ❏ A. Prevent team leads from moving issues to other projects

• ❏ B. Restrict who can view the development panel for an issue

• ❏ C. Limit access so that only team leads can view and update urgent issues

• ❏ D. Hide the entire project from non team leads

• ❏ E. Allow only team leads to view issues that team leads opened

A product team at Maple Apps runs a Jira Cloud site with two company managed projects created from a Kanban template. The select list custom field “Severity” currently has two field contexts. The first context named “Context Core” applies to the CORE project for the Task issue type and offers options S1 S2 and S3 with default S2. The second context named “Context Mobile” applies to the MOBILE project for the Bug issue type and offers options S0 and S1 with default S1. Your lead requests that the “Severity” field provide options S0 S1 S2 and S3 only for the Story issue type within the CORE project. What is the least administratively costly approach to satisfy this requirement?

• ❏ A. Create an Automation rule to set or map a hidden field for Story issues in the CORE project to emulate the new severity choices

• ❏ B. Edit the existing Context Core field context to add the Story issue type and include the requested options

• ❏ C. Create a new select list custom field named “Severity CORE” and restrict its field context to the CORE project and the Story issue type

• ❏ D. Add a new field context for the existing “Severity” field scoped to the CORE project and the Story issue type with the requested options

After a release is archived in a Jira Cloud project hosted on example.com, where can that archived release be chosen from the version fields?

• ❏ A. Archived releases can still appear in both the Fix Versions dropdown and the Affects Versions dropdown

• ❏ B. Archived releases are selectable only in the Fix Versions dropdown

• ❏ C. Archived releases are not selectable in either the Fix Versions dropdown or the Affects Versions dropdown

• ❏ D. Archived releases are selectable only in the Affects Versions dropdown

In a private project where the Task issue type is restricted to the Member and Viewer roles, what actions can users with the project role “Viewer” perform on tasks?

• ❏ A. Create tasks

• ❏ B. Add comments to any task

• ❏ C. Change issue security or project roles

After a recent configuration update, several team members at Nimbus Apps cannot move Stories from the Grooming column to the Ready for Implementation column on their Scrum board and no error message appears while those users can move Stories between other columns without trouble. What could explain this behavior? (Choose 2)

• ❏ A. A workflow validator blocks that specific transition

• ❏ B. The status mapped to the Ready for Implementation column was removed from the board

• ❏ C. The Transition Issues project permission was revoked for the affected users

• ❏ D. A workflow post function is interfering with the transition

• ❏ E. A workflow condition prevents users from executing that transition

• ❏ F. The affected users no longer have Jira Software access

Members of the Atlas project role Analysts can view issues across three security tiers

Members of the Atlas project role Analysts can view issues across three security tiers is correct because the role Analysts is explicitly included in Tier2 and Tier3. An Analyst who creates an issue becomes the Reporter and reporters are included in the Tier1 default level. That combination lets an Analyst see issues in Tier1 when they are the Reporter and lets them see Tier2 and Tier3 by role membership, which totals three tiers. Analysts do not automatically see Tier4 unless they are also added to a role or listed individually in that tier.

Newly created issues will be visible to all members of the Atlas project role Analysts is wrong because newly created issues inherit the Tier1 default which lists Reporter, Assignee and Project Role “Developers”. The default does not include Analysts so newly created issues are not visible to all Analysts unless an Analyst is the Reporter or Assignee.

Every member of the Atlas project role Developers can assign any security tier to an issue is wrong because granting the Set issue security permission to Developers allows that role to set a security level but it does not change which users are included in each security tier. The visibility outcome depends on the members listed in the chosen tier and on the project permission configuration.

Members of the Atlas project role Analysts can change an issue from Tier2 to Tier3 is wrong because only users granted the Set issue security permission can change an issue’s security level and that permission is given to the Project Role “Developers” not to Analysts. Being in the visible list for tiers does not grant the ability to change the tier.

The individual user alex will be restricted to viewing issues in a single security tier is wrong because alex is listed in Tier4 but alex could also appear in other tiers by being Reporter or Assignee or by holding a project role that is included in other tiers. Being listed in one tier does not inherently prevent visibility in other tiers when other membership conditions apply.

When you evaluate security tier questions look at both who is explicitly included in each level and which permissions such as Set issue security are granted to roles or users.

The correct answers are Child sub-tasks move together with their parent issue when the parent is reordered and Individual sub-tasks can be reordered relative to other sub-tasks under the same parent.

Child sub-tasks move together with their parent issue when the parent is reordered is correct because most Scrum backlogs treat sub-tasks as children of the parent issue and keep them nested under that parent when the parent is moved on the backlog. The parent and its children stay together visually and in the backlog ordering to preserve the hierarchical relationship.

Individual sub-tasks can be reordered relative to other sub-tasks under the same parent is correct because while sub-tasks remain attached to their parent, you can change the order of those sub-tasks beneath the same parent to reflect local priorities or workflow needs. Reordering applies to siblings under the same parent without affecting the parent position.

All child items must be arranged before the parent task can be moved is incorrect because there is no requirement to manually arrange every child before moving the parent. The parent can be moved and the children will move with it.

Sub-tasks always keep a ranking value that is different from their parent is incorrect because sub-task ranking is typically handled in relation to the parent and to sibling items and there is not always a separate immutable ranking value that is independent of the parent. Systems vary but the statement is too absolute to be true.

When a question focuses on ordering think about whether the items are treated as a single hierarchical group or as independent entries and check whether the wording requires an absolute rule or a typical behavior. Hierarchy and local reordering are often the key concepts.

The correct option is Epics.

Epics act as a container for related issues and they are designed to show progress and completion of work for that container so you can see totals and completed counts without adding extra reporting or gadgets. You can filter by the epic link to list all member issues and then perform a bulk change on that filtered set so you can edit every issue in the group with minimal effort.

Filters can locate and list issues across multiple projects and they can be used as the basis for bulk operations, but they do not provide a native grouping container that displays aggregate progress and completed counts per group without additional dashboarding or gadgets.

Components are defined at the project level and are not intended to group issues across multiple company managed projects, so they do not meet the cross project grouping requirement.

Boards provide a visual view of issues from one or more projects but they are not a grouping element that creates an issue container with built in aggregated counts and they do not inherently provide a single click bulk edit for a logical group.

Releases or versions are tied to individual projects for tracking shipped work and they are not suitable for grouping issues across multiple company managed projects in the way required by the question.

When a question asks for a way to group related work and show progress and completion without extra gadgets think about issue containers such as epics and how filtering by the container enables bulk operations.

The correct options are The background colour of the primary navigation bar and The colour of the create issue button and the highlight used for the currently selected navigation item.

The global Look and Feel controls the top level branding and the primary accent used across the product interface. That is why The background colour of the primary navigation bar is correct because the header or navigation bar is part of the global branding that these settings change.

The same global accent is applied to prominent actions and selection highlights which is why The colour of the create issue button and the highlight used for the currently selected navigation item is correct. The setting provides a single primary color that is used for the main action button and for highlighting the active navigation item to keep the product appearance consistent.

The background colour of the project sidebar is incorrect because sidebars and per project panels are part of the content layout and are not typically overridden by the global Look and Feel branding.

The colour palette applied to every button across the application is incorrect because the global setting usually sets a single primary accent for key actions and highlights and it does not recolour every button variant and contextual control across the product.

The background colour of the issue detail view is incorrect because the issue content area background remains the page or theme default and is not replaced by the global look and feel accent settings.

Look for words like header, navigation, primary or accent when a question asks about global branding. These settings usually affect the top level UI and primary actions and not every content area.

The correct answer is Revoked the project Add Comments permission for affected users.

When the project level Add Comments permission is removed for certain users the comment control on transition screens will no longer appear for those users because the application hides UI elements that the user is not permitted to use. This change would affect only the users who lost the permission and not users who still have it which matches the scenario described.

Introduced a workflow condition that restricts who can perform the transition is incorrect because a condition controls whether a transition is visible or executable for a user and if it were in effect the users would not see the transition at all rather than only losing the comment field.

Modified a post function on the transition is incorrect because post functions run after a transition completes and they do not determine which fields are displayed on the transition screen.

Detached or removed the transition screen is incorrect because removing or detaching the screen would remove the comment field for all users for that transition and would not explain why only some users are affected.

Added a workflow validator that checks transition input is incorrect because validators only evaluate input when the transition is submitted and they do not hide fields on the form before submission.

If a field is missing only for some users first check the project permission scheme and the Add Comments permission for those users to quickly rule out a permission change.

The correct option is Add example.com to approved domains and require admin approval for access.

When you Add example.com to approved domains and require admin approval for access you create an allow list that lets users with emails at that domain trigger the built in request access flow. Those users can request to join the Jira Cloud site and the requests are routed to site or organization administrators for approval so access is controlled but easy for domain users to request.

Enable invitation links for the site is incorrect because invitation links are used to send direct invites or share a link with specific people and they do not enable a domain based automatic request access workflow.

Configure Google Workspace SAML single sign on for example.com is incorrect because SAML SSO manages how users authenticate and can restrict logins but it does not by itself provide the request access mechanism described in the question. User provisioning can be added separately but the option as stated does not implement the request flow.

Read the question carefully to separate authentication features from access request features. The approved domains setting controls who can request access while SSO controls how they sign in.

The correct answer is: URLs that contain the previous project key will redirect to the new project key.

When a project key is changed Jira updates the issue keys and creates redirects from the old issue URLs to the new keys. This means bookmarks and external links that reference the previous key will resolve to the issues under the new key and users will not generally lose access to those linked issues.

Users must edit their saved filters to use the new project key is incorrect because saved filters and JQL queries are resolved by Jira using internal identifiers and the URL redirects preserve access. Most filters do not require manual rewriting after a key change.

Some dashboards and reports will display errors is incorrect in general because gadgets and reports that reference issues or filters will normally continue to work due to the redirects and the underlying issue identifiers. Only very unusual custom integrations that rely on hard coded assumptions might need attention.

A new project can be created using the previous project key is incorrect because the previous key remains associated with the project history and the redirect behavior. You cannot simply reuse the old key without first addressing the existing project and redirect mapping.

You must manually update Confluence Jira issue macros to reference the new key is incorrect because Confluence macros that link to Jira issues will follow the same redirects and will continue to display the linked issues. Manual updates are not normally required for standard issue macros.

Remember that Jira creates redirects when you change a project key so check links and macros but do not assume you must update every saved filter or macro manually.

The default reporter account does not have the “Create issues” project permission is correct.

The mail handler was configured to create new issues and it uses a reporter mapping when the sender cannot be matched to a Jira user. If the configured default reporter account lacks the project permission to create issues then Jira will not be able to create an issue for those incoming messages and the mail is effectively ignored. That explains why some emails created issues while others did not, because emails that matched an existing user with permissions were created but emails that fell back to the default reporter account failed.

The mail handler is set to add comments to matching issues instead of creating new issues is incorrect because the handler type was explicitly set to create new issues. If the handler were set to add comments then incoming messages would require an issue key to match and would not create new issues.

Some emails are ignored because they do not reference any issue key is incorrect because the chosen handler is meant to create a new issue for each message. Lack of an issue key only prevents comment handlers from finding a matching issue, but it does not prevent a create issue handler from creating a new issue.

The mail handler has the Notify Users option turned off is incorrect because turning notifications off affects whether users are emailed about created issues and comments. It does not stop issues from being created. The report that some emails did not create issues indicates a permission or creation failure rather than notification settings.

When mail-based issue creation fails check the default reporter mapping and then verify that account has the Create issues permission in the project before changing handler types.

The correct answer is Marisol does not have the “Make bulk changes” global permission.

The Bulk change button in the issue navigator is shown based on the global “Make bulk changes” global permission. If a user does not have that global permission the button will not be visible even when filters return matching issues. Project level permissions determine what you can do to individual issues, but they do not make the Bulk change button appear for a user who lacks the global permission.

Marisol is not a Jira administrator is not correct because being a Jira administrator is not required to see or use the Bulk change button. The visibility of that control is governed by the specific global permission rather than by admin status.

Marisol does not have the “Resolve issue” project permission and she also lacks the “Make bulk changes” global permission is not correct because the extra claim about a “Resolve issue” project permission is not the reason the button is hidden. The key reason the button is missing is the lack of the global “Make bulk changes” global permission, and the project level claim in this option is unnecessary and inaccurate for visibility.

Marisol does not have the “Edit issue” project permission and she also lacks the “Make bulk changes” global permission is not correct because while the project Edit issue permission affects whether she can change fields on specific issues it does not control whether the Bulk change button is displayed. The missing global “Make bulk changes” global permission is the specific cause of the hidden button.

The filter returned more issues than the instance maximum for bulk operations so the Bulk change button is suppressed is not correct because the Bulk change button is not hidden based on the number of results alone. The UI requires the global permission to display the button. Exceeding any system limits may affect the operation or selection behavior but it is not the primary reason the button would be entirely suppressed from view.

When a UI action like Bulk change is missing check the relevant global permission first and then verify project permissions for the issues you want to change. The Make bulk changes global permission controls the button visibility.

The correct option is No default issue security level is configured for the project security scheme.

If no default issue security level is set then new issues are created without an issue security level and they remain visible to anyone who can browse the project. Because Hannah filed the issue it had no security level restricting it and she can open it even though she is not in the Compliance Team or the Compliance Managers roles. To restrict visibility you must either set a default level on the scheme or have users select an appropriate security level when creating the issue.

Hannah is a member of the “atlassian-addons-project-access” project role is incorrect because that role is intended for application and integration accounts and it does not explain why a normal user would see an issue. It is not a typical cause of user issue visibility.

Hannah holds the Administrators project role in project “FINX” is incorrect because being a project administrator does not automatically bypass issue security levels. Project admin permissions do not grant unrestricted viewing of issues that are limited by an issue security level.

Hannah is the site administrator for the cloud instance is incorrect because site administration privileges do not automatically give a user visibility into every issue across projects that are protected by issue security. Site admin is about managing the instance and users but it does not override issue security rules for viewing issues.

Hannah does not have the Set issue security project permission is incorrect because that permission only controls who can set or change an issue’s security level. Lacking that permission would not itself grant Hannah visibility and it would not explain why she can open the issue she filed.

When you see a question about issue visibility think about whether an issue security level is actually applied. If no default issue security level exists then issues can be visible to anyone with project browse rights even if role based levels are defined in the scheme.

The correct options are You want the issue assignee to be set automatically based on the selected component and The configuration should be maintained by the project administrator rather than a site administrator.

You want the issue assignee to be set automatically based on the selected component is correct because Jira components can have a default assignee or component lead. When an issue is created with a component the configured lead or default assignee can receive the issue automatically so you do not need a global custom field to drive assignment.

The configuration should be maintained by the project administrator rather than a site administrator is correct because components are managed at the project level and can be created and edited by project administrators. This keeps the configuration local to the project and avoids requiring site administrator access to change a global custom field.

The field must be usable across many projects site wide is incorrect because components are scoped to a single project and are not available site wide. If you need a field usable across many projects you should use a global custom field or a field with a global context.

You need a single picklist value to support cross project reporting and filters is incorrect because a picklist that must be consistent for reporting across projects should be implemented as a global custom field. Components differ by project and will not provide a single consistent picklist across multiple projects.

Remember that components are project scoped and can set default assignees, while global custom fields are site scoped and provide consistent values across projects.

Insert a screen transition into a workflow and Add the “Affects versions” field to an issue type’s field list are not available in team-managed projects.

The workflow editor in team-managed projects is intentionally simplified and does not let you insert transitions that display specific screens or attach screens to individual transitions. Configuring transition screens and detailed transition behaviour relies on the classic workflow and screen schemes that are available only in company-managed projects, so inserting a screen transition is not possible in a team-managed project.

Team-managed projects handle versions in a simplified way and they expose the Fix versions field for release tracking. The “Affects versions” field is not supported in the issue type field lists for team-managed projects, so you cannot add it there. Full control over both version fields and their schemes requires a company-managed project.

Manage project roles is incorrect because team-managed projects allow project administrators to manage project membership and assign simple project-level roles or access via the project settings. You can control who has what access within a team-managed project without needing the global project role schemes used by company-managed projects.

Add the “Fix versions” field to an issue type’s field list is incorrect because the Fix versions field is available in team-managed projects and can be added to issue types to support release planning.

When a question asks about team-managed versus company-managed features think about whether the feature needs global schemes or shared configuration. If it does then the feature is likely only available in company-managed projects.

The correct answers are Users can select a project role to receive the subscription email, Creating any filter subscription requires the Manage group filter subscriptions global permission, and A filter subscription will never send an email when the query returns zero results.

Users can select a project role to receive the subscription email is incorrect because filter subscriptions do not accept project roles as email recipients. The subscription interface allows individual users, email addresses, and Jira groups to be added, but it does not target project roles for delivery.

Creating any filter subscription requires the Manage group filter subscriptions global permission is incorrect because that global permission only applies when creating or managing subscriptions on behalf of groups. Regular users can create their own filter subscriptions for filters they can view without that global permission.

A filter subscription will never send an email when the query returns zero results is incorrect because delivery behavior can depend on subscription settings and system configuration. Subscriptions can be configured or allowed to send notifications even when a query returns no issues, so it is not true that they will never send in that case.

Recipients may receive different issue details from the same filter subscription is not an incorrect choice because recipients see results based on their permissions and issue security. That means different users can receive different issue details from the same subscription.

You can configure a Jira group as an email recipient for a subscription is not an incorrect choice because Jira supports adding groups as recipients when creating filter subscriptions. Using groups is a standard way to notify multiple users at once.

Carefully map each option to real product behavior before answering and watch for words about project roles, group recipients, and global permissions because those details often determine the correct choice.

The correct answer is Alex will be added to two groups.

Two groups in the list are marked as default for Jira Software, namely devomega and trackerteam. Granting product access with the User product role automatically places the user into the product’s default groups, so Alex will be added to those two existing groups.

Alex will be added to three groups is incorrect because only two groups are marked as default. The group sizes do not change which groups are applied when granting product access.

Alex will not be added to any existing groups and will still have Jira Software access is incorrect because assigning a product role to a user adds them to the product’s default groups when those defaults are set. Alex will therefore be added to the default groups for Jira Software.

Alex will become a company administrator is incorrect because becoming a company administrator requires explicit addition to the administrative group or role. The companyadmins group in this case is not a default group, so granting the Jira Software User role does not make Alex a company administrator.

Alex will be added to four groups is incorrect because only two groups are configured as defaults for the product. There is no information that would cause Alex to be placed into additional groups beyond those defaults.

Count the product’s default groups and focus on which groups are marked as default rather than on group sizes or names when answering these questions.

Configure notifications to be sent to the selected component lead is correct.

This capability depends on having components with assigned component leads and the ability to reference those leads in a project notification scheme. Those features are part of the company managed project model so only a company managed project can configure notifications to go to the selected component lead.

Automatically assign an issue during a workflow transition is not exclusive to company managed projects because both project types can perform automatic assignment either through workflow post functions in company managed projects or through automation rules in team managed projects.

Send notifications to the project lead is not correct because notifying the project lead is a general notification option that can be configured in both project types and is not restricted to company managed projects.

Change the project key is not correct because changing a project key is a project administration action that can be done in either project type when you have the required permissions.

Enable or disable the Versions page in project navigation is not correct because control over project navigation and access to versions is not a capability that exists only in company managed projects and can be managed in different ways across both project types.

When you need to choose between company managed and team managed look for features tied to classic Jira administration such as components or notification schemes because those are typically available only in company managed projects.

The correct option is Create a new project role add sales staff to that role within the “HELPDESK” project and then include that role for the requested events in the project notification scheme.

This approach uses a project role so membership is managed only for the HELPDESK project and does not change recipients in other projects that share the notification scheme. You add the sales staff as members of the project role in HELPDESK and then add that role to the specific events in the notification scheme. That preserves existing notifications for developers and QA because you are not altering global groups or users for the shared scheme.

Create a shared group for the sales staff and add that group to the requested events in the “HELPDESK” notification scheme is incorrect because groups are global. Adding a group to the notification scheme would affect all projects that use that scheme and could cause sales staff to receive notifications from other projects.

Add each sales staff member individually to the requested events in the “HELPDESK” notification scheme is incorrect because individual user entries are hard to maintain and the change to the scheme will apply wherever the scheme is used. Using a role keeps membership manageable and scoped to the project.

Create a project role and make sales staff default members of that role then add the role to the requested events in the “HELPDESK” notification scheme is incorrect because setting default members makes the assignment broader and can cause the sales staff to be added across multiple projects or as a global default. That would alter notifications outside of the HELPDESK project which is not desired.

When notification schemes are shared across projects prefer using project roles so you can change membership only in the affected project without impacting other projects.

Add orbit_team_group to Project Role “Analysts” and Add orbit_team_group to Share dashboards and filters global permission are correct.

Add orbit_team_group to Project Role “Analysts” grants the group the project level permissions that the ORBIT permission matrix assigns to the Analysts role, and those project permissions include the ability to Edit Issues and Log Work when the role is mapped to those rights in the permission scheme.

Add orbit_team_group to Share dashboards and filters global permission grants the ability to create and share filters and dashboards across the instance because creating and sharing filters is controlled by that global permission rather than by a project permission.

Add orbit_team_group to Project Role “Developers” is incorrect because adding the group to Developers will only help if the Developers role actually holds Edit Issues and Log Work in the ORBIT permission scheme, and the given matrix shows those rights on Analysts instead.

Add orbit_team_group to Manage group filter subscriptions global permission is incorrect because that permission only controls managing subscriptions to filters and not the ability to create or share filters.

Add orbit_team_group to Project Role “Scrum Team” is incorrect because the Scrum Team role does not carry the necessary Edit Issues and Log Work permissions according to the provided permission matrix.

Add the Project Role “Analysts” to Share dashboards and filters global permission is incorrect because the actionable change is to grant the global permission to the group that needs the ability, not to try to add a project role to the global permission in this scenario.

When you see permissions questions first check whether the right is project level or global. Then confirm whether you must add a group to a global permission or add the group to the project role that the project permission scheme already maps to the needed rights.

Custom field context configuration is correct because the custom field context is what you change when you want a different default option for that field in a single company managed project.

A custom field context lets you scope a field to particular projects and issue types and it also lets you define the option set and the default value for that scope. You create or edit a context for the specific project and then set the default option for the field in that context so only that project uses the changed default.

Screen schemes is incorrect because screen schemes only control which screens are used for create, edit and view actions and which fields appear on those screens. They do not control the option sets or default values of a custom field.

Field configuration scheme is incorrect because field configuration schemes map field configurations to issue types and control behaviors like required or optional and the renderer. They do not provide per project option lists or per project default values for custom fields.

Focus on the concept of scope when asked about changing defaults for a single project. If a question mentions changing defaults or option lists for only one project then think about custom field contexts rather than screens or field configuration schemes.

The correct option is Outgoing Mail.

Outgoing Mail is the Jira administration area that controls whether the application sends notification emails to users and watchers when issues are updated. If notifications stopped after a change in behavior this is the place to confirm that outgoing email is enabled and to send a test message or view the mail queue and delivery status.

Mail Handler is incorrect because mail handlers deal with incoming email and how Jira creates or updates issues from messages. That setting does not control whether Jira sends notification emails to watchers.

SMTP Mail Server is not the best choice because it normally refers to the low level SMTP server details rather than the switch that enables outbound notifications in the admin UI. In some older Jira versions server entries were managed separately so this option may appear as a legacy configuration on older exams.

Personal Settings is incorrect because Maya already checked her personal preference for watching issues and those settings apply per user. Personal settings will not stop all outgoing mail from the system when the global outgoing mail capability is turned off.

Global Mail Settings is incorrect because the modern admin workflow uses the Outgoing Mail page to enable and troubleshoot notifications. If a legacy named page appears on older documentation it is functionally replaced by the Outgoing Mail controls in current versions.

When email notifications stop first check the Outgoing Mail admin page and try a test email before changing user preferences.

The correct option is Company-managed Scrum.

A Company-managed Scrum project supports Scrum sprints and provides advanced board configuration. It allows the team to run weekly sprints and to configure the board layout and swimlanes so issues can be grouped by assignee and so the due date field can be shown on cards.

Team-managed Kanban is incorrect because Kanban projects are not designed around fixed sprints and team-managed projects have more limited board and card customization, so they do not reliably meet the requirement to group by assignee and show due date on every card.

Team-managed Scrum is incorrect because although it supports sprints, team-managed projects have reduced board configuration compared with company-managed projects. That limitation can prevent setting swimlanes to group by assignee and configuring the card layout to display the due date on all cards.

Company-managed Kanban is incorrect because Kanban boards do not use Scrum sprints. Even though company-managed projects offer the needed customization, the Kanban project type will not meet the requirement to plan work in weekly sprints.

When a question requires both sprints and extensive board customization choose a company-managed Scrum project since it provides the most control over swimlanes and card fields.

The correct answers are Carlos’s account can be restored at any later time if required and Other users will still see Carlos’s username after his account has been deleted.

Carlos’s account can be restored at any later time if required is false because managed user deletions are not indefinitely reversible. Restores are generally limited to a defined retention window and after that window the account is permanently removed so it cannot be recovered at any later time.

Other users will still see Carlos’s username after his account has been deleted is false because deleting a managed account removes the user entry from the directory and public listings. Other users will not continue to see the deleted account’s username as an active directory identity.

Content created by Carlos will remain and will not be removed is not a correct choice because that statement is true in this context. Files, emails, and other organizational content are typically retained or can be reassigned rather than being automatically deleted with the user account.

All personal information in Carlos’s managed account will be erased is not a correct choice because that statement is true here. Account deletion processes commonly remove or anonymize personal profile data to meet privacy and compliance requirements.

Carlos’s deletion can be undone during a 30 day grace period is not a correct choice because that statement is true and therefore not one of the false statements. Many directory services implement a soft delete with a limited grace period during which the deletion can be reversed.

Read each statement carefully and watch for absolute phrases like any later time or exact time windows. Compare those phrases to known retention or soft delete windows to decide if a statement is false.

The correct option is Due Date.

Due Date cannot be added to an issue collector because collectors are designed to capture a limited set of basic issue fields from an embedded form and scheduling fields such as a due date are managed in Jira after issue creation or through workflows and permissions rather than through the collector configuration.

Components is incorrect because components can be included or set as defaults in an issue collector and they are part of the basic metadata that collectors support.

Description is incorrect because the whole point of an issue collector is to capture the issue description or details from the reporter via the embedded form.

Attachments is incorrect because collectors can accept file uploads when the collector is configured to allow attachments and the project permits them.

Priority is incorrect because priority can be exposed on the collector so reporters can choose the issue priority during submission.

Environment is incorrect because the environment field can be included to capture information about the user’s environment or system when the issue is reported.

Summary is incorrect because a short summary is a standard required field on collector forms and it is normally included in the embedded form.

When you see a question about issue collectors remember that they are for simple data capture and that scheduling or workflow controlled fields like the due date are commonly not available in the collector form.

Custom field context is correct because it allows different sets of choices for the same custom field to be scoped to specific projects and issue types.

Custom field contexts let an administrator define separate option lists and apply them to particular projects or issue types. Laura can create a context that is limited to her company-managed project so that the shared “Team Seniority” field has a unique set of choices there while other projects keep the original options.

Issue layout is wrong because it controls how fields are displayed on the issue view and it does not change the selectable options for a custom field.

Permission scheme is wrong because it governs user rights like who can create edit or transition issues and it has no effect on the option sets of a custom field.

Screen scheme is wrong because it assigns which screens appear on create edit and view operations and it does not provide per-project option lists for a custom field.

When a question is about different choice lists for the same field across projects think of custom field contexts first and look for keywords like choices or options in the scenario.

The correct option is (assignee in (Sam, Maya)) AND created >= startOfWeek(“Monday”).

This query explicitly groups the two assignees and applies the date filter to the combined set. The use of created >= startOfWeek(“Monday”) makes the cutoff inclusive so issues created on Monday of the current week are returned as well as those created afterwards.

assignee = Sam OR assignee = Maya AND created > startOfWeek(“Monday”) is incorrect because without parentheses the AND binds more tightly so the expression would return all of Sam’s issues regardless of creation date and it also uses > which would exclude issues created exactly at the Monday boundary.

assignee in (Sam, Maya) AND created > startOfWeek(“+1d”) is incorrect because startOfWeek(“+1d”) advances the cutoff and the > operator excludes the Monday start so issues created on Monday would be omitted.

When you see mixed AND and OR use explicit parentheses and check whether the date comparison should be inclusive (>=) or exclusive (>).

The correct options are “Create attachments” project permission was revoked for Leah and “Edit issues” project permission was revoked for Leah.

“Create attachments” project permission was revoked for Leah is correct because that specific project permission controls whether a user can add files to an issue. If Leah lost that permission she would no longer see the add attachment controls and she would be unable to reattach the PDFs.

“Edit issues” project permission was revoked for Leah is correct because attaching files typically requires the ability to modify the issue. Without edit rights Leah cannot change the issue to add attachments and some attachment actions may be hidden from her.

Site attachment storage quota has been exceeded is unlikely because a storage quota normally prevents new uploads but it does not usually make existing attachments vanish from an issue.

Attachments have been disabled across the Jira site is unlikely because disabling attachments is a global admin action that would affect all users. That is less likely than a project permission change and would require an administrator to toggle the site setting.

“Browse projects” project permission was revoked for Leah is not the best explanation because losing browse permission would block Leah from seeing the project or issue at all rather than only removing her ability to add or manage attachments.

When an issue shows missing attachments first check project permissions such as create attachments and edit issues. If the problem affects all users then check global or site attachment settings and storage limits.

The correct option is Issues in project MARCOM where the user shown in the Manager custom field is a member of the “marc-managers” group.

The saved filter uses the JQL function membersOf(“marc-managers”) together with project = MARCOM so it matches issues in MARCOM where the Manager custom field contains a user who belongs to the marc-managers group. The subscription will evaluate that filter and send the resulting issue list to the marc-escalate group. Because the marc-escalate group can view all MARCOM issues they will receive the matched issues.

Issues in project MARCOM where the group “marc-escalate” is entered in the Manager custom field is incorrect because the filter is checking for users who are members of marc-managers and not for a group value stored in the Manager field. The recipient group being marc-escalate is about who receives the emails and does not change what the JQL returns.

Issues in project MARCOM where the group “marc-managers” is stored in the Manager custom field is incorrect because the Manager custom field is a user picker and does not store groups. The membersOf function tests whether the user in that field belongs to the named group rather than looking for a group value inside the field.

Issues in project MARCOM where Sophia is listed as the Manager in the custom field is incorrect because the filter does not target a specific person. It selects any issue where the Manager field contains a user who is a member of marc-managers, so Sophia would only be included if she herself is in that group.

Read the JQL carefully and focus on whether the query checks a user’s group membership or the literal value stored in a custom field. Also confirm that recipients have permission to view the issues because subscriptions only send issues the recipients can see.

The correct options are She is missing the Transition issues project permission, A workflow condition is blocking the transition for her, and She is not a member of the group or project role that has the permission.

She is missing the Transition issues project permission is correct because executing or seeing certain transitions can be controlled by specific project permissions and without that permission the user interface will not present the transition to that user even though others can see it.

A workflow condition is blocking the transition for her is correct because workflow conditions are evaluated for the current user and can hide or prevent a transition from appearing when the condition is not satisfied for that user while it still appears for teammates who meet the condition.

She is not a member of the group or project role that has the permission is correct because project permissions are commonly granted to groups or project roles and if she is not in the allowed group or role she will not receive the permission needed to view or execute the transition.

She lacks Browse issues project permission is incorrect because lacking the browse projects permission would normally prevent the user from opening or viewing the issue details at all rather than only hiding a single transition.

A workflow validator requires changes is incorrect because validators run when a transition is executed and they can stop the transition from completing but they do not typically hide the transition from the issue view before the user attempts it.

When a transition is not visible check transition permissions first then check workflow conditions and finally confirm group or role membership.

Team-managed project with Kanban template is correct because it provides a ready to use Kanban board for daily prioritization and it includes the lightweight board controls that project administrators can use immediately to manage and clear columns while also supporting timeboxed work in flexible cycles without turning on extra features.

The team managed Kanban template gives teams a simple, directly editable board that lets them rank and prioritize work each day on a Kanban board. Project administrators in a team managed project have the in-product controls to configure columns and perform bulk moves or clear the board end column without needing global administration or extra configuration steps. The template is designed to be usable immediately after creation so the SRE and development workflows can start straight away.

Company-managed project with Bug tracking template is wrong because company managed projects use shared schemes and more centralized administration which can require extra configuration and permissions before board and column operations are available to project administrators.

Team-managed project with Bug tracking template is wrong because the bug tracking template does not provide the Kanban workflow and board experience required for daily prioritization on a Kanban board.

Company-managed project with Kanban template is wrong because a company managed Kanban project brings centralized schemes and admin dependencies that can prevent immediate, per project administrator control of board behaviors and clearing the final column without additional setup.

Company-managed project with Scrum template is wrong because the Scrum template focuses on fixed sprint cadence rather than an immediate Kanban style daily prioritization, and the company managed model adds configuration that can delay meeting the requirement right after creation.

When a question emphasizes immediate, per project admin control and simple board prioritization pick a team-managed Kanban project since it gives direct board controls and usable Kanban features without extra configuration.

She must have the “Administer projects” project permission to release a new project version from the Kanban board is the correct statement.

Releasing and managing versions is a project administration task and it is controlled by the project permission “Administer projects”. Without that permission a user cannot create edit or release versions from the project or from the board interface. The scheme shows that “Administer projects” is granted only to the group atlassian_addons_project_access so being a board facilitator does not automatically give the needed project level rights.

Being the board administrator is sufficient to release a version from the Kanban board is incorrect because board administration controls board configuration filters and swimlanes and it does not grant project level version management rights.

She must be assigned as the project lead to perform a release from the Kanban board is incorrect because the project lead role is not required to manage versions and it does not by itself provide the “Administer projects” permission unless the permission scheme explicitly assigns that permission to the lead.

She will be able to release a new version from the Kanban board without additional permissions is incorrect because the permissions Browse projects Edit issues and Resolve issues do not include version management actions. The user needs the “Administer projects” permission to perform a release.

When a task involves creating or releasing versions check which project permission controls that action and verify whether the user is in a group or role that grants Administer projects.

The correct options are Notification schemes, Issue security schemes, and Permission schemes.

Notification schemes control who receives email notifications for project events and they are applied at the project level through a scheme. They are not mapped to individual issue types so they do not depend on which issue type is used.

Issue security schemes define security levels that control who can see particular issues and they are assigned to projects via a scheme. The security levels apply to issues but the scheme itself is not tied to specific issue types.

Permission schemes determine what users can do within a project and they are granted at the project level by applying a scheme. Permissions are not configured per issue type so the permission scheme is not tied to issue types.

Workflow schemes are incorrect because they map workflows to specific issue types. A workflow scheme explicitly assigns a workflow to one or more issue types, so this scheme type is tied to issue types.

When you read questions about schemes think about whether the scheme applies at the project level or whether it maps directly to issue types. Schemes that control notifications, security visibility, or permissions are usually project level.

You cannot merge two Jira Cloud instances into one using only site backup files.

Jira Cloud site backups are designed for single site restore workflows and a site restore replaces the target site rather than merging with it. Restoring a backup will recreate the backed up site’s data and configuration and it will not combine two separate backup sets into one unified site.

To combine content from two cloud sites you must use targeted migration methods or work with Atlassian support to plan a merge. Common approaches include selective exports and imports or vendor supported cloud to cloud migrations, but those are not achieved by applying multiple site backup files to a single instance.

Create site backups for both instances and restore them into a new Cloud instance is incorrect because you cannot apply two different site backup files into the same target site. Restoring one backup will define the site state and a second restore will overwrite that state rather than merge it.

Create a backup of one instance and restore it over the other instance is incorrect because restoring one backup over another would replace the destination site and destroy the original data on that site instead of combining content.

Use the Jira Cloud Migration Assistant or perform a cloud to cloud migration is incorrect in this question context because the Jira Cloud Migration Assistant is primarily intended for Server or Data Center to Cloud migrations and there is no simple self service tool that automatically merges two independent cloud sites. Cloud to cloud moves often require planning and support from Atlassian.

Export issues from one instance and import them into the other using CSV is incorrect as a complete solution because CSV import only moves selected issue data and it will not preserve many elements such as full history, attachments, user mappings, permissions and some configuration details. CSV can help migrate issues but it does not perform a full site merge.

When you see questions about merging cloud sites remember that site backups are single restore operations. Think about what a restore does and then eliminate answers that imply combining multiple backup files into one site.

Members assigned the project role ‘Viewer’ in the FLX project will have access only to stories created after Amelia changed the restriction.

The issue type visibility restriction that Amelia changed in the team managed project takes effect for issues created or edited after the change. When she added the project role Viewer to the Story restriction, users with that role gained visibility for newly created or updated Story issues going forward. Existing Story issues that were created while the restriction allowed only Administrators remain restricted until those issues are changed.

Users who hold the project role ‘Member’ in the FLX project will be able to access all stories is incorrect because Members were not granted visibility by the change and restrictions do not automatically retroactively open previously restricted issues.

Users who hold the project role ‘Viewer’ in the FLX project will be able to access all stories is incorrect because adding Viewer to the restriction does not give access to Story issues created before the change. Viewers can see Stories created or updated after the restriction was modified.

Users who hold the project role ‘Member’ in the FLX project will be able to access only stories they create after Amelia updated the restriction is incorrect because this scenario did not grant Members any new visibility. Whether a creator can see an issue depends on the active visibility rules when the issue is created and not on who created it if the role is not permitted.

Remember that issue type visibility changes in team managed projects generally apply going forward and do not retroactively change who can view issues that were already created.

Adding a new column with a unique name on the board automatically creates a corresponding status and Creating a new status in the project workflow will automatically add a new column to the board are correct.

Team managed projects keep board columns and workflow statuses synchronized so adding a column on the board will create the matching status automatically and creating a status in the workflow will add a corresponding column. This behavior lets project admins manage the board and workflow from either view and the platform handles the mapping for you.

After you add a status in the workflow you must manually place it on the board or it will not be visible is incorrect because a new status in a team managed project is reflected on the board automatically and you do not need to place it manually.

Only a Jira global administrator can add new statuses for a team-managed project is incorrect because team managed project administrators can add and manage statuses for their project and a global administrator is not required for those project scoped statuses.

When a question contrasts team managed and company managed behavior remember that team managed projects sync board columns and statuses automatically and you should look for answers that state this automatic two way mapping.

The correct answer is All of the listed reasons could cause the problem.

This choice is correct because each of the other options describes a plausible reason why Maya might stop receiving subscription emails. Subscriptions deliver the results of a saved filter to recipients on a schedule and if the filter yields nothing to send or if Maya loses the access that makes her a recipient then the emails can stop.

The saved filter yields no results is not a valid exclusion because if a saved filter returns no issues there is often nothing for the subscription to include and many systems will not send an empty notification email.

Someone removed Maya from a user group is not a valid exclusion because if the subscription targets that group then removing her from the group will remove her from the recipient list and she will no longer get the emails.

Project permissions were changed is not a valid exclusion because changes to project or project browsing permissions can prevent a user from seeing issues or receiving notifications tied to that project, so notifications can stop when permissions are reduced.

Someone removed Maya from a project role is not a valid exclusion because project roles are often used to determine notification recipients and access, and removing her from a role can also stop both visibility and email delivery.

When a question asks which option would not explain a problem check whether each listed cause could independently produce the symptom and pick All of the listed reasons only if every item is plausible.

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

The correct option is Trigger When an issue is created Condition If an epic exists Action Edit issue fields “Due Date”.

This rule uses the issue created trigger so it runs when a new issue is added. The condition ensures the rule only proceeds when a parent epic exists and the edit issue fields action can copy the epic’s due date into the newly created issue by using automation smart values when setting the Due Date field.

Trigger When an issue is created Condition Issue type equals Epic Action Edit issue fields “Due Date” is incorrect because it only fires when the created issue is an epic. The requirement is to set the due date on a new issue that is linked to an existing epic and not to act only when the created issue itself is an epic.

Trigger When an issue is created and associated to an epic Action Edit issue fields “Due Date” is incorrect because there is no standard single trigger named associated to an epic and because the safe pattern is to trigger on creation and then verify a parent epic exists. Explicitly checking for the epic prevents the rule from running for unrelated issues.

Trigger When an issue is created Branch rule For parent epic Action Edit issue fields “Due Date” is incorrect because branching into the parent epic changes the rule context to the epic. That pattern would target the epic unless you explicitly reference the newly created issue with smart values, so it is not the simplest or most direct way to copy the epic’s due date into the new issue.

When a question asks about copying a parent field on creation look for a trigger plus a condition that confirms the parent and an action that uses smart values. Use an If an epic exists check to avoid running the rule for issues with no parent.

The correct answers are Show due date on every screen and in all issue layouts and Grant project lead the Delete issues permission.

Show due date on every screen and in all issue layouts is not something a project administrator can enforce when global permissions remain at their defaults because modifying screens and global issue layout schemes is handled by Jira administrators. Those configuration areas apply across projects and are controlled at the global administration level rather than by a single project admin.

Grant project lead the Delete issues permission is also not possible for a project administrator when global permissions are unchanged because the Delete Issues right is assigned through permission schemes. Editing permission schemes requires Jira administrator privileges so a project admin cannot grant that permission on their own.

Create components is incorrect because project administrators can create and manage components within their own project from the project settings.

Create a Kanban board that shows only stories is incorrect because boards can be created using a filter such as an issue type filter and a project admin or other user with board creation rights can make a Kanban board that shows only stories.

Modify issue layout to hide fields when empty is incorrect because project administrators can adjust the issue layout for their project and configure field visibility rules such as hiding empty fields within the project settings.

When questions mention global permissions left at default think about actions that require Jira administrator rights. Permission schemes and global screen or layout configurations are common examples of settings you cannot change as a project admin.

The correct answer is Issues authored by Maya and the currently signed in user.

The JQL evaluates as creator in membersOf(“platform-admins”) AND creator not in membersOf(“administrators”) OR creator=currentUser(). AND is evaluated before OR so the first part selects platform-admins members who are not administrators. The platform-admins group contains Alex and Maya and the administrators group contains Alex and Leo. Excluding administrators from platform-admins therefore leaves only Maya and the OR adds any issues created by the signed in user which together yield issues authored by Maya and the current user.

Issues created by Alex and the current user is wrong because Alex is a member of both groups and is excluded by the creator not in membersOf(“administrators”) condition. The first part returns Maya rather than Alex so that option is not correct.

Issues created only by Maya is wrong because the OR creator=currentUser part adds issues created by the signed in user. The query does not limit results to Maya alone.

Issues reported by the currently signed in user is wrong because the query also returns issues created by Maya from the first part. The result is not limited to the current user.

Issues created by Alex Maya and the current user is wrong because Alex is excluded by the not in membersOf(“administrators”) condition so Alex will not be returned from the first part. The query therefore does not guarantee Alex is included.

Issues where the creator is any member of platform-admins is wrong because the first part explicitly excludes platform-admins members who are also administrators. That means not every platform-admins member is included and the OR may add the current user who could be outside that set.

When you parse JQL remember that AND has higher precedence than OR and check group membership overlaps to see who is removed by not in membersOf().

Users can translate project components, Users can translate the locked custom field, and Users are unable to translate the Resolution field are correct.

Users can translate project components is correct because components are project scoped and their names and descriptions can be localized within a company managed project when the localization features are used.

Users can translate the locked custom field is correct because custom field option labels and values can be localized even when the field configuration is locked, provided the localization or translation workflow for custom field options is available to the project administrators or translators.

Users are unable to translate the Resolution field is correct because Resolution is a system field with globally managed values and it is not provided as a translatable, project scoped field in company managed project localization workflows.

Users can translate issue types is incorrect because issue types are global scheme entities and they are not translated on a per project basis in company managed projects.

Users can translate priorities is incorrect because priorities are shared global entities and priority names are not localized per company managed project through the normal translation UI.

Users can translate statuses is incorrect because statuses are part of workflow definitions and they are managed globally or by workflow scheme rather than being translatable per project in company managed projects.

When a question mentions company-managed project focus on whether the item is project scoped or a global/system entity because only project scoped entities are typically localized per project.

The correct options are The mail processor was deleted, The mailbox location was modified and it is now empty, and The default reporter lost the Create Issues project permission.

The mail processor was deleted is correct because removing the processor stops the service that converts incoming mail into issues. If the handler no longer exists it will not poll or accept messages and that explains why mail that once created issues now does nothing.

The mailbox location was modified and it is now empty is correct because the processor has nothing to read when the mailbox folder or path is changed or when messages are moved. An empty or wrong mailbox location means no emails are available for conversion into issues even for previously working senders.

The default reporter lost the Create Issues project permission is correct because the mail handler often needs a valid reporter account that can create issues. If the default reporter account no longer has the Create Issues permission the handler may fail to create issues even though emails are being received.

The mailbox credentials expired is unlikely to be the root cause here because expired credentials typically produce visible authentication failures or error logs rather than the wider symptom of previously processed messages simply no longer creating issues when the processor still exists.

An issue type was removed from the mail processor configuration is not the best answer because removing an issue type would affect mappings for certain emails but it would not usually stop the entire processor from creating issues for all messages.

An issue security level is missing from the project is not the primary cause because missing security levels normally affect issue visibility or assignment rather than preventing issue creation across the board. This is less likely than a deleted processor, an empty mailbox, or a permission loss.

When troubleshooting inbound mail first verify the processor exists and the mailbox contains messages and then check that the reporter account has the Create Issues permission to quickly identify the most common failures.

The correct options are Saved filters and Workflow conditions.

A Saved filters entry can explicitly reference a group in its JQL or in its sharing settings and removing the group can break saved searches or change who can view or use the filter. For that reason saved filters are a prime place to look when you plan to remove a group.

Workflow conditions often include checks such as User Is In Group that reference a specific group to allow or block transitions. Removing the group can change workflow behavior or prevent transitions so workflow conditions must be checked.

Project roles can have groups assigned to them so they may be affected when a group is removed. They are not the first place to check for explicit group references because saved filters and workflow conditions tend to contain direct references that will immediately break functionality.

System default dashboard typically does not contain direct group references. Dashboards may include gadgets that rely on filters, so checking filters is more effective than checking the default dashboard first.

Issue type schemes define which issue types apply to projects and do not reference user groups, so removing a group will not affect issue type schemes.

When removing a group start by searching saved filters and workflow conditions because they often contain explicit group references that will break searches and transitions if the group is deleted.

The correct choices are Site administrators will add and remove group members, The same users will be active contributors across several projects, You need to assign permissions that apply across the entire Jira site, and Members must be able to perform bulk changes across many issues.

Groups are managed centrally in site administration so they are the right choice when site administrators will add and remove group members. Central management keeps membership consistent and reduces duplicate work across projects.

Using a group makes sense when the same users are active contributors across several projects because you can grant access once and reuse that group in multiple project permission schemes and configurations.

When you need to assign permissions that apply across the entire Jira site a group is appropriate because global permissions and product access are granted at the site level and are typically assigned to groups rather than individual project roles.

Bulk change is controlled by a global permission that affects many issues so granting that capability to a group makes it easier to allow members to perform bulk changes across many issues without managing membership in each project.

A project administrator will be in charge of changing the group membership is incorrect because project administrators cannot manage site groups. If project admins must control membership it is better to use project roles or project level membership options.

Team members require the “Work On Issues” permission to be assigned via a global group is incorrect because the Work On Issues permission is a project permission and it can be assigned via project roles or groups within a permission scheme. It does not have to be assigned only through a global group and using project roles often gives better per project flexibility.

For questions about groups versus project roles think about who manages membership and the scope of permissions. If membership is managed centrally or permissions must apply across the site choose group. If project admins need to control access or membership varies by project choose project role.

The correct answer is that They must be a Jira administrator or project administrator for every affected project.

When performing bulk edits across multiple projects the notification toggles are part of project configuration and the UI will only expose controls if the user has administrative authority for each project. If the user is not a They must be a Jira administrator or project administrator for every affected project the interface hides those controls to prevent unauthorized changes to project notification settings.

Outgoing mail has been disabled at the site level is incorrect because disabling outgoing mail would stop messages from being delivered but it would not explain why the bulk edit interface omits the notification controls. The visibility of those controls is driven by admin privileges rather than the mail engine being enabled or disabled.

They lack the ‘Make bulk changes’ global permission is incorrect because that global permission governs whether a user can initiate bulk operations at all. A lack of that permission would prevent performing bulk edits rather than selectively hiding the email notification toggles. The missing controls indicate a permissions scope tied to project administration instead.

When questions involve actions across multiple projects think about whether the task touches project configuration and then check whether project admin or site admin rights are required. That distinction often points to the correct answer.

The correct option is Screen Scheme.

Screens control which fields are shown on create edit and view operations and a Screen Scheme maps those operations to the specific screens used by the project. If Priya can set the Due Date on the create screen but cannot see it on the edit screen then the edit operation is using a different screen. Changing the project’s Screen Scheme so that the edit operation uses a screen that contains the Due Date field will make the field appear when editing.

Field Configuration is about field behaviors such as whether a field is required hidden or has custom help text and it does not assign fields to the create edit or view operations. Because Priya can set the Due Date when creating issues the field is not hidden so Field Configuration is not the correct setting to change.

Issue Security Scheme controls visibility of entire issues by security level and it does not determine which fields display on an edit screen. That scheme affects who can see an issue not which fields are on a screen.

Project Permissions govern who can perform actions such as creating editing or transitioning issues and they do not control the layout of fields on screens. Since Priya already can create issues changing Project Permissions would not make the Due Date appear on the edit operation.

When a field appears on one operation but not another check the screen and screen scheme mappings first because screens determine which fields are shown per operation.

The correct option is Workflow conditions.

Workflow conditions are the right choice because workflows can include conditions and validators that explicitly check an issue’s priority by its displayed name. When you change the priority labels the logic that matches those names can stop working and you must update the affected workflow conditions or switch them to use priority IDs instead.

Field configurations are not directly affected because the Priority field itself and its screen and context settings remain the same when you rename priority labels.

Automation rules are not automatically broken by a label rename because many automations operate on the underlying priority value or ID rather than the display label. If a rule explicitly referenced the old name then you would update that rule, but that is not a universal direct consequence.

Dashboards do not require a direct change simply because labels were renamed since dashboards display issue data. Some filters or gadgets that match by name might need review, but the dashboard components themselves do not need to be changed as a direct result.

When a question mentions renaming system values think about where the name is used in logic. Check workflows and validators first and prefer using ID references to avoid breakage.

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

The correct option is Javascript.

The feedback widget runs in the visitor’s browser and a custom trigger must be implemented client side so it can listen for user actions and call the widget API. That interactive behavior is implemented with Javascript, which is why Javascript is required for a custom trigger.

HTML defines the structure of the page and can host the widget markup but it cannot implement the interactive logic needed for a custom trigger, so it is not the correct choice.

JQL is a query language for searching Jira issues and it does not provide client side scripting capabilities, so it cannot be used to implement a trigger.

CSS controls presentation and styling and it cannot execute logic or handle events required to open the widget, so it is not suitable for a custom trigger.

Java runs on the server or in a different runtime than the browser and it is not the language used to implement in page widget triggers, so it is not the required language.

When a feature asks for a custom or client side trigger think about what runs in the browser and choose JavaScript for implementing event handling and calling widget APIs.

A change in the workflow post function is the correct answer.

When a transition includes a post function that sends notifications or fires an event and that post function is removed or modified the notification will not be sent when the issue moves. Workflow post functions are the usual mechanism to trigger email notifications on status changes so altering them is the most likely reason Maya did not receive the expected message.

Incoming mail handlers were removed is not the most likely cause because incoming mail handlers control creating or updating issues from email rather than sending notifications when a workflow transition occurs.

The global email processor has been disabled would affect how incoming or queued mail is processed but it is not the typical cause for a missing transition notification. Outgoing notifications depend on the mail server and notification configuration and a post function change is a more direct explanation when a single transition stops sending emails.

The default notification email prefix was changed would only alter the subject prefix of notification emails and would not prevent the notification from being sent. A prefix change would not explain why Maya received no message at all.

When a notification for a transition is missing check the transition’s post functions and the project notification scheme first. If a post function that triggers the notification was removed then restoring it often fixes the issue.

A comment will be appended to the issue “NV-5”

The mail handler in this instance is configured with the “Create a new issue or add a comment to an existing issue” type and Jira will try to thread incoming mail to existing issues before creating new ones. Jira uses the issue key in the subject or the message headers such as Message-ID and In-Reply-To to match mail to an existing issue. In this scenario forwarding the original message retains the threading headers or references to the original notification and so Jira associates the forwarded mail with the already created issue and adds it as a comment.

Not receiving an automated confirmation does not prevent the mail handler from threading the forwarded mail. The lack of a notification only affects whether Marta received an email back and does not change how the handler links the forwarded message to the existing issue.

A new issue will be created in project NV is wrong because the handler will detect that the message belongs to an existing thread and will append a comment rather than create a duplicate issue.

Both a new issue will be created and a comment will be added to “NV-5” is wrong because the mail handler does not perform both actions for the same incoming message. It either creates a new issue or appends to an existing one when it can match the message to an issue.

The forwarded email will be ignored by Jira is wrong because the handler is active and set to create or comment. The mail would only be ignored if it were malformed, identified as spam, or blocked by other mail server rules, which is not indicated in the scenario.

When answering mail handler questions focus on whether the handler matches by issue key or by message headers and then decide if the mail will be threaded into an existing issue or create a new one.

You cannot delete team-group is correct.

This is correct because when a group is configured as the default group for a product like Jira Software it is used to grant product access to new users and the group cannot be deleted while it is set as that product’s default. You must remove the group from the product’s default group setting before you can delete it.

Jira Service Management users also have Jira Software access is incorrect because configuring a default group for Jira Software only affects access to Jira Software and does not automatically grant access to Jira Service Management. Product default groups apply to the specific product named.

New Jira Software users will also need Jira Work Management to create issues in the SUP project is incorrect because the default group setting for Jira Software does not impose a requirement to have Jira Work Management. Issue creation depends on the product access and project permissions, not on adding an unrelated product.

You cannot delete confluence-users group is incorrect because being the default group for Jira Software does not make a Confluence group undeletable. A group is only protected from deletion if it is currently assigned as a default for a product or if other system rules explicitly protect it.

When you see default group in a question check which product it applies to and then consider product scope and deletion rules. A group set as a product default usually must be removed from that default setting before it can be deleted.

The correct option is Create a site backup that can be restored to a Jira Server or Data Center instance.

That operation is not supported because Jira Cloud backup exports are produced for the cloud environment and they are not compatible with on premises Server or Data Center restore processes. Cloud backups omit or transform some system and app data and the resulting package cannot be directly restored into an on premises instance.

Also note that Jira Server has been deprecated by Atlassian and Server deployments are becoming less common, so questions about restoring cloud backups to Server are less frequent on newer exams.

Download a full site backup and upload it to Google Cloud Storage for long term retention is incorrect because administrators can create and download a site backup and then store that file in external object storage such as Google Cloud Storage for long term retention.

Import attachments and other media from a Jira Cloud backup is incorrect because backups can include attachments and media and the import process can restore them when the backup was created with attachments included and size limits are met.

Restore a cloud site backup into another Jira Cloud site is incorrect because cloud site imports or restores into another cloud site are supported by the cloud administration tools, subject to compatibility and size limits and subject to the target site being prepared for the import.

Import issue and project data that originated from a Jira Server backup into the cloud site is incorrect because migrations from Server or Data Center into Jira Cloud are supported using the Jira Cloud Migration Assistant or other import tools to bring issues and project data into Cloud.

When you see backup and restore questions focus on direction of migration and format compatibility. Remember that cloud exports are not simply interchangeable with on premises Server or Data Center restores.

Team-managed project on the Scrum template is correct.

The Team-managed project on the Scrum template provides a backlog and an Agile board immediately after creation and it includes Scrum features so you can configure and run seven day sprints right away without enabling extra project features.

The Team-managed project on the Scrum template also supports quick creation of multiple issues from the backlog and the standard create flow so the team can add batches of work without additional setup. Team-managed projects are designed for team autonomy and minimal administrative configuration.

Company-managed project using the Kanban template is incorrect because the Kanban template does not provide sprint planning or sprint execution and it lacks the sprint-based backlog workflow needed for seven day sprints.

Team-managed project using the Kanban template is incorrect because Kanban is not a sprint based template and it therefore will not meet the requirement to run seven day sprints with a sprint backlog.

Company-managed project using the Scrum template is incorrect because company-managed projects often require more administrative configuration and permissions to get the same team-level, out of the box experience that the team-managed Scrum template provides.

When a question asks for Scrum features that must work immediately with minimal configuration choose a team-managed Scrum project because it is built for team autonomy and quick setup.

The correct answers are: Allow only team leads to view issues that team leads opened and Limit access so that only team leads can view and update urgent issues.

Issue security levels restrict visibility and permissions for individual issues so they are appropriate when you need to limit who can see or update particular issues without changing access for the whole project. This makes issue security well suited to cases where only team leads should view or update specific issues marked urgent or issues opened by team leads.

Prevent team leads from moving issues to other projects is incorrect because moving issues is governed by project and global permissions rather than by issue security levels. Issue security does not stop the Move operation.

Restrict who can view the development panel for an issue is incorrect because the development panel is controlled by application access and integration permissions with developer tools and not by issue security levels. You would adjust app access or integration settings to change that panel visibility.

Hide the entire project from non team leads is incorrect because issue security operates at the issue level and cannot hide an entire project. Project visibility and access are managed through project permissions and project settings.

Focus on whether the requirement applies to individual issues or to the whole project because issue security is for per issue visibility while project permissions control broader access.

Create a new select list custom field named “Severity CORE” and restrict its field context to the CORE project and the Story issue type is the correct choice.

Creating a separate select list field scoped only to CORE Story lets you show exactly the options S0 S1 S2 and S3 without changing any existing contexts or defaults that the current Severity field provides for CORE Tasks and MOBILE Bugs. It isolates the change so you can add the new field to Story screens quickly and avoid any downstream impact on reports filters or automation that reference the original field.

Create an Automation rule to set or map a hidden field for Story issues in the CORE project to emulate the new severity choices is not a good approach because automation adds ongoing maintenance and it does not give users a native select list to interact with. The user experience and filtering will be more complex and it increases operational overhead.

Edit the existing Context Core field context to add the Story issue type and include the requested options is undesirable because changing that context would alter the options and default values that currently apply to Tasks in CORE. That would risk disrupting existing work and require coordination and testing across teams.

Add a new field context for the existing “Severity” field scoped to the CORE project and the Story issue type with the requested options might seem possible but it still changes the global field configuration and can create management complexity for a field that is already used in other projects and issue types. Creating a dedicated field is the safer and lower effort choice for a narrow, project specific requirement.

When you need different choices for a single project and issue type prefer creating a separate custom field to isolate the change and minimize impact on existing contexts and defaults. Use a new field when the existing field is shared across projects.

The correct answer is Archived releases are not selectable in either the Fix Versions dropdown or the Affects Versions dropdown.

When you archive a version in Jira Cloud it is removed from the issue version pickers and cannot be chosen when creating or editing issues. That means Archived releases are not selectable in either the Fix Versions dropdown or the Affects Versions dropdown. Archived versions remain listed on the Releases page for historical reference and you can unarchive them if you need them back in the pickers.

Archived releases can still appear in both the Fix Versions dropdown and the Affects Versions dropdown is incorrect because archiving hides the version from those pickers and prevents selection.

Archived releases are selectable only in the Fix Versions dropdown is incorrect because archiving removes the version from both Fix Versions and Affects Versions and it is not selectable in either field.

Archived releases are selectable only in the Affects Versions dropdown is incorrect because archiving removes the version from both pickers and it cannot be selected in Affects Versions.

Remember that archiving hides versions from the issue version pickers but keeps them on the Releases page so check Releases if you need to unarchive a version.

Add comments to any task is correct. Viewers can see tasks when the Task issue type is restricted to Member and Viewer and they are able to add comments on those tasks.

The restriction of the Task issue type to Member and Viewer limits who can view and access the issues in the private project. Once a Viewer has access to a task they can perform actions that the permission scheme allows for their role, and adding comments is a common nonadministrative action granted to Viewer roles in many permission schemes.

Create tasks is wrong because creating an issue requires the project permission to create issues and that permission is not typically granted to the Viewer role.

Change issue security or project roles is wrong because changing issue security levels and modifying project roles are administrative actions that require project administrator privileges or specific administrative permissions, which Viewers do not have.

When a question mentions role restrictions and issue types focus on which permissions are needed for each action. View and comment are usually separate from create or admin actions so rule out answers that require administrative privileges.

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

The status mapped to the Ready for Implementation column was removed from the board and A workflow condition prevents users from executing that transition are correct.

The status mapped to the Ready for Implementation column was removed from the board explains the behavior because boards display issues based on the statuses that are mapped to columns. If the status that a transition would set is no longer mapped to any column then that board move will not be available even though other transitions continue to work, and the board UI may not show an explicit error.

A workflow condition prevents users from executing that transition also fits because workflow conditions restrict which users, groups, or roles can see or perform a given transition. When a condition blocks a user the transition option is hidden for them and they cannot move the issue, which matches the symptom of only some users being unable to move Stories and no error appearing.

A workflow validator blocks that specific transition is unlikely because validators run when the transition is executed and they normally surface a validation error if required data is missing. The scenario states that no error message appears.

The Transition Issues project permission was revoked for the affected users is unlikely because removing that permission would prevent the users from transitioning any issues in the project. The users can move issues between other columns so they still have transition privileges.

A workflow post function is interfering with the transition is unlikely because post functions run after a transition completes and they do not typically prevent the transition from being offered on the board. A post function failure would not usually cause the transition to be hidden without an error.

The affected users no longer have Jira Software access is unlikely because users without product access cannot use boards to move issues at all. The fact that these users can move Stories between other columns shows they still have Jira Software access.

When a board move silently fails check the board’s status mappings first and then review workflow conditions for that transition. That sequence will quickly reveal whether the column lost its status or whether the transition is hidden for some users.