ACP-120 Jira Certification Sample Questions

A talent operations group uses a weekly subscription to a saved filter that uses the JQL query project = PEOPLEOPS and resolved > startOfWeek() The subscription delivers the filter results each Friday to the team. After a configuration update some team members reported getting an empty email while other members received a list of issues. What explains this behavior?

• ❏ A. The subscription is configured to dispatch emails even when the filter returns no issues

• ❏ B. The returned issues include an issue security level that hides them from some recipients

• ❏ C. Several recipients do not have browse permissions to see the issues returned by the saved filter

• ❏ D. The query returns more issues than Jira includes in a notification and the email appears empty

Aisha must enforce stricter issue visibility in her project at Solstice Solutions. The project lead must be able to view every issue. Payroll and Human Resources must both see HR specific tickets. Only the security group should view issues tagged as security. Developers should only be able to view issues that are assigned to them. How many issue security levels are required to meet these conditions?

• ❏ A. Three security levels

• ❏ B. Two security levels

• ❏ C. One security level

• ❏ D. Four security levels

Your team at RivaCorp has provisioned a new Jira Cloud site with Jira Software enabled only and you then created six projects that share the same configuration. There are many Project Management Officers in the business and you want to keep the Jira setup scalable and easy to maintain. Which requirement can only be satisfied by using a “PMOs” project role?

• ❏ A. PMOs need to perform bulk edits across the entire site

• ❏ B. Only particular PMOs should be able to create issues in specific projects

• ❏ C. Only PMOs who are designated as Project Leads may view issues at a restricted security level in their own projects

• ❏ D. All PMOs must be able to view the read only workflow in every project

• ❏ E. Some PMOs should be selectable in a custom field only for certain projects

BrightLeaf Solutions plans to migrate from an old time tracking system to Jira Cloud and the operations lead asked you to make logging time as simple as before for all staff. Everyone expects to keep entering time in days by default when they log work in Jira. What action should you take to ensure the default unit remains days?

• ❏ A. Change the global time tracking “Time display format” to show days

• ❏ B. Assume Jira Cloud already uses days as the “default unit” so no changes are required

• ❏ C. Update the global time tracking configuration to set the “default unit” to “day”

• ❏ D. Grant every user the project permission to work on issues so they can log time

Maya’s team is using the Default Screen Scheme and they need to add several screens to a company managed project that contains three issue types namely Bug Task and Story. The requirements are that Bug must have a new screen for the View operation and for the Edit operation Task must have a new screen for the Edit operation and for the Create operation and Story must have a new screen for the View operation. The Done status must use a new transition screen. How many new screen schemes must Maya create?

• ❏ A. Five screen schemes

• ❏ B. Two screen schemes

• ❏ C. Three screen schemes

• ❏ D. One screen scheme

• ❏ E. Four screen schemes

A small feature squad at NebulaOps must independently administer its project and each project requires a distinct configuration while the team prefers uncomplicated workflows. Which Jira project type should they choose?

• ❏ A. Company-managed project

• ❏ B. Team-managed project

Maya discovered several tickets assigned to the wrong person and labeled with the incorrect issue type in her new role at a consultancy. She only has the “Browse projects” permission so she can view the tickets. What steps should Maya take to change both the issue type and the assignee on multiple tickets? (Choose 3)

• ❏ A. Use the bulk change tool with a “Move Issues” operation to change both fields

• ❏ B. Request the “Make bulk changes” global permission

• ❏ C. Request the “Assign Issues” project permission

• ❏ D. Request the “Move Issues” project permission

• ❏ E. Request the “Edit Issues” project permission

• ❏ F. Use a bulk change with an “Edit Issues” operation to modify both the issue type and the assignee

Ava from HarborTech has several obsolete workflow statuses in her company-managed projects. What steps must Ava follow to remove an unused status from a company-managed project? (Choose 3)

• ❏ A. Create a duplicate of the active workflow

• ❏ B. Request project administrator permissions

• ❏ C. Remove the status directly from the active company-managed workflow

• ❏ D. Attach the revised workflow copy to the workflow scheme used by the project

• ❏ E. Use the Jira REST API to delete the status across workflows

• ❏ F. Delete the unused status from the duplicated workflow version

A delivery team at Nimbus Solutions wants to receive email alerts when a saved Jira filter matches issues. Which of the following statements about setting up a filter subscription in Jira Cloud is true?

• ❏ A. You can specify more than one Jira group as recipients for a single subscription

• ❏ B. A subscription will never send an email if the saved filter returns no issues

• ❏ C. A project role can be chosen as a recipient for filter subscription notifications

• ❏ D. A user does not need Browse Projects permission to create a subscription

• ❏ E. A subscription can be scheduled using an advanced cron expression

Maya just created her first team-managed project from a Kanban template for her squad and she needs to define a custom role for contributors in that project. Which project settings section allows Maya to create and manage project roles?

• ❏ A. Features

• ❏ B. Issue Types

• ❏ C. Access

• ❏ D. Board

• ❏ E. Details

The People Ops lead at BrightLayer told you what the previous Jira administrator reported. Statement one says that the system has no capability to permit a user to remove attachments uploaded by other users. Statement two says that the system has no capability to let a user edit other users’ time logs. What is your assessment of those two claims?

• ❏ A. Statement one is incorrect and statement two is correct

• ❏ B. Both statements are incorrect

• ❏ C. Statement one is correct and statement two is incorrect

• ❏ D. Both statements are correct

Asha needs to back up a Jira Cloud site and import that backup into a separate Jira Cloud account. Which of the following kinds of data can be included in a Jira Cloud export? (Choose 3)

• ❏ A. Third party apps and app data

• ❏ B. Automation rules

• ❏ C. User accounts and group memberships

• ❏ D. Advanced Roadmaps

• ❏ E. Media files including attachments avatars and logos

Priya created and set up a new company-managed project from a Kanban blueprint for her engineering group and after a recent configuration change team members reported that a custom field no longer appears on one of the issue screens. Priya inspected all screen configurations and field layouts and determined the field should be visible. Why are the users unable to see the custom field?

• ❏ A. The issue type screen scheme assignment is incorrect for this project

• ❏ B. The field is marked as hidden in the field configuration

• ❏ C. The custom field context excludes the project or the issue type

• ❏ D. The associated screen scheme is set up incorrectly

• ❏ E. The project configuration is still propagating after project creation

A mid size consultancy called NovaWorks shows these tenant default user settings in the admin console with Default outgoing email format HTML, Number of issues displayed per navigator page 60, and Default sharing for filters and dashboards Public while many users report that their saved filters and dashboards are being created as Private. Which two administration settings should be checked and updated if required so that new filters and dashboards are automatically shared publicly? (Choose 2)

• ❏ A. Project permissions

• ❏ B. Site general configuration settings

• ❏ C. Global permission grants

• ❏ D. Personal user preferences

• ❏ E. Instance user default settings

• ❏ F. Filter and dashboard scheme

Maya manages the project “ALP” and that project currently contains two versions named “3.0” and “3.1”. Maya needs to remove version “3.0” from the project and move all issues that are assigned to “3.0” into version “3.1”. Which actions on the Releases page will allow Maya to accomplish this? (Choose 2)

• ❏ A. Unrelease

• ❏ B. Merge

• ❏ C. Release

• ❏ D. Archive

• ❏ E. Delete

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

A project administrator named Mateo must enforce several workflow rules for a support project. He needs the system to assign the ticket to the component owner after the transition finishes. He must change a custom field to a new value while the transition is in progress. He must also validate that a user holds a specific permission before allowing the transition to proceed. He only wants the “Done” transition button to be visible to users who have that permission. He needs attachment deletion to be limited to the managers group when an issue is in a particular status. Which combination of workflow elements fulfills these requirements?

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

• ❏ B. 1 Condition, 1 Validator, 1 Post Function, and 2 Status Properties

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

• ❏ D. 1 Condition, 2 Validators, 2 Post Functions, and 0 Status Properties

You are auditing a large Jira Cloud deployment at MeridianApps and you discover that many dashboards and filters are shared with the Public. You escalated the finding to the Chief Information Security Officer who wants a low impact remediation plan. Your review shows that the global setting “Allow users to share dashboards and filters with the public” is ON and the default user preference “Default sharing for filters and dashboards” is set to Public. What is the best course of action? (Choose 2)

• ❏ A. Use the REST API to bulk update existing filters to set their sharing to organization-only

• ❏ B. Disable the global setting “Allow users to share dashboards and filters with the public”

• ❏ C. Restrict the global permission Share dashboards and filters to the group org-admins

• ❏ D. Ask owners of public filters to change their filters to share with any logged-in users in the organization

• ❏ E. Restrict the permission Manage group filter subscriptions to the group site-ops

• ❏ F. Open a support ticket with Atlassian support

Lena can open every issue in the project but she cannot reorder items in the sprint backlog on the Scrum board. Which project permissions should Lena request to obtain the needed access? (Choose 2)

• ❏ A. Move Issues

• ❏ B. Schedule issues

• ❏ C. Transition Issues

• ❏ D. Browse Projects

• ❏ E. Edit issues

• ❏ F. Manage sprints

Which capabilities are supported in a team managed project in Jira Cloud for project administrators? (Choose 2)

• ❏ A. Team managed projects can share their configuration with each other

• ❏ B. Custom swimlanes can be defined using JQL queries

• ❏ C. You can enable a backlog for Kanban team managed projects

• ❏ D. Issue security can restrict issue visibility to specific groups or roles

• ❏ E. Notifications can be sent to a selected set of project roles

Your team manages a company managed project named OPS that uses two issue types called Story and Task. Which of the following requirements can be fulfilled by changing field configurations? (Choose 2)

• ❏ A. For the Story issue type change the description on the “Summary” system field to “Brief Overview”

• ❏ B. For the Story issue type set the “Acceptance Criteria” paragraph custom field to use a wiki style renderer so it can display bold and colored text

• ❏ C. For the Story issue type set the default for the “Description” system field to “As a user I want X because Y”

• ❏ D. For the Task issue type assign the default value for the “Priority” system field to “Low”

• ❏ E. For both issue types remove the “Labels” field from the create screen and add it back to the edit screen using screen schemes

• ❏ F. For both issue types hide the assignee field when a component is selected during issue creation

The Platform team at NovaApps is adding Jira to their CI and CD pipeline and they report they cannot set the fix version field on issues in company managed projects and they also cannot easily populate user picker fields even though they can create and edit all issues. What additional configuration is required while adhering to the least privilege principle? (Choose 2)

• ❏ A. Grant the Platform team the “Manage project roles” project permission

• ❏ B. Grant the Platform team the “Browse users and groups” global permission

• ❏ C. Grant the Platform team the “Schedule issues” project permission

• ❏ D. Grant the Platform team the “Resolve issues” project permission

• ❏ E. Grant the Platform team the “Browse projects” project permission

• ❏ F. Grant the Platform team the “Administer Jira” global permission

Diego is an Atlassian Certified Expert who works for a partner called NOVA Solutions and he uses the email [email protected] to access multiple client cloud sites. NOVA Solutions and two of Diego’s client companies recently verified their domains and activated Atlassian Access with identity providers as shown below. Organization name Verified domain Identity provider NOVA Solutions nova.com Google STAR VOYAGES star-voyages.com Okta LUNA GETAWAYS luna-getaways.com Azure Which statement about Diego is correct?

• ❏ A. He can continue to use his Atlassian account credentials to sign in to NOVA Solutions STAR VOYAGES and LUNA GETAWAYS

• ❏ B. He will be prevented from signing in to STAR VOYAGES and LUNA GETAWAYS

• ❏ C. He will be redirected to Google when he attempts to sign in to STAR VOYAGES

• ❏ D. He will be redirected to Azure when he attempts to sign in to STAR VOYAGES

Diego has just created a company managed scrum project from a template and named it ORION. He wants to know which configuration schemes Jira created specifically for the new ORION project. Which schemes are unique to the newly created ORION project? (Choose 3)

• ❏ A. Field Configuration Scheme

• ❏ B. Screen Scheme

• ❏ C. Notification Scheme

• ❏ D. Workflow Scheme

• ❏ E. Issue Security Scheme

• ❏ F. Issue Type Scheme

• ❏ G. Permission Scheme

Which recipient types are available to add when you configure notifications for a team-managed project in a Jira Cloud site? (Choose 3)

• ❏ A. Component lead

• ❏ B. Signed in user

• ❏ C. Individual by email address

• ❏ D. Project watcher

• ❏ E. Project role

• ❏ F. Project lead

A team member reports a spelling error in the description of the custom field “Completion Criteria” and you update the field description from the custom fields administration. The custom field is in the company-managed project “ORB” and you save the change. When you open the create issue screen in that project the old misspelling still appears as if your edit did not apply. Why is the original text still shown?

• ❏ A. Update the Completion Criteria description in the ORB project field configuration

• ❏ B. Wait for a Jira background reindex to complete

• ❏ C. Clear the browser cache

• ❏ D. Delete the Completion Criteria custom field and recreate it with the corrected description

• ❏ E. Remove the Completion Criteria field from the screen and then add it back

Lina was granted a role that includes the “Move Issues” permission but she still cannot transfer issues into some projects. Which configuration settings could be preventing her from moving those issues? (Choose 2)

• ❏ A. Field configuration

• ❏ B. Workflow property

• ❏ C. Issue security scheme

• ❏ D. Workflow condition

• ❏ E. Project permissions

Alex requested a role that grants permission to change the reporter but still cannot edit the reporter field when an issue is in the Completed status. Which configuration is stopping the reporter from being edited?

• ❏ A. Permission scheme

• ❏ B. Workflow status property

• ❏ C. Field configuration

• ❏ D. Issue security scheme

• ❏ E. Workflow condition

In a Jira Cloud administration scenario at NovaSoft which items can be associated with a project role? (Choose 3)

• ❏ A. Application access

• ❏ B. Dashboard access

• ❏ C. Group membership

• ❏ D. Issue security level

• ❏ E. Global permissions

• ❏ F. Filter subscriptions

Many issues in the Completed state at Nimbus Solutions have an empty Resolution field even though the work is finished. Priya needs to set the Resolution value for those issues to the appropriate option. Which configuration areas must Priya change? (Choose 3)

• ❏ A. Project workflow post function on the transition that closes issues

• ❏ B. Global permission to make bulk changes

• ❏ C. Project permission to transition issues

• ❏ D. Automation rule that updates fields

• ❏ E. Issue status scheme

• ❏ F. Resolution field scheme

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

A fintech startup is preparing to import outside files into its Jira Cloud environment and the team needs to know which file types the import wizard does not accept when bringing in external data? (Choose 3)

• ❏ A. ZIP

• ❏ B. Trello

• ❏ C. HAR

• ❏ D. JSON

• ❏ E. RAR

• ❏ F. CSV

Ravi needs his Kanban board at Brightline Studio to only display issues that use the marketing component without requiring anyone to click filters on the board, and he also wants this board restriction to leave the Pie Chart report data unchanged. Which Jira feature should he use?

• ❏ A. Quick Filters

• ❏ B. Board Filter

• ❏ C. Swimlanes

• ❏ D. Board Sub-Filter

• ❏ E. Issue Detail View

• ❏ F. Hide resolved issues

Maya noticed several obsolete issue types in a company managed project at BlueWave Solutions. Which project configurations should she inspect before removing an issue type? (Choose 3)

• ❏ A. Notification schemes

• ❏ B. Screen schemes

• ❏ C. Permission schemes

• ❏ D. Field configurations

• ❏ E. Issue security schemes

• ❏ F. Workflow schemes

Liam manages his group projects at Nova Systems and he can see every issue in a particular project. No one has ever created issue links in that project and his colleagues want to begin linking related issues. Which project and system settings must he modify so that team members can add links between issues in that project? (Choose 2)

• ❏ A. Application links

• ❏ B. Project permission to Link Issues

• ❏ C. Issue linking setting

• ❏ D. Issue security scheme

• ❏ E. Global permissions

At Acme Software the support team needs to update many tickets at once and they are evaluating Jira Cloud bulk change. Which actions are not supported by Jira Cloud bulk change operations? (Choose 2)

• ❏ A. Transition issues

• ❏ B. Clone issues

• ❏ C. Stop watching issues

• ❏ D. Remove votes from issues

• ❏ E. Edit issues

• ❏ F. Move issues

Lena set up a custom notification for her product squad and she needs the recipients to include All watchers Component lead and User picker. Which Jira project type will allow selecting those recipients?

• ❏ A. Both project types support these recipients

• ❏ B. Neither project type supports these recipients

• ❏ C. Team-managed projects

• ❏ D. Company-managed projects

The configuration for the company managed project NOVA is shown below. Project Lead Martin. Default assignee Project Lead. Components are Aurora with component lead Lila and default assignee Component Lead. Borealis with component lead Marco and default assignee Component Lead. Zenith with component lead Priya and default assignee Project Default. Horizon with component lead Anya and default assignee Unassigned. You create a new issue, choose all four components and assign Sam as the assignee. Who will receive the newly created issue?

• ❏ A. Marco

• ❏ B. Sam

• ❏ C. Lila

• ❏ D. Martin

• ❏ E. Priya

Who is allowed to create new project roles and update role definitions for an organization managed project?

• ❏ A. Project administrators

• ❏ B. Site administrators

• ❏ C. All administrators

• ❏ D. Jira administrators

Marisol needs a weekly email every Friday that contains a consolidated list of all issues marked as critical. Which Jira features will allow her to receive that single email? (Choose 2)

• ❏ A. Automation

• ❏ B. Subscription

• ❏ C. Notifications

• ❏ D. Filters

• ❏ E. Webhook

• ❏ F. Global Permission

Aisha at Orion Solutions must transfer every issue from a team managed project into an organization managed project. Which statement is accurate about what will be preserved during this migration?

• ❏ A. Issue keys will remain the same after migration

• ❏ B. Only a subset of data in existing system fields from the team managed project will carry over

• ❏ C. All values from custom fields created in the team managed project will be preserved

• ❏ D. Every value in the standard system fields from the team managed project will remain intact

Maya’s group has grown to 22 people and will split to keep its agility. One subgroup will continue using the company managed project “CORE” and the other subgroup will adopt a new project “LEGAL” that was created by sharing the configuration from “CORE”. Each subgroup may need to change its project configuration to meet client needs. Which requirement makes it necessary to create a separate issue type scheme?

• ❏ A. The “LEGAL” Bug issue type needs a different create screen from the Bug issue type in the “CORE” project

• ❏ B. The “LEGAL” Bug issue type requires a unique workflow that differs from the workflow used by the Bug issue type in the “CORE” project

• ❏ C. The team using the “LEGAL” project needs to rename the Bug issue type while the team using the “CORE” project must keep the existing name because of downstream impacts

• ❏ D. The “LEGAL” Bug issue type needs to be translated into French rather than using the same label as in the “CORE” project

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

Maya’s group needs a new Jira Software project for an upcoming release. They require stories and tasks to use separate workflows and they want to publish a new version directly from the board. Which project type satisfies all of these requirements?

• ❏ A. Team managed Scrum

• ❏ B. Company managed Kanban

• ❏ C. Team managed Kanban

• ❏ D. Company managed Scrum

Miguel is a scrum master at Nimbus Software and has worked with Jira for many years. He recently received access to the Governance company-managed project and reports that he cannot change an issue that he created in that project even though he can modify other issues where he is the assignee. Which configuration should be adjusted so Miguel can edit the issue he reported?

• ❏ A. Product access

• ❏ B. Global permissions

• ❏ C. Issue security scheme

• ❏ D. Project permissions

The correct answer is Several recipients do not have browse permissions to see the issues returned by the saved filter.

This occurs because Jira delivers the saved filter results to every subscriber but each recipient only sees the issues they are permitted to view. If some team members lost the project browse permission or if the permission scheme changed then their subscription emails will appear empty while other members still receive the list of issues.

The subscription is configured to dispatch emails even when the filter returns no issues is incorrect because that setting would cause all subscribers to receive empty emails when the filter has no results. The scenario describes only some recipients getting empty messages which indicates a per user visibility difference rather than a global send setting.

The returned issues include an issue security level that hides them from some recipients is incorrect in this context because issue security would hide specific issues from certain users and it is a separate mechanism. It can cause visibility differences but the described behavior most closely matches a change in browse project permissions. You should still check issue security if needed.

The query returns more issues than Jira includes in a notification and the email appears empty is incorrect because Jira may truncate long lists in notifications but it would still show some issues or a truncation notice. Truncation would affect all recipients equally and would not explain why some users see a list while others see nothing.

When subscription emails vary by recipient check browse project permissions first and then review issue security and the filter subscription settings.

Two security levels is the correct answer.

You need one security level for HR related tickets that grants Payroll and Human Resources access while also including the project lead so the lead can view every HR issue. You need a second security level for security tagged issues that grants only the security group and the project lead access so those issues remain confidential.

Developers only seeing issues assigned to them does not require its own issue security level when you use the project permissions together with the default or unassigned visibility. You can keep general issues at the default visibility and rely on the assignee and project permissions to ensure developers only see their assigned work, so no additional security level is required for that rule.

Three security levels is incorrect because adding a third distinct level is not necessary to separate HR and security visibility when the assignee requirement can be handled by permissions or the default visibility.

One security level is incorrect because a single level cannot provide distinct access for both HR plus Payroll and a separate exclusive view for the security group while also keeping developers limited to assigned issues.

Four security levels is incorrect because it introduces an unnecessary extra level beyond what is needed to represent the two distinct restricted audiences in this scenario.

Count distinct visibility audiences and remember that project permissions can handle assignee only visibility so you only need security levels for truly distinct groups.

Only particular PMOs should be able to create issues in specific projects is correct.

Using a project role called PMOs lets you grant the Create Issues permission in a project permission scheme to that role. This means you can populate the PMOs role with different users in each project and only those users will be able to create issues in the projects where they are assigned. Project roles are designed for per project assignment and permission mapping.

PMOs need to perform bulk edits across the entire site is incorrect because bulk change is a global permission that applies across the site and is granted via global permissions or site level groups rather than a per project role.

Only PMOs who are designated as Project Leads may view issues at a restricted security level in their own projects is incorrect because issue security schemes do not natively express a logical requirement that a user must both be in a given project role and also be the project lead. Issue security can reference project roles or specific users but combining those two attributes as a single rule is not something a project role alone enforces.

All PMOs must be able to view the read only workflow in every project is incorrect because workflow visibility and administrative views are controlled by global or project permissions and by who is added to shared schemes. Granting a site wide ability to view workflows is typically done with global groups or permission schemes rather than a single project role that is only assigned inside projects.

Some PMOs should be selectable in a custom field only for certain projects is incorrect because custom field contexts let you limit which projects a custom field or its options apply to and you can use groups or project specific configurations to control selectable users. That requirement can be met without introducing a dedicated project role.

When a requirement must be applied differently across projects think of project roles and the project permission scheme. Use project roles when you need per project membership that maps to project level permissions.

The correct option is Update the global time tracking configuration to set the “default unit” to “day”.

You change the companywide default by editing the global time tracking configuration in Jira administration and the Update the global time tracking configuration to set the “default unit” to “day” setting determines which unit is preselected when users log work, so configuring it to day makes days the default for everyone.

Change the global time tracking “Time display format” to show days is wrong because the display format only affects how durations are presented, and it does not set the default unit that is selected when logging time.

Assume Jira Cloud already uses days as the “default unit” so no changes are required is wrong because a Jira instance may use a different default and you must verify and set the global default to ensure days are used by everyone.

Grant every user the project permission to work on issues so they can log time is wrong because changing project permissions does not change the default time unit, and permission changes are not required to set the unit that appears when users enter time.

When a question asks to change a default behavior for all users think about global admin settings and check the Jira time tracking configuration in Site administration rather than changing display options or permissions.

Two screen schemes is correct.

You begin from the Default Screen Scheme and you only need two additional screen schemes to meet the requirements while reusing screens where possible. One screen scheme can map View to a new screen and Edit to a new screen while leaving Create on the default screen and you can assign that scheme to Bug and to Story. A second screen scheme can map Create and Edit to new screens while leaving View on the default screen and you assign that scheme to Task. The Done transition screen is a workflow transition screen and not part of a screen scheme so it does not add to the number of screen schemes.

Five screen schemes is wrong because you can reuse screens and group issue types under shared screen schemes so you do not need a separate scheme for every individual operation and issue type combination.

Three screen schemes is wrong because the differing Create Edit and View needs can be covered by two schemes when you reuse screens and assign schemes across issue types.

One screen scheme is wrong because the issue types require different operation level mappings so a single scheme would force unnecessary changes to operations for some issue types or fail to meet the specific Create Edit and View combinations without extra unwanted impact.

Four screen schemes is wrong because it overcounts the necessary schemes given that two distinct scheme mappings are sufficient and screens can be reused across schemes.

When you see questions about screens count the distinct operation level mappings you need and remember that screens can be reused and that transition screens are separate from screen schemes. This helps you find the minimal number of new schemes.

The correct answer is Team-managed project.

This option gives a small feature squad the ability to administer its own project and to create distinct configurations while keeping workflows uncomplicated. Team managed projects put control in the hands of project admins so the team can adjust workflows, issue types, screens, and permissions without needing a site administrator which matches the requirement for independent administration and simple processes.

Company-managed project is not the best choice because it relies on shared schemes and centralized administration. Changes to workflows and schemes often require a Jira administrator which adds complexity and reduces team autonomy. That model is better suited for organizations that need strict standardization across many teams rather than for an independent squad that wants separate, simple configurations.

When a question emphasizes independence, simple workflows, or project level configuration prefer the project type designed for team autonomy rather than the one built for centralized control.

The correct options are Request the “Make bulk changes” global permission, Request the “Edit Issues” project permission, and Use a bulk change with an “Edit Issues” operation to modify both the issue type and the assignee.

The Request the “Make bulk changes” global permission is required because bulk operations are controlled by a global permission. Without that global permission Maya will not be able to start or execute a bulk change even if she can see the issues.

The Request the “Edit Issues” project permission is required because changing fields such as issue type and assignee is an edit action at the project level. Granting Edit Issues lets the user modify those fields during a bulk edit.

The Use a bulk change with an “Edit Issues” operation to modify both the issue type and the assignee is the correct operation because the bulk Edit action lets you update multiple fields on many issues at once. That operation can change the Issue Type field and the Assignee field for all selected issues in a single workflow.

Use the bulk change tool with a “Move Issues” operation to change both fields is incorrect because the Move operation is intended for transferring issues between projects or adjusting properties while moving. It is not the standard bulk action to edit fields like assignee across multiple issues in place.

Request the “Assign Issues” project permission is incorrect because the Assign Issues permission controls assigning single issues at the project level. Bulk assignment as part of a bulk edit relies on the Edit Issues permission rather than the Assign Issues permission.

Request the “Move Issues” project permission is incorrect because that permission only allows moving issues between projects and is not required to perform field edits during a bulk Edit operation.

Remember that bulk operations require the Make bulk changes global permission and that changing fields in bulk requires the Edit Issues project permission.

The correct steps are Create a duplicate of the active workflow, Delete the unused status from the duplicated workflow version, and Attach the revised workflow copy to the workflow scheme used by the project.

You must start by creating a copy of the active workflow so you have a draft you can safely change without disrupting the live workflow. Editing the copy lets you remove or modify statuses and transitions and then test the changes before applying them.

Once you have the duplicated workflow you remove the unused status from that copy. Removing the status in the duplicate prevents unintended impact on issues that still rely on the original workflow and ensures the status is no longer referenced in transitions or mappings.

After revising the copy you publish it and associate it with the project by attaching it to the workflow scheme the project uses. Applying the updated workflow through the workflow scheme is what causes the project to start using the version that no longer includes the obsolete status.

Request project administrator permissions is incorrect because changing company managed workflows typically requires Jira administrator or specific workflow administration rights rather than only project administrator permissions.

Remove the status directly from the active company-managed workflow is incorrect because you cannot safely edit or remove statuses from an active company managed workflow without creating and publishing a revised copy first.

Use the Jira REST API to delete the status across workflows is incorrect because deleting a status globally is not the standard supported way to update a company managed workflow and it will not substitute for the required workflow copy, edit, and association steps.

When you see questions about company managed workflows remember to copy or draft the workflow, make your changes, and then associate the updated workflow with the project via the workflow scheme.

A subscription can be scheduled using an advanced cron expression is correct.

This is correct because Jira Cloud lets you schedule filter subscriptions using cron style expressions so you can define complex recurring schedules for when the filter should run and send emails to recipients.

You can specify more than one Jira group as recipients for a single subscription is incorrect because a filter subscription does not allow selecting multiple groups as recipients in a single subscription entry in the way that option suggests.

A subscription will never send an email if the saved filter returns no issues is incorrect because subscriptions can still run according to their schedule and may send notifications that report zero matching issues depending on the subscription configuration and implementation.

A project role can be chosen as a recipient for filter subscription notifications is incorrect because project roles are not accepted as direct recipient targets for filter subscriptions in Jira Cloud in the same way individual users or groups are.

A user does not need Browse Projects permission to create a subscription is incorrect because creating and receiving meaningful filter subscription results depends on the user having appropriate permissions to view the projects and issues returned by the saved filter.

When you see options about scheduling or permissions focus on the official filter subscription documentation and the cron expression support. Watch for answers that try to trick you with subtle permission or recipient rules.

The correct option is Access.

The Access section in a team-managed project is where Maya can create and manage project roles for contributors and assign people to those roles. In team-managed projects the Access area controls membership and role-level permissions so it is the appropriate place to define a custom contributor role after creating the Kanban project.

Features is incorrect because that area toggles project features and settings rather than managing roles and membership.

Issue Types is incorrect because that section is used to configure the types of issues and their fields and workflows rather than to create or assign roles.

Board is incorrect because board settings control columns, filters, and card display for the Kanban board and they do not handle project role creation.

Details is incorrect because that section holds basic project metadata such as name, key, and description and it does not provide role management capabilities.

When a question asks where to manage roles in a team-managed project look for settings labelled Access or membership rather than board or issue type sections.

The correct answer is Both statements are incorrect.

Statement one is incorrect because Jira can be configured to allow users to remove attachments uploaded by other users. Administrators or users granted the appropriate project permission can delete attachments that were added by someone else, so the claim that the system has no capability to permit that is false.

Statement two is incorrect because Jira has worklog permissions that let a user edit other users’ time logs when granted. There is a separate permission that allows editing of all worklogs so the platform can be configured to permit users to edit time entries created by other users.

Statement one is incorrect and statement two is correct is wrong because statement two is not correct and statement one is also false, so that option does not match the actual capabilities.

Statement one is correct and statement two is incorrect is wrong because statement one is not correct, and the system does provide a way to remove others’ attachments when permissions are granted.

Both statements are correct is wrong because both claims are false and Jira provides permissions to delete others’ attachments and to edit others’ worklogs when those permissions are assigned.

When an exam statement denies a capability, check whether there is a specific permission that enables that capability. Look for permission names like Delete All Attachments or Edit All Worklogs to confirm whether the platform can perform the action.

The correct answers are User accounts and group memberships, Advanced Roadmaps and Media files including attachments avatars and logos.

A Jira Cloud site export includes User accounts and group memberships when using the site backup and restore or import workflows so that user identities and group associations can be preserved on the destination site. This preserves permissions and user assignments linked to issues and projects during the import.

The export can also include Advanced Roadmaps related configuration and plan data as part of the Atlassian product data that is captured in a site archive. Including this data helps keep planning hierarchies and plan settings when moving between Cloud sites.

In addition a site export includes Media files including attachments avatars and logos which ensures that attachments and visual assets referenced by issues and projects are transferred alongside the issue data.

Third party apps and app data are not included because most app data is stored and managed by the app itself and requires separate export or reinstallation on the target site. Backups do not guarantee preservation of app specific data.

Automation rules are typically not included in a site archive and must be recreated or exported through their own mechanisms. Automation configurations are considered separate from the core site backup in most Jira Cloud export processes.

When answering export questions look for whether the item is native Jira product data or provided by an app. Native data like users and attachments is usually included while app data and automation rules are usually excluded.

The custom field context excludes the project or the issue type is the correct answer. Custom field contexts control which projects and which issue types a custom field applies to, and if the context excludes this project or the specific issue type the field will not appear even when the screen and field layout include it.

The custom field context can be scoped to a subset of projects or issue types so the field will be invisible for any issue that falls outside that scope. This check is often missed because screens and field configurations look correct, but the context is evaluated before the field is rendered on the issue screens.

The issue type screen scheme assignment is incorrect for this project is incorrect because an incorrect issue type screen scheme would affect which screens are used for a given issue type. Priya inspected screen configurations and field layouts and found the field present on the screens, so a wrong issue type screen scheme is not the cause.

The field is marked as hidden in the field configuration is incorrect because a hidden field in the field configuration would be globally hidden regardless of context. The scenario states that the field appears correctly in configurations, which makes a hidden field configuration unlikely.

The associated screen scheme is set up incorrectly is incorrect for the same reason as the issue type screen scheme. If the screen scheme were incorrect the screens themselves would not contain the field, but Priya verified the screen and field layout settings and they include the field.

The project configuration is still propagating after project creation is incorrect because propagation delays are not a typical cause in company managed projects for an existing field suddenly not showing. The problem is a scope limitation of the custom field rather than an ongoing propagation of project settings.

When a custom field is missing check the custom field context first and then verify screens and field configuration. Contexts often silently exclude projects or issue types and they are easy to overlook.

The correct answers are Site general configuration settings and Global permission grants.

Site general configuration settings is correct because the system level configuration controls default behaviors for saved objects across the tenant and it is where administrators can confirm or change the default sharing for filters and dashboards so that new items are created as public.

Global permission grants is correct because even if the site default is set to public, users still need the appropriate global permission to create or share filters and dashboards publicly and updating these grants for the right groups ensures new saved items inherit public visibility.

Project permissions is not correct because project permissions govern actions within individual projects and do not set tenant wide defaults for filter and dashboard sharing.

Personal user preferences is not correct because individual user preferences affect only that user and they do not override or replace the system level default or the global permissions that control sharing capabilities.

Instance user default settings is not correct because those settings refer to individual account defaults and are not the central place to enforce tenant wide sharing behavior for filters and dashboards.

Filter and dashboard scheme is not correct because there is no scheme that centrally replaces the site default and global permission model for controlling whether new filters and dashboards are shared publicly.

First check the site or system default settings and then verify the global permissions for groups that should be allowed to create public filters and dashboards.

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

Merge and Delete are correct because both actions allow Maya to remove version “3.0” while moving its issues into version “3.1”.

Merge combines the source version into the target version and reassigns issues so that the issues previously assigned to the source become assigned to the chosen target version, which accomplishes the move in one operation.

Delete removes the version and presents an option to reassign its issues to another existing version, so Maya can delete “3.0” and choose “3.1” as the destination for all issues.

Unrelease is incorrect because changing a release state only toggles whether a version is marked released and does not move issues between versions.

Release is incorrect because marking a version as released only records its delivery status and does not transfer issues to a different version.

Archive is incorrect because archiving hides or de-emphasizes a version but does not reassign its issues into another version and does not remove the version in the same way that delete or merge do.

When consolidating versions look for the actions that explicitly mention moving or merging issues and always read the prompts before confirming to ensure you select the correct target version.

1 Condition, 2 Validators, 1 Post Function, and 1 Status Property is correct.

The visibility requirement for the Done button is satisfied by a condition on the transition so only users with the required permission will see that transition. A condition controls whether the transition is presented to the user and is the right way to hide the button from users who do not hold the permission.

One validator enforces the permission at transition execution so the transition cannot be bypassed even if someone tries to call it directly. A second validator is used to ensure the custom field has been changed to the required new value while the transition is in progress. In practice you collect the new value on the transition screen and a validator verifies that the field has been set before the workflow proceeds.

A post function assigns the issue to the component owner after the transition finishes. Post functions run as part of the transition and are the correct mechanism to change the assignee after the transition completes.

A status property restricts attachment deletion to a specific group when an issue is in a particular status. Adding a workflow status property that limits deletion to the managers group meets that requirement.

1 Condition, 1 Validator, 1 Post Function, and 2 Status Properties is incorrect because it provides only one validator but the scenario requires two separate runtime checks and it miscounts the status properties that are needed to restrict attachment deletion for a single status.

2 Conditions, 1 Validator, 1 Post Function, and 1 Status Property is incorrect because you only need one condition to control the Done button visibility and the scenario requires two validators to both enforce the permission at execution time and to verify the custom field change.

1 Condition, 2 Validators, 2 Post Functions, and 0 Status Properties is incorrect because it omits the status property that is needed to limit attachment deletion to the managers group and it adds an extra post function that is not required to meet the stated requirements.

When a question separates visibility from enforcement map visibility to a Condition and runtime checks to a Validator. Use post functions for changes after transition and status properties to control behavior while in a status.

The correct answers are Disable the global setting “Allow users to share dashboards and filters with the public” and Ask owners of public filters to change their filters to share with any logged-in users in the organization.

Turning off the global public sharing setting prevents any new items from being made publicly visible outside your organization while keeping existing items intact so you can remediate them. This approach meets a low impact requirement because it stops further exposure quickly without forcefully changing lots of objects or breaking access for internal users.

Requesting that owners change their filters to share with logged in users in the organization shifts visibility from truly public to organization-only while preserving intended access for employees. Combining the global disable with owner updates gives a safe, phased remediation path and lets you communicate and coordinate changes with owners rather than performing a broad automated rewrite.

Use the REST API to bulk update existing filters to set their sharing to organization-only is not the best choice for a low impact plan because a bulk update can create operational risk. Automated changes can break dashboards and subscriptions and they can remove owner context which makes troubleshooting harder.

Restrict the global permission Share dashboards and filters to the group org-admins is overly restrictive and can prevent legitimate internal sharing. The requirement in the question is low impact remediation and locking sharing down to admins would disrupt normal user collaboration.

Restrict the permission Manage group filter subscriptions to the group site-ops is not relevant to public sharing because that permission controls subscription management and not who can publish filters or dashboards publicly.

Open a support ticket with Atlassian support is unnecessary for this issue because the controls to stop public sharing and to change filter visibility are available to site administrators and can be acted on immediately.

When the exam asks for a low impact change look for answers that block future risky actions while giving owners time to fix existing items. Disable the risky global option first and then coordinate owner remediation for the least disruption.

Schedule issues and Edit issues are the correct permissions Lena should request.

Schedule issues gives users the ability to change scheduling related fields and to adjust the placement of issues on boards that use scheduling or ranking for order. That permission is commonly required to move items up and down the sprint backlog so Lena can reorder the list.

Edit issues allows a user to modify issue details and fields that affect backlog order such as the Sprint field or rank. Many board reorder operations change issue data behind the scenes so edit access is also required to make those moves.

Move Issues is oriented toward changing an issue between projects or changing its issue type and it does not grant the ability to reorder backlog items within the same board.

Transition Issues controls moving issues through workflow statuses and it does not affect backlog ranking or the ability to drag items in the sprint backlog.

Browse Projects only allows viewing of the project and its issues and does not permit changing issue order. The scenario states Lena can already open every issue so this permission is not what she is missing.

Manage sprints allows creating, starting, and completing sprints and adjusting sprint metadata but it does not by itself grant the ability to edit issue fields or change an issue’s rank on the backlog.

When a question asks about changing backlog order focus on permissions that let a user modify issue fields and scheduling. Look for options with the words schedule or edit as they often indicate the needed access.

The correct options are You can enable a backlog for Kanban team managed projects and Notifications can be sent to a selected set of project roles.

The You can enable a backlog for Kanban team managed projects option is correct because team managed Kanban projects include a backlog setting that lets teams groom and prioritize issues in a backlog view before moving them onto the board.

The Notifications can be sent to a selected set of project roles option is correct because team managed projects provide simplified notification controls that allow project administrators to choose which project roles receive notifications for project events.

Team managed projects can share their configuration with each other is incorrect because team managed projects are independent and do not use shared schemes. Sharing configuration and centralized schemes is a capability of company managed projects.

Custom swimlanes can be defined using JQL queries is incorrect because JQL based swimlanes are an advanced board feature available for company managed projects. Team managed boards offer simpler, built in swimlane options and do not support arbitrary JQL swimlanes.

Issue security can restrict issue visibility to specific groups or roles is incorrect because issue security schemes that restrict issue visibility are not available for team managed projects. Issue level security is provided through company managed project schemes.

When a question contrasts project types focus on whether the feature needs shared schemes or advanced admin controls. Team-managed projects are simpler and isolated while company-managed projects support shared schemes and more advanced features.

The correct options are For the Story issue type change the description on the “Summary” system field to “Brief Overview” and For the Story issue type set the “Acceptance Criteria” paragraph custom field to use a wiki style renderer so it can display bold and colored text.

Changing a field description is exactly what a field configuration controls. You can assign a specific field configuration to the Story issue type through the project schemes and then update the help text or description shown for the Summary system field so it reads as required.

Renderers for text fields are configured at the field level and are part of the field configuration options. Setting the paragraph custom field to use a wiki style renderer will allow richer formatting such as bold text and color depending on the renderer capabilities and that change is made in the field configuration.

For the Story issue type set the default for the “Description” system field to “As a user I want X because Y” is incorrect because field configurations do not set default values for system fields. Default values are handled by other mechanisms such as field defaults on custom fields, workflow post functions, or automation rules and not by changing the field configuration description or renderer.

For the Task issue type assign the default value for the “Priority” system field to “Low” is incorrect for the same reason. Field configurations control presentation and behavior like required status and renderers but they do not assign default priority values for system fields.

For both issue types remove the “Labels” field from the create screen and add it back to the edit screen using screen schemes is incorrect because that requirement involves screen and screen scheme configuration rather than field configurations. Screen schemes decide which fields appear on create or edit screens and are a separate configuration area.

For both issue types hide the assignee field when a component is selected during issue creation is incorrect because conditional or dynamic hiding based on another field selection is not something field configurations provide. Achieving that behavior requires workflow conditions, behaviors provided by apps, or automation and is not accomplished by changing field configurations alone.

When a question asks about changing field configurations focus on things like field descriptions, required status, and renderers. Do not confuse those settings with screens or dynamic behaviour which are managed elsewhere in Jira.

Grant the Platform team the “Browse users and groups” global permission and Grant the Platform team the “Resolve issues” project permission are the required additions.

The Grant the Platform team the “Browse users and groups” global permission allows the CI CD integration to look up users in the directory so user picker fields can be populated. This permission gives the minimal global access needed for user lookups without granting broad administrative capabilities.

The Grant the Platform team the “Resolve issues” project permission is required because many automated workflows and transitions that tag a Fix Version also set the resolution or perform a resolve transition. Granting resolve rights at the project level lets those automated transitions complete while keeping permissions scoped to the project.

Grant the Platform team the “Manage project roles” project permission is incorrect because that permission is about changing role membership and it is more powerful than required to populate user pickers or update fix versions.

Grant the Platform team the “Schedule issues” project permission is incorrect because scheduling controls start and due dates and it does not affect user picker fields or fix version updates.

Grant the Platform team the “Browse projects” project permission is incorrect because browsing projects does not enable user directory lookups or the resolve transitions that the CI CD automation needs when setting fix versions.

Grant the Platform team the “Administer Jira” global permission is incorrect because it grants full system administration rights and violates the least privilege principle when only narrow permissions are needed.

When integrations cannot update fields check both project and global permissions. Grant the specific global permission for user lookups and the minimal project transition or resolve permission rather than broad admin rights.

He will be redirected to Google when he attempts to sign in to STAR VOYAGES is correct.

This is because Diego signs in with [email protected] and the nova.com domain is verified by NOVA Solutions which has Atlassian Access configured with Google as its identity provider. When an organization verifies a domain and enables Atlassian Access the email domain determines which identity provider handles the authentication and Diego will be routed to Google even when accessing a site owned by a client.

He can continue to use his Atlassian account credentials to sign in to NOVA Solutions STAR VOYAGES and LUNA GETAWAYS is incorrect because NOVA Solutions has verified nova.com and enforces SSO with an external IdP. Diego must authenticate through the organization IdP rather than using local Atlassian credentials.

He will be prevented from signing in to STAR VOYAGES is incorrect because verification and Atlassian Access do not block cross-organization access. They route authentication to the managing organization IdP so Diego can still sign in using his NOVA Solutions identity provider.

He will be redirected to Azure when he attempts to sign in to STAR VOYAGES is incorrect because Azure is the identity provider for LUNA GETAWAYS and not for the nova.com domain. The sign in redirect is based on the email domain mapping and not on the site being accessed.

When a domain is verified and Atlassian Access is enabled the user’s email domain determines the IdP. Read the verified domain and identity provider mapping carefully to choose the right answer.

The correct options are Screen Scheme, Workflow Scheme, and Issue Type Scheme.

The Issue Type Scheme is created so the new project can have its own set or mapping of issue types that match the template. Creating a project from a template often produces a project specific Issue Type Scheme so that issue type changes do not affect other projects.

The Workflow Scheme maps workflows to issue types and templates commonly create a project level Workflow Scheme so the project can follow the template workflows independently from shared workflows.

The Screen Scheme defines which screens are used for create view and edit operations and templates typically generate a project specific Screen Scheme so the screens can be customized for the new project.

The Field Configuration Scheme is not listed as unique because Jira usually reuses a shared field configuration or associates an existing one instead of creating a new unique scheme by default.

The Notification Scheme is generally shared or applied from an existing scheme and is not automatically created as a unique scheme for each new project.

The Issue Security Scheme is only created uniquely when specific security configurations are requested and it is not a default unique scheme for a template created project.

The Permission Scheme is typically assigned from existing permission schemes and is not normally created as a project unique scheme by default.

When a project is created from a template check the schemes that control issue structure and user interactions. Pay attention to Issue Type Scheme, Workflow Scheme, and Screen Scheme as they are the most likely to be project specific.

The correct options are Signed in user, Project lead, and Project role.

Team-managed projects in Jira Cloud use a simplified notifications editor and they let you add recipients by role, by the project lead, or by an individual Jira account. Selecting a Project role sends the notification to everyone assigned to that role, selecting the Project lead sends it to the person designated as the lead for the project, and selecting Signed in user targets a specific Jira user who is signed in.

Component lead is not available as a recipient type for team-managed project notifications. Component lead recipients are part of the more advanced schemes used in company-managed projects and are not exposed in the team-managed editor.

Individual by email address is not supported for team-managed project notifications. Team-managed projects require selecting existing Jira users or roles and do not allow adding arbitrary external email addresses as recipients.

Project watcher is not an option you can add when configuring team-managed project notifications. Although watchers can receive notifications through global or issue-level settings, the team-managed notification editor does not provide a watcher recipient type to select.

When a question mentions team-managed projects remember they use a simplified notification editor and look for Signed in user, Project lead, or Project role as the likely recipient options.

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

The correct answer is Update the Completion Criteria description in the ORB project field configuration.

In company managed projects the field description shown on screens can be controlled by the project level field configuration. Changing the global custom field description does not update a project specific description if that project uses its own field configuration.

To resolve this you must edit the field description in the ORB project field configuration and save the change. Once the project field configuration is updated the create issue screen in that project will show the corrected description.

Wait for a Jira background reindex to complete is incorrect because reindexing does not affect which description a project uses and the issue is a configuration override rather than an indexing delay.

Clear the browser cache is incorrect because a browser cache issue is unlikely to cause a persistent different description when the underlying project configuration still defines the old text.

Delete the Completion Criteria custom field and recreate it with the corrected description is incorrect because deleting a custom field is destructive and unnecessary when a configuration change will fix the display. Deleting the field could also remove data and cause broader disruption.

Remove the Completion Criteria field from the screen and then add it back is incorrect because removing and readding the field does not change the field description defined by the project field configuration and it is not needed to update the visible text.

When UI text looks out of date check for a project level field configuration that may override the global custom field and edit that configuration rather than assuming an indexing or cache issue.

The correct options are Workflow property and Project permissions.

Workflow property can prevent moves because a workflow may include properties that restrict specific actions or transitions. These properties are evaluated during operations such as moving an issue and they can block the move even if the user has been granted the Move Issues permission through a role. Review the workflow properties on the source and target workflows to find any settings that stop moves.

Project permissions can also block moving issues because the user needs the appropriate rights in both the source and destination projects. A role that grants Move Issues may not give the necessary create or other project level permissions in the target project. Verify the permission scheme for the target project and ensure the user has the required project permissions to receive moved issues.

Field configuration is incorrect because field configurations control how fields behave and whether fields are required or hidden. They do not directly stop the action of moving an issue between projects.

Issue security scheme is incorrect because issue security controls who can see an issue after it exists. It does not normally prevent the move operation itself, although visibility may change after the move.

Workflow condition is incorrect because conditions determine whether a transition is available to a user when acting on an issue. Conditions do not generally serve as the mechanism that blocks the move action in the way that a workflow property can.

When a move fails check the target project permissions first and then review the workflow properties on both projects. Verifying permissions and workflow properties in that order helps you find the cause quickly.

Workflow status property is correct. This setting can make the reporter field non editable while an issue is in the Completed status so a user with a role that otherwise allows changing the reporter still cannot edit it.

Workflow status property is applied to a status in the workflow and can mark specific fields as read only for that status. That behavior enforces field level restrictions based on the current status and it takes effect regardless of project level edit permissions.

Permission scheme is incorrect. Permission schemes control who can perform broad actions at the project level such as editing issues or changing the reporter and they do not enforce read only behavior only when an issue is in a particular status.

Field configuration is incorrect. Field configurations let you set fields as required hidden or optional for the project but they do not provide a way to make a field read only only while an issue is in a specific workflow status.

Issue security scheme is incorrect. Issue security schemes control visibility of issues for users and groups and they do not control whether a particular field is editable in a given status.

Workflow condition is incorrect. Conditions restrict who can execute a transition or whether a transition is available and they do not by themselves make a field read only for the duration of a status.

When a field is editable in general but not in one status check for workflow status properties first. Do not confuse per status field locks with project permissions or field configurations.

Filter subscriptions, Dashboard access, and Issue security level are the items that can be associated with a project role.

Dashboard access can be granted to a project role when a dashboard is shared so that all actors in that role gain the specified viewing or editing rights for the dashboard.

Filter subscriptions can target a project role so that scheduled filter emails are sent to the users or groups that are assigned as actors of that role.

Issue security level uses project roles to determine which users can see an issue when a security level is applied, and roles are commonly included in security schemes to control visibility.

Application access is incorrect because product or application access is managed at the site or user level in user management and not assigned via project roles.

Group membership is incorrect because group membership is a separate user directory concept and is not an item that is assigned to a project role, although groups can be added as actors to a role they are not the same as role configuration itself.

Global permissions is incorrect because global permissions are configured at the site administration level and apply across the instance rather than being associated with individual project roles.

Think about scope and ask whether the setting applies at the project level or at the global or user management level when you decide which items relate to project roles.

The correct options are Project workflow post function on the transition that closes issues, Global permission to make bulk changes and Project permission to transition issues.

Project workflow post function on the transition that closes issues is required because the Resolution field is normally set as part of the transition that moves an issue to the Completed or Done status. Ensuring a post function that sets the Resolution guarantees that the field is populated when the workflow transition runs.

Global permission to make bulk changes is required when Priya needs to update many issues at once. The bulk change operation is controlled by a global permission so she cannot perform a mass update if that permission is not granted.

Project permission to transition issues is required because changing the status for issues or triggering the transition post function depends on the ability to transition issues in the project. Without that project permission the transition cannot be executed even if the workflow has the correct post function.

Automation rule that updates fields is not the required configuration here. An automation rule can be used as an alternative to set Resolution but the standard and reliable place to set Resolution is on the closing transition via a post function. The question asks which configuration areas must be changed so automation is not the expected answer.

Issue status scheme is not correct because status schemes control which statuses are available to projects and how they map to workflows. They do not directly set the Resolution field during a transition.

Resolution field scheme is not correct because Jira does not use a separate resolution scheme in the same way it uses field schemes. Resolution values are managed in the system and set by transitions or rules rather than by a scheme that you assign to projects.

Before running a bulk update check the closing transition for a post function that sets Resolution and confirm you have both the Transition Issues project permission and the Bulk Change global permission.

The correct options are ZIP, HAR, and RAR.

These file types are not accepted because the Jira Cloud import wizard expects structured export formats that map fields and issue data. A file such as ZIP is a compressed archive container and the import tool will not process archives directly. A file in the RAR format is also a compressed archive and it is not a supported import type. A HAR file contains HTTP network traffic logs and it does not represent the structured issue or project data that the wizard can import.

Trello is incorrect because Jira Cloud provides a Trello importer and Trello exports are supported for migration into Jira.

JSON is incorrect because JSON is a supported structured format and it can be used for imports or backups that contain issue data.

CSV is incorrect because CSV is a common supported import format for issues and field mappings in Jira Cloud.

When deciding which file types are accepted focus on whether the file is an archive or a structured export. The import wizard accepts structured exports like CSV and JSON and it does not accept archive files or network capture files.

The correct option is Board Sub-Filter.

Board Sub-Filter applies an additional JQL constraint on the board view so that only issues matching the marketing component appear on the Kanban board while the board still uses the original board filter behind the scenes. This means the Pie Chart report that relies on the board or shared filter remains unchanged because the sub-filter affects only the board display and not the saved filter that reports use.

Quick Filters are wrong because they require users to click a filter to change the board view and do not automatically restrict the board for all users.

Board Filter is wrong because changing the board filter alters the base filter that reports and gadgets use, and that would change the Pie Chart data.

Swimlanes are wrong because they only group or organize issues on the board and do not prevent issues from appearing on the board.

Issue Detail View is wrong because it shows issue information when an issue is selected and does not control which issues are visible on the board.

Hide resolved issues is wrong because it only hides issues with a resolved status and would not filter the board to only show issues with the marketing component.

When a question asks for a board level restriction that must not change reports, look for a feature that applies a view only filter. The Board Sub-Filter is applied on the board only so it is a good choice for this scenario.

The correct options are Screen schemes, Field configurations, and Workflow schemes.

Screen schemes should be inspected because they map issue types to the screens that display during create edit and view operations and removing an issue type can leave screens or screen mappings orphaned or misconfigured.

Field configurations should be checked because field configuration schemes and custom field contexts can be scoped to specific issue types so you must update those settings to avoid fields remaining tied to a deleted issue type.

Workflow schemes should be reviewed because they map issue types to workflows and removing an issue type without updating the workflow scheme can leave workflows with unused or dangling associations.

Notification schemes is incorrect because notification schemes control who receives notifications for issue events and they do not map configurations by issue type.

Permission schemes is incorrect because permission schemes govern user and group permissions at the project level and they are not used to associate behaviors with specific issue types.

Issue security schemes is incorrect because issue security schemes define visibility levels for individual issues and they do not create mappings that must be removed when an issue type is deleted.

Before deleting an issue type check any configuration that maps behaviors to issue types such as screens, fields, and workflows so you can update mappings and avoid orphaned settings.

The correct options are Project permission to Link Issues and Issue linking setting.

Project permission to Link Issues is required because the ability to create links between issues is granted at the project permission level and you must give the relevant users or groups that permission in the project’s permission scheme before they can add links.

Issue linking setting is required because issue linking is also controlled by a global system setting and that feature must be enabled for linking to work even when the project permission is granted.

Application links is incorrect because application links are used to connect Jira to other applications for integration and they do not enable or control creating links between issues within a project.

Issue security scheme is incorrect because it controls who can view or access an issue and it does not affect the ability to create links between issues.

Global permissions is incorrect because those permissions govern system wide roles such as administrators and users and they do not specifically grant the ability to link issues inside a project which is handled by the project permission and the global issue linking setting.

When deciding between options check whether the control is project level or global level and remember that the Issue linking setting must be enabled globally in addition to granting the project permission.

The correct answers are Clone issues and Remove votes from issues.

Clone issues is not supported by Jira Cloud bulk change because cloning creates new issues and can involve links and attachments which the bulk operation does not replicate. You must clone issues one at a time in the UI or use automation or the REST API to create clones at scale.

Remove votes from issues is not supported by bulk change because votes are user specific and Jira does not expose a bulk remove votes action in the bulk change workflow. To remove votes across many issues you need to use the API or a script that acts on individual user vote records.

Transition issues is incorrect because bulk change includes a transition operation so you can move many issues through workflow steps in one operation.

Stop watching issues is incorrect because bulk change allows you to stop watching or manage watchers for many selected issues at once.

Edit issues is incorrect because the bulk edit operation is a primary bulk change feature and it lets you update fields across multiple issues in a single action.

Move issues is incorrect because bulk change supports moving issues and you can relocate multiple issues between projects or change their issue type with the appropriate permissions.

When answering questions about bulk operations focus on actions that create new records or affect per-user state since those are less likely to be supported by a single bulk change.

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

The correct option is Company-managed projects.

Company-managed projects use the classic notification scheme model which lets administrators select recipients such as All watchers, Component lead, and a User picker for specific events. This model exposes the full set of notification recipients and the notification scheme settings are managed at the project or system level so you can include those specific recipient types.

Team-managed projects are incorrect because team-managed projects use a simplified notification model and do not provide the same configurable notification scheme. That means you cannot reliably select Component lead or a User picker as notification recipients in team-managed projects.

Both project types support these recipients is incorrect because only company-managed projects provide the full notification scheme that includes All watchers, Component lead, and User picker. Team-managed projects do not offer the same recipient options.

Neither project type supports these recipients is incorrect because company-managed projects do support those recipients through notification schemes.

When a question mentions specific notification recipients think of the notification scheme feature. That feature is available in company-managed projects and is the likely correct choice.

Sam is correct. He will receive the newly created issue because you explicitly assigned him when creating the issue.

Because you chose Sam as the assignee during creation the system uses that explicit assignment and does not apply component or project default assignees. Default assignees only take effect when no explicit assignee is set and selecting multiple components does not override a manual assignee.

Marco is incorrect. He is the component lead for Borealis but the component default would only apply if no assignee was chosen, and you explicitly set Sam.

Lila is incorrect. She is the component lead for Aurora and would receive the issue only if the component default routed to the component lead and no assignee was set, but you set Sam.

Martin is incorrect. He is the project lead and the project default assignee would apply only when there is no explicit assignee, so the manual assignment to Sam takes precedence.

Priya is incorrect. She is the component lead for Zenith but that component is configured to use the project default rather than the component lead and even in that case the explicit assignee Sam overrides defaults.

Remember that an explicitly set assignee always overrides component and project defaults. When in doubt check whether the component default is set to the component lead or the project default.

Jira administrators are allowed to create new project roles and update role definitions for an organization managed project.

Jira administrators hold the product administration privileges required to manage project roles across the organization. They can access the global project role configuration and create or modify role definitions that apply to organization managed projects.

Project administrators can manage settings and user assignments within a specific project but they cannot create or edit the global project role definitions that apply across multiple projects.

Site administrators control site level settings and user access across products but they do not automatically have the Jira product permissions required to create or modify project role definitions unless they are also granted Jira administration rights.

All administrators is too vague to be correct because it is not a specific role that is granted the ability to edit organization wide project role definitions.

When a question asks who can change role definitions think about product administration and choose the role that explicitly manages Jira settings such as Jira administrators.

The correct answers are Subscription and Filters.

You create a saved search that returns all issues marked as critical and save it as a Filters entry so the query is reusable and shareable across the project and instance. Saved filters are the mechanism Jira uses to capture a specific set of issues that can then be acted on or distributed.

Once the query is saved you create a Subscription for that Filters and schedule it to run every Friday. A Subscription will send a single consolidated email that lists the matching issues on the schedule you choose so it meets the requirement for one weekly email.

Automation is not correct because automation rules are oriented around actions triggered by events or scheduled tasks and they do not produce the standard filter subscription style consolidated email as the built in subscription feature does.

Notifications is not correct because notification schemes send event driven emails to users about issue changes and they do not provide a scheduled consolidated list of matching issues.

Webhook is not correct because webhooks send HTTP payloads to external systems and they do not deliver an email containing a consolidated list to a user mailbox.

Global Permission is not correct because global permissions control administrative and access rights and they have nothing to do with scheduling or sending issue list emails.

When studying, practice saving a JQL query for critical issues and then set up a filter subscription to run on a Friday so you can see the exact consolidated email format the exam expects.

The correct answer is Only a subset of data in existing system fields from the team managed project will carry over.

When you move issues from a team managed project into an organization managed project only certain system fields and issue data are preserved by default. Basic fields like summary and description and attachments and comments commonly move, but many system values depend on the target project’s workflows, statuses, and configurations so they may require mapping or may change during the move. For that reason Only a subset of data in existing system fields from the team managed project will carry over accurately reflects typical migration behavior.

Issue keys will remain the same after migration is incorrect because an issue key includes the project key and moving an issue to a different project normally changes its key.

All values from custom fields created in the team managed project will be preserved is incorrect because custom fields can be project specific and may not exist or may have different contexts in the target project so values can be lost or become unavailable if there is no matching custom field.

Every value in the standard system fields from the team managed project will remain intact is incorrect because many standard fields depend on project specific workflows and configurations and therefore do not always remain exactly the same after migration.

When a question asks about migrating issues pay attention to whether fields need mapping or a matching configuration and favour answers that mention a subset being preserved rather than everything staying identical.

The correct option is The team using the “LEGAL” project needs to rename the Bug issue type while the team using the “CORE” project must keep the existing name because of downstream impacts.

This option is correct because requiring different visible names for the same issue type between projects creates a naming conflict that cannot be resolved while both projects share the same issue type configuration. Issue type names and the set of issue types assigned to a project are controlled by the issue type configuration and schemes, and a separate issue type scheme or separate issue type is needed so that one project can present a different label without affecting the other project.

The “LEGAL” Bug issue type needs a different create screen from the Bug issue type in the “CORE” project is incorrect. Create screens and field configurations are managed by screen schemes and field configuration schemes. You can change the create screen for a project or issue type without creating a new issue type scheme.

The “LEGAL” Bug issue type requires a unique workflow that differs from the workflow used by the Bug issue type in the “CORE” project is incorrect. Workflows are assigned via workflow schemes and you can give projects or issue types different workflows by using or modifying those workflow schemes without changing the issue type scheme itself.

The “LEGAL” Bug issue type needs to be translated into French rather than using the same label as in the “CORE” project is incorrect. Localization is typically handled by Jira language settings and translation mechanisms, and it does not by itself mandate creating a separate issue type scheme. If a distinct label is required for a project you may still create a separate issue type or scheme, but translation alone is not the primary reason to choose a new issue type scheme in most cases.

When deciding which scheme to change map the requirement to the scheme type. Think about names and available issue types for issue type schemes and think about screens and workflows for screen schemes and workflow schemes.

The correct option is Company managed Kanban.

Company managed Kanban satisfies the requirement to have stories and tasks use separate workflows because company managed projects support workflow schemes that let you assign different workflows to different issue types. Company managed Kanban also meets the requirement to publish a new version directly from the board because Kanban boards expose the Releases view and release controls that support publishing versions as part of a continuous flow.

Team managed Scrum is incorrect because team managed projects use simplified, project level workflows and do not support assigning different workflows per issue type, so you cannot give stories and tasks separate workflows there.

Team managed Kanban is incorrect for the same reason because team managed projects cannot apply different workflows to different issue types, which fails the requirement for separate workflows for stories and tasks.

Company managed Scrum is incorrect because although company managed projects support workflow schemes the Scrum board is focused on sprint based delivery and does not provide the same direct, continuous publish from board flow that a Kanban board provides for releasing versions in this scenario.

When a question requires different workflows by issue type choose company managed projects because they support workflow schemes that assign workflows per issue type.

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

The correct answer is Project permissions.

Project permissions come from the project permission scheme and determine who can perform actions such as editing issues. If Miguel can view an issue but cannot edit the one he reported then the project needs the “Edit Issues” permission granted to the appropriate role or group or to reporters in the scheme. Adjusting the project permission scheme to include the reporter or the role Miguel belongs to for the “Edit Issues” permission will allow him to modify the issue he created.

Product access controls whether a user has access to the Jira product at the site level and does not grant or restrict edits inside a specific project, so changing product access will not solve a project level edit permission problem.

Global permissions provide broad abilities at the application or system level such as administration rights and they are not used to allow editing of individual issues within a single project.

Issue security scheme controls who can see an issue and does not manage the ability to edit it, so if Miguel can see the issue but cannot edit it then the issue security scheme is not the cause.

When a user cannot perform an action review the project permission scheme first and then run the Jira permission helper to identify which specific permission is missing for that user.