Practice ACP-120 Questions With Certification guide Q&A from Training Expert PassCollection
Free ATLASSIAN ACP-120 Test Practice Test Questions Exam Dumps
NEW QUESTION # 24
Your Jira has 25,000 active users across the globe using 100 projects with over a million issues.
Another administrator has made a change to a field configuration scheme and you now need to re-index Jira.
What would be the impact of rebuilding the index in the foreground?
- A. Database backups cannot be run until the re-indexing is complete.
- B. Issues will take longer to display during the re-index.
- C. Searches using the field may show erroneous results.
- D. All users will be locked out of Jira until re-indexing completes.
- E. The configuration change will not be applied until re-indexing is complete.
Answer: E
NEW QUESTION # 25
version in a company-managed project:
* Move all issues in version 1.1 to version 1.2.
* Remove version 1.1 as an available option from the Fix Versions system field.
Which two operations will both meet the requirements? (Choose two.)
- A. Build and release
- B. Delete
- C. Merge
- D. Archive
Answer: C,D
Explanation:
The question involves managing versions in a company-managed project in Jira Software Cloud. Maia wants to move all issues from version 1.1 to version 1.2 and remove version 1.1 as an available option in theFix Versionsfield. The two operations that meet both requirements areArchiveandMerge.
* Explanation of the Correct Answers:
* Archive (Option B):
* Archiving a version removes it from theFix Versionsfield as an available option for new issues, while preserving the version's association with existing issues. Additionally, archiving allows you to move issues to another version (e.g., version 1.2) during the process, meeting both requirements.
* Exact Extract from Documentation:
Archive a version
Archiving a version removes it from the list of available versions in fields like Fix Versions, so it can't be selected for new issues. You can also move issues to another version during the archiving process.
To archive a version:
* Go to your project'sReleasespage.
* Find the version (e.g., version 1.1) and selectArchive.
* Optionally, choose to move issues to another version (e.g., version 1.2).Archived versions are still visible in reports and issue details but are no longer selectable in fields.Note: You need project admin permissions to archive versions.(Source:
Atlassian Support Documentation, "Manage versions in company-managed projects")
* Why This Fits: Archiving version 1.1 removes it from the Fix Versions field, preventing it from being selected for new issues, and allows Maia to move all issues to version 1.2 during the archiving process, fulfilling both requirements.
* Merge (Option D):
* Merging a version moves all issues from one version (e.g., version 1.1) to another (e.g., version 1.2) and deletes the source version, effectively removing it from the Fix Versions field. This meets both requirements, as it reassigns issues and eliminates version 1.1 as an available option.
* Exact Extract from Documentation:
Merge versions
Merging versions allows you to combine two versions by moving all issues from one version to another. The source version is deleted after the merge.
To merge versions:
* Go to your project'sReleasespage.
* Find the version to merge (e.g., version 1.1) and selectMerge.
* Choose the target version (e.g., version 1.2) to move issues to.After merging, the source version (version 1.1) is removed from the Fix Versions field and is no longer available for selection.Note: Merging is permanent and cannot be undone, so ensure the target version is correct.(Source: Atlassian Support Documentation, "Manage versions in company-managed projects")
* Why This Fits: Merging version 1.1 into version 1.2 moves all issues to version 1.2 and deletes version 1.1, ensuring it is no longer an option in the Fix Versions field, thus meeting both requirements.
* Why Other Options Are Incorrect:
* Delete (Option A):
* Deleting a version removes it from the Fix Versions field, but it also removes the version from all issues associated with it without reassigning them to another version. This does not meet the requirement to move issues to version 1.2.
* Extract from Documentation:
Delete a version
Deleting a version removes it from the project and clears it from the Fix Versions field of all associated issues. Issues are not reassigned to another version automatically.
Note: Use caution, as this action cannot be undone, and issues lose their version association.
(Source: Atlassian Support Documentation, "Manage versions in company-managed projects")
* Build and release (Option C):
* Building and releasing a version marks it as complete and moves unresolved issues to another version, but it does not remove the version from the Fix Versions field. Released versions remain selectable unless archived or deleted.
* Extract from Documentation:
Release a version
Releasing a version marks it as complete and optionally moves unresolved issues to another version. The released version remains available in the Fix Versions field unless archived.
(Source: Atlassian Support Documentation, "Manage versions in company-managed projects")
* Additional Notes:
* BothArchiveandMergeare suitable, but they have different implications:
* Archiving preserves version 1.1 in reports and issue histories, making it ideal if historical data needs to be retained.
* Merging permanently deletes version 1.1, which may be preferred if the version is no longer relevant.
* The operations require project admin permissions in a company-managed project, and the Releasespage is accessed viaProject Settings > Releases.
:
Atlassian Support Documentation:Manage versions in company-managed projects Atlassian Support Documentation:Configure releases and versions
NEW QUESTION # 26
You have been asked to take on the administration of a second Jira installation in your company.
You were given the following information about user accounts:
- The company standard is to use Active Directory (AD) to provide user accounts.
- There are several Active Directory systems in use by different business units.
- The second Jira is not to be merged with your main Jira.
- The main Jira system is connected to Active Directory for user accounts.
- The second Jira is using internal user accounts, not Active Directory.
- People using the second Jira are using the same login ID as they would use in Active Directory.
- Your company would like to use Single Sign-on (SSO) but has not yet implemented it for either Jira system.
Which authentication method should you recommend?
- A. Set up a Crowd server to get the user lists from all internal directories and AD, and use AD directly for the password checking.
- B. Change the new Jira to use your main Jira's directory services, as that is already reading your Active Directory services.
- C. Set up a Crowd server to pull in all the AD services, and plan to migrate internal users.
- D. Change the new Jira to link directly to the required AD servers.
Answer: A
NEW QUESTION # 27
Currently, several groups and project robs are listed in every system event of the DEV Notification Scheme and should remain that way. A new requirement states that when DEV issues move from the status Open to status Assigned, only Project Rob (Managers) should be notified. DEV project does not share any of its schemes.
Identify the event that needs to be configured.
- A. Issue Moved
- B. Work Started On Issue
- C. Custom event
- D. Issue Assigned
Answer: C
NEW QUESTION # 28
You need to create a filter that shows only issues that were created during the last calendar month. Identify the correct JQL query.
- A. created >= startOfMonth(-1) AND created <= endOfMonth(-1)
- B. createdDate >= startOfMonth(-1m) AND createdDate <= endOfMonth(-1m)
- C. createdDate >= startOfMonth(-1) OR createdDate <= endOfMonth(-1)
- D. created changed during (startOfMonth(), endOfMonth())
Answer: B
Explanation:
To create a filter that shows issues created during the last calendar month, the JQL query must use the createdDatefield with thestartOfMonth(-1m)andendOfMonth(-1m)functions to define the time range. The correct query iscreatedDate >= startOfMonth(-1m) AND createdDate <= endOfMonth(-1m)(Option D).
* Explanation of the Correct Answer (Option D):
* ThecreatedDatefield represents the date an issue was created. ThestartOfMonth(-1m)function returns the first day of the previous month (e.g., April 1, 2025, for May 2025), andendOfMonth (-1m)returns the last day of the previous month (e.g., April 30, 2025). The querycreatedDate >= startOfMonth(-1m) AND createdDate <= endOfMonth(-1m)selects issues created within this range, covering the entire last calendar month.
* Exact Extract from Documentation:
Search for issues using JQL
ThecreatedDatefield (orcreatedalias) stores the creation date of an issue. Use date functions like startOfMonth()andendOfMonth()to define time ranges.
Examples:
* createdDate >= startOfMonth(-1m) AND createdDate <= endOfMonth(-1m) returns issues created in the previous calendar month.
* Use-1mto indicate one month ago.Note: Ensure date fields use>=and<=for inclusive ranges.
(Source: Atlassian Support Documentation, "Search for issues using JQL")
* Why This Fits: The query in Option D correctly usescreatedDate,startOfMonth(-1m), and endOfMonth(-1m)withANDto define the last calendar month, making it the correct answer.
* Why Other Options Are Incorrect:
* created changed during (startOfMonth(), endOfMonth()) (Option A):
* Thechanged duringoperator is used for fields that track changes (e.g., status, assignee), not for static fields likecreated. Additionally,startOfMonth()andendOfMonth()without-1 mrefer to the current month, not the last month.
* Extract from Documentation:
Thechanged duringoperator is invalid for thecreatedfield. Use>=and<=for date comparisons.
(Source: Atlassian Support Documentation, "Advanced searching - operators reference")
* createdDate >= startOfMonth(-1) OR createdDate <= endOfMonth(-1) (Option B):
* TheORoperator creates a logical error, selecting issues created after the start of the previous monthorbefore the end of the previous month, which includes almost all issues.
Additionally,-1is ambiguous and typically invalid without a unit (e.g.,-1mfor one month).
The correct operator isANDto define a range.
* Extract from Documentation:
UseANDto define a date range (e.g., createdDate >= startOfMonth(-1m) AND createdDate <= endOfMonth(-1 m)).ORcreates an overly broad range.
(Source: Atlassian Support Documentation, "Advanced searching - operators reference")
* created >= startOfMonth(-1) AND created <= endOfMonth(-1) (Option C):
* The-1syntax without a unit (e.g.,-1m) is ambiguous and typically invalid in JQL. The correct syntax uses-1mto indicate one month ago. Additionally, whilecreatedis an alias for createdDate, the incorrect time unit makes this query invalid.
* Extract from Documentation:
Date functions require units likemfor months (e.g.,startOfMonth(-1m)). Without a unit, the query is invalid.
(Source: Atlassian Support Documentation, "Advanced searching - functions reference")
* Additional Notes:
* The filter can be created inIssues > Search for issues, saved as a filter, and shared if needed.
* Thecreatedalias can be used instead ofcreatedDate, butcreatedDateis more explicit and matches the options.
* Ensure the Jira instance's timezone aligns with the expected month range.
:
Atlassian Support Documentation:Search for issues using JQL
Atlassian Support Documentation:Advanced searching - operators reference Atlassian Support Documentation:Advanced searching - functions reference
NEW QUESTION # 29
Which configurations do NOT have any impact on user notifications? (Choose one)
- A. Permission schemes
- B. Custom events
- C. Personal profile settings
- D. Workflow post functions
- E. Gadget configurations
Answer: E
NEW QUESTION # 30
A team requests updates to the behavior of some fields in the project. The project uses three issue types: Problem, Incident, and Change.
The desired configuration is shown below:
Which configuration update will meet the requirements?
- A. Configure individual screens for any combination of issue operation and issue type.
- B. Configure individual field contexts for each custom field and update the priority scheme.
- C. Configure individual field configuration for each custom field and update the priority scheme.
- D. Create unique field contexts for each issue type for the desired fields.
- E. Configure individual screens for each issue type and update the priority scheme.
- F. Configure individual field configurations for each issue type.
Answer: B
NEW QUESTION # 31
Jon needs to create groups and manage membership in groups. Which administrator privilege does Jon need?
- A. Project administrator
- B. System administrator
- C. Product Admin role for Jira
- D. Jira administrator
- E. Organization admin
Answer: D
Explanation:
Creating groups and managing group membership in Jira Software Cloud are system-level tasks that require theJira administratorprivilege. This privilege allows Jon to access user management settings and perform group-related actions.
* Explanation of the Correct Answer (Option D):
* TheJira administratorprivilege grants users the ability to manage global settings, including creating groups and managing their membership. This includes adding or removing users from groups, which is necessary for Jon's requirements.
* Exact Extract from Documentation:
Jira administrator permissions
Jira administrators can manage global settings, including:
* Creating and deleting groups.
* Adding or removing users from groups.
* Managing global permissions and user access.To create or manage groups:
* Go toSettings > User management > Groups.
* Create a new group or edit existing group membership.Note: Only Jira administrators or organization admins with user management permissions can perform these actions.(Source:
Atlassian Support Documentation, "Manage groups in Jira Cloud")
* Why This Fits: TheJira administratorprivilege directly enables Jon to create groups and manage their membership, making Option D the correct choice.
* Why Other Options Are Incorrect:
* Organization admin (Option A):
* Organization admins manage the Atlassian organization, including user access to products and billing. While they can manage users and groups at the organization level, creating groups specifically in Jira requiresJira administratorprivileges unless the organization admin also has this role.
* Extract from Documentation:
Organization admins manage user access, billing, and security at the Atlassian organization level. Managing Jira-specific groups requires Jira administrator privileges.
(Source: Atlassian Support Documentation, "Manage your Atlassian organization")
* Product Admin role for Jira (Option B):
* TheProduct Adminrole for Jira grants access to manage product-specific settings, such as user access to Jira Software. However, creating and managing groups is a system-level task that requiresJira administratorprivileges.
* Extract from Documentation:
Product admins manage user access to specific products (e.g., Jira Software). Group management requires Jira administrator or organization admin privileges.
(Source: Atlassian Support Documentation, "Manage product access")
* System administrator (Option C):
* The termsystem administratoris not a standard role in Jira Cloud. In some contexts, it may refer toJira administratorsororganization admins, but it is not a distinct privilege for group management.
* Extract from Documentation:
Jira Cloud uses roles like Jira administrator and organization admin. There is no distinct "system administrator" role for group management.
(Source: Atlassian Support Documentation, "Manage users and groups")
* Project administrator (Option E):
* Project administrators manage settings for specific projects (e.g., permissions, components) but cannot create or manage groups, as these are global settings.
* Extract from Documentation:
Project administrators manage project-specific settings but cannot access global settings like user or group management.
(Source: Atlassian Support Documentation, "Manage project permissions")
* Additional Notes:
* Jon's tasks require access toSettings > User management > Groups, which is restricted toJira administrators.
* If Jon is also an organization admin, he might have overlapping permissions, but theJira administratorrole is the most direct for group management in Jira.
:
Atlassian Support Documentation:Manage groups in Jira Cloud
Atlassian Support Documentation:Manage your Atlassian organization
Atlassian Support Documentation:Manage product access
Atlassian Support Documentation:Manage project permissions
NEW QUESTION # 32
No one should be allowed to edit issues in a particular workflow status of a company-managedproject. Which element must be configured?
- A. Post function
- B. Condition
- C. Status Property
- D. Trigger
Answer: C
Explanation:
Okay, let's analyze this question again with the revised options.
The requirement is to preventanyonefromeditingan issue when it resides in aspecific workflow status.
As established previously:
* Conditions (A):Control whether atransitionout of or into a status can occur. They check criteriabeforea transition starts. They don't prevent editingwhilean issue is sitting in a status.
* Post Functions (Implied by B & C):Actions that executeaftera transition is successfully completed (e.
g., updating a field, sending a notification). They don't affect editability within the status itself.
* Triggers (D):Automatically initiate a workflow transition based on external events (like code commits). Not relevant to editing permissions within a status.
The correct way to achieve this in Jira is by setting aStatus Property:
* Navigate to Workflow configuration.
* Select the relevant status.
* Go to its 'Properties'.
* Add a property: jira.issue.editable with the value false.
NEW QUESTION # 33
Your business owners have told you to use roles as much as possible in Jira because it allows them to do things that groups cannot do.
When considering this, you need to be aware of those actions in Jira that require the use of groups rather than roles.
Identify two actions in Jira that require the use of groups. (Choose two.)
- A. controlling who can perform Bulk Change in a project
- B. granting system administrative rights
- C. allowing users to use transitions in all the workflows
- D. defining Issue Security levels
- E. granting permissions to teams coming from Active Directory
- F. granting Project Administration rights
Answer: D,F
Explanation:
Reference: https://confluence.atlassian.com/adminjiracloud/managing-project-roles-776636382.html
NEW QUESTION # 34
An automation rule is configured as shown:
* When: Rule is triggered on All comments
* If: Initiator is in Developers
* Then: Transition the issue to DEVELOPMENT
If: Initiator is in Reviewers
* Then: Transition the issue to REVIEWYou are only in the Reviewers project role. What happens when you comment on an issue?
- A. The rule executes but does not perform any actions.
- B. The rule does not execute.
- C. The issue transitions to REVIEW.
- D. The issue transitions to DEVELOPMENT.
Answer: C
Explanation:
The automation rule is triggered when any comment is added to an issue and checks the initiator's project role to determine the action. Since you are only in theReviewersproject role, commenting on an issue will trigger the rule, and the issue will transition toREVIEWbased on the rule's logic.
* Explanation of the Correct Answer (Option B):
* The rule is triggered byAll comments, meaning any comment on an issue activates the rule.
* The rule has twoIfconditions:
* If the initiator (the user who commented) is in theDevelopersproject role, the issue transitions toDEVELOPMENT.
* If the initiator is in theReviewersproject role, the issue transitions toREVIEW.
* Since you are only in theReviewersproject role, the secondIfcondition is met when you comment, and theThenaction transitions the issue toREVIEW.
* Exact Extract from Documentation:
Configure automation rules
Automation rules consist of triggers, conditions, and actions.
* Trigger: Defines when the rule runs (e.g., Comment Added).
* Condition: Checks criteria like user roles (e.g., Initiator is in Reviewers).
* Action: Performs tasks like transitioning an issue.Conditions are evaluated sequentially, and the corresponding action is executed if the condition is met. If multiple conditions apply, each matching condition's action is executed unless restricted by rule logic.Note:
The initiator is the user who triggers the rule (e.g., the commenter).(Source: Atlassian Support Documentation, "Automate your Jira Cloud instance")
* Why This Fits: As a member of theReviewersproject role, your comment satisfies theIf:
Initiator is in Reviewerscondition, triggering theTransition the issue to REVIEWaction, making Option B the correct answer.
* Why Other Options Are Incorrect:
* The rule does not execute (Option A):
* The rule is triggered byAll comments, so any comment, including yours, will execute the rule. The issue is not whether the rule executes but what action it performs.
* Extract from Documentation:
AComment Addedtrigger activates the rule whenever a comment is added to an issue, regardless of the user' s role.
(Source: Atlassian Support Documentation, "Jira automation triggers")
* The rule executes but does not perform any actions (Option C):
* The rule executes and performs theTransition the issue to REVIEWaction because you are in theReviewersproject role, which satisfies the secondIfcondition. The rule will not skip actions if a condition is met.
* Extract from Documentation:
If a condition in an automation rule is met, the associated action is executed unless restricted by additional logic.
(Source: Atlassian Support Documentation, "Automate your Jira Cloud instance")
* The issue transitions to DEVELOPMENT (Option D):
* TheDEVELOPMENTtransition is only triggered if the initiator is in theDevelopersproject role. Since you are only in theReviewersrole, this condition is not met, and the issue will not transition toDEVELOPMENT.
* Extract from Documentation:
Conditions likeInitiator is in [Role]check the user's project role membership. Only the actions for matching conditions are executed.
(Source: Atlassian Support Documentation, "Jira automation conditions")
* Additional Notes:
* The rule assumes theDEVELOPMENTandREVIEWstatuses exist in the project's workflow and that transitions to these statuses are valid from the issue's current status.
* If you were in bothDevelopersandReviewersroles, both actions could execute sequentially, but the question specifies you are only inReviewers, so only theREVIEWtransition applies.
:
Atlassian Support Documentation:Automate your Jira Cloud instance
Atlassian Support Documentation:Jira automation triggers
Atlassian Support Documentation:Jira automation conditions
NEW QUESTION # 35
You are adding a user to Jira software using the invite users method in user management Which setting on the page guarantees the user access to Jira software (Choose one)
- A. Group membership
- B. Email address
- C. Product access
- D. Email domains
Answer: C
NEW QUESTION # 36
A dashboard displays an Issue Statistics gadget as shown.
The dashboard owner wants to change the order of the statuses shown in the gadget to appear as follows.
1. To Do
2. In Progress
3. Ready For QA
4. Blocked
5. Rejected
6. Done
Which action will permanently arrange the statuses into the required order?
- A. Reorder the statues on the Status administration page.
- B. Add numbers to the status names to allow them to be sorted in numerical order.
- C. Change the category of the statuses.
- D. Change the gadget Sort By field to Total.
- E. Change the Sort Direction option in the gadget to Ascending.
Answer: B
Explanation:
Reference: https://community.atlassian.com/t5/Jira-questions/How-to-change-order-of-statuses-in-a-Two- Dimension-filter/qaq-p/320423
NEW QUESTION # 37
Your site contains the following:
* Alpha filter: Public
* Beta filter: Private
* Omega dashboard: PublicThe system setting 'Allow users to share dashboards and filters with the public' is currently set to ON. You change that setting to OFF. What is the impact of this change?
- A. Users who are not logged in cannot see Omega dashboard.
- B. You cannot set Viewers to Private on Alpha filter.
- C. Users who are not logged in cannot see Alpha filter.
- D. You cannot set Viewers to Public on Beta filter.
Answer: A,C
Explanation:
The system setting'Allow users to share dashboards and filters with the public'in Jira Software Cloud controls whether dashboards and filters marked asPubliccan be accessed by users who are not logged in (i.e., anonymous users). When this setting is turnedOFF, public dashboards and filters become inaccessible to non- logged-in users. The impact is thatusers who are not logged in cannot see Alpha filter(Option C) andusers who are not logged in cannot see Omega dashboard(Option D).
* Explanation of the Correct Answers:
* Users who are not logged in cannot see Alpha filter (Option C):
* TheAlpha filteris marked asPublic, meaning it is accessible to anyone, including non- logged-in users, when the'Allow users to share dashboards and filters with the public' setting isON. Turning this settingOFFdisables public access, so non-logged-in users can no longer view theAlpha filter.
* Exact Extract from Documentation:
Manage public sharing of dashboards and filters
The'Allow users to share dashboards and filters with the public'setting controls whether public dashboards and filters can be accessed by anonymous (non-logged-in) users.
* WhenON, public dashboards and filters are accessible to anyone with the URL, including non-logged-in users.
* WhenOFF, public dashboards and filters are restricted to logged-in users with appropriate permissions (e.g.,Browse Projectsfor filters).To change the setting:
* Go toSettings > System > Sharing.
* ToggleAllow users to share dashboards and filters with the public.Impact:
Turning the settingOFFprevents non-logged-in users from accessing public filters and dashboards.(Source: Atlassian Support Documentation, "Manage sharing in Jira Cloud")
* Why This Fits: TheAlpha filteris public, and turning off public sharing prevents non- logged-in users from accessing it, making Option C correct.
* Users who are not logged in cannot see Omega dashboard (Option D):
* TheOmega dashboardis marked asPublic, so it is accessible to non-logged-in users when the public sharing setting isON. Turning the settingOFFrestricts access to logged-in users only, meaning non-logged-in users cannot see theOmega dashboard.
* Exact Extract from Documentation:
When the'Allow users to share dashboards and filters with the public'setting is turnedOFF, public dashboards and filters are no longer accessible to anonymous users. Logged-in users with appropriate permissions can still access them.
(Source: Atlassian Support Documentation, "Manage sharing in Jira Cloud")
* Why This Fits: TheOmega dashboardis public, and disabling public sharing prevents non- logged-in users from accessing it, making Option D correct.
* Why Other Options Are Incorrect:
* You cannot set Viewers to Public on Beta filter (Option A):
* TheBeta filteris currentlyPrivate, but the ability to set a filter toPublicis controlled by user permissions (e.g.,Share dashboards and filtersglobal permission), not the public sharing setting. Turning off public sharing prevents non-logged-in users from accessing public filters but does not restrict users from setting a filter toPublic. However, even if set to Public, the filter would not be accessible to anonymous users with the settingOFF. This option is misleading and not a direct impact.
* Extract from Documentation:
TheShare dashboards and filtersglobal permission allows users to set filters toPublic. The public sharing setting affects access, not the ability to configure sharing.
(Source: Atlassian Support Documentation, "Manage global permissions")
* You cannot set Viewers to Private on Alpha filter (Option B):
* TheAlpha filteris currentlyPublic, but users can change its sharing settings toPrivate(or other options like a group or role) regardless of the public sharing setting. The system setting only affects whetherPublicfilters and dashboards are accessible to non-logged-in users, not the ability to set sharing toPrivate. This is not an impact of the change.
* Extract from Documentation:
Users can set filters toPrivate,Public, or other sharing options based on their permissions, independent of the public sharing setting.
(Source: Atlassian Support Documentation, "Manage filters in Jira Cloud")
* Additional Notes:
* The change requiresJira administratorprivileges to modify the setting inSettings > System > Sharing.
* Logged-in users with appropriate permissions (e.g.,Browse Projectsfor filters, view permissions for dashboards) can still accessAlpha filterandOmega dashboardafter the setting is turnedOFF.
* TheBeta filter(Private) is unaffected, as it was never accessible to non-logged-in users.
:
Atlassian Support Documentation:Manage sharing in Jira Cloud
Atlassian Support Documentation:Manage global permissions
Atlassian Support Documentation:Manage filters in Jira Cloud
NEW QUESTION # 38
Jon is a new Jira user. He reports that adding comments to Jira isn't working as expected. When he attempts to @mention a user, no list of available users is provided. Because he does not know everyone's username, he is unable to target comments to specific users.
What is the cause of this problem?
- A. Jon does not have the Browse Users global permission.
- B. Jon does not have the View Users project permission.
- C. The field configuration for the Comment field is not set to Autocomplete Renderer.
- D. Jon does not have the correct field security permission for the Comment field.
Answer: C
Explanation:
Reference: https://community.atlassian.com/t5/Jira-questions/Can-t-Mention-other-users/qaq-p/5238
NEW QUESTION # 39
Your Jira Cloud instance has hundreds of company-managed projects which are used only by the development team at your organization. All projects share a single permission scheme. New business requirements state:
* Customer support staff at your organization need to view all issues in all the projects.
* They also need to share filters with other users.
* They should not be granted too much access.
Identify the appropriate way to configure customer support staff in Jira.
- A. As a security level
- B. As a new group
- C. As a new permission
- D. As a new project role
Answer: B
Explanation:
To meet the requirements of allowing customer support staff to view all issues in all company-managed projects, share filters, and avoid granting excessive access, configuring the staff as anew group(Option A) is the most appropriate approach. This allows the group to be granted specific permissions in the shared permission scheme and global permissions without requiring structural changes to the projects.
* Explanation of the Correct Answer (Option A):
* Viewing all issues: All projects share a single permission scheme, which defines permissions like Browse Projects(required to view issues). By creating a new group (e.g., "Customer Support"), you can add this group to theBrowse Projectspermission in the shared permission scheme, granting customer support staff access to view issues in all projects.
* Sharing filters: Sharing filters requires theShare dashboards and filtersglobal permission.
Adding the "Customer Support" group to this global permission allows staff to share filters with other users.
* Minimal access: Using a group ensures that only the necessary permissions (Browse Projectsand Share dashboards and filters) are granted, avoiding excessive access (e.g., editing issues, administering projects).
* Exact Extract from Documentation:
Manage groups in Jira Cloud
Groups are used to manage user permissions efficiently across multiple projects.
To grant permissions to a group:
* Create a new group inSettings > User management > Groups.
* Add users to the group.
* Add the group to permissions in the permission scheme (Settings > Issues > Permission schemes) or global permissions (Settings > System > Global permissions).Example: Add a group to theBrowse Projectspermission to allow members to view issues, and to the Share dashboards and filtersglobal permission to share filters.Note: Groups are ideal for applying permissions across multiple projects with a shared permission scheme.(Source:
Atlassian Support Documentation, "Manage groups in Jira Cloud")
* Why This Fits: Creating a new group allows you to efficiently grant theBrowse Projects permission (via the shared permission scheme) and theShare dashboards and filtersglobal permission to customer support staff, meeting all requirements while keeping access minimal.
* Why Other Options Are Incorrect:
* As a security level (Option B):
* Security levels (part of an issue security scheme) restrict who can view specific issues within a project. The requirement is to grant visibility to all issues, not restrict it, so security levels are irrelevant. Additionally, security levels do not address sharing filters.
* Extract from Documentation:
Issue security levels restrict issue visibility to specific users, groups, or roles. They are not used to grant broad access like viewing all issues.
(Source: Atlassian Support Documentation, "Configure issue security schemes")
* As a new project role (Option C):
* Project roles are used in permission schemes to grant permissions within projects. While a new project role (e.g., "Customer Support Role") could be created and added to theBrowse Projectspermission, this would require adding the role to each project's role membership, which is inefficient for hundreds of projects. A group is more practical, as it can be added once to the shared permission scheme. Project roles also do not directly address global permissions likeShare dashboards and filters.
* Extract from Documentation:
Project roles are project-specific and require membership configuration in each project. Groups are more efficient for permissions across multiple projects with a shared scheme.
(Source: Atlassian Support Documentation, "Manage project roles")
* As a new permission (Option D):
* Creating a new permission is not a valid option in Jira, as permissions are predefined (e.g., Browse Projects,Edit Issues). The requirement is met by granting existing permissions ( Browse Projects,Share dashboards and filters) to a group, not by creating a new permission type.
* Extract from Documentation:
Jira permissions are fixed and cannot be extended with new permission types. Use existing permissions in permission schemes or global permissions.
(Source: Atlassian Support Documentation, "Manage permissions in Jira Cloud")
* Additional Notes:
* Steps to configure:
* Create a "Customer Support" group inSettings > User management > Groups.
* Add customer support staff to the group.
* Add the group to theBrowse Projectspermission in the shared permission scheme ( Settings > Issues > Permission schemes).
* Add the group to theShare dashboards and filtersglobal permission (Settings > System > Global permissions).
* This approach requiresJira administratorprivileges to manage groups and permissions.
* A group is more scalable than a project role for hundreds of projects, as it avoids per-project configuration.
:
Atlassian Support Documentation:Manage groups in Jira Cloud
Atlassian Support Documentation:Configure issue security schemes
Atlassian Support Documentation:Manage project roles
Atlassian Support Documentation:Manage permissions in Jira Cloud
Atlassian Support Documentation:Manage global permissions
NEW QUESTION # 40
You renamed a status in the workflow of a team-managed project. Which statement is true?
- A. Transitions coming into that status must be updated.
- B. The status will be renamed in all team-managed workflows.
- C. Saved filters that reference the status must be updated.
- D. The status will be renamed on the Status page in Jira administration.
- E. Workflow rules that reference the status must be updated.
Answer: C
Explanation:
Renaming a status in a team-managed project's workflow affects only that project's workflow, as statuses in team-managed projects are project-specific. The primary impact is thatsaved filters that reference the status must be updated(Option D), as JQL queries in filters use status names and will no longer return correct results if the status name changes.
* Explanation of the Correct Answer (Option D):
* In Jira, saved filters often use JQL queries that reference status names (e.g., status = "In Progress"). If a status is renamed in a team-managed project's workflow (e.g., from "In Progress" to "Active"), any filters referencing the old status name will no longer include issues in the renamed status. These filters must be updated to use the new status name.
* Exact Extract from Documentation:
Manage statuses in team-managed projects
Statuses in team-managed projects are project-specific and edited inProject settings > Workflow. Renaming a status changes its name for that project's issues.
Impact: JQL queries in filters, boards, or dashboards that reference the status name (e.g., status = "In Progress") will no longer match issues in the renamed status. Update these queries to use the new status name.
(Source: Atlassian Support Documentation, "Configure workflows in team-managed projects")
* Why This Fits: Renaming a status affects JQL-based filters that explicitly reference the status, requiring updates to reflect the new name, making Option D the correct answer.
* Why Other Options Are Incorrect:
* The status will be renamed in all team-managed workflows (Option A):
* Statuses in team-managed projects are project-specific, not shared across projects.
Renaming a status in one project's workflow does not affect other team-managed projects.
* Extract from Documentation:
Each team-managed project has its own workflow and statuses, independent of other projects. Changes to a status in one project do not affect others.
(Source: Atlassian Support Documentation, "Configure workflows in team-managed projects")
* Workflow rules that reference the status must be updated (Option B):
* Workflow rules in team-managed projects (e.g., transition restrictions, fieldupdates) reference statuses by their internal IDs or context, not their display names. Renaming a status does not break these rules, so they do not need updating.
* Extract from Documentation:
Workflow rules in team-managed projects are tied to status IDs, not names. Renaming a status does not require updating rules.
(Source: Atlassian Support Documentation, "Configure workflows in team-managed projects")
* Transitions coming into that status must be updated (Option C):
* Transitions in a workflow reference statuses by their internal IDs or context, not their display names. Renaming a status does not affect the transitions pointing to it, so no updates are needed.
* Extract from Documentation:
Transitions are linked to statuses by internal IDs. Renaming a Bedrock status does not affect transition configurations.
(Source: Atlassian Support Documentation, "Configure workflows in team-managed projects")
* The status will be renamed on the Status page in Jira administration (Option E):
* TheStatus pagein Jira administration (Settings > Issues > Statuses) manages global statuses used in company-managed projects. Team-managed project statuses are project- specific and do not appear on or affect the global Status page.
* Extract from Documentation:
Statuses in team-managed projects are project-specific and not listed inSettings > Issues > Statuses, which is for company-managed projects.
(Source: Atlassian Support Documentation, "Manage statuses in Jira Cloud")
* Additional Notes:
* Renaming a status in a team-managed project is done inProject settings > Workflowand requires project admin privileges.
* To minimize filter issues, use status IDs in JQL queries (e.g., status = 10001), but this is less common than using names.
:
Atlassian Support Documentation:Configure workflows in team-managed projects Atlassian Support Documentation:Manage statuses in Jira Cloud Atlassian Support Documentation:Manage filters in Jira Cloud
NEW QUESTION # 41
......
Prepare Top ATLASSIAN ACP-120 Exam Audio Study Guide Practice Questions Edition: https://www.passcollection.com/ACP-120_real-exams.html
Dumps Practice Exam Questions Study Guide for the ACP-120 Exam: https://drive.google.com/open?id=1gyCZsVqqTFnFs-benwj58X8uqwcqfP5x
