1.2 Jira Cloud Architecture, Products & Admin Hierarchy
Key Takeaways
- Jira Cloud runs as multi-tenant SaaS, so admins work through settings pages, REST APIs, and audit logs instead of servers, databases, or file systems.
- Blueprint 1.2 tests three admin types: organization admin (Atlassian Administration), Jira admin (Administer Jira global permission), and project admin (Administer Projects permission).
- Jira admins cannot manage users, run imports or backups, or edit system email settings; those tasks belong to organization-level admins.
- Project admins manage roles, components, versions, and project details, but only org, site, or Jira admins can change a project key.
- The Edit workflows and Manage work item layouts permissions let non-admins change a workflow or layout only when no other project shares it.
Jira Cloud Architecture, Products & Admin Hierarchy
Operating an enterprise Jira Cloud site requires understanding how Atlassian's modern multi-tenant cloud architecture differs from legacy on-premise infrastructure. Modern Jira administrators must navigate a unified ecosystem spanning multiple specialized products, centralized identity directories, and a tiered administrative model.
This section explores the cloud architecture foundations, details the core Atlassian product portfolio, breaks down the administrator types the blueprint tests, and clarifies the balance between centralized organizational governance and project-level administrative autonomy.
Jira Cloud Multi-Tenant Architecture vs. Data Center / Server Legacy
Historically, Jira administrators operated in on-premise environments (Jira Server or Jira Data Center) with direct access to physical servers, file systems, operating system shells, and relational databases. In Jira Cloud, Atlassian operates a secure, multi-tenant Software-as-a-Service (SaaS) architecture hosted primarily on Amazon Web Services (AWS) global infrastructure.
| Architectural Dimension | Legacy On-Premise (Server / Data Center) | Jira Cloud (Multi-Tenant SaaS) | Administrative Impact |
|---|---|---|---|
| Database Access | Direct relational SQL access (jiraissue, cwd_user, etc.) | Zero direct database access; strictly abstracted | All data querying, scripting, and extraction must use Jira REST API v3 or native JQL |
| Filesystem & Logs | Direct access to <jira-home>, server.xml, and log files | Zero filesystem access; cloud-native logs | Diagnostics rely on the Jira audit log and the organization audit log |
| App Execution (Add-ons) | In-process OSGi P2 plugins running inside the Jira JVM | Out-of-process apps via Atlassian Connect & Atlassian Forge | Apps cannot exhaust Jira JVM memory or crash the host application; strict permission scopes enforced |
| Scheme Propagation | Modifications frequently required full index rebuilds or server restarts | Dynamic cloud propagation across shared schemes | Scheme associations update in real time across all linked projects without downtime |
| Upgrades & Maintenance | Manual maintenance windows, downtime, and upgrade testing | Continuous deployment managed entirely by Atlassian | Administrators focus on configuration governance rather than patching or OS maintenance |
App Architecture: Atlassian Connect vs. Atlassian Forge
In legacy environments, custom plugins executed directly inside the Jira Java Virtual Machine (JVM). A poorly optimized plugin could trigger memory leaks or bring down an entire enterprise node.
In Jira Cloud, apps run completely outside the host process:
- Atlassian Connect: An integration architecture where third-party apps run on vendor-managed cloud infrastructure, interacting with Jira Cloud over HTTPS via secure REST APIs and JSON Web Tokens (JWT).
- Atlassian Forge: Atlassian's next-generation serverless app platform. Forge apps execute in a secure, serverless Function-as-a-Service (FaaS) runtime hosted directly on Atlassian's compute infrastructure. Forge apps feature built-in data residency, declarative security scopes, and isolated storage, minimizing security and compliance overhead.
Jira Cloud Product Portfolio
The Atlassian Cloud platform hosts distinct product offerings built on top of a shared Jira core engine. While all Jira products share foundational scheme architecture (workflows, issues, screens, custom fields, and permissions), each product delivers specialized capabilities:
1. Jira Software (JSW)
Designed specifically for agile software development and technical project management:
- Scrum & Kanban Frameworks: Native support for sprint planning, active sprint tracking, Kanban continuous flow, and release versioning.
- Agile Metrics: Built-in reporting including Sprint Burndown charts, Velocity charts, Cumulative Flow Diagrams, and Version Reports.
- Developer Tool Integrations: Direct linkage to source code repositories (Bitbucket, GitHub, GitLab), surfacing pull requests, commits, and deployment pipelines directly inside Jira issue development panels.
2. Jira Service Management (JSM)
An ITIL-certified service desk and IT Service Management (ITSM) solution:
- Customer Portal & Request Types: Translates internal Jira issue types into user-friendly customer request types presented on a self-service web portal.
- Queues & Service Level Agreements (SLAs): Real-time SLA tracking timers with custom pause/stop conditions and calendar schedules (e.g., 9-to-5 business hours vs. 24/7 support).
- Portal-Only Customers: External or internal end users who submit service requests via the portal or email without consuming licensed Jira Software or JSM agent seats.
- ITSM Practices: Native workflows and schema objects for Incident, Problem, Change, and Service Request Management, including asset and configuration management (Assets).
3. Jira Work Management (JWM) & Jira Product Discovery (JPD)
- Jira Work Management (now part of the unified Jira interface): Tailored for business teams (Human Resources, Legal, Marketing, Finance). Features spreadsheet-like list views, calendar views, timeline views, and simple project templates.
- Jira Product Discovery: Designed for product managers to capture ideas, aggregate customer feedback, score feature opportunities using prioritization formulas, and publish visual product roadmaps.
The Administrator Types You Must Distinguish (Blueprint 1.2)
Blueprint objective 1.2 names three admin types: organization admin, Jira admin, and project admin. You need to know how each role is granted and what each can do. Atlassian Administration also has user-management roles (such as user access admin, and site admin on organizations that haven't moved to centralized user management). Treat those as part of the organization layer.
| Admin Type | How It Is Granted | Can Do | Cannot Do (without another role) |
|---|---|---|---|
| Organization admin | Assigned in Atlassian Administration (admin.atlassian.com) | Manage users and groups, product access, domains and managed accounts, security policies, billing, and org audit logs. Can grant other admin roles and can add themselves to jira-administrators. | Doesn't automatically administer Jira configuration. Atlassian's docs tell org and site admins to add themselves to the jira-administrators group to get Jira admin rights. |
| Jira admin (app admin) | The Administer Jira global permission, usually through the jira-administrators group | Create company-managed and team-managed projects; create and edit work types, fields, workflows, screens, and all schemes; manage global permissions; log in regardless of access restrictions | Manage users or invite new ones, import or export data (backups), or edit system email settings. Those need an organization-level admin role. |
| Project admin (space admin) | The Administer Projects project permission, usually granted to the Administrators project role | Assign users to project roles; edit components and versions; edit project name, URL, lead, description, and avatar; manage project-scoped automation rules | Change the project key, edit schemes or shared workflows and screens, create custom fields or statuses |
Exam trap: Older material refers to a "Jira System Administrators" global permission. That permission exists only in Jira Data Center. In Jira Cloud, the top Jira-level permission is Administer Jira, and site-wide tasks such as backups, user management, and email server settings belong to organization-level admins.
Delegated Configuration Permissions in Company-Managed Projects
Jira Cloud has replaced the old Extended project administration permission with more granular project permissions that you grant in the permission scheme:
- Edit workflows: lets a non-admin update statuses and transitions in the project's workflow using the workflow editor, only if that workflow isn't used by any other project.
- Manage work item layouts: lets a non-admin add existing fields to the issue layout, only if the layout's screens aren't shared with other projects. It doesn't allow creating new fields.
- Manage versions (releases): lets users create, release, archive, merge, edit, and delete versions.
If a workflow or layout is shared, the change needs the Administer Jira global permission. That is one reason experienced admins copy a shared workflow before handing it to a single team.
Cloud Navigation Interfaces & UI Paths
To excel on the ACP-120 exam, you must instantly recognize which administrative interface controls specific administrative tasks:
- Organization Administration (
admin.atlassian.com):- Path: App Switcher (waffle icon) >
Administration - Actions: Verify domains, configure SAML SSO, enforce password policies, review organization-wide audit logs, manage billing.
- Path: App Switcher (waffle icon) >
- Jira Settings (the Settings cog in Jira):
- Path: Top-right Settings icon > System / Apps / Spaces (Projects) / Work items (Issues)
- Actions: Manage global permissions, create custom fields, design workflows, configure permission and notification schemes. (Requires Administer Jira.)
- Project Settings (
Project navigation > Project settings):- Path: Open specific project > Left-hand sidebar >
Project settings - Actions: Manage project role memberships, add components, create versions, view applied schemes.
- Path: Open specific project > Left-hand sidebar >
Separation of Site-Level Governance from Project-Level Autonomy
A fundamental architectural decision in Jira Cloud is choosing between Company-Managed Projects (CMP) and Team-Managed Projects (TMP):
| Characteristic | Company-Managed Projects (CMP) | Team-Managed Projects (TMP) |
|---|---|---|
| Target Audience | Enterprise teams requiring standardized governance | Independent teams requiring rapid agility |
| Scheme Architecture | Standardized, reusable global schemes (workflows, screens, fields, permissions) | Completely isolated, local configuration; no global schemes |
| Field Creation | Created globally by Jira Administrators; customized via Field Configurations | Created directly within the project by Project Administrators |
| Workflow Flexibility | Centralized workflows with complex Conditions, Validators, and Post-functions | Simplified board-driven workflows; basic transition rules |
| Cross-Project Reporting | High consistency; fields and statuses remain standardized across multiple projects | Inconsistent naming; fields created in TMP cannot easily merge into global reporting |
| Administrative Overhead | Requires Jira Administrator to create fields and modify shared schemes | Zero overhead for Jira Administrators; self-service for project leads |
Understanding this trade-off is critical. While Team-Managed Projects empower teams to self-serve without opening administrative tickets, they can introduce data fragmentation across large organizations. Company-Managed Projects remain the enterprise standard tested extensively throughout the ACP-120 blueprint.
An enterprise organization requires that all employee accounts authenticating to Jira Cloud must enforce hardware security key two-factor authentication and authenticate through Okta SAML Single Sign-On. At which administrative level must this requirement be configured?
How does the Atlassian Forge application architecture in Jira Cloud fundamentally differ from legacy Atlassian Server and Data Center plugins?
A Jira Administrator has granted a project lead the 'Administer Projects' project permission in a company-managed project. What administrative action is this project administrator PERMITTED to perform without involving a Jira Administrator?