Gratis

Simulacre d'Examen INF #2 — Oposicions Secundària Catalunya 2026

Duración: 4 hores 30 minuts
Estructura: A 70% · B 30%
Nota de aprobado: 5

Prova pràctica — Informàtica

Resol tots els exercicis amb criteri tècnic i justificació. Indica alternatives quan sigui útil. Es valorarà correcció, eficiència, seguretat, mantenibilitat i claredat.

12.5 puntos

Sistema de cues per torns d'examen· Programació i estructures de dades

Un institut necessita gestionar torns de revisió d'exàmens. a) Dissenya una estructura que permeti afegir alumnes, atendre el següent i prioritzar casos urgents (adaptacions, incidències tècniques). (1,0) b) Escriu pseudocodi per a enqueue, dequeue i promoteUrgent amb complexitat esperada. (1,0) c) Defineix 4 proves unitàries clau. (0,5)

Solución

a) Solució recomanada: doble cua (normal + prioritària) o heap de prioritats amb timestamp. Prioritat: urgent > normal; dins mateix nivell, ordre d'arribada. b) Pseudocodi (doble cua): normal = Queue() urgent = Queue() enqueue(student, isUrgent): if isUrgent: urgent.push(student) else: normal.push(student) dequeue(): if not urgent.empty(): return urgent.pop() if not normal.empty(): return normal.pop() return null promoteUrgent(studentId): # cercar a normal, extreure i moure a urgent (O(n)) Complexitats: - enqueue O(1) - dequeue O(1) - promoteUrgent O(n) (si no hi ha índex auxiliar) c) Tests: - dequeue sobre cues buides retorna null - urgent surt abans que normal - manteniment d'ordre FIFO dins cada cua - promoteUrgent mou correctament i no duplica alumne

Rúbrica de corrección

Disseny de l'estructura correcte: 1,0 pt
Pseudocodi + complexitat coherent: 1,0 pt
Tests rellevants: 0,5 pts

22.5 puntos

Optimització de consultes de rendiment· Bases de dades

Taules: users, quizzes, attempts (10M files), questions, answers. a) Escriu una consulta SQL per obtenir taxa d'encert per tema i grup-classe durant els últims 14 dies. (1,0) b) Proposa índexs i particionament per millorar temps de resposta. (1,0) c) Explica una estratègia de materialització/caché per dashboard docent. (0,5)

Solución

a) Exemple SQL: SELECT q.topic_id, u.class_group, COUNT(*) FILTER (WHERE a.is_correct) * 1.0 / NULLIF(COUNT(*),0) AS hit_rate, COUNT(*) AS total_answers FROM answers a JOIN attempts at ON at.id = a.attempt_id JOIN users u ON u.id = at.user_id JOIN questions q ON q.id = a.question_id WHERE at.started_at >= NOW() - INTERVAL '14 days' GROUP BY q.topic_id, u.class_group; b) Índexs: - attempts(started_at DESC, user_id) - answers(attempt_id, question_id, is_correct) - users(id, class_group) Particionament per rang de data a attempts/answers. c) Vista materialitzada diària + invalidació incremental cada 15 min per grup-classe. Caché Redis amb TTL curt per consultes repetides.

Rúbrica de corrección

SQL correcte i agregació adequada: 1,0 pt
Optimització realista (índex/particions): 1,0 pt
Estratègia de caché viable: 0,5 pts

32.5 puntos

API segura de lliurament d'exercicis· Desenvolupament web

Dissenya una API REST per lliurar exercicis a alumnat autenticat. a) Defineix endpoints mínims, codis d'estat i esquema JSON de resposta. (1,0) b) Inclou control d'accés per rol i limitació de taxa. (0,75) c) Explica com monitoraries errors i latència en producció. (0,75)

Solución

a) Endpoints: - GET /api/exercises?topic=&difficulty= - POST /api/exercises/:id/submit - GET /api/exercises/:id/feedback Codis: 200, 201, 400, 401, 403, 404, 429, 500. JSON base: { "data": {...}, "meta": {"requestId":"...","timestamp":"..."}, "error": null } b) RBAC: alumne (lectura + submit propi), docent (lectura agregada), admin (gestió). Rate limit per IP+usuari (token bucket), p. ex. 60 req/min. c) Monitoratge: - Logs estructurats (requestId, userId, endpoint, status, duration) - Mètriques: P50/P95/P99 latència, error rate, 429 rate - Alertes i tracing distribuït (OpenTelemetry)

Rúbrica de corrección

API definida amb criteri: 1,0 pt
Control d'accés + rate limit: 0,75 pts
Observabilitat pràctica: 0,75 pts

42.5 puntos

Desplegament d'aula virtual híbrida· Sistemes i xarxes

Un centre vol una aula virtual disponible 24/7 amb recursos limitats. a) Proposa arquitectura (on-prem + cloud) i justificació de costos. (1,0) b) Defineix pla de hardening mínim per servidors Linux. (1,0) c) Estableix KPIs operatius i protocol d'incidències crític. (0,5)

Solución

a) Híbrid: LMS on-prem per contingut intern + rèplica cloud per pics de càrrega. Balancejador, BD gestionada, backups externs; escalar només capa web. b) Hardening: - SSH amb clau, sense root login - UFW/ACL mínims - actualitzacions automàtiques de seguretat - fail2ban, auditoria de logs, rotació i retenció - secrets fora del codi c) KPIs: uptime, MTTR, temps de resposta, taxa d'error. Protocol: severitats S1-S3, rol on-call, comunicació cada 30 min a S1.

Rúbrica de corrección

Arquitectura cost-eficient: 1,0 pt
Hardening concret i complet: 1,0 pt
KPIs/protocol accionables: 0,5 pts

Desenvolupament d'un tema

Desenvolupa UN dels dos temes proposats. Inclou introducció, desenvolupament, exemples aplicats a l'aula i conclusió.

Disseny de bases de dades i SQL avançat

Guion del tema

1. Model conceptual, lògic i físic 2. Normalització i anomalies 3. Índexs, plans d'execució i tuning 4. Transaccions i concurrència 5. Seguretat i control d'accés 6. Cas didàctic a Secundària

Arquitectura client-servidor i APIs web

Guion del tema

1. Evolució de l'arquitectura web 2. Protocol HTTP i semàntica REST 3. Autenticació i autorització 4. Escalabilitat i caché 5. Observabilitat i fiabilitat 6. Aplicació en projectes educatius