En este post quiero compartir una guía basada en mi experiencia preparando y aprobando la certificación CJCA de Hack The Box.

A lo largo del post voy a hablar sobre mi preparación, la importancia de practicar con una metodología clara, el peso que tiene la documentación, el componente de análisis defensivo de la certificación y algunos errores que conviene evitar antes y durante el examen.

---

Mi opinión general sobre la certificación

En mi opinión, CJCA es un muy buen punto de partida para quienes quieren comenzar a desarrollar una visión más completa de la ciberseguridad, porque mezcla dos mundos que muchas veces se estudian por separado: Red Team y Blue Team.

Desde la perspectiva ofensiva, exige enumerar servicios, identificar vulnerabilidades, obtener acceso y escalar privilegios. Desde la perspectiva defensiva, plantea el análisis de evidencias, logs y alertas para interpretar actividad sospechosa y justificar conclusiones.

La evaluación tampoco se presenta únicamente como una colección de retos aislados. Su enfoque se acerca más a un escenario práctico en el que debemos comprender el contexto, distinguir la información relevante del ruido y relacionar los hallazgos entre sí.

Por esa razón, considero que CJCA evalúa más que conocimientos técnicos o el uso de herramientas. También pone a prueba el criterio, la capacidad de análisis y la forma en que comunicamos nuestros hallazgos.

---

¿Cómo prepararse para la certificación?

Una de las preguntas más comunes antes de presentar CJCA es si el path de preparación de Hack The Box es suficiente para aprobar la certificación.

Hack The Box solicita completar su path de preparación y, en mi opinión, este ofrece una base muy sólida. El contenido comienza con conceptos fundamentales y avanza progresivamente hacia temas prácticos como redes, Linux, Windows, enumeración, explotación, WordPress, uso de herramientas y análisis de evidencias.

Sin embargo, completar el contenido no debería ser el único objetivo. El path nos enseña conceptos y técnicas, pero somos nosotros quienes debemos convertir ese conocimiento en una metodología de trabajo que podamos aplicar ante escenarios diferentes.

¿A qué me refiero con metodología?

Una metodología es una forma estructurada de enfrentarnos a un entorno: una serie de pasos lógicos que nos ayuda a saber qué revisar, qué preguntas formular, cómo interpretar los resultados y qué decisión tomar a continuación. No es una receta inamovible ni una lista de comandos; es un proceso que podemos adaptar a la información que vamos descubriendo.

Imaginemos que encontramos un servicio web que nunca habíamos visto. Sin una metodología, podríamos comenzar a ejecutar herramientas o probar vulnerabilidades al azar. Con una metodología, en cambio, sabemos cómo construir una ruta de investigación aunque la tecnología sea desconocida.

Podríamos comenzar con preguntas como estas:

• ¿Qué tecnología utiliza el servicio y qué versión está ejecutando?
• ¿Qué información revelan los encabezados, las cookies, el código fuente o los mensajes de error?
• ¿Existen subdirectorios, archivos, endpoints o virtual hosts que todavía no hemos identificado?
• ¿La aplicación expone nombres de usuario, roles o mecanismos de autenticación?
• ¿La documentación oficial menciona configuraciones predeterminadas o comportamientos relevantes?
• ¿Existen vulnerabilidades conocidas para esa versión y realmente se cumplen sus condiciones?

Las respuestas generan nuevas hipótesis y determinan el siguiente paso. Si identificamos una versión, investigamos su documentación y vulnerabilidades conocidas. Si encontramos un panel de autenticación, buscamos usuarios, credenciales expuestas o configuraciones predeterminadas. Si descubrimos un directorio o endpoint nuevo, analizamos su función y la información que revela. De esta forma dejamos de actuar al azar y comenzamos a tomar decisiones basadas en evidencia.

Esta misma lógica se extiende al resto del entorno. Durante la explotación debemos comprobar que una vulnerabilidad realmente aplica; en la post-explotación necesitamos analizar permisos, información sensible y posibilidades de ampliar el acceso; y durante todo el proceso debemos documentar los hallazgos y relacionarlos entre sí.

Por eso recomiendo complementar el path con máquinas Easy de Hack The Box, tanto Linux como Windows, o con laboratorios similares. Su valor no reside únicamente en aprender una técnica nueva, sino en exponernos a distintos servicios, tecnologías y errores para practicar una y otra vez ese proceso lógico. Cuantos más escenarios resolvemos, más natural se vuelve formular preguntas, interpretar resultados y adaptar nuestros siguientes pasos.

Al principio, la metodología puede sentirse como una lista rígida: escanear puertos, enumerar servicios, investigar tecnologías, validar vulnerabilidades, revisar permisos y documentar hallazgos. Con la práctica, deja de ser una lista que debemos recordar y se convierte en una forma natural de investigar.

Al final, prepararse para la CJCA no se trata de memorizar comandos o respuestas, sino de aprender a investigar, correlacionar información y construir una forma ordenada de resolver problemas.

---

Máquinas recomendadas para practicar

Las siguientes máquinas pueden servir como punto de partida para llevar a la práctica los conceptos del path. No las recomiendo porque reproduzcan el examen ni porque compartan necesariamente sus vectores de ataque, sino porque presentan escenarios accesibles en los que podemos poner a prueba nuestro proceso de análisis.

Linux	Windows
Lame	Return
Broker	Legacy
Cap	Blue
Keeper	Devel
Blocky	Optimum
Backdoor	Bastion
Base
Postman
Busqueda
CodePartTwo
Editorial

Mi recomendación es intentar resolver cada máquina por cuenta propia y llevar un registro de lo que vamos probando. Antes de buscar ayuda conviene revisar nuestros resultados, investigar las tecnologías identificadas, plantear nuevas hipótesis y asegurarnos de haber agotado las líneas razonables de análisis. La intención es llegar a nuestro límite real, no abandonar ante el primer bloqueo.

Consultar un video, un writeup o una guía después de ese esfuerzo no es algo malo. De hecho, puede convertirse en una de las mejores formas de mejorar nuestra metodología si lo hacemos con el objetivo correcto. No deberíamos buscar simplemente el comando que resuelve la máquina, sino identificar por qué nuestro proceso no nos llevó hasta ese punto.

Al comparar nuestra ruta con la solución, podemos hacernos preguntas como estas:

• ¿Qué información estaba disponible y no tomamos en cuenta?
• ¿Qué servicio o funcionalidad no enumeramos con suficiente profundidad?
• ¿Formulamos una hipótesis incorrecta o interpretamos mal algún resultado?
• ¿Existía otra técnica para enumerar ese servicio que no conocíamos?
• ¿Nos faltaba conocimiento técnico o simplemente omitimos un paso de nuestro proceso?

La respuesta nos indica qué debemos reforzar. Si descubrimos una nueva forma de enumerar un servicio, la documentamos y la incorporamos a nuestras notas. Si omitimos una evidencia importante, revisamos por qué no la reconocimos. Si el problema era un concepto que desconocíamos, regresamos a estudiarlo y luego intentamos reproducir la solución sin depender de la guía. Así, el writeup deja de ser una fuente de respuestas y se convierte en una herramienta de retroalimentación.

El catálogo de máquinas Easy en Hack The Box, tanto Linux como Windows, es bastante amplio. Sin embargo, considero importante no salirse demasiado del alcance del path de preparación.

Por ejemplo, si el path no profundiza en Active Directory, dedicar una parte considerable de la preparación a entornos de AD no debería ser una prioridad específica para CJCA. Ese aprendizaje puede ser valioso para nuestro crecimiento general, pero conviene priorizar primero los temas y habilidades que sí forman parte del alcance de la certificación.

Esta lista tampoco es definitiva. Podemos practicar con otras máquinas y laboratorios siempre que lo hagamos con intención, analicemos nuestros errores y utilicemos cada bloqueo para fortalecer nuestro proceso de trabajo.

---

Temas clave que conviene reforzar

Permisos en Linux

Además de practicar máquinas, también recomiendo reforzar algunos conceptos que suelen aparecer de forma práctica durante la preparación. Uno de ellos es entender bien los permisos en Linux, especialmente cuando trabajamos con archivos y directorios.

A veces no basta con saber que un archivo existe. También necesitamos entender qué permisos tenemos sobre cada parte de la ruta. En Linux, los permisos no funcionan igual para archivos que para directorios. Por ejemplo, en un directorio, el permiso de lectura permite listar su contenido, pero el permiso de ejecución permite atravesarlo si conocemos el nombre exacto del archivo o subdirectorio.

Esto es importante porque, en ciertos escenarios, podríamos no poder listar un directorio con ls, pero sí acceder a un archivo si conocemos la ruta completa y tenemos los permisos necesarios para atravesar los directorios anteriores.

Permiso en directorio	Qué permite
r lectura	Permite ver los nombres dentro del directorio, siempre que también existan los permisos necesarios para acceder.
w escritura	Permite crear, borrar o renombrar archivos dentro del directorio, normalmente junto con x.
x ejecución	Permite atravesar el directorio y acceder a elementos internos si se conoce su nombre exacto.

Por eso, durante la enumeración no solo debemos preguntarnos “qué archivos existen”, sino también “qué rutas conocemos”, “qué permisos tenemos sobre cada directorio” y “qué información podríamos leer si encontramos una ruta válida”.

Este tipo de detalle ayuda mucho a construir metodología. No se trata de memorizar una ruta específica ni una técnica aislada, sino de entender cómo razona el sistema operativo y cómo podemos validar nuestras hipótesis de forma ordenada. En un examen práctico, esa diferencia puede ser clave: muchas veces el avance no viene de lanzar más herramientas, sino de interpretar correctamente permisos, rutas, usuarios, grupos y archivos accesibles.

El momento de la post-explotación

La post-explotación no consiste únicamente en obtener una flag. También implica identificar qué otros elementos del sistema pueden ser útiles o relevantes para la prueba de penetración. Debemos recordar que no nos enfrentamos a máquinas aisladas, sino a una simulación de una evaluación de seguridad dentro de una empresa.

Este cambio de mentalidad es clave porque nos obliga a mirar más allá de una flag de usuario o de root. Imagina que obtienes acceso a un equipo externo durante una prueba de penetración real: no buscarías una flag, sino credenciales almacenadas, archivos con información sensible, registros del sistema o cualquier otro elemento que pueda facilitar el acceso a nuevos servicios y sistemas. En una evaluación real no existen las flags; existen hallazgos, evidencias y posibles rutas para ampliar el acceso.

Una forma práctica de orientar la búsqueda es filtrar archivos por extensiones que suelen estar asociadas con información sensible.

Extensiones interesantes

Extensión	Qué puede contener
.db	Bases de datos SQLite, datos de aplicaciones web y usuarios.
.sqlite / .sqlite3	Usuarios, hashes, sesiones y tokens.
.sql	Volcados de MySQL o MariaDB y posibles credenciales.
.bak	Respaldos de bases de datos y archivos de configuración.
.dump	Exportaciones de PostgreSQL u otras bases de datos.
.mdb	Bases de datos de Microsoft Access.
.kdbx	Bases de datos de KeePass.
.json	Claves de API, tokens y datos de configuración.
.env	Contraseñas, tokens y otros secretos de aplicaciones.
.yml / .yaml	Configuraciones y credenciales de Docker, servicios y aplicaciones.
.ini / .conf	Configuraciones y posibles credenciales de servicios.
.properties	Configuraciones y contraseñas de aplicaciones Java.
.p12 / .pfx	Certificados digitales y claves privadas.

Comprender qué representa cada una de estas extensiones abre nuevas posibilidades durante la post-explotación. No se trata de asumir que todo archivo será útil, sino de reconocer cuáles merecen una revisión más detallada y analizar su contenido dentro del contexto del entorno.

La enumeración automatizada nunca sustituye a una revisión manual bien ejecutada. Sin embargo, por distintos factores podemos pasar por alto algún archivo o directorio. En esos casos, realizar una segunda pasada con una herramienta de enumeración puede ayudarnos a validar lo revisado y a detectar elementos que no identificamos inicialmente.

Para esta tarea recomiendo Credential Hunting, utilizando su modo clean: Credential Hunting en GitHub

Se trata de un fork en el que he trabajado y que actualizo constantemente. Su objetivo es facilitar la búsqueda de archivos interesantes que pudieron pasar inadvertidos durante la enumeración manual, o realizar una revisión rápida cuando necesitamos priorizar posibles fuentes de credenciales.

Post-explotación con herramientas de enumeración

Mientras que la búsqueda de archivos interesantes nos ayuda a localizar credenciales e información sensible, las herramientas de enumeración automatizada ofrecen una perspectiva diferente: permiten obtener una visión más amplia del sistema y relacionar configuraciones que, revisadas de forma aislada, podrían parecer poco relevantes.

Estas herramientas pueden revisar en pocos minutos usuarios, grupos, permisos, procesos, servicios, tareas programadas, variables de entorno, configuraciones y otros elementos asociados con posibles vectores de escalada de privilegios. Una de las más conocidas es PEASS-ng, que incluye scripts como linpeas y winpeas para apoyar la enumeración en Linux y Windows.

Puedes revisar el proyecto aquí: PEASS-ng en GitHub

Su principal valor no consiste únicamente en encontrar más información, sino en presentar el entorno desde otro punto de vista. Por ejemplo, una herramienta puede destacar la relación entre un servicio ejecutado con privilegios elevados, un archivo de configuración modificable y una ruta controlada por nuestro usuario. Cada elemento por separado podría pasar inadvertido, pero en conjunto puede revelar una oportunidad de escalada.

Esto no significa que debamos ejecutar la herramienta y seguir cada resultado de forma automática. La salida debe utilizarse como una fuente de hipótesis: primero identificamos los hallazgos que parecen relevantes, luego los validamos manualmente y, por último, determinamos si realmente representan un vector aprovechable dentro del contexto del sistema.

Practicar con PEASS-ng también ayuda a reconocer patrones comunes y a comprender qué busca una enumeración completa. Con el tiempo, esos patrones fortalecen nuestra metodología manual y nos permiten interpretar con mayor criterio tanto lo que la herramienta destaca como aquello que podría haber omitido.

---

¿Y qué hay de la parte Blue Team?

En mi caso, debo ser honesto: fuera del contenido incluido en el path de preparación, no realicé demasiada práctica adicional enfocada específicamente en Blue Team.

Sin embargo, si sientes que esta es tu área más débil, o simplemente quieres llegar con más confianza, los Sherlocks de Hack The Box o laboratorios similares pueden ayudarte bastante. Este tipo de retos está enfocado en análisis de evidencias, investigación de incidentes, correlación de eventos y construcción de conclusiones a partir de logs.

Esto es importante porque en la parte Blue Team no basta con ver una alerta y marcarla como True Positive o False Positive. También debes explicar por qué llegaste a esa conclusión.

Por ejemplo, imaginemos una alerta relacionada con múltiples intentos fallidos de inicio de sesión. Una forma muy básica de justificarla sería decir:

Se observaron cinco intentos fallidos de inicio de sesión y luego un inicio de sesión exitoso para el mismo usuario.

El problema con esa explicación es que, por sí sola, no dice demasiado. Podría tratarse de un usuario que olvidó su contraseña, un error de escritura o un intento legítimo. La clave está en investigar qué ocurrió antes y después de ese inicio de sesión exitoso.

Una explicación más completa sería:

Se observaron cinco intentos fallidos de inicio de sesión contra una cuenta privilegiada desde la misma dirección IP. Minutos después, se registró un inicio de sesión exitoso desde esa misma IP. Luego del acceso, se identificó ejecución de comandos de reconocimiento, descarga de archivos hacia un directorio temporal y ejecución de una herramienta relacionada con escalada de privilegios, como JuicyPotato. Esta secuencia permite concluir que no se trató únicamente de intentos fallidos aislados, sino de una posible intrusión seguida de actividad post-explotación.

La diferencia entre ambos ejemplos es importante. En el primero solo estamos mencionando eventos aislados. En el segundo estamos construyendo una línea temporal: intentos fallidos, acceso exitoso, ejecución de comandos, descarga de herramientas y posible escalada de privilegios.

Ese tipo de análisis es mucho más útil para un reporte, porque no solo dice qué ocurrió, sino por qué esos eventos se relacionan entre sí y cómo respaldan la conclusión.

Por eso, al practicar Blue Team, mi recomendación es no quedarte únicamente con la alerta inicial. Intenta responder preguntas como:

• ¿Qué usuario estuvo involucrado?
• ¿Desde qué IP ocurrió la actividad?
• ¿El inicio de sesión fue exitoso después de varios fallos?
• ¿Qué procesos se ejecutaron después?
• ¿Hubo descarga de archivos?
• ¿Se usaron directorios sospechosos como /tmp, Temp o Public?
• ¿La actividad coincide con reconocimiento, persistencia, escalada de privilegios o movimiento lateral?

En resumen, para la parte Blue Team no necesitas memorizar cada alerta posible. Lo importante es aprender a investigar, construir una línea lógica de análisis y justificar tus conclusiones con evidencia clara.

Si quieres reforzar esta parte de forma práctica, en la sección de Recursos adicionales encontrarás un laboratorio que he creado específicamente para practicar el análisis de alertas, la investigación de logs y la justificación de conclusiones con base en evidencia.

---

Errores que debes evitar

Después de pasar por el proceso de preparación y presentar el examen, hay varios errores que considero importantes mencionar. Algunos los cometí directamente y otros los fui identificando durante la preparación o al momento de construir el reporte.

La idea de esta sección no es asustar, sino ayudarte a evitar problemas que pueden afectar tu desempeño, especialmente cuando el tiempo es limitado y necesitas mantener una línea de trabajo ordenada.

Error 1: No leer las instrucciones cuidadosamente

Al momento de iniciar el examen, recibirás instrucciones importantes sobre el alcance, los objetivos y la forma en que debes abordar la evaluación.

Uno de mis principales errores fue no leerlas con suficiente cuidado. Asumí que ya sabía por dónde empezar y comencé a investigar una línea que no era la prioridad en ese momento.

Puede parecer un detalle menor, pero en una certificación práctica el tiempo es un recurso muy valioso. Dedicar varias horas a una línea de investigación incorrecta puede afectar el resto del examen.

Mi recomendación es sencilla: antes de ejecutar un solo comando, lee completamente las instrucciones, identifica qué te están pidiendo y define claramente cuál debería ser tu primer objetivo.

Error 2: No documentar desde el minuto uno

Una de las mejores decisiones que tomé fue documentar todo desde el primer momento.

En mi caso utilicé Obsidian como herramienta principal de organización. La idea era construir mi reporte mientras realizaba el examen, para luego tener gran parte del trabajo adelantado al momento de completar la plantilla final en SysReptor.

Cada vez que obtenía un resultado relevante, agregaba inmediatamente:

• El comando ejecutado.
• El resultado obtenido.
• La evidencia o captura correspondiente.
• Observaciones importantes.
• Posibles siguientes pasos.

Esto me permitió mantener un historial claro de cada acción realizada y evitar tener que reconstruir procesos horas después.

También recomiendo revisar el recurso de Bruno Rocha Moura sobre reportes para CPTS: Leer recurso sobre reportes CPTS

Aunque está orientado a CPTS, muchos de los principios de documentación, estructura y presentación de evidencias también son aplicables a CJCA. Puede servir como una excelente referencia para entender cómo presentar hallazgos de forma clara, ordenada y profesional.

Error 3: Confiar demasiado en la memoria

Después de varias horas de examen, múltiples hosts, comandos, credenciales, eventos y hallazgos, es muy fácil olvidar detalles importantes.

Lo que parece obvio cuando lo encuentras puede ser difícil de recordar al momento de redactar el reporte. Por eso no recomiendo depender de la memoria.

Para evitarlo, organicé mis notas en Obsidian creando una carpeta por cada máquina o sección del examen. Ahí fui guardando la información relevante conforme la encontraba.

Por ejemplo:

• Usuarios.
• Contraseñas.
• Direcciones IP.
• Flags.
• Archivos importantes.
• Ubicaciones interesantes.
• Credenciales.
• Comandos relevantes.
• Notas rápidas sobre posibles líneas de investigación.

Esto me permitió centralizar la información importante y tenerla disponible cuando la necesitaba, sin depender de recordar cada detalle al final.

Error 4: No darle la importancia necesaria al reporte

Si hay algo que me gustaría enfatizar de esta certificación es la importancia del reporte.

Es fácil caer en la idea de que lo más importante es encontrar las flags, pero el reporte es la evidencia real de todo el trabajo realizado durante el examen.

Piensa en el reporte como la forma en que vas a demostrar tus hallazgos. No basta con llegar al resultado final; también debes explicar cómo llegaste hasta él.

Durante el examen intentaba hacerme estas preguntas:

¿Cómo explicaría este paso a otra persona?

¿Qué necesitaría ver un evaluador para entender cómo llegué hasta aquí?

Una flag por sí sola cuenta muy poco si no existe una línea lógica que explique el proceso. Lo que realmente aporta valor es demostrar cómo investigaste, qué decisiones tomaste, qué evidencia encontraste y por qué llegaste a determinada conclusión.

Si encuentras información relevante, obtienes acceso a un sistema o identificas actividad sospechosa, debes ser capaz de explicar qué hiciste, qué observaste y cómo esa evidencia respalda tu hallazgo.

Por eso recomiendo pensar en el reporte desde el primer minuto del examen y no únicamente cuando llega el momento de redactarlo. Mientras mejor documentado tengas el proceso, más fácil será construir una narrativa clara y sólida.

Error 5: No tomar suficientes capturas

Una de las recomendaciones que recibí en la retroalimentación del examen fue tomar más capturas.

Durante el examen sentía que tenía suficiente evidencia, pero al momento de redactar el reporte me di cuenta de que en algunas partes la narrativa quedaba incompleta. Sabía cómo había llegado a ciertos hallazgos, pero me faltaban capturas para demostrar mejor el proceso.

Por eso tuve que regresar a tomar evidencia adicional de puntos que no había documentado tan bien como pensaba.

Mi recomendación es simple: documenta cada paso relevante. Si dudas si una captura vale la pena, probablemente sí la vale.

Es mejor tener evidencia de sobra que descubrir al final que falta una captura importante para explicar cómo llegaste a un hallazgo.

---

Recursos adicionales

Recurso adicional para practicar Blue Team

Para quienes quieran practicar esta parte con un enfoque más cercano al análisis defensivo, he creado un recurso específico llamado CJCA: Laboratorio Blue Team para practicar triage de alertas.

El laboratorio se llama Aurelius Blue Alert Lab y está diseñado para practicar triage de alertas en Elastic/Kibana desde un entorno seguro, sintético y orientado al análisis. El escenario simula a Aurelius Labs, una empresa ficticia donde el objetivo del analista es revisar un conjunto de alertas, investigar los logs relacionados y clasificarlas como True Positive o False Positive utilizando evidencia concreta.

La idea principal es sencilla: se cargan eventos en Elastic, se revisan las alertas en Kibana, se investigan los logs asociados y se justifica cada clasificación con base en lo observado.

Puedes revisar el laboratorio aquí: CJCA: Laboratorio Blue Team para practicar triage de alertas

---

Recurso adicional para practicar el reporte

He creado un recurso enfocado específicamente en cómo reportar con un estilo orientado a CJCA. En este material explico las partes principales que debería incluir un reporte, cómo organizar la evidencia, cómo redactar hallazgos de forma clara y cómo presentar el análisis sin limitarse únicamente a pegar comandos o capturas.

El recurso también incluye un ejemplo práctico, lo cual puede servir como referencia para entender cómo transformar la información recolectada durante la práctica en un reporte más ordenado y útil.

La idea no es memorizar una plantilla, sino acostumbrarse a documentar con intención: explicar qué se hizo, qué se encontró, por qué es relevante y cómo se llegó a cada conclusión.

Puedes revisar el recurso aquí: Guía para crear un reporte estilo CJCA

---

Conclusión

En general, considero que CJCA es una certificación muy interesante para quienes quieren desarrollar habilidades prácticas y tener una primera experiencia en escenarios más cercanos a un entorno real.

Lo que más me gustó de la certificación es que no se limita únicamente a explotar máquinas o encontrar flags. También exige analizar información, relacionar evidencias, justificar conclusiones y documentar los hallazgos de forma clara.

Si tuviera que resumir lo aprendido durante esta experiencia, destacaría varios puntos importantes:

• Construir una metodología propia.
• Practicar más allá del path de preparación.
• Aprender a investigar y formular mejores preguntas.
• Documentar desde el primer minuto.
• No subestimar la importancia del reporte.
• Pensar como investigador, no solo como alguien que busca una flag.

Al final, CJCA no solo evalúa conocimientos técnicos. También pone a prueba la forma en que abordas un problema, cómo interpretas la información disponible, cómo conectas diferentes hallazgos y cómo comunicas tus resultados.

Mi recomendación final es preparar la certificación con calma, practicar con intención y darle mucha importancia a la documentación. Mientras más ordenado sea tu proceso durante la preparación y el examen, más fácil será construir un reporte sólido y demostrar realmente el trabajo que realizaste.