Free ACP-520 Practice Test

In Atlassian Cloud administration, clicking the "Grant access to Jira Software" button (without selecting the "Configure this user's access in the next step" checkbox) automatically approves the request using the default product access settings. By design, this action adds the user to the designated default group(s) for the product (e.g., jira-software-users). Membership in these default groups assigns the standard User product role. To grant a Product Admin role during this workflow, an administrator must select the "Configure..." checkbox to manually change the role assignment. Therefore, without that manual intervention, the system definitively grants the standard User role.

A. Claudia is added to multiple product access groups: This is not definitely true. Administrators can configure a single default group (e.g., just jira-software-users) or multiple groups. The quantity depends on the specific site configuration.

C. Claudia is added to only one default group: Similar to Option A, this is not definitely true. An administrator may have configured multiple groups (e.g., jira-software-users and site-users) to be assigned by default.

D. Claudia is granted access to Jira Software only: Granting access to Jira Software often implicitly grants access to other bundled features (like Jira Work Management) or site-level access depending on how the default groups are utilized.

E. Claudia is not granted any Product Admin roles: While typically true, this relies on the assumption that the default group is not a "Product Admin" group. While non-standard, an admin could theoretically set an admin group as the default. Option B is the stronger answer as it describes the definitive system action (assigning the standard access role).

Atlassian Support: Approve or deny access requests. Describes the behavior of the "Grant access" button adding users to default groups.

Reference: "When you approve a request, the user is added to the default group for that product... giving them the User role."

Atlassian Support: Update product access settings. Explains how default groups determine the level of access (User role) assigned to new users.

Reference: Section "Manage product access for users" - "New users are added to the default groups... assigned the User role."

Atlassian Documentation: Give users admin permissions. Clarifies that assigning Product Admin roles requires specific intervention (using the "Configure" step or editing user details), distinguishing it from the default "Grant" flow.

Atlassian Access bills for unique managed accounts that have product access to at least one billable Atlassian cloud product. Billable products include Jira Software, Confluence, and Jira Service Management on Standard, Premium, or Enterprise plans. Users on a Confluence Enterprise plan are, by definition, active, managed accounts with access to a billable product. Therefore, they will definitely be included in the Atlassian Access bill. Other user types, such as those on Free plans, deactivated accounts, or portal-only customers, are explicitly excluded from this billing model.

A. Users who only have access to Free plans are not counted as billable for Atlassian Access, even if their accounts are managed.
B. Deactivated accounts are not active users and are not included in the billable user count for Atlassian Access or the product itself.
D. Portal-only customers for Jira Service Management are not considered licensed product users and are explicitly excluded from Atlassian Access billing.

1. Atlassian Cloud Support Documentation

"Manage your bill for Atlassian Access." This document explicitly states

"We bill you for the total number of unique users with product access to Jira Software

Jira Service Management

Confluence

Bitbucket

or Trello on a Standard

Premium

or Enterprise plan." It also lists non-billable users

including "Users who only have access to products on a Free plan" and "Jira Service Management portal-only customers."

Reference Section: "How we calculate your bill" and "Users who aren't billable."

2. Atlassian Cloud Support Documentation

"Understand Atlassian Access." This guide clarifies the purpose of Access

which is to manage users across paid Atlassian cloud products. It reinforces that billing is tied to users with access to these products.

Reference Section: "Billing for Atlassian Access."

3. Atlassian University

"ACP-520 Atlassian Cloud Organization Admin Certification Prep." Course materials for this certification cover the billing model for Atlassian Access

emphasizing that billing applies to managed accounts with access to paid product plans (Standard and above)

and specifically excludes Free plans and JSM portal customers.

Reference Module: "Billing and Subscriptions

" Section on "Atlassian Access Billing."

The User product role grants a user a license and the ability to log in to and use the Confluence product. By unselecting this role for the site-admins group, any member whose only access to Confluence is through this group will lose their license and will no longer be able to access the Confluence site. Consequently, they cannot perform any actions within the Confluence user interface. This includes using features like the People directory or @mentioning users, which are ways of "seeing" other Confluence users within the application. While they can still manage user access from the administration hub, they lose all in-product visibility and functionality.

A. Org admins are no longer Confluence users in the ACME site. The action was performed on the site-admins group, not the org admins group. These are distinct roles with different scopes and permissions.
B. Org admins are no longer Confluence admins in the ACME site. This is incorrect for two reasons: the action was on site-admins, not org admins, and the User role was removed, not the Admin role.
C. User product role no longer exists in the ACME site. The User role was unassigned from a specific group; the role itself, a default system role, was not deleted from the site.
F. ACME site admins can no longer manage Confluence users. This is incorrect. Site administrators manage user product access via the central administration portal (admin.atlassian.com), a function separate from having a user role within the product itself.
G. User product role no longer exists in the organization. The change was scoped to a single group on a specific site (ACME), not the entire organization. The role still exists organization-wide. ---

1. Atlassian Cloud Support Documentation, "Give users product access": This document clarifies that product access is required to use a product. It states, "Product access settings control which users can log in to your Atlassian products and which products they can access." Removing the User role from the site-admins group revokes this login capability. (Accessed under the section "How product access works").

2. Atlassian Cloud Support Documentation, "Admin roles and permissions": This page distinguishes between site administrator and product administrator roles. It specifies that site administrators "Manage users and groups for your site" and "Manage product access for users and groups." This confirms that user management (Option F) is a site admin function performed outside the product, which is unaffected by losing the in-product User role.

3. Confluence Cloud Documentation, "Find people and teams": This page describes the "People" directory, an in-product feature for finding and viewing other users. Access to this feature requires the ability to log in to Confluence, which is lost when the User product role is removed. This supports the reasoning for why Option E is correct.

When a user is removed from an Atlassian Cloud site, the change in user count is registered immediately, but the subscription plan itself does not change automatically. In this scenario, both Jira Software and Confluence are on Standard plans. Removing a user drops the Jira user count from 11 to 10 and the Confluence count from 10 to 9. While this change will cause the next bill for Jira Software to be calculated at the lower 1-10 user tier, the active subscription plan (Standard) for both products remains unchanged. Downgrading a plan, for instance from Standard to Free, is a manual action that must be initiated by a site administrator and does not occur automatically based on user count.

B. Confluence will be downgraded to a Standard plan. This is incorrect because the Confluence subscription is already on a Standard plan; it cannot be "downgraded" to the same plan.
C. Confluence will begin a Standard plan trial period. This is incorrect. The subscription is an active, paid plan. Removing a user does not trigger a trial period for a plan that is already in use.
D. Jira Software will be downgraded to a Free plan. This is incorrect. Changing a subscription plan from Standard to Free is a manual administrative action and does not happen automatically when the user count drops.
E. Jira Software will begin a Free plan trial period. This is incorrect. Removing users from a paid plan does not initiate a trial for a different plan tier.

1. Atlassian Cloud Support

"Manage your bill for Jira products." This document explains how billing is handled. It states

"For monthly subscriptions

you will be charged for the upcoming month based on the number of users you have." This confirms that the change affects the next bill

not the immediate subscription plan. The plan itself (Standard) remains active.

Reference Section: "How billing works"

2. Atlassian Cloud Support

"Change your Atlassian Cloud plan." This guide details the explicit

manual steps a site administrator must take to change a subscription from one plan to another (e.g.

Standard to Free). This confirms that such a change is not automatic.

Reference Section: "Change your plan"

3. Atlassian Cloud Support

"Atlassian Cloud billing FAQs." Under the "Managing users" section

it clarifies that for monthly subscriptions

the charge is based on the user count at the time of billing. For annuals

it's adjusted at renewal. In neither case does it mention an automatic plan downgrade.

Reference Section: "How will I be billed if I add or remove users?"

The group names jira-software-users-acme and jira-admins-acme contain a specific reference to "Jira Software." In Atlassian Cloud, when a product like Jira Software is added to a site, a corresponding default group (e.g., jira-software-users) is created to manage product access. The creation of custom groups that explicitly name a product is the most direct and certain evidence that the organization possesses that product. While the function of a group can be changed by an administrator, the name itself is a strong indicator of the assets available within the organization's Atlassian site. There would be no logical reason to create groups with these names if the Jira Software product did not exist.

A. The group name strongly implies this function, but an administrator can configure any group for various purposes. It is not definitely used for product access.
B. While illogical, an administrator has the technical ability to grant Confluence access to any group, so we cannot be certain this is true.
C. An administrator could add these groups to the organization admin role, so it is not a definitive exclusion.
D. A user, particularly an administrator, would very likely be a member of both groups. There is no basis to assume they are mutually exclusive.

1. Atlassian Cloud Documentation - Give users access to products: This document explains that product access is managed by adding users to groups associated with that product. It states

"When you sign up for a new Atlassian cloud product

we create a default group for your product and give that group access." This establishes the direct link between the existence of a product and the creation of groups named after it.

Source: Atlassian. (n.d.). Give users access to products. Atlassian Support. Section: "How product access works".

2. Atlassian Cloud Documentation - Create and update groups: This document details how administrators can create custom groups. The names provided in the question (...-acme) are examples of custom groups. The fact that an administrator would create a custom group named after Jira Software reinforces the conclusion that the product must exist in their instance.

Source: Atlassian. (n.d.). Create and update groups. Atlassian Support. Section: "Create new groups".

The group jira-software-users- (e.g., jira-software-users-acme) is a default group created to grant users application access to Jira Software. Deleting this group revokes that access for any user who relied solely on it. Without Jira Software application access, a user like Bob loses the ability to use product-specific features. Updating an agile board, such as changing its column configuration or filter, is a core Jira Software function. Therefore, if Bob was a member of the deleted group, he would no longer be able to perform this action.

A. Changing personal settings is a function of a user's Atlassian account, not their specific application access within Jira Software.
C. "Spaces" are a core concept in Confluence, not Jira. Jira uses "projects" as its primary container for issues.
D. Service Level Agreements (SLAs) are a feature specific to Jira Service Management, not Jira Software.
E. Creating and managing API keys (API tokens) is done through a user's personal Atlassian account settings, independent of their access to a specific Jira product.

1. Atlassian Cloud Support, "Manage groups": "When you sign up for a new Jira product, we'll automatically create a group for you with access to that product. For example, if you sign up for Jira Software, we'll create a jira-software-users group... Deleting a group removes it from your site. Users in that group may lose permissions or access to products." This confirms the group's purpose and the impact of its deletion.

2. Atlassian Cloud Support, "Configure a board": "To configure a board, you need to be either: a board administrator for the board, or a Jira administrator." Accessing a board and its configuration settings fundamentally requires Jira Software application access, which is lost when the jira-software-users group is deleted.

3. Atlassian Cloud Support, "Manage your Atlassian account": This documentation outlines that personal settings and security features like API tokens are managed at the Atlassian account level (id.atlassian.com), not within the Jira product interface itself.

4. Atlassian Cloud Support, "Set up service level agreements (SLAs)": This official documentation places the configuration and management of SLAs squarely within the Jira Service Management product documentation, distinguishing it from Jira Software's feature set.

In Atlassian Cloud, organization administrators can configure "User access settings" to control how new users gain access to products. These settings can be applied differently to various products. If one product (e.g., Jira Software) is configured to allow existing users to invite anyone who then gets immediate access, Arjun would join instantly. If the other product (e.g., Jira Service Management) is configured to require administrator approval for new users, Arjun's access request, triggered by Laura's invitation, would be placed in a queue for an admin to approve. This difference in product-specific access settings directly accounts for the scenario.

B. Laura's admin status for a product determines her ability to manage that product, not the site-wide user access approval process for an invited user like Arjun.
C. Laura's email verification status is tied to her Atlassian account for the entire site, not configured on a per-product basis.
D. The invitation process described originates from a single Atlassian site that contains both products; it is not possible for Laura to be on different sites for this action.
E. Arjun's email verification is a one-time action for his new Atlassian account and is not a per-product status.

1. Atlassian Cloud Support Documentation, "Specify how users get access to products." This document details the different user access settings available to organization admins. It explains the options for allowing users to join immediately versus requiring admin approval. The settings can be configured for product groups, allowing for the discrepancy described in the question. (Accessed under the "Control how users get access" section).

2. Atlassian Cloud Support Documentation, "Invite users." This guide explains the invitation workflow and explicitly states, "When you invite a user to a product, they'll get an email with a link to join. What happens next depends on your user access settings." This directly links the invitation action to the site's access configuration, which can differ between products. (See the "Before you begin" section).

An organization admin in Atlassian Cloud has exclusive permissions for certain high-level tasks. Based on the actions performed:
1. Verified a domain (User 1): This is a core security and user management function that can only be performed by an organization admin to manage user accounts under that domain.
2. Created a new Jira site (User 2): Adding a new product or site to an existing organization is an administrative action restricted to organization admins. The other tasks can be performed by users with different roles. Adding users to groups or changing roles can be done by site admins at the site level, and any user can create a personal API key. Therefore, only User 1 and User 2 are definitely organization admins.

A. This is incorrect because two distinct tasks listed (verifying a domain and creating a new site) are exclusive to the organization admin role.
C. This is incorrect because adding a user to a group, creating an API key, and changing a user's role can be performed by site admins or individual users, not exclusively by org admins.
D. This is incorrect for the same reasons as C; only two of the five tasks are exclusive to organization admins.
E. This is incorrect as three of the five tasks can be performed by users who are not organization admins.

1. Verifying a Domain: Atlassian Cloud Support Documentation, "Verify a domain to manage accounts." Under the "Before you begin" section, it states, "To verify a domain, you need to be an admin of an Atlassian organization."

2. Creating a New Site: Atlassian Cloud Support Documentation, "Add products to your organization." The introductory paragraph states, "To add a product, you need to be an organization admin."

3. Site Admin Permissions: Atlassian Cloud Support Documentation, "Give users admin permissions." This page details the capabilities of different admin roles, clarifying that site admins can "Manage users and groups for the sites they have access to," which includes adding users to groups and changing site-level roles.

4. Creating API Keys: Atlassian Cloud Support Documentation, "API tokens." The section "Create an API token" states, "You can create an API token from your Atlassian account's profile," indicating this is a standard user-level capability.

The Jira Service Management sandbox creation process is designed to replicate the production environment's configuration for testing. This includes copying users (excluding customers), groups, project roles, and permission schemes. Consequently, a user designated as a project administrator in production will have their account and the associated administrative permissions copied to the sandbox. This ensures the fundamental administrative structure is intact, allowing them to hold the same administrative privileges over the copied projects. While external factors like Single Sign-On (SSO) may require post-copy configuration to enable login, the permissions themselves are definitively present in the sandbox.

B. Atlassian's official documentation explicitly states that while attachment files are copied to the sandbox, they are not downloadable.
C. The ability to log in is not guaranteed. If the production site uses SSO, it must be reconfigured for the sandbox URL before users can authenticate.
D. The visibility of comments is not definite. The copy process may exclude certain apps or app data, which could impact how issue details, including comments, are rendered.
E. To protect real customers from test environment interactions and notifications, customer accounts are explicitly excluded from the data copied to the sandbox.

1. Atlassian Support Documentation

"Use a sandbox to prepare for changes."

For Correct Answer (A): Under the section "What's copied to your sandbox

" the documentation confirms that "Users and groups" and "Jira products and settings" (which includes project roles and permission schemes) are copied from production.

For Incorrect Option (B): Under the section "What's not copied or is different

" it states

"Attachments are copied to your sandbox. However

you won’t be able to download them."

For Incorrect Option (C): Under the section "What's not copied or is different

" the subsection on "Single sign-on" specifies

"If you use Atlassian Guard Standard... for single sign-on (SSO)

you’ll need to add the sandbox URL to your identity provider." This confirms login is not guaranteed without this step.

For Incorrect Option (D): Under the section "What's not copied or is different

" it notes

"Some apps and app data may not be copied to your sandbox."

For Incorrect Option (E): Under the section "What's not copied or is different

" the first point is

"Customer accounts aren't copied to your sandbox."

An Atlassian Cloud organization is the highest administrative level, containing all of a company's sites and users. Organization admins are granted permissions at this top level. Their administrative authority extends across the entire organization, which includes every site (site-1.atlassian.net, site-2.atlassian.net) within it. Therefore, the set of organization admins is identical for both sites because they belong to the same parent organization. Other attributes like pricing plans, user access to specific products, product admins, and default groups are all configured and managed at the individual site level, meaning they can and often do differ between sites.

A. Both sites are on the same pricing plan for Jira Software. Billing is managed on a per-site basis. Each site can have a different subscription plan (e.g., Free, Standard, Premium) for the same product.
B. Both sites have the same users for Jira Software. While users are managed centrally in the organization, product access is granted per site. A user can have access to Jira on one site but not the other.
C. Both sites have the same product admins. Product admin permissions are granted for a specific product on a specific site. An admin for Jira on site-1 is not automatically an admin for Jira on site-2.
E. Both sites have the same default groups. Default groups (e.g., jira-software-users) are created independently for each site. They are distinct entities and can have different user memberships on each site. ---

1. Atlassian Cloud Support Documentation

"Administering an Atlassian organization." This document establishes the hierarchy: "Your organization is the top-level of administration for your company's Atlassian cloud products. As an organization admin

you can manage the user accounts

security policies

and billing for all the Atlassian cloud products and sites used by your company." This supports that the Org Admin role is global to all sites.

Source: https://support.atlassian.com/organization-administration/docs/administering-an-atlassian-organization/

2. Atlassian Cloud Support Documentation

"What's the difference between site admins and organization admins?" This page explicitly defines the scope of the Org Admin role: "Organization admins can perform administrative functions for the entire organization

not just a specific site." This directly confirms the answer D. It also clarifies that site-level functions are separate

refuting C.

Source: https://support.atlassian.com/user-management/docs/whats-the-difference-between-site-admins-and-organization-admins/

3. Atlassian Cloud Support Documentation

"Manage billing for multiple sites." This document states: "Each of your sites has its own separate bill. If you have multiple sites

you'll get a separate bill for each one." This directly refutes option A.

Source: https://support.atlassian.com/billing/docs/manage-billing-for-multiple-sites/

4. Atlassian Cloud Support Documentation

"Give users access to products." This page explains how product access is managed: "When you grant product access to a user

you're adding them to a group that has access to that product on a specific site." This confirms that user access is site-specific

refuting option B and E.

Source: https://support.atlassian.com/user-management/docs/give-users-access-to-products/