Dominio 2 — Usar las funciones de GitHub Copilot

Peso en el examen: 25-30%

¡Holi de nuevo! 🌸 Este es el dominio más grande de toda la certificación — entre un cuarto y un tercio de las preguntas salen de aquí. Y tiene una ironía que conviene tener presente: es el dominio que más "castiga" a quien usa Copilot a diario sin haber estudiado. ¿Por qué? Porque tú ya sabes usar el chat, las sugerencias inline y el Agent Mode con los ojos cerrados… pero el examen no te pregunta si sabes usarlos, sino los matices de qué función pertenece a qué plan, dónde se configura cada política y qué puede y no puede hacer cada modo. Y eso no se aprende tecleando, se aprende estudiando.

Así que la estrategia aquí es clara: en la parte de "usar Copilot en el IDE" iremos con paso ligero (te sonará todo), y frenaremos con lupa en planes, MCP, Spaces, Cloud Agent y administración, que es donde de verdad se ganan o se pierden puntos. ¡Vamos allá! 💛

La explicación en profundidad

Copilot se integra como extensión en los principales editores: VS Code, Visual Studio, JetBrains, Vim/Neovim, Eclipse y Xcode. Pero más allá de dónde vive, lo importante para el examen es entender las cuatro formas de interactuar con él, ordenadas de menor a mayor autonomía. Piensa en ellas como una escalera: cada peldaño le da a Copilot más libertad para actuar, y tú eliges en qué peldaño te subes según la tarea.

1. Sugerencias inline (inline suggestions). Es la forma más básica y la que probablemente más usas: mientras escribes, Copilot te propone completar la línea o el bloque en texto gris tenue. Aceptas con Tab, rechazas siguiendo a lo tuyo. Funciona como un autocompletado con esteroides. Una variante importante son las next edit suggestions: Copilot no solo sugiere código nuevo, sino que puede proponerte ediciones sobre código que ya existe.

2. Copilot Chat. Un panel conversacional donde le preguntas en lenguaje natural. La diferencia crucial frente a un chatbot genérico es que Copilot Chat adapta sus respuestas al contexto de tus archivos y dependencias — no responde en abstracto, sino sobre tu código. Tiene varias presentaciones: la vista de chat (panel lateral), el inline chat (dentro del propio código, ideal para modificar lo que tienes delante) y el quick chat (para preguntas rápidas).

3. Copilot Edits. Cuando necesitas cambios estructurados que tocan varios archivos a la vez, Edits te deja aplicarlos de forma coordinada, con revisión inline de los diffs (aceptas con Tab, rechazas con Alt+Supr) y con checkpoints para volver a un estado anterior si algo no te gusta.

4. Agent Mode. El peldaño más alto de autonomía. Le das una tarea de alto nivel y él orquesta todos los pasos por su cuenta. Lo desarrollamos en detalle más abajo, porque es de lo más preguntado.

Un detalle técnico que cae: IntelliSense vs Copilot

En Visual Studio, cuando IntelliSense está activo (mostrando la lista de miembros o la información de parámetros), las completions de Copilot se suprimen temporalmente para no abrumarte con dos sugerencias a la vez. En cuanto cierras o confirmas IntelliSense, Copilot vuelve a proponer. Es el comportamiento por defecto y no requiere configurar nada — pero es justo el tipo de detalle "de letra pequeña" que el examen usa para distinguir a quien ha estudiado.

Los modos del chat: Ask, Plan y Agent

Dentro del chat conviven tres modos con niveles de intervención distintos, y confundirlos es una de las trampas más frecuentes:

• Ask: responde y aconseja, pero no modifica tu código a menos que tú apliques manualmente lo que propone.
• Plan: explora el problema y elabora un plan de acción antes de tocar nada, para que lo revises.
• Agent: edita de forma autónoma, ejecutando los pasos necesarios.

🎯 Puntos clave que caen en el examen

• Cuatro formas de interactuar: inline, chat, Edits, Agent (autonomía creciente).
• Next edit suggestions: sugiere ediciones a código existente, no solo código nuevo.
• IntelliSense tiene prioridad sobre las completions inline en Visual Studio (comportamiento por defecto).
• Ask no modifica el código sin que apliques; Agent sí actúa de forma autónoma.

🎯 Lo que cae en los tests reales

• Dónde vive Copilot Chat: GitHub.com, VS Code, Visual Studio, JetBrains, Eclipse, Xcode, GitHub Mobile y Windows Terminal. ⚠️ GitHub Desktop NO (es el distractor de siempre).
• GitHub Enterprise Server (GHES) no está soportado: Copilot necesita el servicio en la nube. Nada de "Copilot on-premises" ni "modelo self-hosted en tu centro de datos".
• Aceptar una sugerencia inline solo la inserta en tu editor: tú decides si la mantienes, la editas o la descartas. No hace commit, no hace push, no mergea y no genera por sí sola una entrada en el audit log.
• Inline vs Chat: inline = completions junto al cursor (aceptas con Tab); Chat = conversación multi-turno donde eliges el contexto (selección, archivos).
• Activar o desactivar las inline suggestions en VS Code (global o por lenguaje): Settings → Extensions → GitHub Copilot (Inline Suggest: Enable / Enable for [Language]).
• Copilot en la CLI ayuda a redactar y explicar comandos de shell y Git con sus flags. No los ejecuta por su cuenta sin tu confirmación.

📝 Mini-repaso

1. ¿Qué diferencia hay entre el modo Ask y el modo Agent?
2. ¿Qué son las "next edit suggestions"?
3. En Visual Studio, ¿qué pasa con las completions de Copilot cuando IntelliSense está activo?

La explicación en profundidad

Las content exclusions permiten a los administradores excluir archivos o repositorios concretos para que Copilot no los use — ni como contexto para sus sugerencias, ni como material a partir del cual generar. Aquí las vemos en su versión "de funciones"; en el Dominio 6 profundizaremos en sus limitaciones (que son una mina de preguntas trampa).

La idea de fondo es proteger contenido sensible: imagina un archivo con lógica propietaria, claves de configuración o algoritmos que no quieres que alimenten las sugerencias de Copilot. Con una exclusión, ese archivo queda "invisible" para Copilot.

🎯 Puntos clave que caen en el examen

• Es una función solo de planes Business y Enterprise. (¡Grábatelo, cae muchísimo!)
• Se configura a nivel de repositorio o de organización, nunca por usuario en el IDE.
• Cuando hay contenido excluido, no hay completions ni chat para esos archivos.
• Agent Mode no puede acceder a archivos excluidos por content exclusion.

⚠️ Trampa típica

• Un usuario de Copilot Pro que quiere configurar content exclusions → imposible: Pro no lo incluye, necesita Business o Enterprise.

La explicación en profundidad

No todo el desarrollo ocurre dentro de un editor gráfico: gran parte de la vida de una desarrolladora transcurre en la terminal. La CLI de Copilot lleva la asistencia de IA justo ahí, ayudándote a generar, explicar y componer comandos de shell, scripts y gestión de archivos usando lenguaje natural.

¿Para qué sirve en concreto? Para cuando no recuerdas la sintaxis exacta de un comando (tar con sus flags, un git rebase complicado, un find con condiciones), para entender qué hace un comando que te han pasado antes de ejecutarlo a ciegas, o para construir un script paso a paso conversando. Trabaja de forma interactiva y en sesiones, manteniendo el contexto de lo que vais haciendo.

🎯 Puntos clave que caen en el examen

• El CLI está disponible en TODOS los planes (Free, Pro, Pro+, Business, Enterprise). Es de las pocas funciones tan transversales.
• Se instala como una extensión del GitHub CLI (gh).
• Funciones clave: sugerir comandos desde lenguaje natural, explicar comandos, y ayudar a componer scripts y gestionar archivos.
• Uso interactivo y en sesiones.

⚠️ Trampa típica

• Marcar el CLI como "solo para planes de pago" → falso, está en todos, incluido Free.

📝 Mini-repaso

1. ¿En qué planes está disponible la CLI de Copilot?
2. Nombra dos cosas que la CLI puede hacer por ti.

La explicación en profundidad: Copilot Edits

Copilot Edits es el paso intermedio entre el chat y la autonomía total. Te permite describir un cambio y aplicarlo coordinadamente sobre varios archivos, revisando cada modificación como un diff antes de aceptarla. La gran ventaja frente a ir archivo por archivo es la coherencia: si renombras un concepto o cambias una firma de función, Edits propaga el cambio por todos los sitios afectados a la vez. Los checkpoints te dejan retroceder si una iteración no te convence, como los puntos de guardado de un videojuego.

La explicación en profundidad: Agent Mode

Agent Mode es la evolución natural de Copilot Edits, y representa un salto cualitativo. La diferencia esencial: mientras el chat en modo Ask te da una respuesta y se detiene, el Agent Mode recibe una tarea de alto nivel y trabaja de forma iterativa hasta completarla, tomando decisiones sobre la marcha. Cuando le asignas algo, el agente sigue este ciclo:

1. Analiza el código base completo para determinar qué archivos y dependencias son relevantes — no se queda con el archivo abierto, entiende la estructura global del proyecto para que los cambios sean coherentes.
2. Sugiere y ejecuta los cambios, alineándolos con la estructura y las convenciones del proyecto.
3. Ejecuta comandos de terminal cuando hace falta: compilar, instalar dependencias, lanzar tests… (siempre pidiéndote confirmación antes).
4. Supervisa y refina su propia salida, iterando varias veces: si un test falla, lo detecta e intenta corregirlo, y vuelve a probar.

Este bucle de auto-refinamiento es lo que convierte al Agent Mode en un colaborador de verdad y no en un simple autocompletado. Puede crear aplicaciones desde cero, refactorizar entre múltiples archivos, escribir y ejecutar tests, y migrar código heredado a frameworks modernos — todo manteniéndote a ti en control total, porque tú apruebas los pasos sensibles.

La explicación en profundidad: MCP (Model Context Protocol)

MCP es uno de los conceptos más "de moda" y más preguntados. Es un protocolo abierto que permite a Copilot (y a otras herramientas de IA) conectarse a herramientas y fuentes de datos externas de forma estandarizada. La analogía oficial de Microsoft es tan buena que conviene aprendérsela literalmente:

MCP define tres formas de conexión según dónde vivan los recursos, y el examen puede preguntarte por ellas:

• Local con datos locales: el servidor MCP corre en tu máquina y accede a archivos o bases de datos locales. Ideal para desarrollo local y datos que quieres mantener privados.
• Servidor local como puente a servicios remotos: el servidor corre en local pero llama a APIs web remotas. Útil cuando quieres una capa intermedia para cachear, validar seguridad o preprocesar.
• Remoto por internet: el servidor MCP vive enteramente en la nube y se conecta a servicios externos. Ideal para SaaS o integraciones de terceros que solo existen online.

El servidor MCP de GitHub en concreto es de código abierto, ofrece más de 30 herramientas (crear issues, gestionar PRs, buscar en el código, automatizar triaje…) y destaca por su comodidad: sin ficheros Docker ni configuración manual, con login OAuth de un solo clic, funcionando en web, escritorio y móvil, con soporte de identidad empresarial (Entra, Auth0) y escalado automático.

🎯 Puntos clave que caen en el examen

• MCP solo funciona en Agent mode. Sus herramientas no se activan solas: los checkboxes vienen desmarcados por defecto y tú decides cuáles habilitar.
• En Business/Enterprise, para usar MCP debe estar habilitada la política "Servidores MCP en Copilot".
• Agent Mode pide confirmación antes de ejecutar comandos de terminal o herramientas no nativas.
• Agent Mode solo toca archivos locales dentro de la solución/directorio abierto y no accede a los excluidos.
• Copilot Edits evolucionó hacia Agent Mode (relación que preguntan).

⚠️ Trampas típicas

• "Agent Mode ejecuta comandos de terminal sin pedir permiso" → falso, pide confirmación.
• "Las herramientas MCP se activan automáticamente al añadir el servidor" → falso, hay que marcarlas.
• "MCP funciona en modo Ask" → falso, requiere Agent mode.

🎯 Lo que cae en los tests reales: ¿Edit o Agent?

• Edit mode → cambios acotados y revisables en los archivos que tú eliges. Ejemplo típico: actualizar un helper en un archivo y añadir un try/catch en otro, revisando un diff pequeño, sin ejecutar tests ni comandos. ✅ Edit.
• Agent mode → tareas multi-paso que cruzan archivos y herramientas: ejecutar tests, arreglar fallos en varios módulos, actualizar configuración y abrir un PR. ✅ Agent.
• Agent es excesivo para cambios mínimos, como renombrar un parámetro y actualizar un docstring en un solo archivo.
• Chat y Agent en la misma tarea: Chat → redactar tests y configuración; Agent → ejecutar comandos, iterar y abrir el PR.
• 🧠 Regla: cambio pequeño con diff revisable → Edit. Varios pasos + comandos + PR → Agent. Solo explicar o preguntar → Ask.

📝 Mini-repaso

1. Describe el bucle iterativo del Agent Mode en tus palabras.
2. ¿Qué es MCP y con qué se compara oficialmente?
3. ¿En qué modo de chat funciona MCP? ¿Se activan sus herramientas solas?

La explicación en profundidad

Hasta ahora hemos hablado de agentes que trabajan contigo en tu editor. El Copilot Cloud Agent (también llamado coding agent) es distinto: trabaja de forma asíncrona en la nube, sin que tú tengas que estar delante. El flujo es precioso en su simplicidad: le asignas un issue de GitHub, él se pone a trabajar en segundo plano en su propio entorno, y cuando termina abre una pull request que tú (o tu equipo) revisáis, comentáis e iteráis.

Esto cambia el paradigma: en vez de "yo programo y Copilot me asiste", pasa a ser "yo delego una tarea acotada y Copilot me trae una propuesta terminada para revisar". Es como sumar un miembro junior al equipo que se encarga de tareas bien definidas mientras tú te centras en lo complejo.

🎯 Puntos clave que caen en el examen

• Requiere Copilot Pro, Pro+, Business o Enterprise — NO está en Free.
• Solo funciona en repositorios hospedados en GitHub (no en hosts de git externos).
• Se le asignan issues; trabaja en sesiones de pull request que puedes seguir e iterar comentando a @copilot.
• Se puede preconfigurar su entorno y ampliar con MCP.
• Tiene protecciones integradas, y conviene validar su salida antes de hacer merge.

⚠️ Trampa típica

• Situar el Cloud Agent en el plan Free → no está; necesita plan de pago (Pro ya vale).
• Pensar que funciona en cualquier host de git → solo repos de GitHub.

🎯 Lo que cae en los tests reales (el agente es de lo más preguntado ⭐)

• Cómo trabaja: arranca un entorno de desarrollo efímero en la nube, con GitHub Actions, explora el repo, hace los cambios en una rama, ejecuta tests y linters, y abre un pull request en borrador para revisión. No edita tu IDE local, no corre en GHES y no mergea solo.
• Personalizar su entorno: fichero .github/workflows/copilot-setup-steps.yml con los pasos de preparación (herramientas, dependencias, paquetes privados). Es lo que hace sus ejecuciones más rápidas y fiables. ⚠️ Distractores: un .copilot-env.json en tu carpeta personal, "copia tu dev container local", scripts en tu home o subir node_modules al repo.
• Permisos: actúa con los mismos permisos que la persona que lo invoca. No gana permisos de admin ni hace force-push.
• Protecciones: sus PRs siguen sujetos a branch protections, revisiones obligatorias, status checks y CODEOWNERS, como cualquier otro PR.
• Firewall del agente: controla a qué dominios y URLs puede acceder, para reducir el riesgo de exfiltración de datos. En entornos regulados se deja activado.
• Control administrativo (Business/Enterprise): las políticas de organización y empresa lo habilitan o deshabilitan por repositorios y usuarios. No lo decide cada dev desde su IDE.
• MCP: le permite usar herramientas y fuentes especializadas (p. ej. GitHub o Playwright MCP). No reentrena los modelos ni desactiva el firewall o las políticas.
• Cuándo SÍ: una feature de un issue bien definido con criterios de aceptación, cambios en varios archivos + tests + PR, actualizar una librería de componentes en todo el repo, añadir paginación, mejorar la cobertura de tests.
• Cuándo NO: incidentes en producción, fugas de PII o de tokens, rotar credenciales en vivo, configurar SSO o audit logs sin supervisión, o diseñar una arquitectura crítica desde cero sin tests ni criterios.
• El buen encargo: "Desde este issue, implementa el endpoint order-cancellation de punta a punta: actualiza la spec de la API, añade handler y routing, escribe tests de integración y abre un PR cuando pasen." ❌ Nada de "arregla todo" o "refactoriza lo que veas".
• Límites seguros: rama de feature, commits pequeños, status checks obligatorios y plan de rollback (revertir el PR). En un monorepo, acota la tarea a rutas o paquetes concretos y pide diffs por paquete.
• Responsabilidades que siguen siendo del equipo: revisar y aprobar el PR, asegurar que pasan tests, linters y security scans, y definir tareas bien acotadas. ❌ Nunca auto-merge a producción.
• Despliegue en la empresa: piloto con un grupo pequeño, firewall activado y monitorización antes de abrirlo a todos.

📝 Mini-repaso

1. ¿Cómo se le asigna trabajo al Cloud Agent y qué entrega?
2. ¿En qué planes está disponible? ¿Funciona en GitLab?

La explicación en profundidad

Imagina que trabajas en un proyecto concreto y quieres que Copilot responda siempre anclado a la documentación, el código y las convenciones de ese proyecto, sin que tengas que recordarle el contexto cada vez. Para eso están los Copilot Spaces: áreas de trabajo reutilizables donde Copilot opera dentro de un ámbito claramente definido que tú configuras. El resultado son respuestas fundamentadas (grounded) y de mucha más calidad, porque el modelo parte de un contexto curado en vez de responder "en abstracto".

Se crean en github.com/copilot/spaces, y a la hora de configurarlos hay dos decisiones y dos tipos de contexto que caen en el examen:

Propiedad: un Space puede ser personal (solo tuyo) o propiedad de una organización (y estos se comparten con el modelo de permisos integrado de GitHub, ideal para equipos).

Contexto, que se compone de dos ingredientes:

• Instrucciones: texto libre donde defines en qué debe centrarse Copilot dentro de ese Space, en qué es experto, qué tipo de tareas debe abordar y qué debe evitar.
• Attachments (datos adjuntos): el material de referencia. Puedes adjuntar archivos y carpetas de repos, vincular issues y pull requests por su URL, subir archivos desde tu máquina (imágenes, documentos, hojas de cálculo) o pegar texto libre (transcripciones, notas). Un detalle importante: Spaces siempre referencia la versión más reciente del código de la rama principal.

Un uso muy destacado es democratizar el conocimiento tribal del equipo: ese saber que suele estar solo en la cabeza de la persona senior pasa a estar disponible para todos a través del Space.

🎯 Puntos clave que caen en el examen

• Disponibles para cualquier usuario con suscripción a Copilot, en GitHub.com.
• Dos tipos de contexto: instrucciones (texto libre) y attachments (archivos, issues, PRs, subidas, texto).
• Pueden ser personales u organizativos (estos usan el modelo de permisos de GitHub).
• Respetan las políticas de content exclusion y code referencing.

📝 Mini-repaso

1. ¿Qué dos tipos de contexto puedes añadir a un Space?
2. ¿Cuándo usarías un Space en lugar del chat general?

La explicación en profundidad

Copilot ha crecido más allá del editor para meterse en el flujo de colaboración de GitHub:

• Copilot code review: acelera los ciclos de revisión de código, detecta problemas y sugiere mejoras aplicando buenas prácticas. Es como tener a alguien dando un primer repaso antes de la revisión humana. En Free solo tienes "Review selection" en VS Code; el resto de planes lo tienen completo.
• Pull request summaries: genera automáticamente un resumen de los cambios de una PR, ahorrando el tedioso trabajo de redactar "qué hace este PR". Disponible en Pro y superiores (no en Free).
• GitHub Spark: permite crear aplicaciones full-stack a partir de lenguaje natural. Está en public preview y solo en Pro+ y Enterprise.
• Instruction files y prompt files: archivos donde defines cómo quieres que Copilot se comporte (convenciones, estilo, idioma de los comentarios) o guardas prompts reutilizables. Sirven para obtener respuestas consistentes sin repetir las mismas indicaciones una y otra vez.

🎯 Puntos clave que caen en el examen

• Code review completo: en todos los planes salvo el limitado de Free.
• PR summaries: Pro y superiores, no Free.
• Spark: solo Pro+ y Enterprise.
• Instruction/prompt files → consistencia y reutilización.

🎯 Lo que cae en los tests reales: Copilot en la revisión de PRs

• PR summaries: ayudan a entender rápido la intención, las zonas de riesgo y el alcance del cambio. No garantizan que no haya errores.
• Review suggestions: son consultivas. No cuentan como aprobación, no sustituyen a los required reviewers ni a CODEOWNERS y no saltan las protecciones, aunque el CI esté en verde.
• Si aplicas una sugerencia de Copilot en la revisión → en la rama del PR, relanzas los checks y pides de nuevo la revisión obligatoria.
• ¿Quieres que expertos revisen siempre ciertas rutas? → fichero CODEOWNERS. (Ni los PR summaries ni el agente "adivinan" revisores.)
• ❌ Copilot code review no auto-mergea, no valida licencias y no es "solo análisis estático".

La explicación en profundidad

Si tuviera que apostar por el tema del que más preguntas verás en el examen, sería este. GitHub tiene cinco planes — Free, Pro, Pro+, Business y Enterprise — y el examen se dedica a comprobar si sabes qué función pertenece a cuál. La dificultad no está en entender los planes, sino en memorizar las fronteras: esos puntos donde una función aparece o desaparece.

Aquí tienes la tabla con las funciones que más se preguntan:

*Ilimitado con los modelos incluidos.

Las tres fronteras que tienes que memorizar sí o sí

En vez de intentar memorizar la tabla entera celda a celda (agotador y propenso a fallos), memoriza estas tres fronteras clave, que es lo que el examen explota:

1. Las funciones "de empresa/administración" empiezan en Business. Content exclusion, gestión de políticas de organización y organization custom instructions son solo Business y Enterprise. Tiene lógica: son cosas que administra una organización, no un individuo.
2. Los audit logs empiezan un escalón antes: en Pro+. Esta es la trampa favorita, porque intuitivamente pensarías que los logs son "cosa de empresa". Pero Pro+ ya los tiene, junto a Business y Enterprise.
3. Spark vive en Pro+ y Enterprise… pero NO en Business. Esta es la frontera más contraintuitiva y la más preguntada. (Actualización de octubre de 2026: la documentación oficial ya incluye los agentes de terceros en Pro, Pro+, Business y Enterprise. Si un material antiguo te dice que son "solo Pro+ y Enterprise", está desactualizado.)

⚠️ Trampa mortal

• El examen mezcla constantemente Business y Enterprise como si fueran idénticos. Pero Spark está en Pro+ y Enterprise, no en Business. Cuando veas un escenario con "Business" y una de las opciones sea Spark, sospecha.

🎯 Lo que cae en los tests reales: los datos de planes que más se repiten

• Planes que existen: Free, Pro, Pro+, Business y Enterprise. ⚠️ Inventados: Copilot Teams, Copilot Premium, Copilot for Azure DevOps. Y "GitHub Team" es un plan de GitHub, no de Copilot. (La documentación de octubre de 2026 ya muestra también Copilot Student y Copilot Max; si no salen en tu examen, no te preocupes por ellos.)
• Pro gratis para estudiantes, profesores verificados y maintainers de proyectos open source populares. Free = para empezar, uso personal y funciones limitadas.
• Copilot Enterprise requiere GitHub Enterprise Cloud (GHEC) y no viene incluido gratis con GHEC: es una suscripción aparte. Matiz: la prueba gratuita de 30 días de GHEC incluye Copilot Business mientras dura.
• Solo Enterprise: Knowledge Bases (documentación curada como contexto del chat), Chat que conoce el repositorio en GitHub.com, soporte de proxy empresarial e integración con compliance avanzado.
• SSO no es "una feature del plan": es una capacidad de la organización en Enterprise Cloud, y Copilot Enterprise usa el SSO de tu org si está configurado. Si la pregunta es "¿qué plan se integra con SSO?" → Enterprise.
• Premium Support con SLAs: es una oferta aparte y de pago que se combina con Copilot Enterprise. "¿Qué plan ofrece SLAs de soporte?" → Enterprise. "¿Vienen incluidos por defecto?" → No.
• 🧠 Respuesta única vs "elige todas": usage reporting, content exclusion, gestión de seats y políticas de organización están en Business y Enterprise. Si es "choose all" → marca las dos. Si es de respuesta única y dice "sin integraciones enterprise" → Business, que es el plan que las introduce.

📝 Mini-repaso

1. ¿En qué planes está content exclusion?
2. ¿Los audit logs están en Pro+? ¿Y en Business?
3. Un equipo con Business quiere usar Spark. ¿Puede?

La explicación en profundidad

La última pieza del dominio es la administración, la parte que gestionan los admins de una organización o empresa. Aunque tú uses Copilot como desarrolladora, el examen espera que entiendas cómo se gobierna a nivel organizativo.

Gestión de políticas. Se hace desde los ajustes de organización/empresa en GitHub.com (nunca desde el IDE, ¡ojo con esta trampa!). Desde ahí, un admin puede habilitar o deshabilitar funciones, activar las políticas de code review de Copilot, controlar la disponibilidad de las características en los distintos IDE y en github.com, y gestionar el allow list de servidores MCP (qué servidores MCP están permitidos; los que no estén en la lista quedan bloqueados). Un principio importante de gobernanza: si la empresa (enterprise) impone una política, la organización y el repositorio no pueden anularla — solo pueden configurar dentro de lo permitido. La jerarquía manda hacia abajo.

Audit logs. Registran los eventos administrativos y de uso: asignaciones de licencias, cambios en la configuración (por ejemplo, cambios en las content exclusions), y actividad de Copilot (quién usó qué y cuándo). Es clave entender que los audit logs registran eventos de administración y configuración, NO el contenido de las sugerencias que Copilot genera.

Gestión de acceso. En Business/Enterprise, se da o se quita acceso a Copilot mediante la asignación de licencias (seats).

REST API de suscripciones. Permite gestionar programáticamente las suscripciones de Copilot de una organización: listar los asientos asignados, añadir o quitar licencias, y obtener métricas de uso (número de sugerencias, actividad del chat…). Pero — y esto es importantísimo y volveremos a ello en el Dominio 6 — la API es de administración y métricas, nunca da acceso al contenido del código que un usuario concreto ha generado (eso sería una violación de privacidad).

🎯 Puntos clave que caen en el examen

• Las políticas se configuran en GitHub.com (organización/empresa), no en el IDE.
• Las políticas de enterprise tienen prioridad; org y repo no pueden anularlas.
• Los audit logs registran administración y uso, no el contenido de las sugerencias.
• El acceso se gestiona por asignación de licencias.
• La REST API gestiona suscripciones y métricas, no contenido de código.

⚠️ Trampas típicas

• Ubicar la gestión de políticas "en el IDE" → es en GitHub.com.
• Confundir deshabilitar Copilot vía Group Policy / ADMX (nivel máquina/cliente, p. ej. en Visual Studio) con la gestión de licencias en GitHub.com (nivel cuenta). Son mecanismos distintos.

🎯 Lo que cae en los tests reales

• Quién compra y asigna los seats: en Business, los org owners; en Enterprise, los enterprise owners. Ni los devs desde el IDE, ni los repo admins.
• Actividad de Copilot en el audit log de la organización ("elige todas" entre Free, Pro, Business y Enterprise) → Business y Enterprise.
• Política impuesta por la empresa (p. ej. "bloquear código público" o limitar los modelos permitidos) → la organización solo puede configurar dentro de lo permitido; ni la org ni el repo la anulan.
• Telemetría y métricas de uso: señales de actividad y uso de funciones (sugerencias, chat, agentes), nunca un volcado de tu código fuente.

📝 Mini-repaso

1. ¿Dónde se configuran las políticas de organización?
2. Si la empresa impone una política, ¿puede la organización anularla?
3. ¿Los audit logs registran el contenido de las sugerencias de Copilot?

• Comparación de planes de Copilot — Microsoft Learn
• Modo agente de GitHub Copilot
• Cloud Agent de GitHub Copilot
• Introducción al servidor MCP
• Introducción a Copilot Spaces
• Página oficial de planes (siempre actualizada)