Moodle — Cursos, Actividades, Evaluación, Administración, Seguridad e Integraciones

Q1. ¿Qué es Moodle y qué problema resuelve?

Moodle es un LMS open source (licencia GPL) escrito en PHP que permite crear entornos virtuales de aprendizaje: cursos, actividades, recursos, evaluaciones, comunicación y seguimiento. Resuelve la necesidad de impartir formación presencial, blended o 100% online con una plataforma flexible, extensible y multilingüe. Se usa en universidades, empresas y organismos públicos. Al ser open source se puede personalizar y desplegar on-premise o en la nube; a cambio, requiere administración técnica y gobierno.

Q2. ¿Qué diferencia hay entre Moodle LMS, Moodle Workplace y MoodleCloud?

Moodle LMS es el núcleo open source para gestionar cursos y usuarios. Moodle Workplace es una distribución empresarial de pago sobre Moodle LMS, con organizaciones, certificaciones, planes de aprendizaje, onboarding y automatizaciones. MoodleCloud es el servicio SaaS oficial, con planes gestionados y menos control de infraestructura. La elección depende de requisitos de multi-tenancy, cumplimiento, personalización y equipo. Todas comparten el modelo de cursos, actividades y roles, lo que facilita migrar.

Q3. ¿Cuál es la arquitectura técnica de Moodle?

Es una aplicación web PHP con arquitectura de plugins. El código vive en el directorio raíz (dirroot), la configuración en config.php y los archivos de usuario en dataroot (fuera del webroot). Usa una base de datos relacional (MySQL/MariaDB, PostgreSQL, SQL Server u Oracle), un servidor web (Apache/Nginx) y PHP con extensiones. El core se organiza en módulos y subsistemas; los plugins (actividades, bloques, temas, autenticación, matriculación, filtros, etc.) extienden la funcionalidad. Cron ejecuta las tareas programadas.

Q4. ¿Cuáles son los conceptos básicos de un curso en Moodle?

Categorías (organización jerárquica de cursos), cursos (contenedor de actividades y recursos), secciones o temas, actividades (foro, tarea, cuestionario, etc.), recursos (archivo, página, URL, libro), usuarios y roles, grupos y agrupaciones, métodos de matriculación, finalización (completion) e insignias. Los cursos pueden ser visibles u ocultos y usar formato por temas, semanas o actividad única. La estructura debe responder a objetivos de aprendizaje, no a la herramienta.

Q5. ¿Qué tipos de despliegue existen?

On-premise (servidor propio o VPC), IaaS (AWS, Azure, GCP), contenedores orquestados, hosting gestionado o MoodleCloud. Factores: control, cumplimiento, presupuesto, escalabilidad, backups, seguridad y equipo de operación. En todos los casos se necesita un entorno de pruebas, monitoreo, plan de upgrades y gestión de plugins. Para alta disponibilidad se usan balanceadores, sesiones compartidas (Redis), almacenamiento compartido o S3 y base de datos gestionada.

Q6. ¿Qué es un rol en Moodle y cuáles son los arquetipos?

Un rol es un conjunto de permisos (capabilities) que se asigna en un contexto. Arquetipos: manager, coursecreator, editingteacher, teacher, non-editingteacher, student, guest, user y frontpage. Los permisos se heredan por contexto (sistema, categoría, curso, módulo, bloque, usuario) y se pueden permitir, prohibir o dejar sin definir. Se recomienda usar los roles estándar y crear roles personalizados solo si es necesario, documentando el principio de mínimo privilegio.

Q7. ¿Moodle es solo para educación formal?

No. Se usa en educación (K-12 y universidad), formación corporativa, compliance, onboarding, certificaciones y comunidades de práctica. Las actividades, la finalización, las insignias y los informes sirven para rutas de aprendizaje y evidencias. Moodle Workplace añade herramientas para empresas. La clave es diseñar la experiencia según el público: no trasladar un curso académico tal cual a un entorno corporativo.

Q8. ¿Cómo se compara Moodle con otros LMS?

Ventajas: open source, flexibilidad, ecosistema enorme de plugins, comunidad, multilingüe, control de los datos y costo de licencia. Desventajas: requiere administración técnica, la experiencia de usuario puede ser menos pulida que la de SaaS modernos y el rendimiento depende de la infraestructura. Canvas, Blackboard o Google Classroom ofrecen experiencias gestionadas y menor carga operativa, con otros costos y límites de personalización. La elección depende de requisitos pedagógicos, integraciones, presupuesto total y equipo.

Q9. ¿Qué requisitos necesita una instalación de Moodle?

PHP con las extensiones requeridas (entre otras: mbstring, curl, gd, xml, zip, intl, openssl, sodium), una base de datos soportada (MySQL/MariaDB, PostgreSQL, SQL Server u Oracle), servidor web (Apache o Nginx), HTTPS, memoria y disco suficientes, y un directorio dataroot fuera del webroot. Además se necesita cron cada minuto, correo saliente y backups. La página de comprobación del entorno del instalador señala extensiones y límites que deben corregirse antes de continuar.

Q10. ¿Cómo se instala Moodle?

Se puede usar el instalador web o la CLI: php admin/cli/install.php con los parámetros de wwwroot, dataroot, base de datos y usuario admin. El proceso crea config.php y el esquema de la base de datos. Buenas prácticas: dataroot fuera del webroot, permisos correctos, HTTPS, correo configurado, cron activo y un backup inicial. En producción conviene automatizar la instalación con configuración como código y validar el entorno antes de exponer el sitio.

Q11. ¿Qué contiene config.php y qué cuidados requiere?

Define wwwroot, dataroot, conexión a la base de datos (tipo, host, nombre, usuario, contraseña, prefijo), rutas y opciones como proxy inverso o depuración. Contiene secretos, por lo que no debe estar en el repositorio ni ser accesible públicamente; permisos restringidos y backup seguro. En entornos gestionados se usan variables de entorno o gestores de secretos. Evitar editar config.php a mano en producción sin control de cambios. Cualquier cambio debe probarse en staging.

Q12. ¿Por qué es crítico el cron en Moodle?

Cron ejecuta tareas programadas y adhoc: envío de correos y notificaciones, procesamiento de calificaciones, finalización, insignias, backups, informes, limpieza y sincronizaciones. Debe ejecutarse cada minuto con el usuario adecuado: php admin/cli/cron.php. Si falla, los usuarios ven acciones que no se completan y las tareas se acumulan. Monitorear el resultado, la duración y las tareas fallidas desde la administración; evitar ejecuciones solapadas y revisar límites de tiempo y memoria.

Q13. ¿Cómo se actualiza Moodle de forma segura?

Leer las notas de la versión, verificar compatibilidad de PHP, base de datos y plugins, hacer backup completo (base de datos, dataroot y config), entrar en mantenimiento, actualizar el código y ejecutar php admin/cli/upgrade.php; después purgar cachés y probar. Las versiones mayores pueden requerir pasos intermedios. Mantener un plan de rollback y un entorno de staging con datos representativos. No actualizar plugins y core a la vez sin pruebas; revisar plugins abandonados antes de la actualización.

Q14. ¿Cómo se gestionan los plugins?

Los plugins extienden actividades, bloques, temas, autenticación, matriculación, filtros, informes, etc. Se instalan desde el directorio oficial o subiendo un ZIP, y deben cumplir dependencias y versión de Moodle. Antes de instalar: revisar mantenimiento, valoraciones, seguridad, licencia, compatibilidad y soporte; probar en staging. Documentar el inventario, actualizar de forma controlada y eliminar los que no se usan. Evitar plugins abandonados o con código sospechoso; el core debe permanecer sin modificaciones.

Q15. ¿Cómo funcionan el backup y la restauración?

El backup del sitio incluye la base de datos, el dataroot y config.php; deben respaldarse de forma consistente y coordinada, porque los archivos y la base se referencian entre sí. Los backups de curso (MBZ) incluyen contenido y ajustes, con opción de incluir datos de usuarios. Automatizar, cifrar, almacenar fuera del servidor y probar restauraciones periódicamente. Definir RPO y RTO; conservar versiones compatibles con la versión actual. Un backup que nunca se restaura no es una garantía.

Q16. ¿Cómo se organizan los entornos de desarrollo, staging y producción?

Cada entorno debe tener su propia base de datos, dataroot y wwwroot; no compartir archivos ni base entre ellos. Staging se usa para probar actualizaciones, plugins y cambios de tema con datos anonimizados. El código propio (plugins, temas) se versiona en Git y se despliega con un pipeline; el dataroot no se versiona. Mantener ventanas de mantenimiento, control de cambios y un plan de rollback. Nunca probar en producción ni copiar datos personales sin protección.

Q17. ¿Cómo se organizan las categorías de cursos?

Las categorías forman una jerarquía para organizar cursos y delegar administración. Se pueden anidar (facultad → departamento → programa), asignar roles por contexto y usar plantillas. Una estructura clara facilita la gestión, los permisos y los informes. Evitar categorías duplicadas o demasiado profundas; definir convenciones de nombres y un owner. Las categorías también afectan la visibilidad y la navegación del usuario.

Q18. ¿Qué formatos de curso existen y cuándo usar cada uno?

Los formatos más comunes son temas (secciones por contenido), semanas (secuencia temporal), social (basado en un foro) y actividad única (todo el curso es una actividad). La elección depende del diseño: un curso autoguiado suele funcionar con temas; un curso con cohortes y fechas, con semanas. Se pueden añadir restricciones de acceso y finalización por sección. El formato debe facilitar la navegación, no complicarla.

Q19. ¿Qué ajustes definen un curso?

Nombre y nombre corto, categoría, visibilidad, fechas de inicio y fin, formato, número máximo de estudiantes, idioma, apariencia, archivos, finalización, grupos, renombrado de roles y etiquetas. También se definen el resumen, la imagen y las competencias. Los ajustes deben alinearse con la política institucional (visibilidad por defecto, matriculación, retención). Documentar las plantillas y evitar que cada docente cambie configuraciones críticas sin control.

Q20. ¿Qué métodos de matriculación existen?

Manual, auto-matriculación (con clave o aprobación), sincronización de cohortes, base de datos externa, LDAP, archivo plano, IMS Enterprise, LTI y pago, entre otros. Se pueden combinar varios métodos con orden y reglas. Definir la fuente de verdad (SIS, RRHH, SSO) y cómo se desmatricula. Configurar duración, fechas de inicio y fin, notificaciones y suspensión. La sincronización debe ser idempotente y monitoreada.

Q21. ¿Qué son los grupos y las agrupaciones?

Los grupos dividen a los estudiantes dentro de un curso para actividades, foros o tareas. Las agrupaciones agrupan varios grupos y permiten restringir el acceso a una sección o actividad a una agrupación. Los modos de grupo (sin grupos, grupos separados, grupos visibles) cambian lo que cada estudiante ve. Se pueden crear manualmente, importar o sincronizar. Usarlos para trabajo colaborativo, cohortes o diferenciación; documentar la lógica para no fragmentar el curso.

Q22. ¿Qué son las cohortes y para qué sirven?

Las cohortes son grupos a nivel de sitio que se usan para matricular o asignar roles de forma masiva. Se pueden crear manualmente, importar o sincronizar desde fuentes externas. Con cohort sync se matriculan automáticamente en cursos y se desmatriculan al salir. Son útiles para onboarding, promociones, programas y permisos por departamento. Requieren gobierno: altas y bajas automáticas, revisión y una fuente de verdad clara.

Q23. ¿Cómo funciona la finalización (completion)?

La finalización de actividad se marca manualmente o cuando se cumple una condición (ver, entregar, recibir una calificación, etc.). La finalización de curso agrega criterios: actividades completadas, calificación mínima, fecha, duración. Se usa para restringir acceso a contenidos, emitir insignias, certificados y reportes. Configurar con cuidado y probar con un usuario de prueba; si se cambia la estructura, revisar criterios. Es una herramienta pedagógica, no solo un checkbox.

Q24. ¿Qué son las insignias (badges) y cómo se gobiernan?

Las insignias reconocen logros con criterios definidos (actividad, calificación, finalización o asignación manual). Pueden ser de sitio o de curso, emitirse automáticamente y exportarse como Open Badges. Sirven para motivación y evidencias, pero deben tener valor real y criterios claros. Evitar insignias triviales o duplicadas; documentar quién las diseña y aprueba. Revisar privacidad y visibilidad del perfil.

Q25. ¿Cómo se reutilizan cursos y plantillas?

Se puede usar backup/restore (MBZ), importación de contenido, copia del curso o plantillas institucionales. Para reutilizar, restaurar sin datos de usuarios en un curso nuevo y ajustar fechas, nombres y contenidos. Las plantillas reducen trabajo y estandarizan la calidad, pero deben revisarse para no arrastrar contenido obsoleto o enlaces rotos. Versionar las plantillas y documentar los cambios. Evitar duplicar cursos a mano sin control.

Q26. ¿Qué tipos de recursos ofrece Moodle y cuándo usarlos?

Archivo (descarga o visualización), carpeta (colección), página (HTML editable), URL (enlace), libro (capítulos) y etiqueta (texto en la página del curso). Elegir según el formato y la accesibilidad: una página es mejor que un PDF para contenido breve; un libro para material estructurado; una carpeta para recursos descargables. Cuidar tamaños, nombres, licencias y formato móvil. Los recursos no generan interacción por sí solos: combinarlos con actividades.

Q27. ¿Cómo funciona la actividad de tarea (assignment)?

Permite recibir entregas (archivo, texto en línea o ambos), calificar con comentarios, rúbricas o guías, y devolver retroalimentación. Configura fechas de entrega y de cierre, intentos, extensiones, trabajo en grupo, envío ciego y flujo de calificación. Puede calificar sin conexión o anotar PDF. La configuración debe comunicar expectativas y plazos. Revisar la visibilidad de calificaciones y la política de reintentos; usar la tarea adecuada para el tipo de evidencia.

Q28. ¿Cómo se configura un cuestionario (quiz)?

Se compone de preguntas de un banco, con categorías y etiquetas. Se configuran intentos, tiempo, calificación (mayor, promedio, primero, último), comportamiento de preguntas, retroalimentación, aleatorización, revisión, contraseña, restricciones de red y Safe Exam Browser. Las preguntas aleatorias y los bancos compartidos reducen copia. Probar el cuestionario como estudiante y revisar la calificación automática. La calidad de las preguntas importa más que la configuración.

Q29. ¿Qué tipos de foro existen y cuándo usarlos?

Foro estándar (debate general), foro de preguntas y respuestas (el estudiante debe responder antes de ver respuestas), debate único simple, una discusión por persona y formato tipo blog. Se configuran suscripciones, grupos, calificaciones, bloqueo y finalización. El foro es una herramienta de interacción asíncrona; para anuncios es preferible el foro de novedades. Moderar y establecer normas de participación. Evitar foros vacíos o sin consigna clara.

Q30. ¿Qué es el taller (workshop) y cómo funciona?

Es una actividad de evaluación entre pares con fases: configuración, envío, evaluación, calificación y cierre. Los estudiantes envían trabajos, evalúan los de otros con criterios definidos y reciben una calificación por su evaluación y su trabajo. Se pueden usar ejemplos y autoevaluación. Es potente para rúbricas y feedback, pero complejo de configurar; requiere instrucciones claras y tiempos. Probar el flujo completo antes de abrirlo.

Q31. ¿Qué es la lección (lesson) y para qué sirve?

La lección permite crear rutas ramificadas: páginas de contenido, preguntas y saltos condicionales. Sirve para escenarios, simulaciones, refuerzo y aprendizaje autoguiado. Se pueden definir clusters y ramas, y calificar respuestas. Es más adecuada para decisiones que para contenido lineal. Requiere diseño instruccional y pruebas de navegación; si solo se necesita presentar contenido, usar página o libro.

Q32. ¿Qué diferencia hay entre SCORM y H5P?

SCORM es un estándar de paquetes de contenido con seguimiento (completion, score) en Moodle; es común en cursos importados y herramientas de autor. H5P permite crear contenido interactivo (vídeo interactivo, presentaciones, quizzes, arrastrar y soltar) dentro de Moodle, con seguimiento y sin empaquetar. Ambos pueden registrar intentos y calificaciones, con limitaciones. Elegir según interactividad, accesibilidad, autoría y necesidades de reporting. Probar en móvil.

Q33. ¿Qué otras actividades conviene conocer?

Consulta (choice), encuesta (feedback), base de datos, glosario, wiki, chat, herramienta externa (LTI), BigBlueButton, paquete SCORM, H5P y taller. Cada una responde a una pedagogía: encuesta para diagnóstico, glosario para construcción colectiva, wiki para colaboración, LTI para herramientas externas. No usar todas: elegir las que aporten al objetivo. Documentar la finalidad y evitar la sobrecarga cognitiva. Revisar privacidad y dependencias externas.

Q34. ¿Cómo se diseñan actividades efectivas?

Alinear cada actividad con un objetivo de aprendizaje y con la evaluación; dar instrucciones claras, criterios y plazos; usar aprendizaje activo y retroalimentación; cuidar la accesibilidad y el móvil; y evitar muros de texto. Dosificar la carga y usar scaffolding. Incluir una actividad de cierre o reflexión. Revisar el diseño con un usuario real y medir participación. La herramienta es un medio: la calidad depende del diseño pedagógico y del acompañamiento.

Q35. ¿Cómo funciona el libro de calificaciones?

El gradebook contiene ítems de calificación y categorías, con pesos y métodos de agregación. Las actividades envían sus notas a ítems; también se pueden crear ítems manuales. Incluye escalas, letras, resultados, importación y exportación, historial de cambios, anulación y ocultación. Configurar la agregación antes de cargar notas y probar con datos de ejemplo. Documentar la fórmula y comunicar dónde se ve cada nota; la transparencia reduce reclamos.

Q36. ¿Qué métodos de agregación existen y cuál elegir?

Media de notas, media ponderada, media ponderada simple, mediana, mínimo, máximo, suma y media natural, entre otros. La elección depende del diseño: una media ponderada si los pesos importan; media natural si todos los ítems valen igual; mediana para reducir el efecto de valores extremos. Revisar el tratamiento de notas vacías, el crédito extra y los ítems ocultos. Simular el resultado con un alumno antes de publicar; los errores de agregación son costosos.

Q37. ¿Qué son los resultados, escalas y competencias?

Los resultados (outcomes) describen lo que el estudiante debe lograr y se califican con una escala; las escalas son niveles personalizados (por ejemplo, insuficiente, suficiente, notable). Las competencias permiten mapear actividades a marcos y evaluar su desarrollo. Son útiles para acreditación y currículo, pero añaden complejidad. Definir pocos resultados, con descriptores claros y un plan de evaluación. Reportar y revisar con el equipo académico; no confundir con la calificación numérica.

Q38. ¿Qué son las rúbricas y las guías de evaluación?

Una rúbrica define criterios y niveles de desempeño con descriptores; una guía (marking guide) define criterios con comentarios y puntos. Se usan para calificar de forma consistente y para comunicar expectativas. Se configuran en tareas y otros módulos; pueden ser visibles antes de la entrega. Diseñar criterios observables, pocos y alineados con los objetivos; compartir ejemplos. Validar la rúbrica con el equipo y revisar la calificación final. Son clave para la equidad.

Q39. ¿Qué tipos de preguntas se usan en un cuestionario?

Opción múltiple, verdadero/falso, emparejamiento, respuesta corta, numérica, calculada, ensayo, arrastrar y soltar, cloze (rellenar huecos), descripción y aleatoria, entre otras. Se organizan en un banco de preguntas con categorías y etiquetas. Elegir según el objetivo: conocimiento, cálculo, aplicación o redacción. Cuidar la calidad, la retroalimentación y la accesibilidad; revisar la calificación automática. Usar bancos compartidos con control de versiones y evitar preguntas ambiguas.

Q40. ¿Qué ajustes de cuestionario afectan la evaluación?

Intentos permitidos, tiempo límite, método de calificación (mayor, promedio, primero, último), comportamiento de las preguntas (retroalimentación diferida, inmediata, adaptativa), orden aleatorio, opciones de revisión, contraseña, restricción por red y Safe Exam Browser. También afectan las anulaciones por usuario o grupo y la fecha de apertura y cierre. Configurar según el propósito y comunicar las reglas. Probar el flujo completo, incluyendo la revisión posterior.

Q41. ¿Cómo se califica y se da retroalimentación?

Depende de la actividad: calificación automática en cuestionarios objetivos, calificación manual en tareas y ensayos, rúbricas o guías, comentarios generales y por criterio, anotaciones en PDF y flujo de revisión. Se puede ocultar la nota hasta liberar la retroalimentación, usar envío ciego y moderación. La retroalimentación debe ser oportuna, específica y accionable. Configurar notificaciones y plazos; revisar que el estudiante vea lo que corresponde.

Q42. ¿Cómo se aborda la integridad académica?

Combinar diseño de evaluación (preguntas de aplicación, bancos amplios, tareas auténticas), aleatorización, límites de tiempo, Safe Exam Browser, supervisión y herramientas de similitud o proctoring cuando estén aprobadas. Revisar logs y patrones, pero evitar vigilancia invasiva o sesgos. La tecnología no garantiza honestidad: la cultura, las expectativas y el diseño importan. Documentar las reglas y el tratamiento de incidentes, con privacidad y debido proceso.

Q43. ¿Qué reportes y analítica de evaluación ofrece Moodle?

Exportación del libro de calificaciones, informes de finalización, participación, actividad y logs; estadísticas por actividad y por pregunta; y modelos de analítica del aprendizaje. Se complementan con dashboards externos vía base de datos o API. Definir indicadores útiles (aprobación, abandono, tiempo, brechas) y actuar sobre ellos. Cuidar la privacidad y el sesgo; no usar la analítica para etiquetar sin contexto. La analítica debe mejorar la enseñanza, no solo medir.

Q44. ¿Qué métodos de autenticación soporta Moodle?

Manual, auto-registro por correo, LDAP, SAML2, OAuth2, CAS y base de datos externa, además de plugins. Para instituciones se recomienda SSO (SAML2 u OAuth2) con el IdP corporativo y aprovisionamiento coherente. Se pueden combinar métodos, pero conviene una fuente de verdad. Configurar mapeo de atributos, MFA en el IdP, desactivación de cuentas y revisión de cuentas de servicio. Probar login, logout, expiración y recuperación antes de habilitarlo masivamente.

Q45. ¿Cómo funcionan los permisos y las capabilities?

Cada acción está protegida por una capability; los roles la permiten, prohíben o dejan sin definir en un contexto. La herencia y las anulaciones determinan el permiso efectivo. Se puede asignar un rol a un usuario en sistema, categoría, curso, módulo o bloque. Probar con la cuenta real y usar el informe de permisos. Aplicar mínimo privilegio: no dar editingteacher o manager a quien no lo necesita. Documentar roles personalizados y revisarlos periódicamente.

Q46. ¿Cómo se integra la matrícula con sistemas externos?

Mediante plugins de matrícula (base de datos externa, LDAP, archivo plano, cohort sync, LTI) o la API. El sistema de origen (SIS, RRHH) debe ser la fuente de verdad: altas, bajas y cambios se sincronizan, con idempotencia y logs. Definir la frecuencia, el manejo de errores y el desmatriculamiento. Evitar duplicados y matrículas manuales paralelas. Probar con datos reales y monitorear la sincronización; documentar el mapeo de campos y roles.

Q47. ¿Qué son las cohortes y cómo se usan para matricular?

Las cohortes agrupan usuarios a nivel de sitio y se sincronizan a cursos con cohort sync. Al agregar o quitar un usuario de la cohorte, la matrícula se actualiza. Son útiles para programas, departamentos, promociones e incorporación. Se pueden cargar por CSV o sincronizar desde un sistema externo. Requieren una fuente de verdad y revisión; una cohorte mal mantenida genera accesos indebidos o pérdida de acceso. Documentar su propósito y owner.

Q48. ¿Cómo se gestionan los usuarios?

Alta manual, carga CSV, aprovisionamiento por SSO o API. Se pueden editar perfiles, campos personalizados, preferencias, suspender o eliminar cuentas. Suspender conserva datos y bloquea el acceso; eliminar borra según la política de privacidad. Evitar cuentas duplicadas y compartidas; usar nombres únicos y correo institucional. Revisar cuentas inactivas, roles y permisos. La gestión debe alinearse con RRHH y con el ciclo de vida del usuario (alta, cambio, baja).

Q49. ¿Cómo funciona el acceso de invitado y el acceso público?

Se puede permitir acceso de invitado a un curso con o sin clave, y habilitar la auto-matriculación. El rol guest tiene permisos limitados y no suele poder entregar actividades. Es útil para catálogos o contenidos abiertos, pero riesgoso para datos sensibles. Revisar la visibilidad del curso, las restricciones y la política de privacidad. Evitar que el acceso de invitado permita ver participantes o calificaciones. Documentar y monitorear; deshabilitarlo si no es necesario.

Q50. ¿Qué es LTI y cómo se usa en Moodle?

LTI (Learning Tools Interoperability) permite integrar herramientas externas. Moodle puede ser consumidor (actividad External tool) o proveedor (publicar cursos o actividades LTI). LTI 1.3 con Deep Linking es el estándar recomendado; incluye autenticación, roles y devolución de calificaciones. Se configura con claves y endpoints, y se prueba con el proveedor. Revisar privacidad y dependencia del proveedor; documentar la integración y los datos que se comparten.

Q51. ¿Cómo se cumple con privacidad y GDPR en Moodle?

Moodle incluye la Privacy API y herramientas de solicitudes de datos, retención y políticas. Configurar avisos de privacidad, consentimiento, plazos de conservación y procesos de exportación o eliminación. Revisar plugins de terceros y proveedores (DPA), minimización de datos, acceso y cifrado. Los logs y backups también contienen datos personales. Documentar el registro de actividades de tratamiento y el contacto del DPO. La privacidad se diseña, no se añade al final.

Q52. ¿Cómo se gobierna el ciclo de vida de accesos?

Definir alta, cambio y baja (joiner, mover, leaver) con RRHH y el IdP; roles por función; revisiones periódicas; cuentas admin nominativas con MFA; separación de funciones; registro de auditoría; procedimiento de emergencia. Evitar cuentas compartidas y privilegios permanentes. Automatizar la suspensión al salir y transferir la propiedad de cursos. Documentar la matriz de accesos y probar con auditorías. El gobierno de identidades es parte de la seguridad del LMS.

Q53. ¿Cuáles son las buenas prácticas de seguridad para Moodle?

HTTPS en todo el sitio, contraseñas fuertes y MFA, mínimo privilegio, actualizaciones de core y plugins, backups probados, permisos de archivos correctos, dataroot fuera del webroot, base de datos separada y con permisos acotados, WAF y monitoreo de logs. Deshabilitar funciones que no se usan y revisar el informe de seguridad del sitio. Vetting de plugins y gestión de secretos. La seguridad es un proceso continuo: parchear, revisar accesos, detectar y responder.

Q54. ¿Cómo se endurece (hardening) una instalación de Moodle?

Proteger config.php y el dataroot; bloquear listados de directorios y acceso directo a archivos sensibles; cookies seguras y httponly; proxy inverso bien configurado; sesiones en Redis; usuario de base de datos con permisos mínimos; deshabilitar depuración en producción; limitar admin; cuentas nominativas y MFA. Revisar el informe de seguridad y los chequeos del entorno. Automatizar con configuración como código y escaneos. Documentar excepciones y revisarlas.

Q55. ¿Qué controles de privacidad y protección de datos se aplican?

Minimización de datos, base legal y avisos de privacidad, consentimiento cuando corresponde, plazos de retención, acceso restringido, cifrado en tránsito y en reposo, exportación y eliminación de datos, y contratos con proveedores. Revisar logs y backups, anonimizar datos para pruebas y limitar la analítica. Moodle ofrece herramientas de privacidad y solicitudes de datos. Documentar el registro de tratamientos, el DPO y el proceso de incidentes. Cumplir GDPR, CCPA u otras normas aplicables.

Q56. ¿Cómo se garantiza la accesibilidad?

Aplicar WCAG 2.1/2.2 AA: contenido semántico, texto alternativo, contraste, navegación por teclado, subtítulos y transcripciones, no depender solo del color, formularios etiquetados y contenido responsive. Elegir temas accesibles y probar con lector de pantalla y usuarios reales. Revisar documentos PDF y H5P; ofrecer formatos alternativos. La accesibilidad es requisito legal en muchos contextos y mejora la experiencia de todos. Incluir criterios de accesibilidad en la revisión de calidad del curso.

Q57. ¿Qué considerar para el acceso móvil y la experiencia de usuario?

Usar un tema responsive y probar en la app oficial de Moodle; contenido breve, imágenes optimizadas, vídeos con subtítulos y navegación clara. Configurar los web services móviles y las notificaciones; revisar el comportamiento offline y los enlaces externos. La app tiene limitaciones frente a la web; validar las actividades críticas. La experiencia móvil importa porque muchos estudiantes acceden solo desde el teléfono. Medir y simplificar.

Q58. ¿Cómo se registran y auditan los eventos?

Los log stores (estándar o base de datos) registran accesos, visualizaciones, envíos, calificaciones y acciones administrativas. Los informes permiten filtrar por usuario, curso, actividad y fecha. Para seguridad se revisan inicios de sesión fallidos, cambios de permisos y exportaciones. Definir retención, proteger los logs y, si es necesario, enviarlos a un SIEM. La auditoría debe cumplir privacidad y servir para investigar incidentes. No recolectar más de lo necesario.

Q59. ¿Cómo se diseña una estrategia de backup y recuperación?

Regla 3-2-1: tres copias, dos medios, una fuera del sitio. Respaldar base de datos, dataroot y config.php de forma consistente; cifrar y restringir el acceso. Definir RPO y RTO, automatizar, monitorear y probar restauraciones periódicamente. Considerar la compatibilidad de versión y los plugins. Los backups también son datos personales: aplicar retención y protección. Documentar el runbook de recuperación y asignar responsables. Un backup no probado es una falsa sensación de seguridad.

Q60. ¿Qué riesgos existen con archivos y contenido subido?

Archivos maliciosos, XSS en contenido HTML, enlaces a sitios no confiables, filtraciones por permisos incorrectos y almacenamiento sin límites. Configurar tipos de archivo permitidos, tamaño máximo, antivirus/escaneo, filtros de HTML y permisos del dataroot. Revisar plugins que muestran contenido externo. Capacitar a los docentes y monitorear. No confiar en la extensión del archivo; validar el contenido. Aplicar cuarentena y procedimientos de limpieza ante incidentes.

Q61. ¿Cómo se demuestra cumplimiento y se prepara una auditoría?

Mantener políticas, matriz de roles, registro de tratamientos, inventario de plugins y proveedores, evidencias de backups y restauraciones, logs, planes de formación y pruebas de accesibilidad. Definir controles y responsables; revisar accesos y cambios. Documentar incidentes y respuestas. Alinear con ISO 27001, SOC 2, GDPR o normativa educativa según aplique. La auditoría se facilita con evidencia continua, no con documentos improvisados. Revisar y actualizar el marco cada año.

Q62. ¿Cómo se mejora el rendimiento de Moodle?

Usar cachés (MUC) con stores adecuados (Redis o Memcached), OPcache, PHP-FPM, un tema ligero y purgar cachés tras cambios. Activar la caché de JavaScript, evitar el modo de diseño de temas en producción y revisar el informe de rendimiento. Optimizar la base de datos y las consultas; separar servicios. Medir una línea base y comparar. No optimizar a ciegas: identificar el cuello de botella (PHP, base de datos, disco, red) antes de cambiar configuraciones.

Q63. ¿Cómo se operan el cron y las tareas programadas a escala?

Ejecutar cron cada minuto con un usuario dedicado, sin solapamientos y con logs. Revisar tareas fallidas o lentas, tareas adhoc y picos de correo o backups. Separar tareas pesadas y ajustar límites de tiempo y memoria. Monitorizar la cola y alertar si crece. En alta disponibilidad, asegurar que solo una instancia ejecute cada tarea o usar bloqueos. Documentar las tareas críticas y su impacto; probar cambios en staging. El cron es el corazón operativo de Moodle.

Q64. ¿Qué arquitectura de infraestructura soporta carga alta?

Web tier con PHP-FPM y Nginx/Apache, base de datos gestionada y ajustada, Redis para sesiones y caché, almacenamiento compartido o S3 para el dataroot, CDN para estáticos y balanceador. Las sesiones deben ser compartidas para evitar pérdidas al cambiar de nodo. Monitorizar y escalar horizontalmente; definir límites y pruebas de carga. La base de datos suele ser el cuello de botella: indexar, revisar consultas y separar servicios. Documentar la topología y los puntos únicos de fallo.

Q65. ¿Cómo se gestiona el almacenamiento de archivos?

El dataroot puede estar en disco local, NFS o almacenamiento de objetos (S3) mediante plugins. Debe ser compartido si hay varios nodos, con permisos correctos y backup. Considerar cuotas, ciclo de vida, cifrado, antivirus y limpieza de archivos huérfanos. Migrar el almacenamiento requiere planificación y pruebas de rendimiento. Medir latencia y costo de egreso. Proteger el acceso directo y auditar. La consistencia entre base de datos y archivos es crítica para la restauración.

Q66. ¿Cómo se manejan sesiones y autenticación a escala?

Configurar un session handler compartido (Redis) para que cualquier nodo valide la sesión; ajustar cookies seguras y tiempo de vida; usar SSO para reducir credenciales locales; aplicar MFA y límites de intentos. Un balanceador sin sesiones compartidas provoca cierres de sesión y errores. Revisar logout, expiración y concurrencia. Monitorizar sesiones y errores de autenticación. Documentar la configuración y probar con varios nodos; la experiencia de login debe ser estable.

Q67. ¿Qué monitorear y alertar en producción?

Disponibilidad y latencia del sitio, errores de PHP y del servidor web, conexiones y consultas lentas de la base de datos, uso de CPU/memoria/disco, ejecución de cron y tareas fallidas, colas de correo, certificados TLS, backups y espacio del dataroot. Configurar alertas con umbrales y dashboards; revisar logs de seguridad. Definir on-call, runbooks y escalado. Monitorear la experiencia real (login, curso, quiz) además de la infraestructura. La observabilidad permite anticipar incidentes en picos de exámenes.

Q68. ¿Cómo se escala Moodle para picos de exámenes?

Planificar con pruebas de carga (k6, JMeter), dimensionar base de datos y PHP-FPM, usar caché y sesiones compartidas, distribuir estáticos por CDN y escalar horizontalmente. Evitar tareas pesadas durante el pico; programar backups y cron intensivo fuera de horario. Revisar límites de conexiones y timeouts. Preparar un plan de contingencia y comunicación. Medir después del evento y ajustar. La capacidad debe validarse con el patrón real de uso, no solo con números de usuarios.

Q69. ¿Cómo se gestionan releases, mantenimiento y cambios?

Definir una cadencia de actualizaciones (seguridad y menores) y ventanas de mantenimiento; probar en staging; comunicar a los usuarios; hacer backup y plan de rollback. Usar control de cambios para plugins, temas y configuración. Revisar el ciclo de vida y el fin de soporte de la versión. Automatizar despliegues y validaciones. Documentar runbooks e incidentes. No acumular actualizaciones durante años: los saltos grandes son más riesgosos. La gestión de releases es parte de la confiabilidad.

Q70. ¿Cómo funcionan los web services de Moodle?

Se habilitan en administración, se elige el protocolo (REST o SOAP), se crea un servicio y se autorizan funciones. Los clientes se autentican con un token asociado a un usuario y a un servicio; los permisos dependen de las capabilities de ese usuario. La app móvil usa el servicio moodle_mobile_app. Exponer solo las funciones necesarias, con cuentas de servicio de mínimo privilegio, HTTPS y monitoreo. Documentar endpoints, límites y manejo de errores. No usar tokens de admin para integraciones.

Q71. ¿Cómo se consume la API REST desde una aplicación externa?

Se envía una petición a /webservice/rest/server.php con wstoken, wsfunction y parámetros; la respuesta es JSON o XML. Se puede usar Postman para explorar y un SDK o cliente HTTP en la aplicación. Manejar errores, timeouts, paginación y reintentos; validar permisos y datos. Versionar la integración y registrar llamadas. Evitar llamadas masivas sin control; usar tareas asíncronas o procesos batch. La API es potente, pero no sustituye un buen diseño de integración.

Q72. ¿Qué estándares de interoperabilidad conviene conocer?

LTI 1.3 para integración de herramientas y devolución de calificaciones; SCORM para paquetes de contenido; H5P para contenido interactivo; xAPI (mediante plugins) para experiencias de aprendizaje; Common Cartridge para importar contenido; y Open Badges para credenciales. Cada estándar resuelve un problema distinto; elegir el que el proveedor soporte y probar el flujo completo. Documentar privacidad y datos compartidos. La interoperabilidad reduce el lock-in, pero añade configuración y dependencias.

Q73. ¿Cómo se implementa SSO con SAML u OAuth2?

Se configura el plugin de autenticación con los metadatos del IdP, el entity ID, los certificados y el mapeo de atributos (usuario, correo, nombre, grupos). Se prueba login, logout, expiración y aprovisionamiento; se define qué hacer con cuentas existentes y con el desaprovisionamiento. Rotar certificados antes de que expiren. El SSO no reemplaza la autorización: los roles y matrículas siguen gestionándose en Moodle o en el sistema de origen. Documentar y monitorear errores de autenticación.

Q74. ¿Cómo se habilita y configura la app móvil?

Activar los web services móviles, configurar la app (nombre, logo, colores, idioma), habilitar notificaciones y SSO, y probar en iOS y Android. La app ofrece acceso a cursos, actividades, mensajes y offline limitado; algunas actividades o plugins no funcionan igual que en la web. Revisar la política de privacidad y el soporte. Comunicar a los usuarios y monitorear errores. La app es un canal adicional, no un reemplazo de la experiencia web; validar las actividades críticas.

Q75. ¿Cómo se desarrolla un plugin de Moodle?

Elegir el tipo (local, actividad, bloque, tema, auth, etc.) y crear la estructura con version.php, lang/en, clases, db/install.xml, db/access.php, upgrade.php y, si aplica, privacy/provider.php. Usar la API de Moodle (output, forms, DML, capabilities, tareas) y las convenciones de código; incluir tests. Evitar modificar el core. Documentar la instalación y el soporte. Probar en staging con datos reales y revisar seguridad/privacidad. Para personalizaciones pequeñas, un plugin local suele ser más sostenible que un parche.

Q76. ¿Cómo se personaliza el tema y la interfaz?

Usar un tema basado en Boost y, preferiblemente, un tema hijo para no modificar el original. Personalizar SCSS, logotipos, colores, navegación y textos de idioma; revisar accesibilidad y responsive. Evitar cambios directos en el core o en temas de terceros que se pierdan al actualizar. Probar en staging y validar contraste, teclado y lectores de pantalla. Documentar la personalización y su compatibilidad con la versión. La marca no debe sacrificar usabilidad ni accesibilidad.

Q77. ¿Qué integraciones externas suelen implementarse?

SIS/RRHH para altas y matrículas, SSO con el IdP, proveedores de contenido (LTI/SCORM/H5P), videoconferencia (BigBlueButton, Zoom, Teams), similitud/proctoring, analítica y CRM. También API/web services para aplicaciones propias. Definir el sistema de origen, el mapeo de datos, la idempotencia y el monitoreo; usar middleware cuando reduzca acoplamiento. Documentar contratos y responsables. Probar altas, bajas y errores. Evitar integraciones punto a punto sin gobierno; la complejidad se acumula.

Q78. ¿Cómo se migra desde otro LMS a Moodle?

Inventariar cursos, usuarios, matrículas, calificaciones, finalización e integraciones; definir el mapeo y las prioridades; exportar/importar contenido (Common Cartridge, SCORM, backups) y reconstruir lo que no se migra automáticamente. Ejecutar un piloto, validar con usuarios, capacitar y migrar por olas. Planificar privacidad, retención y comunicación. No trasladar deuda pedagógica: aprovechar para limpiar y estandarizar. Medir calidad y adopción; tener plan de contingencia.

Q79. ¿Cómo se importa contenido y se valida?

Mediante backup/restore (MBZ), importación de curso, Common Cartridge, SCORM o H5P. Revisar enlaces, archivos, fechas, finalización, calificaciones, permisos y licencias; probar como estudiante. Los backups entre versiones pueden requerir conversión; restaurar sin datos de usuarios cuando corresponda. Limpiar contenido duplicado u obsoleto y documentar el origen. Validar accesibilidad y móvil. La importación técnica es solo el inicio: la calidad pedagógica debe revisarse después.

Q80. ¿Qué principios de diseño instruccional aplicar?

Diseño inverso: objetivos de aprendizaje, evidencias y actividades alineadas. Chunking, aprendizaje activo, práctica con retroalimentación, UDL (múltiples formas de representación y expresión), consistencia visual y navegación. Evaluar con rúbricas y ofrecer oportunidades de mejora. Diseñar para móvil y accesibilidad. Usar plantillas y QA. La tecnología debe reducir fricción, no añadir carga cognitiva. Validar con estudiantes reales y iterar; el diseño es un ciclo.

Q81. ¿Cómo se impulsa la adopción y la capacitación?

Plan de cambio con patrocinio, formación de docentes y estudiantes, documentación, plantillas, horas de consulta, comunidad de prácticas y soporte. Identificar campeones y casos de éxito; recoger feedback y ajustar. Medir adopción, satisfacción y resultados de aprendizaje, no solo logins. Comunicar beneficios y responder rápido a incidentes. La adopción no termina en el lanzamiento: requiere acompañamiento continuo y mejoras. Un LMS vacío no transforma la enseñanza.

Q82. ¿Cómo se gobierna el ciclo de vida de cursos y plugins?

Definir solicitud, aprobación, plantilla, revisión de calidad, publicación, archivo y eliminación; naming y owner; accesos por rol; política de plugins (aprobados, vetting, actualización, retirada) y de upgrades. Coordinar con privacidad, accesibilidad y seguridad. Documentar RACI y SLA de soporte. Revisar cursos inactivos y contenido obsoleto. Un gobierno liviano pero claro evita caos y deuda técnica; debe facilitar el trabajo, no burocratizarlo.

Q83. ¿Qué KPIs y analítica usar para evaluar la plataforma?

Finalización, participación, calificaciones, tiempo en actividad, entregas, satisfacción, retención, tickets de soporte, disponibilidad y rendimiento. Segmentar por curso, cohorte y rol; cuidar la privacidad y evitar métricas vanidosas. Usar dashboards y revisiones periódicas; convertir hallazgos en acciones. La analítica debe informar decisiones pedagógicas y operativas, no solo reportar. Definir una línea base y medir el impacto de los cambios. Documentar definiciones para que los números sean comparables.

Q84. ¿Cómo se diagnostican los problemas típicos?

Revisar logs de PHP, servidor web y Moodle; activar depuración solo en staging; comprobar cron y tareas fallidas; verificar permisos del dataroot y config.php; validar versión de plugins y compatibilidad; purgar cachés; revisar sesiones y SSO. Para base de datos, usar los chequeos y logs del motor. Reproducir en staging, cambiar una cosa a la vez y documentar. Los problemas comunes incluyen cron caído, permisos, caché, plugins incompatibles, correo y límites de subida. Tener runbooks acelera la resolución.

Q85. ¿Qué checklist de producción y buenas prácticas recomiendas?

HTTPS, MFA, mínimo privilegio, SSO, backups probados, staging, actualizaciones y plugins aprobados, cron monitoreado, caché y sesiones compartidas, almacenamiento protegido, monitoreo y alertas, retención y privacidad, accesibilidad, plantillas y documentación, plan de incidentes y capacidad probada. Antes de un lanzamiento: revisar permisos, probar cursos y actividades críticas, validar correo y notificaciones, y comunicar. Medir adopción y rendimiento, y revisar periódicamente. La excelencia operativa es continua: el LMS debe ser seguro, accesible, rápido y confiable.