GH-200 GitHub Actions: guida alla certificazione

GH-200 è l’esame che certifica GitHub Actions. Non “conoscere il CI/CD” in astratto: saper scrivere, mantenere, diagnosticare e governare l’automazione di GitHub, anche quando i repository non sono tre ma trecento. È di livello Intermediate e si rivolge a chi automatizza per mestiere — DevOps engineer, sviluppatori, IT professional.

Prima trappola, e la si paga subito: la certificazione non vive su github.com. Pagina d’esame, study guide ufficiale, sandbox e prenotazione stanno su Microsoft Learn. Se cerchi “GitHub certification” partendo dal sito di GitHub arrivi a una pagina che elenca le cinque certificazioni ma non ti dà nessuno dei numeri che ti servono.

Cosa valida GH-200

L’audience profile ufficiale chiede competenza nell’automatizzare i flussi di sviluppo software con GitHub Actions: creare e mantenere workflow e action, gestire Actions su scala, e garantire un’automazione sicura ed efficiente per organizzazioni ed enterprise. Dà inoltre per scontata la familiarità con CI/CD, con i repository GitHub, con GitHub Packages e con l’integrazione di servizi di terze parti.

La forma dell’esame si legge nei pesi. I due domini più pesanti — scrivere workflow e gestire Actions per l’enterprise, 20-25% ciascuno — valgono insieme circa metà della prova. Tradotto: chi sa scrivere un file YAML che funziona sul proprio repo ha in mano metà del primo dominio e quasi niente del quarto. Le domande sulla governance (chi può usare quali action, dove girano i job, dove vive un segreto) sono tante quante quelle sulla sintassi.

I numeri ufficiali, e quelli che non esistono

Tre note che valgono più della tabella.

Il tempo d’esame non è il tempo in sala. I 100 minuti sono quelli utili per rispondere; istruzioni, accettazione dell’accordo e commenti finali stanno fuori. Se l’esame non è disponibile nella tua lingua preferita puoi richiedere 30 minuti aggiuntivi.

Durante gli esami GitHub non puoi consultare Microsoft Learn. È una differenza esplicita rispetto agli esami role-based associate ed expert di Microsoft, dove la consultazione è concessa: sugli esami GitHub, come sui fundamentals, no.

Il prezzo non è sulla pagina. La scheda ufficiale dice soltanto che l’importo dipende dal paese o dalla regione di erogazione: la cifra che fa fede è quella che vedi al momento della prenotazione su Pearson VUE. Circola un valore di riferimento intorno ai 99 USD, ma non lo pubblichiamo né sulla scheda GH-200 né qui: non è sostenuto da nessuna pagina ufficiale leggibile, e un ordine di grandezza spacciato per listino è il tipo di dato che poi qualcuno usa per fare un preventivo.

C’è poi una discrepanza fra pagine ufficiali che preferiamo dichiarare invece di risolvere a nostro gusto: la study guide di GH-200 rimanda alla pagina di rinnovo Microsoft, dove si legge che le certificazioni associate, expert e specialty scadono ogni anno e si rinnovano gratis con un assessment online, mentre le fundamentals non scadono. GH-200 però è classificata Intermediate, che non è nessuno di quei tre livelli, e la FAQ sul rinnovo non nomina mai le certificazioni GitHub. Finché le due pagine non si allineano, l’unica risposta onesta è: la data di scadenza effettiva la vedi nel tuo profilo Microsoft Learn.

A chi si rivolge

Il candidato tipico ha già costruito pipeline e si è già scontrato con i problemi che l’esame racconta: un workflow che non parte, una matrix che esplode in venti job, un segreto che serve in tre repository, un’action di terze parti che nessuno ha mai revisionato. Non ci sono prerequisiti formali e non serve GH-900 prima, ma GH-200 non è un esame introduttivo: presuppone che tu abbia letto log di run fallite e scritto almeno un’action tua.

Se vieni dal mondo DevOps su altre piattaforme, la parte di sintassi si assorbe in fretta; quella che costa è il dominio enterprise, perché richiede di aver visto — o almeno di aver studiato bene — come si configurano runner group, policy d’uso delle action e scoping dei segreti in un’organizzazione vera.

I concetti trasversali

Alcune distinzioni tornano in più domini, e l’esame le mette a confronto direttamente:

• I tre meccanismi di riuso non sono intercambiabili. Uno starter workflow è uno scaffold che viene copiato e poi vive di vita propria; un reusable workflow è una definizione centrale e versionata invocata con workflow_call; una composite action incapsula una sequenza di step. Sapere quale scegliere è una domanda ricorrente.
• Immutable actions e pinning. L’immutabilità si aggancia al tag legato a una release, non ai tag del repository in generale: è per questo che un tag major mobile come v2 non deve portare una release agganciata. Sul fronte consumo, la raccomandazione è agganciarsi allo SHA completo di un commit, non a @main o a un tag mobile.
• Identità effimere invece di segreti eterni. GITHUB_TOKEN ha un ciclo di vita effimero e permessi granulari, e va contrapposto a un PAT; il token OIDC con il permesso id-token serve a federare verso un cloud provider eliminando i segreti di lunga durata.
• Dove vive un segreto. Organizzazione, repository, environment: tre livelli di scoping diversi, con effetti diversi su chi può leggerli e su quali job.
• Dove gira il job. Runner ospitati e self-hosted, runner group, allow list di IP, software preinstallato nelle immagini e cambi d’immagine (la deprecazione di Ubuntu 20.04, il passaggio di windows-latest a Windows Server 2025) sono materia d’esame esplicita.
• Contesti ed espressioni. I contesti predefiniti (github, runner, env, vars, secrets, inputs, matrix, needs, steps) e la differenza fra valutazione statica, al parse del workflow, e valutazione a runtime, con l’obbligo di non far finire un segreto nei log.

I cinque domini d’esame

Scrivere e gestire workflow — 20-25%

Trigger ed eventi (schedulati, manuali, webhook, eventi di repository), input di workflow_dispatch e passaggio di input e secret a un reusable workflow; struttura di job e step, dipendenze, comandi di workflow, service container con porte e health check, strategy e matrix con include/exclude, fail-fast e max-parallel; ancore e alias YAML (&, *, la chiave di merge); cache e artifact con le retention policy applicate via REST API; passaggio di dati fra job e step tramite GITHUB_ENV e GITHUB_OUTPUT, e job summary con GITHUB_STEP_SUMMARY.

Consumare e diagnosticare workflow — 15-20%

Leggere la run di qualcun altro: capire da configurazione e log perché un workflow è partito o non è partito, diagnosticare i fallimenti, espandere ancore e alias quando analizzi un file che non hai scritto tu, interpretare l’espansione di una matrix e rilanciare il singolo job fallito. Più la parte su template: starter workflow pubblici e non pubblici, reusable workflow, e la differenza fra disabilitare ed eliminare un workflow.

Creare e mantenere action — 15-20%

I tre tipi di action (JavaScript, Docker, composite), il file di metadata e la struttura di directory obbligatoria, i comandi di workflow dentro un’action, il troubleshooting dell’esecuzione; poi distribuzione (pubblica, privata, Marketplace), pubblicazione sul Marketplace e strategie di versioning e release, con le implicazioni delle immutable actions.

Gestire GitHub Actions per l’enterprise — 20-25%

Distribuire e governare componenti riusabili, controllare l’accesso ad action e workflow nell’organizzazione, configurare le policy d’uso; gestire runner ospitati e self-hosted, runner group, allow list di IP e impostazioni di rete, identificare il software preinstallato e installarne altro a runtime; definire e scopare segreti e variabili a livello di organizzazione, repository ed environment, anche via REST API.

Mettere in sicurezza e ottimizzare — 10-15%

Il dominio più piccolo e più denso: environment protection e approvazioni, riconoscere action affidabili, mitigare la script injection (input validati, permessi minimi, niente dati non fidati dentro run:), permessi granulari del token, OIDC, pinning allo SHA, allow/deny list a livello di organizzazione, generazione e verifica delle attestazioni di provenance; e la parte costo: cache, retention degli artifact, strategie di scalabilità.

Come prepararsi

1. Parti dalla study guide, non da un corso. La versione degli obiettivi è quella di gennaio 2026 e il change log dichiara che l’esame è cambiato in modo sostanziale: materiale più vecchio ti prepara a una prova che non esiste più. Immutable actions, attestazioni di provenance, OIDC e gestione dei runner su scala sono entrati con quel refresh.
2. Costruisci, non leggere. Scrivi un workflow con una matrix e un service container, spezzalo di proposito, leggi il log. Poi scrivi una composite action e versionala. La gran parte delle domande parte da un frammento YAML e chiede perché non fa quello che sembra fare.
3. Studia il dominio enterprise anche se non amministri un’organizzazione. Vale quanto il dominio dei workflow, ed è quello dove chi ha solo esperienza personale perde punti in blocco.
4. Chiudi con le simulazioni. Il percorso di preparazione GH-200 su CertUp segue i cinque domini con la stessa distribuzione dei pesi; la simulazione GH-200 attinge a un banco di 80 domande e propone sessioni da 50 domande in 100 minuti con soglia 700 su 1000. Durata e soglia sono i valori ufficiali; le 50 domande sono una nostra convenzione, dato che il numero reale non è pubblicato. Le domande sono in inglese, come all’esame, mentre spiegazioni e interfaccia sono in italiano. E una precisazione che ci teniamo a fare: riproduciamo scelta singola, scelta multipla e matrici sì/no, non i formati interattivi che puoi provare nel sandbox ufficiale linkato dalla pagina d’esame.

In sintesi

GH-200 certifica che sai automatizzare con GitHub Actions in un contesto reale: workflow che reggono, action tue mantenute nel tempo, governance dell’automazione su decine di repository e una catena di fornitura che non si fida dell’ultima action trovata sul Marketplace. I numeri da ricordare sono pochi e verificati: 100 minuti, soglia 700, cinque lingue senza l’italiano, cinque domini con due pesi dominanti. Il resto — prezzo, scadenza, numero di domande — è quello che le fonti ufficiali non pubblicano o pubblicano in modo non allineato, e su cui ti conviene fidarti solo di ciò che vedi al checkout e nel tuo profilo Learn.