GitHub Administration (GH-100) è la certificazione per chi amministra GitHub Enterprise: non chi scrive il codice o i workflow, ma chi decide chi entra, che cosa può fare, che cosa è lecito eseguire e quanto tutto questo sta costando. È la più recente delle cinque certificazioni GitHub, e la sua lista di obiettivi è stata riscritta a luglio 2026 — un dettaglio che qui conta più del solito, perché buona parte del materiale di preparazione in circolazione descrive ancora la versione precedente dell’esame.
Cosa valida GH-100
Il profilo di candidato pubblicato sulla pagina ufficiale parla di esperienza nell’amministrare ambienti GitHub Enterprise: gestione delle identità e degli accessi, GitHub Actions, governance a livello di enterprise e amministrazione delle funzionalità che sostengono uno sviluppo software sicuro. Chi ricopre questo ruolo segue sia GitHub Enterprise Cloud sia GitHub Enterprise Server e collabora con i team di sviluppo, sicurezza e operations. Il livello dichiarato da Microsoft è Intermediate.
C’è una nota di paternità che spiega diverse stranezze: l’esame è erogato da Microsoft, ma l’esame e la certificazione sono mantenuti da GitHub. Lo scrive la pagina della certificazione, e ha conseguenze pratiche — la principale riguarda il rinnovo, di cui parliamo più avanti.
I numeri pubblicati, e quelli che non ci sono
- Durata: 100 minuti. È il tempo che la pagina ufficiale indica per completare l’esame.
- Soglia: 700. La study guide è esplicita: serve un punteggio di 700 o superiore, su una scala che arriva a 1000.
- Lingua: solo inglese. La pagina elenca l’inglese come unica lingua in cui l’esame è offerto. Non esiste una versione italiana, e non esiste nemmeno documentazione GitHub ufficiale in italiano su cui studiare. Se un esame non è disponibile nella lingua che preferisci puoi chiedere 30 minuti aggiuntivi.
- Erogazione: esame con proctoring, prenotabile tramite Pearson VUE. La documentazione GitHub avverte che si prenota al massimo 90 giorni in anticipo e che il documento d’identità deve corrispondere esattamente al nome usato in registrazione.
- Numero di domande: non pubblicato. Non lo dichiara la pagina della certificazione, non lo dichiara la study guide. Diffida di qualunque fonte non ufficiale che te lo dia con precisione.
- Prezzo: non pubblicato sulla pagina d’esame. Microsoft Learn scrive soltanto che il prezzo dipende dal paese in cui l’esame viene erogato, e la pagina di registrazione di GitHub è un’applicazione JavaScript che non espone il listino a una lettura diretta. Nemmeno noi pubblichiamo una cifra, per lo stesso motivo: la sola che faccia fede è quella mostrata al checkout Pearson VUE per il tuo paese.
Un’ultima avvertenza prima di studiare: la pagina ufficiale dice che l’esame può contenere componenti interattive, quindi non dare per scontato che sia tutto a risposta multipla. GitHub mette a disposizione un exam sandbox proprio per prendere confidenza con l’interfaccia e con i tipi di domanda prima del giorno dell’esame.
Il problema dei nomi: due fonti ufficiali, due verità
Su questa certificazione capita di trovare pagine ufficiali che si contraddicono. Meglio saperlo prima che durante.
Il caso più evidente è la sicurezza del codice. La study guide di GH-100 descrive il dominio più pesante parlando di GitHub Advanced Security. La documentazione di prodotto, però, ha già separato l’offerta in due prodotti acquistabili: GitHub Secret Protection (secret scanning e push protection) e GitHub Code Security (code scanning, funzionalità Dependabot premium, dependency review); “GitHub Advanced Security” sopravvive come licenza che include entrambi. In sede d’esame conviene conoscere tutte e due le grafie e sapere quale funzionalità sta sotto quale nome, invece di scommettere su una sola terminologia.
Il secondo caso riguarda la scadenza. La study guide di GH-100 ospita, nella tabella dei link utili, la frase standard del catalogo Microsoft: le certificazioni associate, expert e specialty scadono ogni anno e si rinnovano gratuitamente con un assessment online. Ma la stessa pagina della certificazione dice che la credenziale è mantenuta da GitHub, e la documentazione GitHub sulle certificazioni non pubblica né una durata di validità né una procedura di rinnovo. Non abbiamo trovato una fonte ufficiale che chiuda la questione per GH-100: prima di pianificare un rinnovo, verifica lo stato della tua credenziale nel tuo profilo invece di applicare una regola generale.
A chi si rivolge
Il destinatario naturale è chi amministra già un enterprise GitHub, o sta per ereditarne uno: sistemisti, platform engineer, DevOps, application administrator, chi in azienda tiene le chiavi dell’organizzazione. È anche una certificazione utile a chi deve rispondere a un auditor, perché buona parte dell’esame è in sostanza una domanda sola ripetuta: dove sta scritta questa regola, e dove si vede chi l’ha violata?
Non ci sono prerequisiti formali, ma il livello è intermedio e si sente. Se GitHub per te è “il posto dove faccio push”, la scheda della certificazione GitHub Administration è il punto da cui partire per capire quanta strada c’è. Il salto vero non è tecnico, è di scala: le domande non chiedono come si configura un repository, chiedono come si impone una regola a duecento repository senza bloccare il lavoro di nessuno.
I concetti trasversali
Alcune distinzioni tornano in tutti e cinque i domini.
Dove vive l’enterprise. La study guide chiede esplicitamente di saper descrivere i quattro scenari di deployment. Sono modelli diversi soprattutto per una ragione: chi possiede le identità.
| Scenario | Chi possiede gli account | Cosa cambia per l’amministratore |
|---|---|---|
| GHEC con account personali | L’utente, con il suo account github.com | Le identità si collegano con SAML SSO; le persone restano parte della community pubblica di GitHub |
| GHEC con Enterprise Managed Users (EMU) | L’azienda, tramite l’identity provider | Gli account nascono e si disattivano nell’IdP via SCIM e sono isolati dal resto di GitHub.com |
| GHEC con data residency su GHE.com, con EMU | L’azienda, tramite l’identity provider | Sottodominio dedicato di GHE.com e dati in una regione scelta; la documentazione conferma che gli enterprise su GHE.com usano account gestiti |
| GitHub Enterprise Server (GHES) | L’azienda, sulla propria istanza | L’istanza è tua: aggiornamenti, backup, diagnostica e support bundle |
Tre meccanismi di identità che non sono intercambiabili. Il SAML SSO autentica; il provisioning SCIM gestisce il ciclo di vita degli account, cioè creazione, aggiornamento e disattivazione; la team synchronization allinea l’appartenenza ai team a un gruppo dell’identity provider e non è un servizio di provisioning. Confonderli è l’errore classico, ed è esattamente il tipo di distinzione su cui l’esame costruisce le risposte sbagliate credibili.
Dove si mette la regola. Policy di enterprise, impostazioni di organizzazione e ruleset di repository agiscono a livelli diversi e con precedenze diverse. Molte domande si riducono a: qual è il livello più alto a cui posso imporre questo vincolo?
Actions è un problema di governo, non di sintassi YAML. Non ti viene chiesto di scrivere un workflow, ma di decidere quali action sono consentite, dove girano — runner group, runner self-hosted, IP allow list, rete privata Azure — e con quali segreti.
Accesso programmatico. Personal access token, GitHub App e OAuth App non sono la stessa cosa: cambiano il modello dei permessi, i rate limit e il modo in cui un’organizzazione può approvarne o negarne l’uso.
I cinque domini d’esame, con i pesi ufficiali
1. Manage GitHub identities and access (15-20%)
Differenze fra managed user e account personali, configurazione ed enforcement di SAML SSO e 2FA, SCIM e team synchronization, scelta dell’identity provider, modello di autenticazione e autorizzazione di GitHub. Nella seconda metà del dominio: ruoli di organizzazione e di repository, enterprise team, audit di accessi e permessi, gestione di impostazioni, policy, ruleset e ruoli.
2. Administer GitHub Enterprise environment (10-15%)
Il dominio più di mestiere: distinguere i problemi che risolve l’amministratore da quelli che vanno al supporto GitHub, generare support bundle e diagnostica, raccomandare standard per i processi di sviluppo — workflow, branching, review, release. E poi deployment e licenze: i quattro scenari della tabella qui sopra, i modelli di licensing e fatturazione, il monitoraggio del consumo di licenze.
3. Implement secure software development and compliance (25-30%)
Il dominio più pesante. Policy di organizzazione e di enterprise, postura di sicurezza e protezione dei dati, audit logging e reportistica; poi le funzionalità di sicurezza del repository — alert di vulnerabilità, secret scanning, CodeQL, Dependabot e security advisory — e la definizione di un piano di risposta. Chiude la parte su API e integrazioni: personal access token, rate limit di PAT e GitHub App, differenza fra GitHub App e OAuth App, approvazione o rifiuto delle app in base alle policy.
4. Manage GitHub Actions (20-25%)
Configurare e gestire il riuso di action e workflow a livello di enterprise, applicare le policy organizzative su Actions; amministrare i runner, cioè runner group, GitHub-hosted contro self-hosted, IP allow list e rete (incluso il private networking su Azure), monitoraggio e troubleshooting delle prestazioni; gestire i segreti cifrati definendone ambito e accesso a livello di organizzazione e di repository, inclusa l’integrazione con vault di terze parti.
5. Monitor and optimize GitHub usage (10-15%)
Analizzare audit log e uso delle API, distinguere le responsabilità dell’amministratore da quelle del supporto, valutare i pattern d’uso dell’enterprise per individuare adozione, attività e funzionalità sottoutilizzate. Poi l’ottimizzazione: interpretare i report di consumo dei prodotti a consumo e proporre strategie di ottimizzazione di licenze e risorse.
Come prepararsi
- Parti dalla study guide di luglio 2026, non dai riassunti. Il change log ufficiale dichiara che l’esame è cambiato in modo significativo in quella data: obiettivi aggiunti, rimossi, spostati fra i gruppi funzionali e tutti riformulati. Qualunque materiale più vecchio descrive un esame diverso.
- Studia l’enterprise, non il repository. Se hai accesso a un enterprise di prova, passa il tempo nelle impostazioni di enterprise e organizzazione, nell’audit log e nei report di consumo, non nel codice.
- Allena le distinzioni che si somigliano. SCIM contro team synchronization; GitHub App contro OAuth App; runner GitHub-hosted contro self-hosted; policy di enterprise contro impostazioni di organizzazione contro ruleset; Secret Protection contro Code Security. L’esame vive lì.
- Alterna teoria e domande a scenario. Il percorso di preparazione GH-100 è organizzato sui cinque domini, con le unità distribuite in proporzione al peso di ciascuno. Quando vuoi misurarti, la simulazione GH-100 propone 50 domande in 100 minuti pescate da un banco di 80, con soglia 700 su 1000: il tempo e la soglia coincidono con quelli ufficiali, mentre il numero di domande è una nostra scelta, perché quello vero non è pubblicato. Le domande sono in inglese come all’esame, le spiegazioni in italiano. Quello che non riproduciamo sono le componenti interattive citate dalla pagina ufficiale: i nostri tipi di domanda sono a risposta singola, a risposta multipla e a matrice sì/no. Per quelle, usa l’exam sandbox di GitHub.
Un amministratore che gestisce già un enterprise arriva pronto con qualche settimana di studio mirato sui domini di sicurezza e Actions. Chi invece conosce GitHub solo dal lato sviluppatore deve mettere in conto molto più tempo sulla parte di governance, licensing e audit.
In sintesi
GH-100 certifica che sai governare GitHub Enterprise: far entrare le persone giuste con le identità giuste, imporre policy che reggono su tutta l’organizzazione, tenere sotto controllo che cosa gira nelle pipeline e leggere le evidenze di come la piattaforma viene usata davvero. I due domini su sicurezza e Actions valgono da soli quasi metà dell’esame, e la lista degli obiettivi è nuova di luglio 2026. I due dati da riverificare sempre alla fonte prima di prenotare sono il prezzo per il tuo paese e le condizioni di validità della credenziale: su entrambi la documentazione ufficiale, oggi, non dà una risposta unica.