> **📝 Exame de Nivel Avanzado: Administración, Desenvolvemento e Sistemas** # Pregunta 1: Procedemento Administrativo e Administración Electrónica (Galego) (Temas 5 e 8) Un concello galego tramita un procedemento sancionador a unha empresa provedora de material informático (suxeito obrigado a relacionarse electronicamente segundo o art. 14 da Lei 39/2015). O Concello pon a notificación da resolución á súa disposición na sede electrónica un martes día 1. A empresa non accede á notificación. O día 10, o sistema da sede electrónica sofre unha caída xustificada e documentada de 4 horas pola mañá. O día 12, o Concello dita resolución dándoo por notificado e continúa o procedemento. A empresa alega indefensión argumentando que o sistema fallou o día 10 e pide a nulidad da notificación. - **O teu labor**: Razoa xuridicamente, baseándote nos prazos da Lei 39/2015, se a alegación da empresa ten algún percorrido legal ou se o Concello actuou correctamente. ## Resposta Esta pregunta tívenna que buscar na Ley en sí por mor de non saber este caso concreto. Atopei o seguinte: - Apartado 4, Artigo 32, da Ampliación, do Capítulo II, dos Termos e Prazos, do Título II, das Normas Xerais de Actuación dinos que ante unha incidencia que afecte ós prazos, como é o caso que temos aquí, éste ampliarase dentro dos marcos da incidencia, neste caso, 4 horas, dentro do marco obrigatorio. - Nese mismo artigo, non podemos acollernos ó Apartado 1 por mor do dito no Apartado 2, é dicir, non podemos acollernos nin a que a Administración amplíe os tempos de oficio, así como tampouco por solicitude do interesado por mor de haberse vencido os prazos designados. - Por outra banda, no Apartado 2 do Artigo 30, do Cómputo de Prazos, o non sair refrexado o tipo de días que estanse a considerar específicamente, éstes entenderanse como hábiltes, polo se contamos que o prazo comeza ó día seguinte, e as semanas constan de 5 días hábies por defecto, sendo naturais de 7, o prazo realmente remataría como mínimo o 15, polo que estando dentro do prazo, sí poderíase considerar o dito no Apartado 1 do Artigo 32, xa sexa por petición ou de oficio. - Por outra banda temos un matiz importante de obriga por parte da administración no Apartado 1 do Artigo 20 de Responsabilidade da Tramitación, onde se di que os titulares das unidades administrativas, o persona ó servicio das Administracións Públicas e demais, teñen que facelo necesario para evitar e eliminar toda anormalidad na tramitación de procedementos, polo que houbendo unha incidencia, é dicir, unha anomalía, ésta deberá subsanar se non a pode evitar en deducción á súa obriga. - **Anotacións**: Non che sei se foi unha resposta acertada ou non, pero gustoume moito este nivel: dame inseguridade de non saber nada ou moito menos do que requiro, pero tamén sei que conseguirei maiores niveis de coñecemento e aplicación. ## Corrección Tu razonamiento ha sido muy bueno al buscar la legislación e intentar aplicar la lógica de los plazos y de las incidencias técnicas. Sin embargo, hay aquí una "trampa" legal muy específica en la Ley 39/2015 que altera completamente el desenlace. El error crítico en el análisis reside en el tipo de días que se cuentan. Para el cómputo general de plazos, la regla es usar días hábiles (Art. 30.2). No obstante, las notificaciones electrónicas tienen una regla especial y estricta descrita en el **Artículo 43.2**: "*Cuando la notificación por medios electrónicos sea de carácter obligatorio... se entenderá rechazada cuando hayan transcurrido diez días **naturales** desde la puesta a disposición de la resolución o acto sin que se acceda a su contenido.*" Al ser 10 días naturales, el plazo se agota mucho más rápido. Si fue puesta a disposición el martes día 1, el plazo de 10 días naturales termina el día 11. El hecho de que el sistema sufriera una caída durante 4 horas el día 10 es irrelevante para dar la notificación por rechazada el día 12, ya que la empresa tuvo más de 9 días completos e ininterrumpidos para acceder. La jurisprudencia y los tribunales suelen dictar que un fallo puntual (unas horas) no genera indefensión si hubo tiempo más que suficiente en los restantes días naturales. Por tanto, el Ayuntamiento actuó correctamente y la alegación de la empresa no tendría ningún recorrido legal. ## Contrapuesta En lo único que tengo que corregirte es en una aclaración: lo de la auditoría ordinarioa de 2 años es como te lo dije, lo acabo de comprobar, en el **Apartado 1 del Artículo 31**: *Los sistemas de información comprendidos en el ámbito de aplicación de este real decreto serán objeto de una auditoría regular ordinaria, al menos cada dos años, que verifique el cumplimiento de los requerimientos del ENS*; mientras que el **Artículo 34** nos habla de *Prestación de servicios de respuesta a incidentes de seguridad a las entidades del sector público*. # Pregunta 2: Visual Studio .NET y Manejo de Excepciones (Castellano) (Temas 9, 12 y 13) Estás desarrollando un módulo en VS.NET (C#) para la gestión del Padrón Municipal. En tu bloque `try-catch`, capturas una excepción de tipo `SqlException` al intentar actualizar un registro concurrente. Quieres registrar el error en un archivo de log local y, a continuación, **relanzar exactamente la misma excepción hacia el nivel superior de la aplicación sin perder ni alterar el *Stack Trace* original** (la traza de la pila) para que el equipo de soporte pueda depurarlo después. - **Opciones**: ¿Cuál de estas instrucciones dentro del bloque `catch` es la única correcta para lograr esto? - a) `throw ex;` - b) `throw;` - c) `throw new Exception(ex.Message);` - d) `return ex;` - **Tu labor**: Elige la opción correcta y justifica técnicamente por qué las otras tres opciones fallarían en este caso raro o arruinarían el Stack Trace. ## Respuesta Voy a responder a ciegas de primeras. Por experiencia en gestión de excepciones, nunca se me dio esta casuística de tener la posibilidad de perder la traza con el objeto Exception conformado, pero si quisiera obtener una traza concreta, y sabiendo los niveles de iteracción que he tenido, ésta se puede extraer de la creacuón de una nueva excepción, que sería el throw new Exception(ex.Message), aislando la excepción original sobre un nuevo objeto, pero éste lanza el throw en el Catch, por lo que rompería el Catch por la excepción. La idea más lógica es retornar la excepción en las opciones que dan, pero tampoco, porque el retorno no va concretamente a donde se busca como caso especial, sería llamando a un método u objeto. Por tanto, y viendo que estamos hablando de una pila, entiendo que el `return` es la mejor más lógica, aunque poca tiene, así que por descarte digo la **d**. Ahora que miré en Internet acabo de tener la solución, y es la **b** pues la palabra reservada `throw` es la encargada de hacerla subir de nivel dentro de la pila sobre el bloque `catch`. Con esto pregunto... ¿Cómo hacen para capturar la excepción en ese caso? ¿Me puedes poner un ejemplo? ## Corrección Hiciste una excelente deducción al investigar y llegar a la respuesta correcta: **b)** `throw;`. Cuando utilizamos `throw ex;`, la plataforma .NET reescribe el *Stack Trace* (la traza de la pila), marcando la línea del `catch` actual como el punto de origen de la excepción. Esto destruye el historial de dónde ocurrió realmente el error en las profundidades del código. El uso aislado de `throw;` indica al compilador que relance la excepción original, manteniendo la línea de código exacta donde saltó el error inicialmente. Aquí tienes el ejemplo de cómo se estructura esto y cómo se captura en el nivel superior para no perder el hilo: ```C# // Nivel Inferior (Acceso a Datos) public void ActualizarPadron() { try { // Código que intenta actualizar la base de datos y falla ComandoSql.ExecuteNonQuery(); } catch (SqlException ex) { RegistrarLogLocal("Error al actualizar padrón: " + ex.Message); // Relanza la excepción preservando el Stack Trace original throw; } } // Nivel Superior (Interfaz de Usuario o Controlador) public void BotonGuardar_Click() { try { ActualizarPadron(); // Llama al método inferior } catch (SqlException ex) { // La excepción se captura aquí. // Si inspeccionas 'ex.StackTrace', verás la línea exacta del // 'ComandoSql.ExecuteNonQuery()' y no la línea del primer catch. MostrarMensajeAlUsuario("Ocurrió un error en el sistema. Contacte con soporte."); } } ``` # Pregunta 3: Esquema Nacional de Seguridade (Galego) (Tema 29) O Concello vai implantar un novo sistema web para a xestión de incidencias nas vías públicas xestionado polo teu departamento. Tras a preceptiva análise de riscos, determínase que as dimensións de seguridade teñen a seguinte valoración: - *Dispoñibilidade*: BAIXA - *Integridade*: MEDIA - *Confidencialidade*: ALTA - **O teu labor**: Segundo o ENS, cal é a categoría global deste sistema de información? Ademais, xustifica se con esta categoría é obrigatorio realizar unha auditoría regular de seguridade e, de ser así, con que periodicidade mínima. ## Resposta Aquí vou responder a cegas de primeiras. Se imos o apartado 3, da Deteminación do Nivel de Seguridade Requerido nunha Dimensión de Seguridade, do Anexo I, das Categorías de Seguridade dos Sistemas de Información, iríase co máis sensible, o cal categorizaría a clasificación do Nivel de Seguridade, neste caso, Alto. Polo tanto, os requerimentos cara éste tamén son altos e polo tanto, faría falla realizala Certificación de Conformidade a partires de cada Auditoría que sería obrigatoria cada 2 anos. Agora, mirando, atopamos que non sae no Apartado 3 do Anexo I, senón no Apartado 4, da Determinación da Categoría de Seguridade dun Sistema de Información, concretamente, no seu Punto 1a. O tema da Certificación o temos no Artigo 38, dos Procedementos de Derminación da Conformidade co ENS, do Capítulo V, das Normas de Conformidade, concretamente no seu Apartado 1, que ven apoiado coa auditoría que temos asinada no Apartado 1 do Artigo 31, da Auditoría da SEguridade, do Capítulo IV, da Seguridade dos Sistemas: Auditoría, Informe e Incidentes de Seguridade. ## Corrección ¡Diste en el clavo! La deducción fue perfecta y el resultado es 100% correcto. La categoría global de un sistema en el ENS viene determinada por el valor más alto alcanzado en cualquiera de las dimensiones de seguridad. Siendo la Confidencialidad ALTA, el sistema hereda la categoría **ALTA**. Un pequeño y crucial detalle para la oposición: mencionaste el Artículo 31 para la auditoría. El ENS fue actualizado por el **Real Decreto 311/2022**. En la nueva legislación en vigor, la auditoría de seguridad está regulada en el *Artículo 34*. Es obligatorio realizar una auditoría regular ordinaria para sistemas de categoría MEDIA o ALTA, al menos, cada dos años (o antes, si hay modificaciones sustanciales). Tener bien asentados los números de los artículos de la legislación más reciente marca la diferencia frente al tribunal. # Pregunta 4: Bases de Datos y Optimización SQL (Castellano) (Temas 15 y 17) Tienes una tabla inmensa llamada `LicenciasObras` en SQL Server. Tienes creado un *Non-Clustered Index* (índice no agrupado) perfectamente configurado sobre la columna `FechaSolicitud` (tipo *DATE*). Sin embargo, un compañero júnior escribe esta consulta para buscar las licencias del año 2023: ```sql SELECT Expediente, CIF_Empresa FROM LicenciasObras WHERE YEAR(FechaSolicitud) = 2023; ``` Al monitorizar, notas que la consulta va lentísima. El plan de ejecución muestra que SQL Server está ignorando el índice y haciendo un *Index Scan* (o Table Scan) en lugar de un *Index Seek*. - **Tu labor**: Explica brevemente por qué el motor de base de datos se niega a usar el índice de forma eficiente (el concepto técnico detrás de usar funciones en el `WHERE`) y reescribe la consulta de forma que sea *SARGable* (es decir, que el optimizador sí utilice el índice). ## Respuesta Aquí me voy a lanzar a la piscina de primeras. El problema radica en cómo se ha configurado el Índice y si el mismo fue procesado tras exceder del `fillfactor`, es decir, cuanto espacio reserva entre los nuevos elementos para poder intercalar en el orden. Si éste fue excedido, éste empieza a apilar, por lo que ha que procesar el índice para que se ordene pues al ser un recurso de consumo, éste requiere de ser procesado en esprofeso. Para poder solucionarlo, primero hemos de arreglar el reorden reconstruyendo el índice, y luego, haciendo la o las consultas necesarias. ```sql use BASE_DE_DATOS alter index licencias_obras_df_fecha_solicitud on LicenciasObras.FechaSolicitud rebuild with (fillfactor = 90) ``` Tras la reconstrucción del índice podemos lanazar la consulta como lo hace originalmente y deberíamos de ver una mejoría sustancial en el rendimiento de la misma. ## Corrección Tu respuesta se enfocó en la fragmentación del índice (`fillfactor` y `rebuild`), lo cual es un problema real y común de mantenimiento en bases de datos. Sin embargo, el escenario descrito expone un problema de desarrollo y código: la falta de **SARGability** (*Search ARGument ABLE*). El motor de base de datos se niega a usar el índice de forma eficiente porque la cláusula `WHERE` aplica una función (`YEAR()`) directamente sobre la columna indexada. Para evaluar `YEAR(FechaSolicitud) = 2023`, SQL Server se ve forzado a extraer el año de *todas las filas de la tabla* una a una (haciendo un *Index Scan* o un *Table Scan*) para comprobar si corresponde a 2023, inutilizando por completo la estructura de árbol del índice. Para que la consulta sea *SARGable* y el optimizador pueda saltar directamente a los datos deseados (*Index Seek*), la columna indexada debe estar "limpia", sin funciones aplicadas sobre ella. La consulta reescrita correctamente sería: ```SQL SELECT Expediente, CIF_Empresa FROM LicenciasObras WHERE FechaSolicitud >= '2023-01-01' AND FechaSolicitud < '2024-01-01'; ``` De esta forma, el motor sabe exactamente dónde empezar a leer en el índice y dónde parar, haciendo que la consulta sea prácticamente instantánea, independientemente de lo inmensa que sea la tabla de licencias.