Jira & Atlassian tooling admin: interview prep

A one-page study guide for software-tooling support roles that administer Jira, Confluence, Bitbucket, Jenkins, Bamboo and Artifactory for R&D teams.

1. What the role really is

It's a developer-tools platform admin and support role, not hands-on infrastructure DevOps. You own the tools R&D engineers use every day: keep them running, configure them, handle tickets within SLAs, test upgrades and migrations, and improve how engineers work.

Roles like this often rate candidates higher if they can script (Python/JS) and understand how the applications are built. Frame automation work as "productivity and developer-experience improvements."

2. What to study

3. Confluence

Atlassian's team wiki. Jira tracks the work; Confluence holds the knowledge about the work.

Structure

Site → Spaces (one per team/product, own permissions) → Pages (a tree with parent/child pages and version history) + blog posts.

Permissions: three layers

1. Global: who can use Confluence and create spaces.
2. Space: view, add, edit, delete, administer. Grant to groups.
3. Page restrictions: lock one page for view/edit. A restriction on a parent applies to its children.

Features to know

• Templates and blueprints for meeting notes, decision logs, retros, how-tos.
• Macros: Jira Issues (live JQL list), Page Tree, Excerpt/Include, status labels, code blocks, panels.
• Labels and search to keep knowledge findable; Jira integration (link issues, create issues from text, requirement pages on epics).

What an admin does

Creates spaces and permissions for new teams, manages LDAP/SSO-synced groups, maintains templates, archives stale spaces, manages Marketplace apps (e.g. draw.io), plans upgrades or Cloud migrations on staging first, answers how-to tickets.

Likely questions

• Set up a space for a new R&D team.
• Keep docs from going stale: owners, review dates, archiving, templates.
• Move docs between spaces: move/copy, export/import, fix broken links.
• Confluence is slow: attachment size, heavy macros, logs, database, JVM memory (Data Center).

4. Company-managed vs team-managed projects

Think of an apartment building. Company-managed is a building where management sets the rules for every flat: change the lock design once and every flat gets it. Team-managed is an independent house: the owner decides everything, quickly, but nothing is shared. (Newer Jira screens may call projects "spaces.")

Example: 50 R&D projects must share one Bug process. Company-managed: build one workflow scheme, attach it to all 50, edit once. Team-managed: 50 slightly different workflows, edited 50 times.

"Company-managed projects are configured centrally by admins using shared schemes, so one configuration gives consistency across many projects. Team-managed projects are configured by the team itself and aren't shared. For many R&D teams, company-managed is the right choice, and it's where most admin work happens."

Converting? No direct switch: create a project of the other type and move the issues, then check field and status mapping.

5. Jira permissions

Four layers, like airport checkpoints. A user must pass every one.

1. Product access: do they have a Jira licence? (admin.atlassian.com)
2. Global permissions: site-wide powers: Administer Jira, browse users and groups, share dashboards/filters, bulk change, create team-managed projects. Give sparingly.
3. Project permissions (permission scheme): what they can do inside a project. Most tickets come from here.
4. Issue security: optional lock on individual issues (e.g. security bugs).

Key project permissions

Grant to: project role (best), group, user (avoid), or special entries like Reporter, Current Assignee, Any logged-in user, Public (avoid).

Groups vs project roles

Groups are site-wide and usually synced from AD/SSO. Roles are per project. A scheme says "Developers can edit issues"; each project fills its own Developers role. So one scheme serves hundreds of projects.

Troubleshooting flow

1. Product access (licence).
2. Permission Helper (admin): enter user, project, permission; it explains exactly why.
3. Role and group membership.
4. Issue security level on that issue.
5. Can't move an issue? Check the workflow condition on that transition, not just permissions.

Best practices

• Copy the default scheme before editing; use few, standard schemes.
• Least privilege for Delete Issues and Administer Jira.
• Audit via the audit log; remove inactive users to free licences.

Related settings: notification scheme (who gets emailed on which events), issue security scheme, field configuration (required/hidden fields — often confused with permissions).

6. Hands-on Jira Cloud lab (about 4–5 hours)

Newer Jira Cloud screens call issues "work items."

Step 0 — Set up

Sign up for free Jira Cloud and invite a second user (another email) to test permissions. If admin features are greyed out on Free, start the Standard trial.

Step 1 — Project

Create a Scrum, company-managed project, e.g. "R&D Tools", key RDT.

Step 2 — Use it as a user

Create an Epic, three Stories, two Bugs, a Sub-task. Create and start a sprint. Move cards across the board. Add Components (Firmware, Mobile App) and a Version (v1.0).

Step 3 — Custom fields and screens

Create a select-list field "Affected Environment" (Dev, QA, Prod), add it to the project's screens, confirm it shows on a Bug.

Step 4 — Custom workflow: only QA can close bugs

1. Copy the workflow as "RDT Bug Workflow": Open → In Progress → In Review → QA Testing → Closed, plus Reopen.
2. On Close add a condition (User is in group qa-team), a validator (Resolution required) and a post function (set resolution).
3. Map Bug to it in a workflow scheme, attach to RDT, map old statuses.
4. Test with a user outside and then inside qa-team.

Step 5 — Permissions and roles

Copy the default permission scheme, grant to roles, attach to RDT. Remove Browse Projects from your second user's role, confirm the project disappears, check the Permission Helper, restore.

Step 6 — JQL, filters, dashboards

project = RDT AND issuetype = Bug AND status != Closed
assignee = currentUser() AND sprint in openSprints()
created >= -7d AND priority in (High, Highest)
project = RDT AND updated <= -30d AND statusCategory != Done

Save one as a filter; build a dashboard with Filter results and a pie chart.

Step 7 — Automation

• Highest-priority Bug created → assign and comment.
• All sub-tasks done → transition parent to Done.
• Weekly: issues not updated in 30 days → comment pinging the assignee.

Use each rule's audit log to debug rules that didn't fire.

Step 8 — Python against the REST API

import requests
from requests.auth import HTTPBasicAuth

SITE = "https://your-site.atlassian.net"
auth = HTTPBasicAuth("you@example.com", "YOUR_API_TOKEN")

r = requests.get(
    f"{SITE}/rest/api/3/search/jql",
    params={"jql": "project = RDT AND issuetype = Bug AND statusCategory != Done",
            "fields": "summary,status,assignee"},
    auth=auth,
)
r.raise_for_status()
for issue in r.json()["issues"]:
    f = issue["fields"]
    who = f["assignee"]["displayName"] if f["assignee"] else "Unassigned"
    print(issue["key"], "|", f["status"]["name"], "|", who, "|", f["summary"])

Create the token at id.atlassian.com → Security → API tokens. Check Atlassian's REST docs if an endpoint has changed.

7. Jira Q&A — 20 answers to say out loud

project = RDT AND issuetype = Bug AND priority in (High, Highest)
AND statusCategory != Done AND created >= -7d

Practise 5, 7 and 8 out loud — they come up most.

8. Other question bank

Bitbucket, Jenkins, Bamboo, Artifactory

• Protect main: branch permissions + merge checks (required approvals, passing build).
• Gitflow vs trunk-based development.
• Declarative vs scripted Jenkins pipelines; agents; shared libraries.
• Build fails on one agent only: tool versions, disk space, credentials, network, workspace.
• Safe Jenkins/plugin upgrade: backup, staging, compatibility check, rollback plan.
• Bamboo vs Jenkins: Bamboo integrates natively with Jira/Bitbucket; Jenkins is open source and plugin-heavy.
• Artifactory local / remote / virtual repos; control storage with retention and cleanup policies.
• GitHub Actions → Jenkins mapping: workflow file ≈ Jenkinsfile, runners ≈ agents, secrets ≈ credentials.

Platform and support

• Cloud vs Data Center migration; evaluating a Marketplace app; users at scale via SSO/AD groups.
• Incident vs service request vs problem vs change; SLAs; prioritise by impact × urgency.
• Tool down for 500 engineers, first 30 minutes: acknowledge, communicate, triage, escalate, restore, then root cause.
• Documenting changes: change record, runbook, knowledge article.

Behavioural (prepare STAR stories)

An incident under pressure · automating a repetitive task · a difficult stakeholder · learning a new tool quickly · a deployment that went wrong.

Questions to ask them

Cloud or Data Center, any migration planned? How big is the user base and the tooling team? Mostly tickets or improvement projects?

9. CI/CD project story — checklist

A strong story covers three layers, then rollback and results:

1. PR gate: branch protection, required review approval, merge only when checks pass.
2. CI on every PR: build, unit tests (developers write them, the pipeline enforces them), code-quality scan with a quality gate, image build. Results show on the PR.
3. CD after merge: immutable image tag (version + commit SHA), push to registry, promote the same artifact Dev → QA → Prod with a manual approval before prod. Never rebuild for prod.
4. Rollback: redeploy the previous tag; on Kubernetes, kubectl rollout undo; on Azure App Service, deployment-slot swap.
5. Results: before/after numbers, even rough ones.

Gaps interviewers probe

• Exactly how you deploy to Kubernetes (manifests, Helm, set image) and whether you used readiness probes.
• How the pipeline authenticates to the cloud: OIDC federated credentials > service principal secret > hard-coded (red flag). How the cluster pulls from the registry.
• Security scanning (Trivy, Defender, Dependabot) — or say it was the next step.
• Database changes must be backward-compatible so rollback stays safe.
• Speeding up a slow pipeline: dependency and layer caching, parallel jobs, running only affected tests.

10. 7-day plan

Be honest about which tools you've administered and which you've practised. "I built this hands-on and can explain it in depth" beats a claim that breaks under follow-up questions.