GH-200 - Author and maintain actions (18% of the exam) - Section 3.3

Define the required files, directory structure and action.yml metadata, including inputs, outputs and branding, for a custom action.

Define the required action.yml metadata file, including inputs, outputs, and runs configuration, within the correct directory structure. Add branding fields (icon and colour) for actions published to the GitHub Marketplace.

action.ymlinputs and outputsbrandingruns configuration

Practice question for this objective

Free sampleAuthor and maintain actionsmedium

A team wants their published custom action to display a recognisable icon and colour on its GitHub Marketplace listing. They are editing the branding section of action.yml and need to know which two keys that section accepts and the constraint on their values. Which statement about the branding keys is correct?

  • Abranding accepts icon and color, where icon must be the name of a supported Feather icon and color must be one of the named colours from the allowed palette. Correct
  • Bbranding accepts logo and background, where logo is any uploaded PNG file path and background is a hex colour code applied behind the action's listing card.
  • Cbranding accepts icon and theme, where icon is a Feather icon name and theme selects a light or dark presentation for the action's Marketplace card.
  • Dbranding accepts image and color, where image is a URL pointing to a hosted icon and color is a free-form hex value that styles the listing border.
Recognise that action branding uses icon and color, where icon is a named Feather icon and color is from a fixed named palette. The branding section of action.yml is limited to two keys, icon and color, which style the action's GitHub Marketplace listing. The icon value must be the name of one of the supported Feather icons, and the color value must be one of the named colours from the allowed palette rather than an arbitrary hex code, an uploaded file, a hosted URL, or a light or dark theme.

Why A is correct: The branding block defines exactly icon and color, with icon set to a supported Feather icon name and color restricted to a fixed list of named colours, which matches the documented constraint.

Why B is wrong: Tempting because real listings show an image and a colour, but the keys are icon and color, the icon is a named Feather icon not an uploaded file, and there is no background key.

Why C is wrong: Tempting since icon is genuinely valid, but the second key is color drawn from a fixed palette, not a theme selector, so a light or dark theme value is not recognised.

Why D is wrong: Tempting because color is half right, but the first key is icon naming a built-in icon rather than an image URL, and color must come from a named set rather than an arbitrary hex value.

See more GH-200 practice questions, answers explained.

Exam traps in Author and maintain actions

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-200 bank for this domain.

  • The metadata file must be named action.yaml with the longer extension, because GitHub only auto-discovers the longer spelling at the repository root and ignores a file named action.yml.

    Why it is wrong: Tempting because extension confusion is common, but GitHub recognises both action.yml and action.yaml, so the shorter spelling at the root is valid and is not the cause of the failure.

  • The repository contains a Dockerfile, because the GitHub Marketplace accepts only Docker container actions for publication and rejects JavaScript actions that declare using: node20 in their metadata file.

    Why it is wrong: Tempting because container packaging feels official, but the Marketplace publishes JavaScript, composite, and Docker actions alike, so a node20 action is fully eligible rather than rejected.

  • Inside the dist directory as dist/action.yml, beside the compiled entry point, because the metadata must sit next to the JavaScript file that the runs block names as main.

    Why it is wrong: Co-locating metadata with the entry point feels tidy, but the runner reads action.yml from the reference path root, not from wherever main points, so a root reference would not find it here.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.