GH-300 · Tips y Trampas

Guía de estudio para la certificación GH-300: GitHub Copilot, organizada por los 6 dominios oficiales del examen. No es un banco de preguntas: es el destilado de conceptos explicados, hechos clave que caen seguro, trampas típicas y trucos para memorizar, contrastado con la documentación oficial de GitHub y Microsoft Learn.

Leyenda: 🧠 truco de memoria · ⚠️ trampa típica · 📌 dato que cae seguro · 💡 ejemplo · ✅ correcto · ❌ incorrecto · 📝 mini-preguntas de repaso

Este dominio va de los 6 principios de IA responsable de Microsoft. El examen casi nunca te pide la definición "de libro": te da un escenario y tienes que identificar qué principio aplica. Por eso lo importante no es memorizar la frase, sino reconocer la palabra clave que dispara cada principio.

Los 6 principios (la tabla que hay que dominar)

• 📌 "Maximizing Profit" NO es un principio de IA responsable. Es la trampa clásica de la pregunta "cuál NO es un principio".
• 🧠 Regla de las palabras clave (las dos parejas que más se confunden):
  • Fairness vs Inclusiveness → Fairness es mismo trato (igualdad, sin sesgo). Inclusiveness es llegar a todos (accesibilidad, empoderar a personas con distintas capacidades/culturas/idiomas). Truco: si dice "equally / without bias / discrimination" → Fairness; si dice "accessible / everyone can use it / disabilities" → Inclusiveness.
  • Transparency vs Accountability → Transparency es "lo entiendo" (explicable). Accountability es "alguien responde" (supervisión humana, governance). Truco: verbo entender/explicar → Transparency; verbo responsabilizarse/supervisar/rendir cuentas → Accountability.

¿Qué es bias (sesgo) en IA? — el concepto estrella del dominio

Bias = cuando un sistema de IA produce resultados sistemáticamente injustos o desviados hacia (o en contra de) ciertas personas o grupos. Lo importante: no es un error aleatorio, es una inclinación que se repite siempre en la misma dirección.

• ¿De dónde sale el sesgo? Casi siempre de los datos de entrenamiento. El modelo aprende de ejemplos; si esos ejemplos vienen desequilibrados o cargados de prejuicios históricos, el modelo los hereda e incluso los amplifica.
  • 💡 Un modelo entrenado sobre todo con código/comentarios en inglés sugiere peor en otros idiomas.
  • 💡 Datos históricos de contratación con sesgo humano → la IA reproduce ese sesgo como si fuera "lo normal".
• Combatir el bias = trabajar la Fairness. Y no se hace con una sola medida, sino con una combinación: datos diversos y representativos + métricas de equidad (fairness metrics, para medir el sesgo objetivamente) + supervisión humana (human oversight).
• ⚠️ Las 3 trampas recurrentes que salen como "solución falsa" a fairness (memorízalas, aparecen en varias preguntas):
  1. "Collect massive / large amounts of data" → más datos ≠ datos sin sesgo. Si recoges toneladas de datos sesgados, tienes toneladas de sesgo. Cantidad no es representatividad.
  2. "Focus on accuracy" → precisión ≠ equidad. Un modelo puede ser muy "preciso" reproduciendo fielmente un sesgo histórico.
  3. "Regularly monitor performance" → monitorizar ayuda a detectar problemas, pero por sí solo no garantiza que los resultados sean justos.

Los riesgos reales de la IA (los que reconoce el examen)

• Sesgos que se perpetúan o amplifican.
• Falta de interpretabilidad ("caja negra" / black box): decisiones difíciles de explicar → es justo lo que mitiga Transparency.
• Privacidad y seguridad de los datos.
• 🧠 Un "riesgo" real se redacta con matiz prudente (can sometimes, may, difficult to interpret). Desconfía de opciones optimistas y absolutas (eliminates the need for regulations, incapable of perpetuating bias, replaces developers) → esas son las incorrectas.

¿Por qué una IA generativa da salidas inexactas (alucina)?

• ✅ Porque los datos de entrenamiento pueden contener sesgos o inconsistencias.
• ❌ NO por "downtime / servicio caído" (si está caído, no responde) ni por "sobrecarga de peticiones" (eso afecta a la velocidad, no a la veracidad) ni por "estar programada para priorizar creatividad".
• 💡 Matiz técnico (por si te lo redactan bien): las alucinaciones también vienen de la naturaleza probabilística del modelo (predice el siguiente token, no "sabe" la verdad). Pero si esa opción no está, la respuesta del examen es los datos.

Escenarios de IA responsable — el patrón de la respuesta correcta

El examen mete escenarios largos. La correcta casi siempre combina principios + acciones concretas, y descarta las que se apoyan en un solo principio "a medias" o en no hacer nada:

• Fairness + Inclusiveness → "Copilot funciona peor con comentarios no ingleses" + "el auto-asignador sobrecarga a unos devs": ampliar datos no ingleses, testear entre idiomas y ajustar la lógica de reparto.
• Accountability + Privacy & Security → ante una fuga de datos personales: retirar los identificadores, reportar el incidente, documentar los cambios técnicos/de proceso y actualizar políticas (exigir consentimiento), manteniendo un registro auditable.
• Privacy & Security tiene prioridad cuando "mejorar la fairness" exigiría exceder el consentimiento del usuario (p. ej. meter atributos sensibles en el training). Solución: métodos sintéticos o que preserven la privacidad.
• Reliability & Safety + Inclusiveness + Accountability → política de equipo: todo el código de Copilot pasa revisión de secure coding y tests antes del merge (Reliability & Safety), se arreglan los problemas de accesibilidad del UI generado (Inclusiveness) y se documenta que se ha hecho (Accountability).
• Transparency bien entendida → publicar cómo funciona el sistema, su uso previsto, sus limitaciones conocidas y, a alto nivel, las fuentes de datos y los métodos de validación, protegiendo lo sensible o propietario. ❌ No es publicar todo el código y los datasets completos, ni datos personales de los usuarios, ni previsiones de ingresos y costes.

Los casos de Reliability & Safety que despistan ⚠️

En los tests reales hay varias preguntas que suenan a otro principio pero son Reliability & Safety:

• Establecer procesos para identificar, evaluar y mitigar riesgos antes del despliegue → Reliability & Safety (no Accountability).
• Probar exactitud, seguridad y fiabilidad antes de un lanzamiento amplio → Reliability & Safety.
• La IA genera contenido ofensivo o inseguro durante las pruebas → Reliability & Safety.
• Copilot sugiere a veces patrones de código obsoletos o inseguros → Reliability & Safety.
• 🧠 Truco: si el enunciado va de que el sistema se comporte como debe y no haga daño (probar, evaluar riesgos, salidas inseguras) → Reliability & Safety. Si va de quién responde → Accountability.

Uso responsable en el día a día (escenarios que caen)

• Copilot sugiere loguear tokens JWT completos para depurar → rechazar o modificar la sugerencia: nada de secretos en logs, usar logging enmascarado o estructurado. ❌ Ni aceptarla "porque es temporal", ni apagar todo el logging.
• Copilot propone algo muy parecido a un proyecto open source con su cabecera de licencia → revisar la licencia y atribuir correctamente o sustituirlo por una implementación propia. ❌ Ni quitar la cabecera, ni asumir que Copilot ya lo ha resuelto, ni rechazar todo lo que mencione una licencia.
• Textos de UI y mensajes de error generados por Copilot → revisarlos para quitar lenguaje sesgado o excluyente. Si preocupa el sesgo en comentarios o docs: revisar y ajustar las guías del equipo y los prompts.
• Miedo a la dependencia excesiva (over-reliance) → guías de equipo: las sugerencias se revisan, se testean y nunca se tratan como autoridad. ❌ Ni prohibir Copilot, ni auto-merge cuando pasan los tests.
• Explicar Copilot a perfiles no técnicos → "acelera el desarrollo, pero no garantiza corrección ni seguridad; el equipo sigue siendo responsable de testear y cumplir".
• Evaluar Copilot en la organización → medir dónde ahorra tiempo y, a la vez, vigilar tasa de bugs, hallazgos de seguridad y feedback del equipo. ❌ No: las líneas de código generadas ni el número de seats como prueba de productividad.
• Despliegue (rollout) responsable → piloto con un grupo pequeño, guías de uso aceptable y de revisión, configurar content exclusion y code referencing, y ampliar según feedback y métricas. Para el coding agent, igual: piloto, firewall activado y monitorización antes de abrirlo a todos.

📝 Mini-preguntas de repaso (Dominio 1)

1. ¿Qué principio busca que la IA trate a todas las personas por igual? → Fairness.
2. ¿Cuál NO es un principio de Microsoft: Fairness, Transparency, Maximizing Profit, Accountability? → Maximizing Profit.
3. Un sistema recomienda pero no hay forma de entender su razonamiento. ¿Qué principio se viola? → Transparency.
4. ¿Cómo se integra la equidad en una IA? → Reduciendo el bias en datos y algoritmos (no "más datos", no "accuracy", no "monitorizar").
5. Principio que exige que personas sean responsables del despliegue y su impacto → Accountability.
6. Principio que evita excluir a personas con discapacidad → Inclusiveness.
7. Principio que exige evaluar y mitigar riesgos antes de desplegar → Reliability & Safety.
8. Mejor forma de medir si Copilot funciona en tu organización → Tiempo ahorrado + bugs, hallazgos de seguridad y feedback (no líneas de código ni seats).

Aquí el examen premia saber qué plan existe y qué incluye cada uno. Muchas preguntas se resuelven descartando planes inventados o recordando qué feature pertenece a qué plan.

Los planes que EXISTEN

Free · Pro · Pro+ · Business · Enterprise. ("Individual" es el término paraguas para Pro/Pro+.)

• ⚠️ Planes inventados (distractores muy habituales): Copilot Teams, Copilot for Azure DevOps, Copilot Premium, Copilot Codespace. Ninguno existe → siempre incorrectos.

Datos que caen seguro 📌

• Copilot Enterprise ⇒ requiere GitHub Enterprise Cloud (GHEC). Es la dependencia estrella del dominio.
• Copilot NO viene incluido gratis con GHEC → es una suscripción/add-on aparte (matiz: una trial de 30 días de GHEC sí trae Copilot Business incluido durante la prueba).
• SSO no es "una feature suelta del plan": es una capacidad de la organización en Enterprise Cloud; Copilot Enterprise usa el SSO de tu org si está configurado.
• Premium Support con SLAs = oferta separada y de pago para clientes Enterprise; se puede combinar con Copilot Enterprise, no viene por defecto.
• Usage reporting / usage metrics → Business y Enterprise (ambos).
• Content exclusion → Business y Enterprise.
• Knowledge Bases (docs curados como contexto del Chat) → Enterprise only.
• Chat consciente del repositorio en GitHub.com (referencia archivos/docs del repo remoto) → Enterprise.
• Individual (Pro/Pro+): solo code completions + Chat. NO tiene Knowledge Bases, PR diff analysis avanzado ni gestión organizativa.
• Quién compra y asigna los seats: en Business, los org owners; en Enterprise, los enterprise owners. (No los devs desde el IDE, ni los repo admins.)
• Gestión centralizada de seats → Business y Enterprise. ⚠️ "GitHub Team" es un plan de GitHub, no un plan de Copilot (distractor).

🧠 Cómo separar Business de Enterprise (regla de oro):

• Business = gestión + políticas + reporting + exclusions (para administrar un equipo).
• Enterprise = todo lo anterior + integraciones y "conocimiento de la organización": SSO, audit logs, Knowledge Bases, Chat repo-aware en GitHub.com, proxy. Si la feature suena a "integración corporativa" o "contexto de toda la empresa" → Enterprise.

¿Business o Business + Enterprise? (respuesta única vs "elige todas") ⚠️

Muchas features están en los dos planes de organización, y el examen las pregunta de dos maneras:

• "Choose all that apply" (usage reporting, content exclusion, gestión de seats, actividad de Copilot en el audit log de la org, políticas como el filtro de código público) → marca Business y Enterprise.
• Respuesta única con la misma feature ("usage reporting", "content exclusion por repositorio", "políticas para las sugerencias"), sobre todo si añade "sin integraciones enterprise" → Business, que es el plan que la introduce.
• Audit logs: si la pregunta los junta con SSO y compliance avanzado → Enterprise. Si pregunta qué planes muestran la actividad de Copilot en el audit log de la org (elige todas) → Business y Enterprise.
• SLAs de soporte: "¿qué plan ofrece SLAs de soporte enterprise?" → Enterprise (porque se combina con Premium Support). "¿Vienen incluidos por defecto?" → No, Premium Support se compra aparte.

Superficies donde vive Copilot Chat 📌

GitHub.com · VS Code · Visual Studio · JetBrains · Eclipse · Xcode · GitHub Mobile · Windows Terminal.

• ⚠️ GitHub Desktop NO es una superficie de Copilot Chat (distractor típico).
• ⚠️ GHES (GitHub Enterprise Server, on-premises) NO está soportado: Copilot requiere el servicio en la nube. Nada de "Copilot corriendo on-prem" ni "modelo self-hosted".

Feedback de una respuesta del Chat

• ✅ Botones 👍 / 👎 debajo de cada respuesta (in-line). Es el mismo mecanismo en IDE, GitHub.com y GitHub Mobile.
• ❌ NO es "el menú de ajustes de la app", "la sección de feedback de la web" ni "tuitear a la cuenta de GitHub en X".
• 🧠 Feedback de una respuesta concreta → siempre 👍/👎 in-line, sea cual sea la superficie.

Inline suggestions vs Chat, y dónde se configuran

• Inline suggestions: completions junto al cursor que aceptas con Tab. Chat: panel de conversación multi-turno donde eliges el contexto (selección, archivos). Ninguno se aplica solo sin que tú actúes.
• Activar o desactivar las inline suggestions en VS Code (global o por lenguaje) → Settings → Extensions → GitHub Copilot (Inline Suggest: Enable / Enable for [Language]).
• Copilot code review y PR summaries en GitHub.com → sugerencias de revisión y resúmenes en lenguaje natural de los cambios. ❌ No auto-mergean, no validan licencias y no son "solo análisis estático".

📝 Mini-preguntas de repaso (Dominio 2)

1. ¿Qué plan puede usar una org de Azure DevOps sin necesitar GitHub Enterprise? → Copilot Individual (Pro). (Enterprise requiere GHEC; "for Azure DevOps" y "Teams" no existen.)
2. ¿Qué planes excluyen tus prompts/completions del entrenamiento por defecto? → Business y Enterprise. (Individual puede opt-out, pero no por defecto.)
3. ¿Qué plan da Knowledge Bases y Chat repo-aware en GitHub.com? → Enterprise.
4. ¿Qué planes tienen content exclusion? → Business y Enterprise.
5. ¿Copilot Enterprise viene gratis con GHEC? → No, es una suscripción aparte.
6. ¿Está Copilot soportado en GHES? → No, requiere la nube.
7. ¿Cómo das feedback de una respuesta del Chat en GitHub Mobile? → Con los 👍/👎 in-line.

Este dominio es el más "conceptual". Si entiendes qué es Copilot por dentro y cómo viajan tus datos, caen muchas preguntas.

Concepto clave: Copilot NO es un modelo, es un producto sobre LLMs

• Copilot = un producto / orquestador que se sienta encima de modelos de lenguaje (LLMs). Es multi-modelo: por debajo puedes elegir el modelo (proveedores como OpenAI/GPT, Anthropic/Claude, Google/Gemini…).
• 🚗 Analogía del coche: Copilot es el coche (volante, salpicadero, sistemas de seguridad, integración con GitHub); el LLM es el motor intercambiable. Cambias el motor y sigues conduciendo el mismo coche. El coche te da la experiencia; el motor, la potencia de razonamiento.
• Flujo de una sugerencia: tu contexto (prompt + código de alrededor + archivo actual + comentarios) → Copilot lo procesa y le aplica filtros → el LLM genera → Copilot te devuelve la sugerencia filtrada dentro del IDE.
• 📌 Los filtros (código público, toxicidad, content exclusions) los pone Copilot, no el modelo.
• ⚠️ Para el examen vale el concepto (Copilot ≠ modelo; es multi-modelo). NO memorices la lista exacta de modelos disponibles: es lo que más rápido se queda desactualizado.

Dónde se procesan los prompts y qué pasa con tus datos 📌

• Los prompts se procesan en el servicio en la nube de Copilot, que los reenvía al modelo elegido según el data pipeline de GitHub. No es 100% local, ni tu CI, ni GHES.
• Tu código privado, prompts y completions NO se usan para entrenar los modelos base de Copilot. Ni "siempre", ni "solo para Enterprise", ni "salvo que desactives la telemetría". Es un no rotundo.
• Telemetría = señales agregadas de actividad y uso de features (completions, chat, agents) para reporting — NO un volcado de tu código fuente.
• Contexto de inferencia: Copilot usa el código de alrededor, el contenido del archivo actual y los comentarios para dar mejores sugerencias (no ejecuta tu código, no navega la web por su cuenta salvo integración, no usa "plantillas pre-guardadas").
• El historial del Chat aporta contexto para respuestas más relevantes y precisas (mantiene el hilo). NO entrena el modelo ni se comparte con otros usuarios.

Fuentes de las respuestas del Chat

• Copilot Chat combina varias fuentes: los datos de entrenamiento del modelo + el contexto de tu código/repositorios + fuentes externas (p. ej. Bing) cuando la integración aplica.
• 🧠 Desconfía de las opciones con "primarily / exclusively" apuntando a una sola fuente → suelen ser las incorrectas. La correcta es la que dice "combina".

Filtro de código público (code referencing / duplication detection)

• Qué hace: detecta o bloquea sugerencias que coinciden con código público en GitHub.
• Mecanismo: compara la sugerencia (+ unos ~150 caracteres de contexto alrededor) contra un índice de todos los repos públicos de GitHub.com.
• Bloquea coincidencias exactas largas (≈150+ caracteres). Con la opción "Allow + show references", muestra la sugerencia con enlaces a las fuentes públicas (útil para atribuir licencias).
• Solo indexa repos públicos (no privados ni código fuera de GitHub); el índice se refresca cada pocos meses; las coincidencias ocurren en menos del 1% de las sugerencias.
• Se configura a nivel de cuenta individual y por políticas de organización/enterprise.
• ⚠️ No confundir con content exclusion: code referencing gobierna las salidas (output que se parece a código público); content exclusion limita las entradas (lo que Copilot puede ver como contexto).
• 🧠 Exacto vs parecido: una coincidencia exacta y larga (≈150+ caracteres, p. ej. 200) la bloquean los filtros de duplication detection. Las sugerencias parecidas pero no exactas las gobierna el ajuste de code referencing (bloquear o mostrar con referencias). Fíjate si el enunciado dice exact o similar.

Modelos, latencia y calidad

• Copilot soporta múltiples modelos con distintas capacidades y compromisos; la elección del modelo SÍ afecta a la latencia y a la calidad. (Falso: "un único modelo fijo", "el modelo nunca afecta a la latencia".)

Custom models (modelos personalizados)

• Beneficio: las respuestas usan las prácticas y patrones de tus repositorios → salen con el estilo propio de tu organización.
• ❌ No es "más rápido", ni "garantiza corrección", ni "usa el motor LLM de la organización" (frase-humo).

📝 Mini-preguntas de repaso (Dominio 3)

1. ¿Copilot es un modelo de IA? → No, es un producto/orquestador multi-modelo sobre LLMs.
2. ¿Dónde se procesan los prompts? → En el servicio en la nube de Copilot, que los reenvía al modelo.
3. ¿Copilot entrena con tu código privado? → No.
4. ¿Qué incluye la telemetría? → Actividad y uso de features, no el contenido del código.
5. ¿Cómo genera el Chat sus respuestas? → Combinando training data + tu código/repos + fuentes externas (Bing).
6. ¿Contra qué compara el filtro de código público y cuántos caracteres? → Contra un índice de repos públicos de GitHub, ~150 caracteres de contexto.
7. ¿Qué rol juega el historial del chat? → Aporta contexto (relevancia/precisión); no entrena ni se comparte.

El examen valora que sepas qué hace bueno a un prompt y que distingas las técnicas (zero/one/few-shot, role prompting). Muchas preguntas te dan 4 prompts y te piden el "mejor": gana siempre el más específico y acotado.

Principios de un buen prompt 📌

• Clarity → enfócate en una sola tarea bien definida.
• Specificity → instrucciones claras y explícitas (lenguaje, versión, formato de salida…).
• Keep it simple → conciso, no recargado.
• Give examples → los ejemplos alinean la salida con el estilo/patrón que quieres.
• Provide context → contexto = sugerencias más relevantes y precisas.
• "Surround" → usa nombres de archivo descriptivos y mantén abiertos los archivos relacionados (Copilot aprovecha ese contexto).
• Break big tasks into small ones → trocea tareas grandes.
• ⚠️ "Verbosity / provide extensive descriptions" NO es un principio. El principio es keep it simple → más texto no es mejor prompt. (Es la respuesta a la pregunta "cuál NO es un principio".)

Herramientas del Chat para optimizar la experiencia

• Chat participants → los @ (p. ej. @workspace, @github): amplían el contexto.
• Slash commands → los / (/explain, /fix, /tests…): acciones predefinidas.
• Chat variables → los # (#file, #selection…): inyectan contenido concreto como contexto.
• ⚠️ Malas prácticas (siempre incorrectas): ser vago, pedir tareas enormes de golpe, evitar ejemplos/snippets.

Técnicas de prompting (definiciones que caen)

• Zero-shot = le pides algo sin ejemplos.
• One-shot = le das un ejemplo.
• Few-shot = le das varios ejemplos de entrada→salida para que capte el patrón.
• Role prompting = le asignas un rol/persona ("actúa como experto en seguridad", "como desarrolladora backend, quiero…") para orientar el tipo y nivel de respuesta.
• 🧠 Ejemplos = few-shot · Rol = role prompting · Tono ≠ rol. El tono de voz puede formar parte de un rol, pero por sí solo no es role prompting.

Ejemplos de prompts "ganadores" (por qué el específico gana)

Copilot rinde mejor con alcance pequeño y contexto claro. Fíjate en el patrón de las opciones correctas:

• 💡 Refactor acotado: "Modifica SOLO la función parseHeader; mantén el comportamiento público; añade bounds checks; devuelve errores detallados." (mejor que "mejora esto" o "limpia el parser").
• 💡 Reducir alucinaciones en API: "Usa Foo API v3; solo endpoints /users/{id} y /users/search; TypeScript; fetch; sin campos no documentados; maneja errores 4xx/5xx."
• 💡 Código seguro con secretos: "Lee la API key de una variable de entorno; no la hardcodees; falla rápido si falta; no loguees secretos."
• 💡 Formato de salida para CI: "Devuelve un array JSON de tests fallidos con campos name, file, line, message — sin prosa."
• 💡 Tests parametrizados: "Genera tests table-driven en Go para Parse(), cubriendo vacío, inválido y longitudes límite; incluye nombres y wantErr."
• 🧠 Regla: nombra lenguaje + versión + alcance + formato + restricciones. Descarta lo genérico ("improve this", "make it cleaner", "write tests") y lo enorme ("fix everything in the repo").
• Si Copilot da sugerencias irrelevantes o el prompt es ambiguo → reformular añadiendo contexto y detalles. ❌ No acortar el prompt, ni reintentar sin cambios, ni dejar de usar Copilot.

La trampa de las 4 opciones casi iguales ⚠️

En muchas preguntas de prompts las 4 opciones ya son específicas. La correcta es la que reúne todas las restricciones y no cuela ninguna práctica insegura. Los patrones que se repiten:

• 💡 SQL: versión del motor (PostgreSQL 14) + esquema + qué devolver + función de ventana para el ranking + columnas exactas de salida. Si falta una pieza, pierde.
• 💡 Explicar un archivo a alguien nuevo: audiencia (new backend hire) + qué cubrir (propósito, flujos de datos, dependencias, riesgos) + límite de longitud (5 bullets max).
• 💡 Rendimiento: restricciones medibles (O(1) extra space, entradas de 10MB+, backpressure, stub de benchmarks) frente a un vago "rápido y eficiente".
• 💡 Plan antes que código: "plan de 5 pasos para migrar Flask → FastAPI con riesgos, pasos de rollback y cómo mantener las rutas compatibles hacia atrás".
• 💡 HTTP seguro: HTTPS + validar certificados TLS + timeouts y reintentos + ocultar secretos en los logs + backoff ante 429/5xx.
• 💡 Librerías sin alucinaciones: versión exacta (Python 3.11; redis-py v5 only), método concreto (Redis.from_url) y "sin APIs deprecadas".
• 💡 CLI configurable: argparse, flags concretos, validación de ficheros, códigos de salida y ejemplos.
• 💡 Migración de BD segura: valor por defecto + backfill + online (sin downtime) + SQL de rollback.
• 💡 Logging con privacidad: logs JSON estructurados con requestId, sin PII, tokens ocultos y una línea por evento.
• ⚠️ Las opciones trampa suelen esconder un solo detalle inseguro: loguear cuerpos completos o tokens, saltarse la validación de certificados, una API key "de prueba" como respaldo, subir la configuración con secretos al repo o aceptar downtime. Con uno basta para descartarla.

📝 Mini-preguntas de repaso (Dominio 4)

1. ¿Qué es role prompting? → Describir en el prompt qué rol/persona debe adoptar Copilot.
2. ¿Qué es few-shot? → Darle varios ejemplos de entrada→salida.
3. ¿Cuál NO es un principio: Clarity, Verbosity, Specificity, Surround? → Verbosity.
4. ¿Cómo se optimiza la experiencia del Chat? → Con participants (@), slash commands (/), variables (#) y siendo específica.
5. Entre "Improve this" y "Refactor to pure functions; keep public API; add docstrings; return early on invalid input" → el segundo (específico).

Aquí el examen comprueba que sabes para qué sirve Copilot de verdad (siempre alrededor del código) y que distingues los casos reales de los distractores absurdos.

Para qué SÍ sirve (casos de uso reales)

• Explicar código y entender un codebase desconocido (onboarding de un nuevo dev).
• Generar tests unitarios y scaffolding de integración.
• Documentación: docstrings, comentarios, secciones de README.
• Debugging: explicar mensajes de error/stack traces y proponer fixes o refactors.
• Boilerplate y prototipado rápido; explorar APIs/librerías desconocidas; aprender frameworks/lenguajes con ejemplos en tiempo real.
• Productividad en proyectos grandes: sugerencias que aprovechan el contexto del workspace (varios archivos).
• ⚠️ Para qué NO sirve (distractores que se repiten): nómina/RRHH, contratos legales, copys de marketing/publicidad, gestión de agenda/salas, ejecutar tu CI, hostear registries, sustituir tu servidor de control de versiones.

Buenas prácticas para la calidad del código

• ✅ Revisar y refactorizar siempre lo que sugiere; tratar las sugerencias como borradores (drafts); pasar tests y security scans antes de mergear.
• ❌ Malas prácticas (siempre falsas): "rely solely / commit without review", "disable/avoid Copilot", "skip code review porque lo escribió Copilot", "auto-merge de PRs cuando pasan los tests".
• 🧠 Copilot acelera, pero NO garantiza corrección ni seguridad → el equipo sigue siendo responsable de testear, revisar y cumplir compliance. Este es el mensaje del dominio.

Riesgos de depender demasiado de Copilot

• ✅ Puede introducir vulnerabilidades (código con exploits conocidos) y no reflejar buenas prácticas ni los estándares más recientes.
• ❌ Falso: "aumenta el lead time" o "reduce la velocidad del desarrollador" → contradice el propósito de la herramienta.

Toxicity filter (filtro de toxicidad)

• Marca/bloquea contenido dañino: hate speech / lenguaje discriminatorio y contenido sexual o explícito.
• ❌ NO marca: código con errores lógicos/bugs (eso no es toxicidad) ni opiniones/críticas fuertes en comentarios (opinión firme ≠ ofensa).
• 🧠 El toxicity filter va de daño humano, NO de calidad técnica ni de tono opinado.

Refactoring (definición)

• Refactorizar = mejorar la ESTRUCTURA INTERNA del código SIN alterar su comportamiento externo. Mejora legibilidad/mantenibilidad; el código sigue haciendo lo mismo por fuera.
• ❌ No es: cambiar la funcionalidad, añadir features nuevas, ni (necesariamente) optimizar el rendimiento.
• Buen prompt de refactor → específico y acotado ("this function / this code segment") + un atributo de calidad nombrado (readability, maintainability).

Copilot y análisis estadístico

• 🧠 Copilot sugiere a partir de patrones estadísticos aprendidos → lo que propone es "lo habitual", puede no aplicar bien a tu dataset concreto → hay que revisar y validar.
• ❌ No "corrige errores estadísticos automáticamente", ni "verifica la significancia por su cuenta", ni "diseña métodos estadísticos nuevos no documentados".

Consistencia en tests

• Copilot detecta el patrón con el que escribes tus tests (nombres, estructura, framework, estilo de asserts) y sugiere tests futuros con ese mismo patrón → coherencia en todo el suite.
• ❌ No "arregla todos los tests" ni "escribe el código de implementación de la función".

Testing con Copilot: los flujos que pide el examen 📌

• TDD (red → green → refactor): Copilot redacta los tests o stubs que fallan a partir de una selección o una especificación, ayuda con cambios acotados hasta que pasan y luego a refactorizar. Con Agent mode: scaffold de tests que fallan → el agente implementa → revisas y refactorizas con los tests en verde.
• BDD (Given/When/Then): dale la especificación corta Given/When/Then + el framework de tests y pídele que genere los tests que fallan antes de implementar.
• Tests parametrizados (table-driven): selecciona la función y pide parameterized/table-driven tests en tu framework (p. ej. pytest parametrize o JUnit @MethodSource).
• Después de generar tests: revisar asserts y fixtures, añadir los edge cases que falten y ejecutar el suite para medir la cobertura. La cobertura la mides tú: Copilot da el punto de partida, no garantiza el 100 %.
• Tests flaky: aislar dependencias externas (mocks/fakes), fixtures deterministas y reducir la dependencia del tiempo. ❌ Ni desactivarlos, ni subir timeouts y reintentos a todo el suite, ni relanzar el CI hasta que pase una vez.
• Quality gates: aceptar la sugerencia → tests y cobertura en CI → code review apoyado en PR summaries → (opcional) code scanning → merge.
• ⚠️ En las preguntas de "¿cuál NO hace Copilot en testing?", la respuesta es ejecutar tu framework de tests en CI e informar de pass/fail. Generar plantillas, sugerir asserts, ayudar en TDD y organizar fixtures sí.
• Las content exclusions también afectan a los archivos de test: no están exentos.

📝 Mini-preguntas de repaso (Dominio 5)

1. Buena práctica para mejorar la calidad del código con Copilot → revisar y refactorizar lo que sugiere.
2. Dos riesgos reales de depender de Copilot → vulnerabilidades de seguridad y sugerencias que no siguen buenas prácticas/estándares.
3. ¿Qué marca el toxicity filter? → hate speech y contenido sexual/explícito (no bugs ni opiniones).
4. Definición de refactoring → mejorar la estructura interna sin cambiar el comportamiento externo.
5. ¿Qué NO es un caso de uso de Copilot: generar tests, escribir docs, producir copys de marketing, explicar código? → copys de marketing.
6. ¿Cómo ayuda Copilot a la consistencia de tus tests? → detecta tu patrón y sugiere tests similares.
7. Tienes tests flaky generados con Copilot, ¿qué haces? → Mocks/fakes, fixtures deterministas y menos dependencia del tiempo (no desactivarlos ni subir los timeouts).

El dominio más "denso" en detalles. Aquí conviene tener súper claras content exclusions, la gobernanza (settings de org/enterprise), la REST API/audit logs, los slash commands y el coding agent.

Content Exclusions — lo que cae seguro 📌

• Qué hace: impide que ciertos contenidos se usen como contexto de entrada (input) de Copilot. NO censura las salidas ni borra nada del historial de Git.
• Distinto de .gitignore: content exclusion limita lo que Copilot puede ver como input; .gitignore controla lo que Git rastrea. Son cosas totalmente distintas.
• En qué planes: Business y Enterprise.
• Quién puede gestionarla: administradores de repositorio, org owners y enterprise owners. (NO: colaboradores externos, ni el rol Maintain, ni contributors normales.)
• Qué targets/granularidad admite: repositorios, rutas/directorios, tipos de archivo y patrones (fnmatch, case-insensitive).
• ⚠️ NO se pueden excluir "líneas sueltas" de un archivo (mínimo, el archivo entero). Tampoco gists.
• Se acumulan, no se sobrescriben: las exclusiones heredadas de org/enterprise aparecen en el repo como cajas grises de solo lectura. Las políticas impuestas a nivel enterprise tienen prioridad y no se pueden anular ni en org ni en repo.
• Alcance de las de org: solo aplican a usuarios que reciben su seat de esa organización; las de enterprise aplican a toda la enterprise.
• Aplican en todas las superficies (definen el límite del contexto de entrada) para inline suggestions; Copilot code review en GitHub.com también las respeta.
• ⚠️ Dónde NO aplican: Copilot CLI, la app de Copilot, GitHub Mobile, y los modos Edit y Agent del Chat en editores.
• 🧠 Cómo responder en el examen: si preguntan "¿aplica content exclusion en todas las superficies?" con opciones tipo "solo VS Code / solo GitHub.com / solo JetBrains / sí", la respuesta que dan por buena los tests es sí: define el límite del contexto de entrada sea cual sea la superficie. Las excepciones de arriba son la letra pequeña de la documentación.
• Propagación: hasta 30 minutos en IDEs con la sesión ya cargada. Se fuerza con Developer: Reload Window (VS Code), reabriendo Visual Studio/JetBrains; Vim/Neovim recarga al abrir cada archivo.
• ⚠️ Fuga de contexto (limitación oficial): aunque un archivo esté excluido, Copilot puede usar información semántica indirecta que le pasa el IDE (tipos, definiciones al hacer hover sobre símbolos, propiedades del proyecto) cuando código no excluido referencia algo del excluido (p. ej. una llamada a función). No "lee" el archivo, pero se le "escapa" contexto por las referencias. @workspace no salta una exclusión.
• Validar si un archivo está excluido: por el icono de Copilot en la barra de estado del editor (cambia y muestra un mensaje). Una exclusión no es un error → no aparece en el "errors panel".

Content exclusion vs Code referencing (el par que confunden)

• Content exclusion → limita lo que Copilot ve como ENTRADA (contexto).
• Code referencing (matching public code) → gobierna las SALIDAS que se parecen a código público (bloquear/mostrar referencias).
• 🧠 Entrada = exclusion · Salida = referencing.

Gobernanza y políticas

• Las políticas de Copilot (features, content exclusions, public code filter, modelos/superficies permitidas) se configuran en los settings de organización/enterprise, NUNCA en un archivo dentro del repo.
• ⚠️ Archivos inventados como distractores: copilot.policy, .copilotignore como policy, aplicar políticas "vía GitHub Actions". No existen / no es así.
• Si el enterprise impone una política (p. ej. "block matching public code" o restringir a ciertos modelos), la org y el repo NO pueden anularla; la org solo puede configurar dentro del conjunto permitido.

REST API de Copilot (admin + métricas, nunca contenido)

• ✅ Se puede: listar los seat assignments de una org (GET /orgs/{org}/copilot/billing/seats), obtener usage metrics de la organización (nº de sugerencias aceptadas y usadas, métricas de aceptación del Chat).
• ❌ NO se puede: ver las sugerencias/código de un usuario (privacidad), listar "unsubscribed members", medir calidad de código, dar feedback de estilo ni refactorizar (es una API de datos, no actúa sobre el código).
• 🧠 Regla: la API es administración + métricas de uso, nunca el contenido de lo que Copilot sugiere.

Audit logs

• Registran eventos administrativos / de configuración: p. ej. cambios en la configuración de content exclusion, gestión de seats, y actividad de Copilot (quién usó qué y cuándo) en Business y Enterprise.
• ❌ NO registran el contenido de las sugerencias, ni "accepted/blocked suggestions" como tales.
• 🧠 Audit log = "quién administró/configuró qué", no "qué sugirió Copilot".

Slash commands (el nombre = la función)

• 🧠 /optimize → SOLO Visual Studio (si te lo ponen como comando de VS Code, cuidado). /simplify → Xcode.
• 🧠 En la web (GitHub.com) los / son para gestionar conversaciones (/new, /clear, /rename, /delete), NO para tocar código.
• ⚠️ /btw NO es del examen: es una propuesta de comunidad para Copilot CLI (preguntas efímeras "by the way"), no un comando oficial del Chat del IDE. Si aparece como opción de "comando del IDE" → distractor.

Chat en el IDE vs Chat en GitHub.com

• IDE → gira sobre tu código: explicar, arreglar, testear, optimizar, documentar, mejorar, entender un codebase.
• GitHub.com → contexto del repositorio remoto: releases, commits, PRs, issues, y repo-aware Chat (Enterprise).
• 🧠 Si el enunciado dice "IDE" y la opción habla de releases/commits/PRs → incorrecta (eso es web).

Coding Agent (Agent mode)

• 📌 Disponible en Pro, Pro+, Business y Enterprise (NO en Free).
• Trabaja desde un issue de GitHub, arranca un entorno de desarrollo efímero en la nube (powered by GitHub Actions), hace cambios en una rama y abre un pull request (draft) para revisión.
• Respeta branch protections, required reviews, status checks y CODEOWNERS — igual que cualquier PR. Actúa con los mismos permisos que el usuario que lo invoca (no gana admin ni salta protecciones).
• Personalizar su entorno: fichero copilot-setup-steps.yml en .github/workflows/ → pre-instala dependencias/herramientas para builds más rápidos y fiables.
  • ⚠️ Distractores del entorno: un .copilot-env.json en tu carpeta personal, un script en tu home, "el agente copia tu dev container local" o subir node_modules al repo. Nada de eso. (En algunas preguntas el fichero aparece como .yaml: es el mismo concepto.)
• Agent firewall (enterprise): controla qué dominios/URLs puede acceder el agente → reduce el riesgo de exfiltración de datos.
• Se puede extender con servidores MCP (Model Context Protocol) para llamar a herramientas/fuentes externas (p. ej. GitHub o Playwright MCP).
• Control administrativo: políticas de org/enterprise habilitan/deshabilitan el agente por repos y usuarios.
• ⚠️ Cuándo NO usarlo: incidentes en producción, fugas de PII, credenciales filtradas, decisiones de seguridad en caliente, o arquitecturas nuevas críticas sin tests ni criterios claros. ✅ Cuándo SÍ: implementar una feature de un issue bien definido con criterios de aceptación, cambios multi-archivo + tests + PR, actualizar una librería de componentes en todo el repo, mejorar cobertura de tests.

Edit mode vs Agent mode vs Chat

• Edit mode (Copilot Edits): cambios acotados y revisables (diffs) en los archivos que tú eliges. Ideal para tocar 1-2 ficheros con revisión, sin ejecutar comandos.
• Agent mode: autónomo y multi-paso (edita varios archivos, ejecuta comandos/herramientas, puede abrir un PR).
• Chat: conversación y razonamiento; propone, pero no ejecuta comandos por su cuenta.
• 🧠 Cambio pequeño y revisable → Edit. Tarea multi-paso que cruza archivos + tests + PR → Agent. Solo explicar/preguntar → Chat/Ask.

Responsabilidades que SIEMPRE quedan en el equipo

• Revisar y aprobar el PR antes de mergear; asegurar que pasan tests, linters y security scans; definir tareas/issues bien acotados para el agente.
• ❌ Nunca: dejar que el agente auto-mergee a producción saltándose revisiones, ni desactivar branch protections "para ir más rápido".

Trabajar con el agente de forma segura (patrones que caen) 📌

• Límites seguros: rama de feature, commits pequeños, status checks obligatorios, ejecutar tests y tener un plan de rollback (revertir el PR si hace falta). ❌ Nunca en la rama por defecto, ni con force-push, ni con las protecciones desactivadas.
• Monorepo: acota la tarea a rutas o paquetes concretos y pide diffs revisables por paquete, para evitar cambios cruzados no deseados.
• Chat y Agent en la misma tarea: Chat → redactar tests y configuración; Agent → ejecutar comandos, iterar y abrir el PR.
• Agent mode es excesivo para cambios mínimos, como renombrar un parámetro y actualizar un docstring en un solo archivo.
• "Ejecuta los tests y arregla los que fallan" → lo esperable es que ejecute los tests, proponga cambios mínimos con diff y suba a una rama para revisión por PR.
• El mejor encargo para el agente es acotado y con criterios: "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".
• MCP en el coding agent: sirve para que llame a herramientas y fuentes especializadas (p. ej. GitHub o Playwright MCP). ❌ No reentrena los modelos ni desactiva el firewall ni las políticas.

Copilot en la revisión de PRs: siempre consultivo

• 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. (No los PR summaries ni el agente "adivinando" revisores.)

Copilot Spaces

• Organizan contexto curado (archivos, repos, PRs, issues) para que el Chat esté anclado a tu proyecto ("project expert" — ideal para onboarding de un equipo a un servicio complejo).
• Disponibles para cualquier usuario con suscripción a Copilot, en GitHub.com. Respetan las políticas de content exclusion y code referencing.

Otros datos de administración / soporte 📌

• Copilot en la CLI: ayuda a redactar y explicar comandos de shell/Git y sus flags (no los ejecuta por su cuenta).
• Diagnóstico en VS Code: comando "GitHub Copilot: Collect Diagnostics" (Command Palette: Ctrl/Cmd+Shift+P). Logs de la extensión en el panel Output; logs de Electron en Developer Tools.
• Aceptar una sugerencia inline = se inserta en tu editor; tú decides si la mantienes, editas o descartas (no se auto-commitea ni se mergea, no genera audit log por sí sola).
• Almacenar secretos / API keys de forma segura → Azure Key Vault / Managed HSMs con acceso controlado (nunca en texto plano, en el repo, ni por email).

📝 Mini-preguntas de repaso (Dominio 6)

1. ¿Qué hace content exclusion? → Impide que ciertos contenidos se usen como contexto de ENTRADA.
2. ¿Qué targets admite? → Repos, rutas/directorios, tipos de archivo y patrones (no líneas sueltas, no gists).
3. ¿Quién la gestiona? → Admins de repo, org owners, enterprise owners.
4. ¿Cuándo puede Copilot "ver" algo de un archivo excluido? → Cuando código no excluido lo referencia (info semántica indirecta del IDE).
5. ¿Dónde se configuran las políticas org-wide de Copilot? → En los settings de la organización.
6. ¿Qué NO puede la REST API de Copilot? → Ver las sugerencias/código de un usuario.
7. ¿Qué registran los audit logs? → Eventos de config/admin, p. ej. cambios en content exclusion.
8. ¿Qué hace /optimize y dónde? → Mejora el runtime del código; solo en Visual Studio.
9. ¿En qué planes está el coding agent? → Pro, Pro+, Business y Enterprise.
10. ¿El coding agent puede saltarse branch protections? → No; respeta protecciones, reviews y CODEOWNERS.
11. ¿Edit mode o Agent mode para tocar 2 archivos con diff revisable? → Edit mode.
12. ¿Cuentan las review suggestions de Copilot como aprobación de un PR? → No, son consultivas; siguen aplicando required reviewers, checks y CODEOWNERS.
13. ¿Cómo garantizas que expertos revisen siempre ciertas rutas? → Con un fichero CODEOWNERS.

1. Absolutos = casi siempre falsos. always, guaranteed, only, never, 100%, incapable of, replaces the need for, exclusively, limited to. Si una opción promete algo absoluto, sospecha.
2. Copilot asiste, tú validas. Toda opción que diga "confía a ciegas / sin revisar / auto-merge" → incorrecta. Toda opción que diga "revisa, testea, refactoriza, valida" → suele ser correcta.
3. Lo específico gana a lo genérico. El buen prompt y la buena práctica son siempre acotados y concretos; descarta lo vago ("improve this") y lo enorme ("fix everything").
4. Combinar principios/acciones gana en IA responsable; una sola medida "a medias" pierde.
5. La REST API y los audit logs NO tocan el contenido de tus sugerencias (solo admin + métricas + eventos de config).
6. Enterprise = integraciones + conocimiento de la organización (SSO, audit, Knowledge Bases, repo-aware Chat). Business = gestión + políticas + exclusions, sin integraciones enterprise.
7. Copilot requiere la nube: GHES no soportado; no se entrena con tu código privado; los prompts pasan por el servicio cloud de Copilot.
8. Cuidado con las preguntas "NOT / cuál NO es": léelas dos veces; la correcta es la que rompe el patrón.
9. Nombres inventados = fuera: Copilot Teams, Copilot Premium, Copilot for Azure DevOps, Copilot Codespace, copilot.policy, .copilotignore, .copilot-env.json, /btw como comando del IDE.
10. El nombre del slash command = su función. /fix arregla, /tests genera tests, /doc documenta, /explain explica, /optimize optimiza (VS), /simplify simplifica (Xcode).

• Me sé los 6 principios y la palabra clave de cada uno (y que "Maximizing Profit" no es uno).
• Distingo Fairness/Inclusiveness y Transparency/Accountability.
• Sé qué es bias y las 3 trampas (más datos / accuracy / monitorizar).
• Me sé los planes (Free/Pro/Pro+/Business/Enterprise) y qué incluye cada uno.
• Sé que Enterprise ⇒ GHEC y que Copilot no viene gratis con GHEC.
• Entiendo que Copilot es multi-modelo y que no entrena con mi código privado.
• Domino content exclusions (qué, quién, targets, se acumulan, fuga semántica).
• Sé que la REST API/audit logs = admin + métricas, nunca contenido.
• Me sé los slash commands y dónde vive cada uno.
• Distingo Edit / Agent / Chat y cuándo usar el coding agent.
• Distingo cuándo marcar solo Business y cuándo Business + Enterprise.
• Sé elegir entre 4 prompts casi iguales (todas las restricciones, ninguna práctica insegura).
• Me sé los flujos de testing (TDD, BDD, flaky, quality gates) y los límites seguros del agente (rama, rollback, CODEOWNERS).
• Aplico los meta-trucos (absolutos falsos, Copilot asiste/tú validas, nombres inventados).