132 lines
9.3 KiB
JSON
132 lines
9.3 KiB
JSON
[{
|
|
"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)."
|
|
]
|
|
}]
|
|
}] |