[{
    "origin": "Gemini 3 Flash",
    "sources": [
        "https://www.axelos.com/certifications/itil-service-management",
        "https://www.boe.es/buscar/act.php?id=BOE-A-2015-10565",
        "https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/access-modifiers",
        "https://www.ccn-cert.cni.es/ens.html"
    ],
    "title": "Precisión Técnica e Legal - Refactorizado KyMAN",
    "group": "precision_tecnica_016",
    "queries": [{
        "question": "¿Cuál es la {rand:diferencia conceptual|distinción en ITIL} entre una {rand:Incidencia|Incident} y un {rand:Problema|Problem}?",
        "rights": [
            "La incidencia busca {rand:restaurar el servicio|resolver el fallo rápido} y el problema busca {rand:la causa raíz|el origen subyacente}."
        ],
        "wrongs": [
            "La incidencia es un {rand:fallo de hardware|error físico} y el problema es exclusivamente un {rand:error de software|bug de código}.",
            "Son términos {rand:sinónimos|idénticos} que se diferencian solo por el {rand:nivel de soporte (L1/L2)|equipo que lo gestiona}.",
            "El problema es una {rand:alerta preventiva|detección temprana} y la incidencia es cuando el {rand:usuario reporta el fallo|servicio cae}."
        ],
        "wrong_explanations": [
            "ITIL no diferencia incidentes y problemas por el tipo de activo (HW/SW), sino por el objetivo de la gestión (restauración vs. investigación).",
            "No son sinónimos: la gestión de incidentes y problemas son procesos distintos con flujos de trabajo diferentes.",
            "Ambos pueden ser reactivos o proactivos; la diferencia radica en si se trata el síntoma (incidencia) o la enfermedad (problema)."
        ]
    }, {
        "question": "Segundo o Art. 77.2 da Lei 39/2015, ¿cal é a {rand:duración legal|extensión} do {rand:período de proba|prazo para probar feitos} nun procedemento?",
        "rights": [
            "Un prazo non superior a {rand:30 días|trinta días} nin inferior a {rand:10 días|dez días}."
        ],
        "wrongs": [
            "Un prazo de {rand:15 días hábiles|quince días} de carácter {rand:improrrogable|obrigatorio} para todos os casos.",
            "Un prazo non superior a {rand:20 días|vinte días} nin inferior a {rand:5 días|cinco días} naturais.",
            "Un máximo de {rand:3 meses|tres meses}, coincidente co tempo máximo de {rand:resolución|finalización} do expediente."
        ],
        "wrong_explanations": [
            "O prazo de 15 días non é o estándar para o período de proba na Lei 39/2015.",
            "Os límites de 20 e 5 días non corresponden á fase de proba regulada no Artigo 77.",
            "O período de proba é unha fase dentro do procedemento, non pode ocupar todo o tempo máximo de resolución."
        ]
    }, {
        "question": "En C#, ¿desde dónde se permite el acceso a un miembro {rand:protected internal|declarado como protected internal}?",
        "rights": [
            "Desde el {rand:mismo ensamblado|propio assembly} O desde cualquier {rand:clase derivada|clase hija} incluso en otro ensamblado."
        ],
        "wrongs": [
            "Solo desde la {rand:misma clase|propia clase} y sus hijas que estén {rand:estrictamente|obligatoriamente} en el mismo ensamblado.",
            "Exclusivamente desde las {rand:clase derivadas (herencia)|subclases}, ignorando el {rand:ensamblado|proyecto} de origen.",
            "Es un sinónimo exacto de {rand:internal|el modificador internal}, limitando el acceso al {rand:mismo proyecto|binario}."
        ],
        "wrong_explanations": [
            "Eso sería 'private protected'. El 'protected internal' es más permisivo (actúa como un OR).",
            "Eso sería solo 'protected'. Al añadir 'internal', se abre también a clases no derivadas dentro del mismo ensamblado.",
            "No es sinónimo; 'internal' cierra el acceso fuera del ensamblado, pero 'protected internal' lo permite fuera si hay herencia."
        ]
    }, {
        "question": "No ENS, ¿que {rand:rol|figura} é responsable de determinar os {rand:requisitos de seguridade|niveles das dimensións} da información?",
        "rights": [
            "O {rand:Responsable da Información|Dono da información}."
        ],
        "wrongs": [
            "O {rand:Responsable da Seguridade|CISO}, que propón as medidas técnicas e organizativas.",
            "O {rand:Responsable do Sistema|Administrador}, que se encarga da implantación e operación técnica.",
            "O {rand:Delegado de Protección de Datos (DPD)|Data Privacy Officer}, encargado da coordinación do RGPD."
        ],
        "wrong_explanations": [
            "O de Seguridade decide CÓMO protexer, pero o de Información decide QUÉ é importante proteger.",
            "O do Sistema executa as ordes de seguridade, pero non ten competencia para valorar a importancia dos datos.",
            "O DPD supervisa o cumprimento da lei de privacidade, pero a valoración de activos no ENS é competencia do Responsable de Información."
        ]
    }, {
        "question": "¿Qué {rand:cláusula|sentencia} SQL se usa para filtrar {rand:agregaciones|resultados de un GROUP BY} (ej: HAVING COUNT > 50)?",
        "rights": [
            "{rand:HAVING|la cláusula HAVING}."
        ],
        "wrongs": [
            "WHERE, que se usa para filtrar {rand:filas individuales|registros} antes de la agrupación.",
            "FILTER, un {rand:operador especial|comando} para depurar la memoria caché del Buffer Pool.",
            "ORDER BY, que se limita a {rand:ordenar|clasificar} el resultado final de la consulta."
        ],
        "wrong_explanations": [
            "WHERE no admite funciones de agregado (como COUNT o SUM) en el filtrado; para eso está HAVING.",
            "FILTER no es una cláusula estándar de filtrado de agregación en SQL Server.",
            "ORDER BY cambia la visualización de los datos, pero no elimina grupos del conjunto de resultados."
        ]
    }, {
        "question": "¿Cuál es la {rand:diferencia fundamental|distinción técnica} entre {rand:git fetch|fetch} y {rand:git pull|pull}?",
        "rights": [
            "Fetch solo {rand:descarga cambios|actualiza las tracking branches} y Pull es un {rand:Fetch + Merge|2 por 1}."
        ],
        "wrongs": [
            "Fetch descarga {rand:todas las ramas|el repo completo} y Pull solo afecta a la {rand:rama actual|rama activa}.",
            "Pull es 100% {rand:seguro|inofensivo} y Fetch puede {rand:pisar tus cambios locales|provocar conflictos}.",
            "Fetch es para {rand:servidores remotos|GitHub} y Pull se usa solo en {rand:repositorios locales|entornos offline}."
        ],
        "wrong_explanations": [
            "Ambos pueden actuar sobre una o todas las ramas; la diferencia es si fusionan (merge) o no el código.",
            "Es al revés: Fetch es el comando seguro (no toca tu código); Pull puede generar conflictos al intentar el merge.",
            "Ambos son comandos de Git que interactúan entre el entorno local y el remoto."
        ]
    }, {
        "question": "¿Qué {rand:caracteriza legalmente|define} a la {rand:Anonimización|técnica de anonimizado} frente a la Seudonimización en el RGPD?",
        "rights": [
            "La anonimización es {rand:irreversible|definitiva} y los datos dejan de considerarse {rand:personales|de carácter privado}."
        ],
        "wrongs": [
            "La seudonimización {rand:borra el DNI|elimina la identidad} de forma que nadie puede volver a identificar al sujeto.",
            "Son términos {rand:sinónimos|equivalentes} que se aplican según el {rand:volumen de datos|tamaño del Big Data}.",
            "La anonimización permite {rand:recuperar la identidad|reversibilidad} mediante una clave custodiada por la Administración."
        ],
        "wrong_explanations": [
            "La seudonimización es reversible; es la anonimización la que rompe el vínculo permanentemente.",
            "Legalmente son muy distintos: el dato anonimizado sale del ámbito de aplicación del RGPD; el seudonimizado no.",
            "Si es reversible mediante una clave, se trata de seudonimización, no de anonimización."
        ]
    }, {
        "question": "¿Por qué un {rand:Switch|Conmutador} es Capa 2 y un {rand:Router|Enrutador} es Capa 3 del modelo OSI?",
        "rights": [
            "El Switch lee {rand:direcciones MAC|direcciones físicas} y el Router lee {rand:direcciones IP|direcciones lógicas}."
        ],
        "wrongs": [
            "El Switch lee la {rand:dirección IP|IP de destino} y el Router lee el {rand:puerto de transporte|puerto TCP/UDP}.",
            "El Switch trabaja con {rand:redes externas|Internet} y el Router solo con la {rand:red local|LAN interna}.",
            "El Switch es un dispositivo {rand:físico (Capa 1)|pasivo} y el Router es un dispositivo {rand:lógico|activo}."
        ],
        "wrong_explanations": [
            "Un Switch tradicional no entiende las IPs (Capa 3); el dispositivo que lee puertos es de Capa 4 (Transporte).",
            "Es al revés: el Switch gestiona la red local (LAN) y el Router permite la interconexión con redes externas (WAN/Internet).",
            "Ambos son dispositivos activos, pero operan en diferentes niveles de abstracción del modelo OSI (Enlace vs. Red)."
        ]
    }]
}]