Manage Projects with GitHub
This domain tests whether you can plan, track, and report on work using GitHub Projects (v2) and the repository-level planning objects that feed it — issues, labels, milestones, assignees — plus the automation (built-in workflows) and reporting (Insights charts) layered on top. At roughly 9% of the exam, expect about 5–8 scored questions out of a typical 60–75-question GH-900 form. Questions are scenario-flavoured but shallow: "which layout," "where is this configured," "which object is repository-scoped," "which feature standardizes a reply." You will not be asked to write GraphQL or design a sprint process. You will be asked to distinguish confusable objects — label vs milestone vs project field, saved reply vs issue template, project Insights vs repository Insights, assignee vs reviewer — and to know which scope (personal account, organization, repository) each object lives in.
GitHub Projects v2: boards, tables, roadmaps, and layout options
GitHub Projects (the "v2" or "new" experience) is an adaptable, flexible spreadsheet-and-task-board tool that lives on top of your issues and pull requests. It is not a separate database: adding an issue to a project creates a project item that references the live issue, so title, state, assignees, labels, and milestone stay in sync with the source repository.
Key structural facts (high-yield):
| Concept | Exam-critical detail |
|---|---|
| Ownership | A project is owned by an organization or a personal (user) account. There is no repository-owned Projects v2. |
| Linking | A project can be linked to one or more repositories; linked repos surface the project on their Projects tab and allow quick add. |
| Projects (classic) | The old repository/organization boards with columns and cards were retired in 2024. "Columns," "cards," and "automation presets" are legacy vocabulary and frequently used as distractors. |
| Item types | Issues, pull requests, and draft issues. |
| Draft issues | Exist only inside the project. They can have a title, body, assignees, and custom field values, but cannot have labels or milestones (those are repository objects) and are invisible to the repo until converted to an issue, which requires choosing a repository. Conversion is one-way. |
| Views | A project holds multiple saved views, shown as tabs. Each view stores its own layout, filter, grouping, sorting, slice, and visible fields. Changes to a view must be saved or they are local to you. |
| Visibility | Projects are private by default; an admin can make a project public (world-readable). |
| Access roles | No access, Read, Write, Admin, assignable to individuals and teams; org owners set a base role for all members. |
| API | Projects v2 is GraphQL-only. There is no REST API for Projects v2 (classic projects had one). Webhook event: projects_v2_item. |
The three layouts
| Layout | What it shows | Column/axis driver | Best for |
|---|---|---|---|
| Table | Spreadsheet grid, one row per item, all fields as columns | N/A — group by any field | Bulk editing, triage, seeing many fields at once, summing/counting numeric fields per group |
| Board | Kanban columns of cards | A single select field (default: Status) or an iteration field | Daily flow, drag-and-drop status changes, WIP visualization |
| Roadmap | Horizontal timeline of bars | Date fields and/or iteration fields; optional markers for milestones/iterations | Release planning, quarterly views, dependencies over time; zoom by month / quarter / year |
Board and Roadmap are not separate projects — they are layout options of a view inside the same project. Switching a view from Table to Board does not copy data; it re-renders the same items.
Fields
Built-in fields are synced from the source issue/PR: Title, Assignees, Status, Labels, Milestone, Repository, Reviewers, Linked pull requests, Parent issue, Sub-issue progress. Note that Status is a project field, not an issue field — an issue's repository state is only open or closed; "In Progress" exists solely in the project.
Custom field types you must recognize:
| Field type | Notes |
|---|---|
| Text | Free text |
| Number | Can be summed in table group headers and charted |
| Date | Drives Roadmap bars and date filters |
| Single select | Options with colors/descriptions; the only field type that can drive board columns besides iteration |
| Iteration | Recurring, time-boxed blocks (sprints). Default length 2 weeks, three iterations created up front; supports breaks; filter with @current, @previous, @next |
Filtering
View filters use the same query grammar as issue search: is:issue, is:pr, is:open, is:closed, label:bug, -label:wontfix, no:assignee, assignee:@me, status:"In Progress", milestone:"v1.0", iteration:@current. Filters are saved per view, so the common design is one project with several views (e.g., Triage, Current sprint board, Roadmap, My items).
One-line caption: how to pick the right layout for a stated requirement.
Common traps
- "Create a project in the repository." Projects v2 cannot be owned by a repository — only linked to one. Answers that say "repository-level project board" are testing the retired classic experience.
- Draft issue = issue. It is not. No labels, no milestone, no repo, not searchable in the repo, invisible to non-project members. Convert it first.
- Board columns from any field. Only single select and iteration fields can be board columns. "Group the board by the Text field Notes" is always wrong.
- Roadmap without dates. Roadmap needs a date or iteration field; a project with no date fields cannot render a meaningful roadmap.
- Separate projects per layout. The exam likes answers such as "create one project for the board and one for the roadmap." The correct answer is one project, multiple views.
- REST for Projects v2. Automation questions that mention REST endpoints for Projects v2 are wrong; it is GraphQL.
- Deleting a project item deletes the issue. It does not. Removing/archiving an item only affects the project; the issue remains in the repository.
Worked scenario. A team of 12 tracks work across four repositories. Leadership wants a quarterly timeline; engineers want a sprint kanban; the triage lead wants to bulk-edit priority on 200 open issues. → Create one organization-owned project, link all four repositories, add a custom Iteration field and Date fields, then build three views: a Roadmap view grouped by quarter for leadership, a Board view with columns from Status filtered iteration:@current for engineers, and a Table view filtered is:open no:assignee for triage. One project, three views — not three projects.
Unlock with a paid plan
6 more sections (about 3,009 words) continue below. Every paid plan unlocks all GH-900 study guides, the full question bank and mock exams, from $4.97/month.