# 50 Reptes Cloud: AWS + Kubernetes per a CFGS

> **Context**: Reptes dissenyats per a alumnat de 2n de Grau Superior (ASIX / DAW) que apliquen conceptes homelab a l'entorn AWS Academy per a desplegaments a escala. Cada repte inclou etapes de reflexió on la IA no pot substituir el raonament crític de l'alumne.

> **Tecnologies cobertes**: EC2, ECS, EKS, S3, RDS, DynamoDB, Amplify, Cognito, Lambda, Systems Manager, API Gateway, Route53, Terraform (IaC)

> **Llegenda d'especialitats**:
> - **SIS** = Administració de Sistemes
> - **DEV** = Desenvolupament Web
> - **SIS+DEV** = Principal + Secundària

> **Notes AWS Academy Learner Lab**:
> - Crèdits limitats (~100 USD). Cal apagar recursos quan no s'utilitzen.
> - No es poden crear IAM users/roles personalitzats (s'utilitza el rol `LabRole`).
> - Algunes regions i serveis poden estar restringits.
> - Les sessions caduquen cada 4 hores (cal fer `Start Lab` de nou).
> - No hi ha accés a Route53 per registrar dominis (es pot simular amb registres locals o dominis existents).

---

## Nivell 1: Fàcil (15 reptes)

---

### Repte 1 — Desplegament de WordPress a EC2 amb RDS

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4-5 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EC2, RDS (MySQL/MariaDB), S3, Route53 |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Desplegar WordPress en una instància EC2 (Amazon Linux 2023 o Ubuntu) amb la base de dades en RDS Multi-AZ. Els fitxers multimèdia s'emmagatzemaran a S3 mitjançant un plugin. Configurar un domini amb Route53 (o /etc/hosts per a simulació).

**Passos integrats de reflexió** (obligatoris, sense IA):
1. Abans de crear cap recurs, dibuixa el diagrama d'arquitectura a mà i justifica cada component.
2. Decideix el dimensionament de la instància EC2 i la classe de RDS explicant el raonament cost/rendiment.
3. Durant el desplegament, documenta cada error que trobis i com l'has resolt (log de troubleshooting).

**Secció de reflexió**:
- Per què separar la base de dades del servidor d'aplicació? Quins avantatges i inconvenients té?
- Quin impacte econòmic té activar Multi-AZ a RDS? En quin escenari real ho justificaries?
- Compara el cost mensual estimat d'aquesta arquitectura amb un hosting compartit tradicional.

**Alternativa on-premises**: Proxmox/VirtualBox amb una VM per a WordPress (Apache/Nginx + PHP) i una altra VM per a MariaDB. Compartició de fitxers via NFS o MinIO (alternativa S3). DNS local amb dnsmasq o Pi-hole.

**Adaptació AWS Academy**: Utilitzar el rol `LabRole` existent. Escollir instàncies t2.micro/t3.micro per conservar crèdits. Simular Route53 amb /etc/hosts si no està disponible.

---

### Repte 2 — Web estàtica amb Amplify, GitHub Actions i API Gateway + Lambda

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4-5 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | Amplify, Lambda, API Gateway, S3, DynamoDB |
| **IaC** | Terraform (infraestructura) + GitHub Actions (CI/CD) |
| **Prerequisits** | Cap |

**Descripció**: Crear una web estàtica (portfolio, blog o landing page) desplegada amb AWS Amplify connectada a un repositori GitHub. Implementar un formulari de contacte serverless: les dades s'envien via API Gateway a una funció Lambda que les emmagatzema a DynamoDB. Configurar GitHub Actions per executar linting i tests abans del desplegament automàtic.

**Passos integrats de reflexió**:
1. Dissenya el flux de dades del formulari (client → API Gateway → Lambda → DynamoDB) abans d'escriure codi.
2. Explica per què has triat el runtime de Lambda (Node.js, Python...) i les implicacions de cada opció.
3. Quan tot funcioni, introdueix un error deliberat al codi Lambda i documenta com el diagnostiques amb CloudWatch Logs.

**Secció de reflexió**:
- Quina diferència hi ha entre Amplify i S3+CloudFront per servir contingut estàtic?
- Calcula el cost d'aquesta arquitectura per a 10.000 visites/mes vs 1.000.000 visites/mes.
- Per què DynamoDB i no RDS per a aquest cas d'ús?

**Alternativa on-premises**: Nginx servint els fitxers estàtics. Backend amb un petit servei en Flask/Express que rep el formulari i escriu a SQLite/PostgreSQL. CI/CD amb Gitea + Drone CI o Jenkins.

**Adaptació AWS Academy**: Amplify pot no estar disponible a Learner Lab; en aquest cas, desplegar a S3 amb Static Website Hosting + CloudFront. Lambda i API Gateway funcionen correctament amb `LabRole`.

---

### Repte 3 — Contenidors Docker a ECS Fargate amb balanceig de càrrega

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 5-6 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | ECS (Fargate), ECR, ALB, CloudWatch |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Conteneritzar una aplicació web senzilla (per exemple, una app en Flask o Express) i desplegar-la a ECS Fargate. Configurar un Application Load Balancer (ALB) al davant i autoescalat basat en CPU. Pujar la imatge Docker a ECR. Monitoritzar amb CloudWatch.

**Passos integrats de reflexió**:
1. Antes de conteneritzar, justifica per què Fargate i no EC2 com a launch type d'ECS.
2. Configura manualment el Task Definition sense copiar exemples; entén cada paràmetre.
3. Fes una prova de càrrega senzilla (ab, hey o siege) i documenta com reacciona l'autoescalat.

**Secció de reflexió**:
- Quina diferència real hi ha entre ECS Fargate i executar Docker en una EC2?
- Quin és el cold start de Fargate i com afecta l'experiència d'usuari?
- Compara el cost de Fargate vs EC2 per a una càrrega constant vs una càrrega variable.

**Alternativa on-premises**: Docker Compose en una VM amb Nginx com a reverse proxy i balancejador. Escalat manual afegint rèpliques al docker-compose.yml.

**Adaptació AWS Academy**: ECR i ECS funcionen amb `LabRole`. Vigilar el nombre de tasks Fargate actives per no consumir crèdits ràpidament. Aturar el servei quan no s'usi.

---

### Repte 4 — Sistema de backup automatitzat amb S3 i Lambda

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4-5 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | S3, Lambda, SNS, CloudWatch Events (EventBridge), Systems Manager |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Implementar un sistema de backup automatitzat per a una instància EC2. Un script (instal·lat via Systems Manager Run Command) genera backups de directoris crítics i els puja a S3. Una regla d'EventBridge programa l'execució diària. Lambda verifica la integritat dels backups (checksum) i envia notificacions via SNS si falla.

**Passos integrats de reflexió**:
1. Defineix la política de retenció de backups (quants dies, quantes versions) i justifica-la.
2. Calcula l'espai d'emmagatzematge necessari a S3 per a un any amb la política definida.
3. Simula una restauració completa des del backup i documenta el procés pas a pas.

**Secció de reflexió**:
- Quina diferència hi ha entre S3 Standard, S3-IA i S3 Glacier per a backups?
- Per què és important verificar la integritat dels backups? Quin risc real hi ha si no es fa?
- Compara aquesta solució amb AWS Backup. Quins avantatges i inconvenients té cadascuna?

**Alternativa on-premises**: Script bash amb rsync/restic/borgbackup que puja a un servidor NFS o MinIO. Cron per a la programació. Healthcheck amb un script que envia correus via SMTP local.

**Adaptació AWS Academy**: SNS pot tenir restriccions per enviar correus. Alternativa: escriure els logs de verificació a un fitxer a S3 o mostrar-los a CloudWatch Logs.

---

### Repte 5 — Desplegament de HedgeDoc a ECS amb autenticació OAuth

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 5-6 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | ECS (Fargate), RDS (PostgreSQL), S3, Cognito |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Desplegar HedgeDoc (editor col·laboratiu de Markdown) a ECS Fargate amb PostgreSQL a RDS. Configurar AWS Cognito com a proveïdor d'autenticació OAuth2/OIDC. Les imatges pujades pels usuaris s'emmagatzemen a S3.

**Passos integrats de reflexió**:
1. Investiga com HedgeDoc gestiona l'autenticació i dibuixa el flux OAuth2 complet (diagrama de seqüència).
2. Configura Cognito manualment des de la consola abans d'automatitzar amb Terraform. Entén cada paràmetre.
3. Prova l'autenticació amb un usuari de test i documenta el flux de tokens (ID token, access token, refresh token).

**Secció de reflexió**:
- Quina diferència hi ha entre OAuth2 i OIDC? Per què HedgeDoc necessita OIDC?
- Quins riscos de seguretat hi ha si configures malament el callback URL de Cognito?
- Compara Cognito amb Keycloak: avantatges i inconvenients de cada solució.

**Alternativa on-premises**: HedgeDoc amb Docker Compose, PostgreSQL local i Keycloak o Authentik com a proveïdor d'identitat. Nginx com a reverse proxy amb certificat Let's Encrypt.

**Adaptació AWS Academy**: Cognito funciona amb `LabRole`. Si hi ha problemes, substituir per autenticació local de HedgeDoc i documentar les diferències.

---

### Repte 6 — Gestió centralitzada de configuració amb Systems Manager

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4-5 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | EC2 (3+ instàncies), Systems Manager (Parameter Store, Run Command, Session Manager, Patch Manager) |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Crear un entorn amb 3 instàncies EC2 (simulant web server, app server i base de dades) i gestionar-les centralitzadament amb AWS Systems Manager. Utilitzar Parameter Store per a configuració sensible, Run Command per executar scripts de manteniment, Session Manager per accés SSH sense obrir el port 22, i Patch Manager per a actualitzacions.

**Passos integrats de reflexió**:
1. Dissenya l'estructura del Parameter Store (jerarquia de paràmetres) abans d'implementar.
2. Sense IA, escriu un document Run Command personalitzat que automatitzi una tasca de manteniment.
3. Comprova que Session Manager funciona i reflexiona sobre per què és més segur que SSH directe.

**Secció de reflexió**:
- Per què és millor usar Parameter Store que variables d'entorn o fitxers .env?
- Quins avantatges de seguretat aporta Session Manager respecte a obrir el port 22?
- Com escalaries aquesta solució per gestionar 100 instàncies?

**Alternativa on-premises**: Ansible per a gestió de configuració, Vault de HashiCorp per a secrets, i WireGuard o Tailscale per a accés remot segur.

**Adaptació AWS Academy**: Systems Manager funciona bé amb `LabRole`. Les instàncies EC2 han de tenir l'agent SSM instal·lat (Amazon Linux 2023 el porta per defecte).

---

### Repte 7 — Aplicació CRUD serverless completa

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 5-6 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | Lambda, API Gateway, DynamoDB, S3, Cognito |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Desenvolupar una aplicació CRUD completa (gestió de tasques, notes o inventari) 100% serverless. El frontend (React/Vue/vanilla JS) es serveix des de S3. L'API REST es construeix amb API Gateway + Lambda. Les dades es guarden a DynamoDB. Cognito gestiona l'autenticació d'usuaris.

**Passos integrats de reflexió**:
1. Dissenya l'esquema de DynamoDB (partition key, sort key, GSI) i justifica les decisions. Per què no una taula relacional?
2. Implementa la gestió d'errors a Lambda manualment, sense copiar codi genèric.
3. Fes un test de rendiment amb 100 peticions concurrents i analitza els logs de CloudWatch.

**Secció de reflexió**:
- Quina és la diferència entre API Gateway REST i HTTP API? Quina has triat i per què?
- Com gestiones la consistència eventual de DynamoDB? Afecta la teva aplicació?
- Calcula el cost mensual per a 50.000 operacions CRUD/mes.

**Alternativa on-premises**: Express/Flask amb PostgreSQL/MongoDB, desplegat en un contenidor Docker. Autenticació amb JWT implementada manualment o amb Passport.js/Flask-Login.

**Adaptació AWS Academy**: Tot funciona amb `LabRole`. Cognito User Pools funciona correctament. Si hi ha problemes amb Cognito, implementar autenticació amb API keys a API Gateway.

---

### Repte 8 — Desplegament de Nextcloud a EC2 amb emmagatzematge S3

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 5-6 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | EC2, S3, RDS (MariaDB), Route53, Certificate Manager |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Desplegar Nextcloud en EC2 amb emmagatzematge primari a S3 (External Storage), base de dades a RDS MariaDB, i HTTPS amb un certificat ACM (o autosignat per a proves). Configurar Redis (ElastiCache o instal·lat localment) per a caching de sessions.

**Passos integrats de reflexió**:
1. Calcula l'emmagatzematge S3 necessari per a 20 usuaris amb 10 GB cadascun durant un any.
2. Configura Nextcloud manualment (sense scripts d'automatització) i documenta cada pas.
3. Prova la pujada de fitxers grans (>1 GB) i diagnostica si hi ha problemes de timeout.

**Secció de reflexió**:
- Per què S3 com a emmagatzematge principal i no un disc EBS més gran?
- Quin impacte té la latència S3 en l'experiència d'usuari de Nextcloud?
- Compara el cost d'aquesta solució amb Google Workspace o Microsoft 365 per a 20 usuaris.

**Alternativa on-premises**: Nextcloud amb Docker Compose, MariaDB local, emmagatzematge en disc NFS/ZFS, Redis local. Certificat Let's Encrypt amb Nginx reverse proxy.

**Adaptació AWS Academy**: ElastiCache pot no estar disponible; instal·lar Redis directament a la instància EC2. Certificat autosignat en lloc d'ACM si no hi ha domini.

---

### Repte 9 — Pipeline CI/CD bàsic amb CodePipeline i ECS

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 5-6 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | CodePipeline, CodeBuild, ECR, ECS (Fargate) |
| **IaC** | Terraform |
| **Prerequisits** | Repte 3 (recomanat) |

**Descripció**: Crear un pipeline CI/CD que, quan es fa push a la branca main d'un repositori (GitHub o CodeCommit), automàticament: (1) executa tests, (2) construeix la imatge Docker, (3) la puja a ECR, i (4) desplega a ECS Fargate. Configurar rollback automàtic si el health check falla.

**Passos integrats de reflexió**:
1. Dibuixa el flux complet del pipeline (des del git push fins al desplegament) abans de crear-lo.
2. Introdueix un test que falla i documenta com el pipeline gestiona l'error.
3. Mesura el temps total del pipeline i identifica colls d'ampolla.

**Secció de reflexió**:
- Quina diferència hi ha entre CI i CD? On acaba una i comença l'altra?
- Per què és important el rollback automàtic? Quin risc hi ha sense ell?
- Compara CodePipeline amb GitHub Actions: quan usaries cadascun?

**Alternativa on-premises**: Jenkins o Gitea Actions amb un registre Docker local (Harbor o registre simple). Desplegament a Docker Compose o K3s amb scripts bash.

**Adaptació AWS Academy**: CodePipeline i CodeBuild funcionen amb `LabRole`. Si CodeCommit no està disponible, connectar amb GitHub. Vigilar el temps d'execució de CodeBuild (consum de crèdits).

---

### Repte 10 — Monitorització bàsica amb CloudWatch i SNS

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4-5 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | EC2, CloudWatch (Mètriques, Alarmes, Dashboards, Logs), SNS |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Configurar un sistema de monitorització complet per a una instància EC2 amb aplicació web. Crear un dashboard de CloudWatch amb mètriques personalitzades (ús de disc, connexions actives, temps de resposta). Configurar alarmes que notifiquen via SNS quan se superen llindars. Centralitzar logs d'aplicació amb CloudWatch Logs.

**Passos integrats de reflexió**:
1. Defineix els llindars d'alarma (CPU, memòria, disc) i justifica per què has triat aquests valors.
2. Genera càrrega artificial i observa com reaccionen les mètriques en temps real.
3. Crea un runbook (document de resposta) per a cada alarma: què fer quan salta.

**Secció de reflexió**:
- Quina diferència hi ha entre mètriques bàsiques i detallades de CloudWatch? Quin cost addicional tenen?
- Per què és important tenir un runbook per cada alarma?
- Compara CloudWatch amb Prometheus+Grafana: avantatges i inconvenients.

**Alternativa on-premises**: Prometheus + Grafana + Alertmanager amb node_exporter a cada màquina. Loki per a logs. Alertes via Telegram bot o email SMTP.

**Adaptació AWS Academy**: CloudWatch funciona completament. SNS pot tenir restriccions per enviar correus; alternativa: verificar manualment les alarmes al dashboard.

---

### Repte 11 — Aplicació amb cua de missatges: SQS + Lambda

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4-5 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | SQS, Lambda, DynamoDB, S3, API Gateway |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Crear un sistema de processament asíncron. Un endpoint d'API Gateway rep peticions (per exemple, sol·licituds de generació d'informes o processament d'imatges) i les envia a una cua SQS. Una Lambda consumeix els missatges, processa la tasca i guarda el resultat a S3/DynamoDB. El client pot consultar l'estat del seu treball.

**Passos integrats de reflexió**:
1. Dibuixa el diagrama de flux asíncron complet i explica per què no processem directament a l'API.
2. Configura la Dead Letter Queue (DLQ) i explica quan i per què s'utilitza.
3. Envia 50 missatges simultàniament i observa com Lambda escala automàticament.

**Secció de reflexió**:
- Quina diferència hi ha entre processament síncron i asíncron? Quan usaries cada model?
- Per què SQS i no simplement cridar Lambda directament des d'API Gateway?
- Què passa si un missatge falla repetidament? Com ho gestiones?

**Alternativa on-premises**: RabbitMQ o Redis (amb bull/celery) com a broker de missatges. Workers en processos Node.js/Python. Resultat guardat a PostgreSQL o disc local.

**Adaptació AWS Academy**: SQS i Lambda funcionen correctament amb `LabRole`.

---

### Repte 12 — Desplegament multi-contenidor amb Docker Compose a EC2

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4-5 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EC2, S3, Route53 |
| **IaC** | Terraform + Docker Compose |
| **Prerequisits** | Cap |

**Descripció**: Desplegar una aplicació multi-contenidor (per exemple, Gitea + Drone CI, o Uptime Kuma + Grafana) a una instància EC2 utilitzant Docker Compose. Configurar Nginx com a reverse proxy amb certificats autosignats. Automatitzar el provisionament de la instància amb user-data i Terraform.

**Passos integrats de reflexió**:
1. Justifica l'elecció de l'aplicació multi-contenidor i explica per què Docker Compose és adequat per a aquest cas.
2. Escriu el docker-compose.yml des de zero, sense copiar exemples, entenent cada directiva.
3. Implementa una estratègia de persistència de dades i justifica-la (volumes Docker vs bind mounts vs EBS).

**Secció de reflexió**:
- Quines limitacions té Docker Compose respecte a ECS o EKS per a producció?
- Com gestionaries les actualitzacions de les imatges Docker sense downtime?
- Quin és el punt a partir del qual Docker Compose ja no és suficient i cal passar a un orquestrador?

**Alternativa on-premises**: Idèntic però en una VM de Proxmox/VirtualBox. Mateixa configuració Docker Compose. Traefik o Caddy com a alternativa a Nginx.

**Adaptació AWS Academy**: EC2 funciona perfectament. Utilitzar una instància t3.medium per tenir prou memòria per als contenidors.

---

### Repte 13 — Lloc web estàtic amb S3, CloudFront i HTTPS

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | S3, CloudFront, Certificate Manager, Route53 |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Crear un lloc web estàtic professional (generat amb Hugo, Jekyll, Astro o similar) i desplegar-lo a S3 amb distribució CloudFront per caching global i HTTPS. Configurar cache invalidation, error pages personalitzades i redireccionaments.

**Passos integrats de reflexió**:
1. Explica el concepte de CDN i per què millora el rendiment. Dibuixa el flux d'una petició.
2. Configura diferents TTL per a diferents tipus de fitxers i justifica cada valor.
3. Fes un test de velocitat (Lighthouse, GTmetrix) abans i després de CloudFront i compara.

**Secció de reflexió**:
- Quant costa servir 1 milió de pàgines/mes amb S3+CloudFront vs un VPS amb Nginx?
- Per què CloudFront és necessari si S3 ja pot servir webs estàtiques?
- Com gestionaries una actualització urgent del contingut que està cacheada a CloudFront?

**Alternativa on-premises**: Nginx servint fitxers estàtics. Varnish Cache com a CDN local. Let's Encrypt per HTTPS. Opcionalment Cloudflare (servei extern) com a CDN gratuït.

**Adaptació AWS Academy**: CloudFront pot trigar 15-20 minuts a desplegar-se. Certificat ACM a la regió us-east-1 per a CloudFront.

---

### Repte 14 — Automatització de tasques amb Lambda i EventBridge

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4-5 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | Lambda, EventBridge, EC2, SNS, S3 |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Crear un conjunt de funcions Lambda programades amb EventBridge per automatitzar tasques d'administració: (1) apagar instàncies EC2 fora d'horari laboral, (2) netejar objectes S3 antics, (3) generar informes d'ús de recursos i enviar-los via SNS. Cada funció ha de tenir gestió d'errors i logging.

**Passos integrats de reflexió**:
1. Defineix l'horari d'execució per a cada funció amb expressions cron i verifica-les manualment.
2. Implementa la lògica de cada Lambda manualment (sense plantilles) incloent gestió d'excepcions.
3. Provoca un error controlat i verifica que el sistema de notificació funciona.

**Secció de reflexió**:
- Quins altres serveis AWS es podrien optimitzar amb automatització Lambda?
- Quin estalvi econòmic pot suposar apagar instàncies fora d'horari per a una empresa amb 50 EC2?
- Compara Lambda amb un cron job en un servidor: avantatges i inconvenients.

**Alternativa on-premises**: Scripts Python/Bash amb cron jobs. Notificacions amb un bot de Telegram o email SMTP. Gestió d'errors amb systemd timers en lloc de cron.

**Adaptació AWS Academy**: EventBridge i Lambda funcionen correctament. Les Lambdes d'apagat d'EC2 són especialment útils per estalviar crèdits al lab.

---

### Repte 15 — Base de dades DynamoDB amb API REST

| Camp | Valor |
|------|-------|
| **Dificultat** | Fàcil |
| **Temps estimat** | 4-5 h |
| **Especialitat** | DEV (principal) |
| **Serveis AWS** | DynamoDB, API Gateway, Lambda, CloudWatch |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Dissenyar i implementar una taula DynamoDB per a una aplicació (catàleg de productes, sistema de reserves, registre d'esdeveniments) amb els patrons d'accés optimitzats. Crear una API REST amb API Gateway + Lambda per a les operacions CRUD. Implementar paginació, filtrat i cerca.

**Passos integrats de reflexió**:
1. Defineix primer els patrons d'accés (access patterns) i després dissenya la taula. Mai al revés.
2. Crea un Global Secondary Index (GSI) i explica per què és necessari per al teu cas d'ús.
3. Insereix 1.000 registres de prova i mesura la latència de les queries amb i sense GSI.

**Secció de reflexió**:
- Per què DynamoDB no té JOINs? Com models les relacions entre entitats?
- Quina diferència hi ha entre el model de facturació on-demand i provisionat? Quin tries per a cada escenari?
- Compara DynamoDB amb MongoDB: similituds i diferències.

**Alternativa on-premises**: MongoDB o PostgreSQL (amb JSONB) amb una API REST en Express/Flask. Documentar per què el model NoSQL té sentit per al cas d'ús escollit.

**Adaptació AWS Academy**: DynamoDB funciona perfectament amb `LabRole`. Utilitzar mode on-demand per evitar costos fixos.

---

## Nivell 2: Dificultat Mitjana (15 reptes)

---

### Repte 16 — WordPress a ECS Fargate amb RDS, EFS i Cognito

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | ECS (Fargate), RDS, EFS, Cognito, ALB, CloudFront |
| **IaC** | Terraform |
| **Prerequisits** | Repte 3 (recomanat) |

**Descripció**: Desplegar WordPress en contenidors ECS Fargate amb múltiples tasks (autoescalables). La base de dades és RDS MySQL Multi-AZ. EFS proporciona emmagatzematge compartit entre tasks per als uploads de WordPress. Autenticació d'administradors via Cognito (SSO). CloudFront al davant per caching.

**Passos integrats de reflexió**:
1. Explica el problema de la persistència de fitxers en contenidors i per què EFS és necessari.
2. Configura l'autoescalat i fes una prova de càrrega. Documenta com escala i desescala.
3. Identifica i resol els problemes de sessions PHP amb múltiples contenidors (Redis/Memcached o sessions a BD).

**Secció de reflexió**:
- Per què no serveix un EBS per compartir fitxers entre múltiples tasks Fargate?
- Quin impacte té l'autoescalat en la consistència de les sessions d'usuari?
- Compara aquesta arquitectura amb WordPress en una sola EC2: complexitat vs beneficis.

**Alternativa on-premises**: Docker Swarm o K3s amb WordPress, MySQL, Redis. NFS per a emmagatzematge compartit. Keycloak per SSO. Nginx com a reverse proxy amb caching.

**Adaptació AWS Academy**: EFS funciona amb `LabRole`. Vigilar el cost de Fargate amb múltiples tasks. Començar amb desiredCount=1 i escalar només per a proves.

---

### Repte 17 — Cluster EKS bàsic amb aplicació web i Ingress

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, ECR, ALB (via AWS Load Balancer Controller), Route53 |
| **IaC** | Terraform (eksctl per validar) |
| **Prerequisits** | Cap |

**Descripció**: Crear un cluster EKS amb Terraform (VPC, subnets, node group). Desplegar una aplicació web conteneritzada amb Deployment, Service i Ingress (AWS ALB Ingress Controller). Configurar Horizontal Pod Autoscaler (HPA). Exposar l'aplicació amb un domini (Route53 o simulat).

**Passos integrats de reflexió**:
1. Dibuixa l'arquitectura de xarxa d'EKS (VPC, subnets públiques/privades, NAT Gateway) i explica cada component.
2. Desplega l'aplicació manualment amb kubectl abans d'automatitzar amb Terraform/manifests.
3. Explica la diferència entre NodePort, LoadBalancer i Ingress amb els teus propis mots.

**Secció de reflexió**:
- Per què EKS necessita subnets privades i públiques? Què passa si tot està en subnet pública?
- Quin és el cost fix d'un cluster EKS (control plane) i com afecta la decisió d'usar-lo?
- Compara EKS amb ECS: quan escolliries cadascun?

**Alternativa on-premises**: K3s o MicroK8s en VMs de Proxmox. MetalLB com a load balancer. Nginx Ingress Controller. DNS local.

**Adaptació AWS Academy**: EKS funciona però consumeix crèdits significatius (~$0.10/h per al control plane + nodes). Utilitzar t3.medium per als nodes. Eliminar el cluster quan no s'usi. Alternativa: utilitzar el mòdul `terraform-aws-modules/eks/aws`.

---

### Repte 18 — Aplicació serverless amb autenticació i autorització completa

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | Cognito, Lambda, API Gateway, DynamoDB, S3 |
| **IaC** | Terraform |
| **Prerequisits** | Repte 7 (recomanat) |

**Descripció**: Evolucionar una aplicació CRUD serverless afegint autenticació completa amb Cognito (registre, login, verificació per email, recuperació de contrasenya) i autorització basada en grups (admin/editor/viewer). API Gateway utilitza un Cognito Authorizer. Cada usuari només pot accedir a les seves pròpies dades (row-level security a DynamoDB).

**Passos integrats de reflexió**:
1. Dissenya el model d'autorització complet: quins grups existeixen, quins permisos té cadascun, i com s'implementa a nivell de Lambda.
2. Implementa la validació del JWT token a Lambda manualment (sense biblioteques d'autorització). Entén cada camp del token.
3. Prova amb un usuari intentant accedir a dades d'un altre: documenta com el sistema ho impedeix.

**Secció de reflexió**:
- Quina diferència hi ha entre autenticació i autorització? On s'implementa cadascuna en aquesta arquitectura?
- Per què és perillós confiar només en l'autorització del frontend?
- Quins atacs (OWASP) podria rebre la teva API i com els mitigues?

**Alternativa on-premises**: Express/Flask amb Passport.js/Flask-Login, JWT tokens, PostgreSQL amb Row-Level Security (RLS). Keycloak per a gestió d'identitat.

**Adaptació AWS Academy**: Cognito funciona completament. La verificació per email pot requerir confirmar emails manualment a la consola si SES no està configurat.

---

### Repte 19 — Infraestructura multi-entorn amb Terraform (dev/staging/prod)

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | EC2, RDS, S3, VPC |
| **IaC** | Terraform (workspaces o directoris) |
| **Prerequisits** | Cap |

**Descripció**: Dissenyar i implementar una infraestructura Terraform reutilitzable amb tres entorns (dev, staging, prod) amb diferent dimensionament. Utilitzar mòduls Terraform, variables per entorn, i backend remot (S3 + DynamoDB per a state locking). Cada entorn té la seva pròpia VPC amb peering entre dev i staging.

**Passos integrats de reflexió**:
1. Dissenya l'estructura de directoris/fitxers de Terraform abans d'escriure codi. Justifica l'organització.
2. Decideix entre Terraform workspaces i directoris separats per entorn. Argumenta la decisió.
3. Simula un canvi que s'ha de propagar de dev → staging → prod i documenta el procés.

**Secció de reflexió**:
- Per què és important aïllar l'state de Terraform per entorn?
- Quins riscos hi ha si staging i prod comparteixen recursos (VPC, BD)?
- Compara Terraform workspaces amb directoris separats: quan usaries cada enfocament?

**Alternativa on-premises**: Terraform amb Proxmox provider o libvirt provider per a VMs locals. Vagrant com a alternativa per a entorns locals. Ansible per complementar la configuració.

**Adaptació AWS Academy**: Crear només 1-2 entorns per estalviar crèdits. Utilitzar instàncies petites (t2.micro) per a dev. State a S3 local del lab.

---

### Repte 20 — Desplegament de Grafana + Prometheus a ECS per monitoritzar infraestructura AWS

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | ECS (Fargate), EFS, EC2, CloudWatch |
| **IaC** | Terraform |
| **Prerequisits** | Repte 3 (recomanat) |

**Descripció**: Desplegar Prometheus i Grafana com a contenidors a ECS Fargate amb persistència a EFS. Configurar Prometheus per recollir mètriques d'instàncies EC2 (node_exporter), de contenidors ECS (cadvisor), i de serveis AWS (CloudWatch Exporter). Crear dashboards a Grafana amb alertes.

**Passos integrats de reflexió**:
1. Dissenya quines mètriques necessites monitoritzar i per què. No tot és important.
2. Configura el prometheus.yml manualment, entenent cada scrape_config.
3. Crea un dashboard de Grafana des de zero (no importat) amb les mètriques més rellevants.

**Secció de reflexió**:
- Per què Prometheus i no CloudWatch directament? Quan usaries cada opció?
- Quin és el cost d'executar Prometheus+Grafana a Fargate 24/7? Val la pena?
- Com escalaries Prometheus si tens centenars de targets? (pista: Thanos, Victoria Metrics)

**Alternativa on-premises**: Prometheus + Grafana + Alertmanager en Docker Compose. Node_exporter a cada VM. Loki per a logs. Tot a Proxmox/VirtualBox.

**Adaptació AWS Academy**: EFS per persistir dades de Prometheus i Grafana entre reinicis del lab. Vigilar els recursos de Fargate.

---

### Repte 21 — Aplicació amb WebSockets via API Gateway i Lambda

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | DEV (principal) |
| **Serveis AWS** | API Gateway (WebSocket), Lambda, DynamoDB, S3 |
| **IaC** | Terraform |
| **Prerequisits** | Repte 7 (recomanat) |

**Descripció**: Crear una aplicació en temps real (xat, dashboard en viu, o joc multijugador senzill) utilitzant WebSockets d'API Gateway. Lambda gestiona les connexions ($connect, $disconnect, $default) i emmagatzema les connexions actives a DynamoDB. El frontend a S3 es connecta via WebSocket i rep actualitzacions push.

**Passos integrats de reflexió**:
1. Dibuixa el cicle de vida d'una connexió WebSocket (connect, message, disconnect) i com difereix d'HTTP.
2. Implementa la gestió de connexions a DynamoDB (guardar, eliminar, llistar) entenent per què cal persistir-les.
3. Prova amb 10+ clients connectats simultàniament i documenta el comportament.

**Secció de reflexió**:
- Per què WebSocket i no polling HTTP per a temps real? Quins són els trade-offs?
- Com gestionaria el sistema si una Lambda falla mentre envia missatges a 1.000 connexions?
- Compara API Gateway WebSocket amb un servidor Socket.io dedicat: rendiment i cost.

**Alternativa on-premises**: Node.js amb Socket.io o Go amb gorilla/websocket. Redis Pub/Sub per a escalat horitzontal. Nginx com a WebSocket proxy.

**Adaptació AWS Academy**: API Gateway WebSocket funciona amb `LabRole`. El cost és mínim per a proves.

---

### Repte 22 — Desplegament d'Authentik/Keycloak a ECS com a IdP centralitzat

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | ECS (Fargate), RDS (PostgreSQL), EFS, ALB, Route53 |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Desplegar Keycloak o Authentik a ECS Fargate com a Identity Provider (IdP) centralitzat. Configurar-lo amb PostgreSQL a RDS i persistència a EFS. Crear realms/tenants, configurar OAuth2/OIDC, i integrar-lo amb almenys dues aplicacions (per exemple, Grafana i una app web pròpia).

**Passos integrats de reflexió**:
1. Investiga la diferència entre SAML, OAuth2 i OIDC. Explica-les amb els teus mots sense consultar IA.
2. Configura un realm complet amb rols i grups manualment a la interfície de Keycloak/Authentik.
3. Depura un problema de callback URL o token incorrecte sense ajuda de IA (només logs).

**Secció de reflexió**:
- Per què centralitzar l'autenticació en un IdP en lloc d'implementar-la a cada aplicació?
- Quins riscos de seguretat implica que l'IdP caigui? Com ho mitigues?
- Compara Keycloak/Authentik amb Cognito: funcionalitats, complexitat i cost.

**Alternativa on-premises**: Keycloak o Authentik amb Docker Compose, PostgreSQL local. Integrar amb aplicacions locals via Nginx reverse proxy.

**Adaptació AWS Academy**: ECS i RDS funcionen. Si EFS no està disponible, muntar un volum EBS a una instància EC2 i executar Keycloak allà.

---

### Repte 23 — Arquitectura event-driven amb EventBridge, SQS i Lambda

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | EventBridge, SQS, Lambda, DynamoDB, SNS, S3 |
| **IaC** | Terraform |
| **Prerequisits** | Repte 11 (recomanat) |

**Descripció**: Dissenyar un sistema event-driven per a una botiga online simplificada. Quan es crea una comanda (via API Gateway), EventBridge distribueix l'event a múltiples consumidors: (1) Lambda de processament de pagament (simulat), (2) Lambda d'actualització d'inventari a DynamoDB, (3) Lambda de notificació via SNS, (4) Lambda d'arxiu a S3. Implementar retry i DLQ per a cada consumidor.

**Passos integrats de reflexió**:
1. Dissenya l'esquema d'events (event schema) abans d'implementar. Defineix els camps de cada event.
2. Implementa el patró de retry amb backoff exponencial i explica per què és important.
3. Simula un fallo en el servei de pagament i documenta com el sistema gestiona la inconsistència.

**Secció de reflexió**:
- Quina diferència hi ha entre coreografia (events) i orquestració (Step Functions)?
- Com garanteixes la consistència eventual entre tots els serveis?
- Què passa si el servei de notificació falla després que el pagament s'hagi processat?

**Alternativa on-premises**: RabbitMQ o Apache Kafka com a event broker. Microserveis en contenidors que consumeixen events. PostgreSQL per a l'inventari.

**Adaptació AWS Academy**: EventBridge funciona amb `LabRole`. Tots els serveis involucrats estan disponibles.

---

### Repte 24 — Desplegament de Gitea + Woodpecker CI a EKS

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, EBS (CSI Driver), RDS, Route53 |
| **IaC** | Terraform + Helm |
| **Prerequisits** | Repte 17 (recomanat) |

**Descripció**: Sobre un cluster EKS, desplegar Gitea (alternativa lleugera a GitHub) i Woodpecker CI (CI/CD compatible amb Docker) amb Helm charts. Configurar persistència amb EBS CSI Driver, base de dades amb RDS PostgreSQL, i un pipeline CI/CD complet que construeixi i desplega una aplicació al mateix cluster.

**Passos integrats de reflexió**:
1. Investiga les Helm charts de Gitea i Woodpecker. Personalitza els values.yaml entenent cada paràmetre.
2. Crea un pipeline .woodpecker.yml que construeixi, testegi i desplega una aplicació. Escriu-lo des de zero.
3. Diagnostica un problema de permisos entre Woodpecker i el cluster EKS (ServiceAccount, RBAC).

**Secció de reflexió**:
- Per què Helm en lloc de manifests YAML crus per a desplegaments complexos?
- Quina diferència hi ha entre Woodpecker CI i GitHub Actions/GitLab CI?
- Com gestionaries els secrets de la base de dades dins Kubernetes? (Sealed Secrets, External Secrets, etc.)

**Alternativa on-premises**: K3s amb Gitea i Woodpecker CI. Longhorn o local-path per a persistència. PostgreSQL en un pod o VM separada.

**Adaptació AWS Academy**: EBS CSI Driver necessita configurar-se amb `LabRole`. Alternativa: usar local-path-provisioner per a persistència (no recomanat per a producció).

---

### Repte 25 — API Gateway amb múltiples microserveis Lambda i DynamoDB

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | API Gateway, Lambda, DynamoDB, Cognito, CloudWatch |
| **IaC** | Terraform |
| **Prerequisits** | Repte 7 (recomanat) |

**Descripció**: Construir una API REST amb múltiples microserveis (users, products, orders) cada un amb la seva pròpia Lambda i taula DynamoDB. API Gateway actua com a entry point únic amb rutes per a cada microservei. Implementar rate limiting, CORS, i validació de requests amb models JSON Schema. Cognito per autenticació.

**Passos integrats de reflexió**:
1. Dissenya el contracte de l'API (OpenAPI/Swagger) abans d'implementar cap Lambda.
2. Implementa la comunicació entre microserveis (per exemple, orders necessita validar que el producte existeix) i justifica el patró triat.
3. Fes un test de càrrega i identifica quin microservei és el coll d'ampolla.

**Secció de reflexió**:
- Quins avantatges i inconvenients té l'arquitectura de microserveis respecte a un monòlit?
- Com gestionares les transaccions distribuïdes (per exemple, crear una comanda que redueix l'inventari)?
- Per què cada microservei hauria de tenir la seva pròpia taula DynamoDB?

**Alternativa on-premises**: Express/Flask amb rutes separades per servei, PostgreSQL amb esquemes per servei, Nginx com a API Gateway. Alternativa amb Kong o Traefik.

**Adaptació AWS Academy**: Tot funciona amb `LabRole`. Organitzar bé les Lambdes amb prefixos per servei.

---

### Repte 26 — Desplegament d'Uptime Kuma + Alertmanager a ECS

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 5-6 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | ECS (Fargate), EFS, ALB, SNS |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Desplegar Uptime Kuma (monitorització de disponibilitat) a ECS Fargate amb persistència a EFS. Configurar monitors per a múltiples serveis (webs, APIs, ports TCP, DNS). Integrar les alertes amb SNS per notificacions i opcionalment amb un webhook de Telegram/Slack. Afegir Alertmanager per gestió avançada d'alertes (agrupació, silenciament, escalat).

**Passos integrats de reflexió**:
1. Defineix una estratègia de monitorització: què monitoritzar, cada quant, i quins llindars establir.
2. Configura alertes reals i prova-les tallant intencionadament un servei.
3. Escriu un runbook per a les 3 alertes més crítiques: què fer quan salten.

**Secció de reflexió**:
- Per què monitoritzar des de fora (blackbox) a més de des de dins (métriques)?
- Com evites les false positives? Quines estratègies existeixen?
- Compara Uptime Kuma amb serveis com UptimeRobot o Pingdom: quan self-hosted i quan SaaS?

**Alternativa on-premises**: Uptime Kuma amb Docker Compose i volums locals. Alertmanager configurat per enviar a Telegram/Discord. Tot a una VM de Proxmox.

**Adaptació AWS Academy**: EFS i ECS funcionen bé. Uptime Kuma és lleuger (256 MB RAM suficient).

---

### Repte 27 — Migració d'aplicació monolítica a contenidors ECS

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EC2, ECS (Fargate), ECR, RDS, ALB |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Partint d'una aplicació web monolítica desplegada en una EC2 (per exemple, una app Django/Rails/Laravel amb BD local), migrar-la a contenidors ECS Fargate. Pas 1: Conteneritzar l'aplicació (Dockerfile). Pas 2: Externalitzar la BD a RDS. Pas 3: Desplegar a ECS amb ALB. Pas 4: Configurar autoescalat i health checks.

**Passos integrats de reflexió**:
1. Analitza l'aplicació monolítica i identifica les dependències que compliquen la contenerització.
2. Escriu el Dockerfile pas a pas, justificant cada instrucció (FROM, COPY, RUN, etc.).
3. Documenta els problemes trobats durant la migració i com els has resolt.

**Secció de reflexió**:
- Quins canvis has hagut de fer a l'aplicació per funcionar en un contenidor? Per què?
- La migració a contenidors millora automàticament el rendiment? Per què sí o per què no?
- En quins casos no val la pena migrar a contenidors?

**Alternativa on-premises**: Migrar de VM a Docker Compose dins de la mateixa infraestructura Proxmox. PostgreSQL externalitzat a una altra VM.

**Adaptació AWS Academy**: Proporcionar l'aplicació monolítica pre-instal·lada en una AMI per estalviar temps.

---

### Repte 28 — Sistema de processament d'imatges amb S3 i Lambda

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 5-6 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | S3, Lambda, DynamoDB, API Gateway, SNS |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Crear un sistema que, quan es puja una imatge a un bucket S3, una Lambda s'activa automàticament per: (1) generar thumbnails en diversos tamanys, (2) extreure metadades EXIF, (3) guardar la informació a DynamoDB. Una API permet consultar i cercar imatges. Notificació via SNS quan el processament acaba.

**Passos integrats de reflexió**:
1. Dissenya l'arquitectura event-driven (S3 event → Lambda trigger) i identifica possibles punts de fallada.
2. Implementa el processament d'imatges amb una llibreria (Pillow/Sharp) i gestiona els layers de Lambda manualment.
3. Puja 20 imatges simultàniament i verifica que totes es processen correctament.

**Secció de reflexió**:
- Què passa si la Lambda falla a mitja execució? La imatge original es perd?
- Com gestionaries imatges molt grans (>10 MB) que superen els límits de Lambda?
- Compara aquesta arquitectura amb un servei de processament en un servidor dedicat.

**Alternativa on-premises**: MinIO (compatible S3) amb events de webhook. Un servei en Python/Node.js que escolta els webhooks i processa les imatges. PostgreSQL per a metadades.

**Adaptació AWS Academy**: Crear un Lambda layer amb la llibreria de processament d'imatges. Limitar la mida de les imatges de prova.

---

### Repte 29 — VPC avançada amb subnets públiques/privades, NAT i bastió

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 5-6 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | VPC, EC2, NAT Gateway, Security Groups, NACLs, Systems Manager |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Dissenyar i implementar una VPC amb arquitectura multi-capa: subnets públiques (ALB, bastió), subnets privades (aplicació), subnets aïllades (base de dades). Configurar NAT Gateway, Security Groups, NACLs, i VPC Flow Logs. Implementar accés a les instàncies privades via Systems Manager Session Manager (sense bastió) o via bastió SSH.

**Passos integrats de reflexió**:
1. Dibuixa el diagrama de xarxa complet amb CIDRs, rutes, i fluxos de tràfic ABANS de crear res.
2. Configura les regles de Security Groups amb el principi de mínim privilegi. Justifica cada regla.
3. Intenta accedir des d'una instància privada a Internet sense NAT Gateway i documenta què passa.

**Secció de reflexió**:
- Quina diferència funcional hi ha entre Security Groups i NACLs? Quan usaries cadascun?
- Per què el NAT Gateway és a la subnet pública si serveix les instàncies privades?
- Quin cost mensual té un NAT Gateway? Hi ha alternatives més econòmiques?

**Alternativa on-premises**: VLANs amb pfSense/OPNsense com a firewall/router. Subnets separades amb regles de firewall. VPN WireGuard per accés remot.

**Adaptació AWS Academy**: VPC i components de xarxa funcionen amb `LabRole`. Eliminar el NAT Gateway quan no s'usi (cost elevat ~$0.045/h).

---

### Repte 30 — Desplegament blue-green amb ECS i ALB

| Camp | Valor |
|------|-------|
| **Dificultat** | Mitjana |
| **Temps estimat** | 6-7 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | ECS (Fargate), ALB (amb target groups), ECR, CodeDeploy, CloudWatch |
| **IaC** | Terraform |
| **Prerequisits** | Repte 3 i 9 (recomanats) |

**Descripció**: Implementar una estratègia de desplegament blue-green amb ECS i ALB. Dues versions de l'aplicació corren simultàniament en target groups separats. CodeDeploy gestiona el canvi de tràfic (canary, linear o all-at-once). Configurar rollback automàtic basat en alarmes de CloudWatch si la nova versió falla.

**Passos integrats de reflexió**:
1. Explica la diferència entre desplegament blue-green, canary i rolling update amb els teus mots.
2. Desplega una versió "trencada" i verifica que el rollback automàtic funciona.
3. Mesura el temps de downtime (si n'hi ha) durant el desplegament.

**Secció de reflexió**:
- En quins escenaris el blue-green és millor que el rolling update?
- Quin cost addicional té mantenir dues versions actives durant el desplegament?
- Com testejaries la nova versió abans de canviar tot el tràfic?

**Alternativa on-premises**: Nginx amb upstream servers i canvi de configuració. Docker Compose amb perfils per a blue/green. Script bash per automatitzar el canvi.

**Adaptació AWS Academy**: CodeDeploy funciona amb `LabRole`. Vigilar que no quedin tasks Fargate innecessàries actives.

---

## Nivell 3: Difícil (15 reptes)

---

### Repte 31 — Plataforma WordPress multi-tenant a EKS amb Helm

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, EFS, RDS (Aurora MySQL), ElastiCache (Redis), CloudFront, Route53 |
| **IaC** | Terraform + Helm |
| **Prerequisits** | Repte 17 (necessari) |

**Descripció**: Crear una plataforma que permeti desplegar múltiples instàncies de WordPress a EKS, cadascuna en el seu namespace amb el seu domini. Utilitzar un Helm chart personalitzat que parametritzi la configuració. Base de dades compartida Aurora MySQL amb esquemes separats. Redis a ElastiCache per caching. CloudFront per CDN. Implementar limits i quotas de recursos per namespace.

**Passos integrats de reflexió**:
1. Dissenya l'arquitectura multi-tenant: aïllament per namespace, com es comparteixen els recursos, i com s'escala.
2. Crea el Helm chart des de zero amb templates parametritzables. No usis charts existents com a base.
3. Desplega 3 instàncies i fes una prova de càrrega. Verifica que els resource limits funcionen.

**Secció de reflexió**:
- Quins riscos de seguretat hi ha en una arquitectura multi-tenant? Com aïlles els tenants?
- Per què Aurora i no RDS MySQL estàndard? Quina diferència de cost i rendiment hi ha?
- Com gestionaries l'onboarding d'un nou tenant de forma automatitzada?

**Alternativa on-premises**: K3s amb WordPress per namespace, MariaDB Galera Cluster compartit, Redis Sentinel, Nginx Ingress Controller amb certificats Let's Encrypt per a cada domini.

**Adaptació AWS Academy**: Aurora pot no estar disponible; substituir per RDS MySQL. ElastiCache pot no estar disponible; usar Redis en un pod del cluster. Limitar a 2 tenants per estalviar crèdits.

---

### Repte 32 — GitOps amb ArgoCD a EKS

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, ECR, S3, Route53 |
| **IaC** | Terraform + ArgoCD + Kustomize/Helm |
| **Prerequisits** | Repte 17 (necessari) |

**Descripció**: Implementar el model GitOps complet a EKS amb ArgoCD. Crear dos repositoris: un per al codi de l'aplicació i un per als manifests de Kubernetes. ArgoCD sincronitza automàticament l'estat del cluster amb el repositori de manifests. Configurar ApplicationSets per a múltiples entorns (dev/staging/prod). Implementar Sealed Secrets per a gestió segura de secrets.

**Passos integrats de reflexió**:
1. Explica el concepte de GitOps amb les teves paraules: què significa que Git sigui la "font de veritat"?
2. Fes un canvi al repositori de manifests i observa com ArgoCD el detecta i l'aplica. Documenta el procés.
3. Introdueix un manifest erroni (per exemple, una imatge que no existeix) i observa com ArgoCD gestiona l'error.

**Secció de reflexió**:
- Quina diferència hi ha entre GitOps (pull) i CI/CD tradicional (push)?
- Com gestionaries un rollback d'emergència amb GitOps? És més ràpid o més lent que sense GitOps?
- Per què Sealed Secrets i no Kubernetes Secrets directament al repositori?

**Alternativa on-premises**: K3s amb ArgoCD, Gitea com a repositori Git, Kustomize per a entorns. Sealed Secrets o Mozilla SOPS per a secrets.

**Adaptació AWS Academy**: ArgoCD funciona dins d'EKS. Utilitzar GitHub com a repositori (gratis). Instal·lar ArgoCD amb Helm.

---

### Repte 33 — Plataforma de microserveis amb service mesh (Istio) a EKS

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, ECR, CloudWatch, X-Ray |
| **IaC** | Terraform + Istio |
| **Prerequisits** | Repte 17 (necessari) |

**Descripció**: Desplegar 3-4 microserveis a EKS amb Istio com a service mesh. Configurar traffic management (canary deployments, circuit breaker, retry), mTLS entre serveis, observabilitat (Kiali, Jaeger per a tracing distribuït), i rate limiting. Simular fallades amb fault injection i validar la resiliència.

**Passos integrats de reflexió**:
1. Explica què és un service mesh i per què és necessari quan tens molts microserveis.
2. Configura un canary deployment amb Istio VirtualService i DestinationRule. Entén cada camp.
3. Injecta un retard de 5 segons en un servei i observa com el circuit breaker reacciona.

**Secció de reflexió**:
- Quin overhead afegeix Istio (CPU, memòria, latència)? Val la pena per a qualsevol projecte?
- Compara Istio amb Linkerd: complexitat vs funcionalitats.
- Com depuraries un problema de comunicació entre serveis amb mTLS activat?

**Alternativa on-premises**: K3s amb Istio o Linkerd. Jaeger per a tracing. Kiali per a visualització del service mesh. Prometheus+Grafana per a mètriques d'Istio.

**Adaptació AWS Academy**: Istio requereix nodes amb més recursos (t3.large mínim, 3 nodes). Costós en crèdits; fer la pràctica intensivament en una sessió.

---

### Repte 34 — Arquitectura serverless completa amb Step Functions

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | Step Functions, Lambda, DynamoDB, S3, SQS, SNS, API Gateway |
| **IaC** | Terraform |
| **Prerequisits** | Repte 23 (recomanat) |

**Descripció**: Dissenyar un workflow complex amb AWS Step Functions per a un procés de negoci (per exemple, processament de comandes d'una botiga online): validació → reserva d'inventari → processament de pagament → enviament de confirmació → actualització d'estat. Implementar compensació (saga pattern) per a rollback si una etapa falla. Incloure branching condicional, paral·lelisme i waitstates.

**Passos integrats de reflexió**:
1. Dissenya l'autòmat d'estats (state machine) complet en paper abans d'implementar-lo.
2. Implementa el saga pattern: si el pagament falla després de reservar l'inventari, cal revertir la reserva.
3. Visualitza l'execució de Step Functions a la consola i identifica colls d'ampolla.

**Secció de reflexió**:
- Quina diferència hi ha entre orquestració (Step Functions) i coreografia (EventBridge)?
- Com gestioneries un timeout a mitja execució? Què passa amb les operacions ja completades?
- Calcula el cost de Step Functions per a 10.000 execucions/dia.

**Alternativa on-premises**: Temporal.io o Apache Airflow per a orquestració de workflows. Microserveis en Docker Compose amb cues RabbitMQ per a comunicació.

**Adaptació AWS Academy**: Step Functions funciona amb `LabRole`. Molt visual i didàctic amb la consola AWS.

---

### Repte 35 — Cluster EKS amb Karpenter per autoescalat avançat

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | EKS, EC2 (Spot + On-Demand), CloudWatch |
| **IaC** | Terraform + Karpenter |
| **Prerequisits** | Repte 17 (necessari) |

**Descripció**: Configurar Karpenter a EKS per a autoescalat de nodes intel·ligent. Definir NodePools amb restriccions (tipus d'instància, zones de disponibilitat, Spot vs On-Demand). Configurar consolidació automàtica (compactar pods en menys nodes). Desplegar una aplicació amb HPA + Karpenter i fer proves de càrrega per observar l'escalat.

**Passos integrats de reflexió**:
1. Explica la diferència entre Cluster Autoscaler i Karpenter. Per què Karpenter és millor per a certs escenaris?
2. Configura un NodePool amb instàncies Spot i observa què passa quan AWS reclama una instància.
3. Fes una prova de càrrega progressiva i documenta com Karpenter escala (temps de reacció, tipus d'instància triat).

**Secció de reflexió**:
- Quins riscos tenen les instàncies Spot? Com mitigues la interrupció?
- Com decideix Karpenter quin tipus d'instància llançar? Quins factors considera?
- Calcula l'estalvi de Spot vs On-Demand per a una càrrega variable.

**Alternativa on-premises**: K3s amb autoescalat manual (scripts que creen VMs a Proxmox basats en mètriques de Prometheus). No hi ha equivalent directe de Spot.

**Adaptació AWS Academy**: Karpenter pot tenir problemes amb els permisos de `LabRole` per crear instàncies. Alternativa: usar Cluster Autoscaler amb managed node groups.

---

### Repte 36 — Aplicació multi-regió amb DynamoDB Global Tables i Route53 failover

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | DynamoDB (Global Tables), Lambda, API Gateway, Route53, CloudFront, S3 |
| **IaC** | Terraform |
| **Prerequisits** | Repte 7 (recomanat) |

**Descripció**: Desplegar una aplicació serverless en dues regions AWS (per exemple, eu-west-1 i us-east-1). DynamoDB Global Tables replica les dades automàticament entre regions. Cada regió té la seva pròpia API Gateway + Lambda. Route53 amb health checks i failover routing dirigeix el tràfic a la regió activa. CloudFront distribueix el frontend globalment.

**Passos integrats de reflexió**:
1. Dibuixa el diagrama d'arquitectura multi-regió amb els fluxos de dades i tràfic.
2. Simula el fallo d'una regió (desactivant l'API d'una) i mesura el temps de failover.
3. Escriu dades a una regió i verifica la replicació a l'altra. Mesura la latència de replicació.

**Secció de reflexió**:
- Quins problemes de consistència pot causar la replicació asíncrona entre regions?
- Quin és el RPO (Recovery Point Objective) i RTO (Recovery Time Objective) d'aquesta arquitectura?
- Duplicar la infraestructura a dues regions duplica el cost? Quins costos són addicionals?

**Alternativa on-premises**: Dues infraestructures en datacenters/VPS diferents amb CockroachDB (replicació multi-master), HAProxy/Nginx per failover, rsync per fitxers estàtics.

**Adaptació AWS Academy**: Pot ser difícil treballar amb múltiples regions a Learner Lab. Alternativa: simular amb dues VPCs a la mateixa regió i documentar com seria en multi-regió.

---

### Repte 37 — Desplegament de Vault (HashiCorp) a EKS per gestió de secrets

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | EKS, EBS (per Vault storage), KMS, DynamoDB (backend Vault) |
| **IaC** | Terraform + Helm |
| **Prerequisits** | Repte 17 (necessari) |

**Descripció**: Desplegar HashiCorp Vault en mode HA (High Availability) a EKS amb storage backend a DynamoDB (o Raft integrat). Configurar auto-unseal amb AWS KMS. Implementar els següents use cases: (1) secrets estàtics per a aplicacions, (2) credencials dinàmiques de base de dades (RDS), (3) PKI per generar certificats TLS, (4) Vault Agent Injector per injectar secrets als pods.

**Passos integrats de reflexió**:
1. Explica el procés d'unseal de Vault i per què és crític per a la seguretat.
2. Configura un secret engine manualment via CLI i entén el model de permisos (policies).
3. Implementa credencials dinàmiques de RDS i observa com Vault les crea i revoca automàticament.

**Secció de reflexió**:
- Per què Vault i no AWS Secrets Manager o Parameter Store? Quan usaries cadascun?
- Quins riscos de seguretat hi ha si Vault es compromet? Com mitigues l'impacte?
- Com gestionaries la rotació de secrets per a aplicacions que ja estan en producció?

**Alternativa on-premises**: Vault en Docker Compose amb backend Raft, auto-unseal amb Transit (un segon Vault) o amb fitxer de claus segur. PKI amb easy-rsa o step-ca com a alternativa lleugera.

**Adaptació AWS Academy**: KMS funciona amb `LabRole`. DynamoDB com a backend de Vault funciona. Alternativa: usar backend Raft (integrat en Vault) per no dependre de DynamoDB.

---

### Repte 38 — Desplegament de MediaWiki/Wiki.js a EKS amb cerca avançada (OpenSearch)

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, RDS (PostgreSQL/MySQL), OpenSearch, S3, EFS |
| **IaC** | Terraform + Helm |
| **Prerequisits** | Repte 17 (recomanat) |

**Descripció**: Desplegar Wiki.js o MediaWiki a EKS amb RDS per a la base de dades i OpenSearch per a cerca de text complet. Configurar backups automàtics a S3. Implementar SSO amb un IdP (Cognito o Keycloak del repte 22). Optimitzar OpenSearch per a cerca multiidioma.

**Passos integrats de reflexió**:
1. Investiga com funciona la indexació de text complet i per què una BD relacional no és suficient per a cerques avançades.
2. Configura l'índex d'OpenSearch manualment amb mappings adequats per al contingut wiki.
3. Prova cerques amb i sense OpenSearch i compara la qualitat dels resultats i la velocitat.

**Secció de reflexió**:
- Per què OpenSearch i no simplement PostgreSQL Full Text Search?
- Quin cost afegeix OpenSearch a l'arquitectura? Es justifica per a una wiki petita?
- Com sincronitzaries el contingut de la BD amb l'índex d'OpenSearch? Quins problemes poden sorgir?

**Alternativa on-premises**: Wiki.js/MediaWiki amb Docker Compose, PostgreSQL, OpenSearch (o Meilisearch com a alternativa lleugera). Backups amb borgbackup.

**Adaptació AWS Academy**: OpenSearch Service pot no estar disponible; alternativa: desplegar OpenSearch com a pod dins d'EKS (node amb prou memòria). Limitar el tamany del cluster OpenSearch.

---

### Repte 39 — CI/CD complet amb ArgoCD + Tekton/GitHub Actions a EKS

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | EKS, ECR, S3 |
| **IaC** | Terraform + ArgoCD + Tekton/GitHub Actions |
| **Prerequisits** | Repte 32 (recomanat) |

**Descripció**: Implementar un pipeline CI/CD complet: GitHub Actions (o Tekton a EKS) fa la part CI (build, test, push imatge a ECR) i ArgoCD fa la part CD (desplegament a EKS via GitOps). Implementar image promotion entre entorns (dev → staging → prod), image signing amb cosign, i vulnerability scanning amb Trivy.

**Passos integrats de reflexió**:
1. Dissenya el flux complet CI → CD amb totes les etapes. Identifica on acaba CI i comença CD.
2. Configura image signing amb cosign i explica per què és important per a la supply chain security.
3. Fes un scan amb Trivy d'una imatge amb vulnerabilitats conegudes i decideix quines acceptar i quines no.

**Secció de reflexió**:
- Què és supply chain security i per què és important en un pipeline CI/CD?
- Com gestionaries un hotfix urgent que necessita saltar-se el procés normal?
- Compara Tekton amb GitHub Actions: quan usaries cada opció?

**Alternativa on-premises**: Gitea + Woodpecker CI per CI, ArgoCD per CD. Harbor per a registre d'imatges amb scanning integrat. cosign per signing.

**Adaptació AWS Academy**: GitHub Actions és extern i gratuït. ArgoCD i ECR funcionen a EKS amb `LabRole`.

---

### Repte 40 — Desplegament d'una aplicació amb base de dades Aurora Serverless i caching ElastiCache

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 6-7 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | Aurora Serverless, ElastiCache (Redis), ECS (Fargate), ALB, CloudWatch |
| **IaC** | Terraform |
| **Prerequisits** | Cap |

**Descripció**: Desplegar una aplicació web (Django/Rails/Laravel) a ECS Fargate amb Aurora Serverless v2 com a base de dades (escala automàticament) i ElastiCache Redis per a caching de sessions i queries. Implementar el patró cache-aside (lazy loading). Monitoritzar la cache hit ratio i l'escalat d'Aurora.

**Passos integrats de reflexió**:
1. Implementa el patró cache-aside manualment al codi de l'aplicació. Explica quan s'invalida la cache.
2. Compara el rendiment de l'aplicació amb i sense caching (temps de resposta, queries a BD).
3. Observa com Aurora Serverless escala amb càrrega variable i documenta el comportament.

**Secció de reflexió**:
- Quins problemes pot causar una cache mal invalidada? Com els detectaries?
- Per què Aurora Serverless i no RDS provisionat? Quins escenaris afavoreixen cadascun?
- Calcula el cost de la solució per a tràfic baix vs tràfic alt. Quan surt a compte serverless?

**Alternativa on-premises**: PostgreSQL amb PgBouncer per connection pooling, Redis local per caching, Docker Compose per a l'aplicació. No hi ha equivalent directe de l'autoescalat de BD.

**Adaptació AWS Academy**: Aurora Serverless pot no estar disponible; alternativa: RDS amb instància petita. ElastiCache pot requerir VPC configurada correctament. Si no disponible, Redis en un contenidor.

---

### Repte 41 — Observabilitat completa: mètriques, logs i traces a EKS

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, CloudWatch Container Insights, X-Ray, OpenTelemetry |
| **IaC** | Terraform + Helm |
| **Prerequisits** | Repte 17 i 20 (recomanats) |

**Descripció**: Implementar els tres pilars de l'observabilitat a EKS: (1) Mètriques amb Prometheus + Grafana, (2) Logs amb Fluentbit + Loki (o CloudWatch Logs), (3) Traces amb OpenTelemetry + Jaeger (o AWS X-Ray). Instrumentar una aplicació amb 3+ microserveis per generar traces distribuïts. Crear dashboards unificats a Grafana que correlacionin mètriques, logs i traces.

**Passos integrats de reflexió**:
1. Explica la diferència entre mètriques, logs i traces amb exemples concrets del teu sistema.
2. Instrumenta una aplicació amb OpenTelemetry manualment (no auto-instrumentation) per entendre què es captura.
3. Segueix una petició de principi a fi a través dels 3 microserveis i diagnostica un coll d'ampolla.

**Secció de reflexió**:
- Per què necessitem els tres pilars? No n'hi ha prou amb logs?
- Quin overhead afegeix l'observabilitat al cluster? Com el minimitzaries?
- Compara una solució self-hosted (Prometheus+Loki+Jaeger) amb serveis managed (CloudWatch+X-Ray).

**Alternativa on-premises**: Prometheus + Grafana + Loki + Tempo (o Jaeger) + OpenTelemetry Collector. Tot en Docker Compose o K3s. Grafana com a dashboard unificat.

**Adaptació AWS Academy**: L'stack d'observabilitat funciona dins d'EKS. Pot consumir molts recursos; usar nodes t3.large o dedicar un node per a l'stack.

---

### Repte 42 — Desplegament de Mastodon a EKS amb tots els serveis AWS

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, RDS (PostgreSQL), ElastiCache (Redis), S3, SES, Route53, CloudFront |
| **IaC** | Terraform + Helm |
| **Prerequisits** | Repte 17 (necessari) |

**Descripció**: Desplegar Mastodon (xarxa social federada) a EKS amb tots els serveis gestionats: PostgreSQL a RDS, Redis a ElastiCache, imatges/vídeos a S3 amb CloudFront com a CDN, enviament de correus via SES. Configurar els workers de Sidekiq per a processament asíncron. Implementar backups automàtics i monitorització.

**Passos integrats de reflexió**:
1. Investiga l'arquitectura de Mastodon (web, streaming, sidekiq) i entén com es comuniquen els components.
2. Configura el Helm chart de Mastodon ajustant cada valor al teu entorn AWS.
3. Fes una federació de prova (enviar un missatge a una altra instància) i diagnostica problemes si falla.

**Secció de reflexió**:
- Per què Mastodon necessita Redis? Quins components l'utilitzen i per a què?
- Quin cost mensual tindria mantenir una instància de Mastodon per a 100 usuaris a AWS?
- Compara desplegar Mastodon a EKS vs en una sola EC2 amb Docker Compose.

**Alternativa on-premises**: Docker Compose amb PostgreSQL, Redis, MinIO (S3), Mailpit (per testing d'email). Nginx amb Let's Encrypt.

**Adaptació AWS Academy**: SES pot no estar disponible; usar Mailpit o SMTP de prova. ElastiCache pot no estar disponible; Redis en un pod. Limitar l'ús a 1-2 hores per conservar crèdits.

---

### Repte 43 — Disaster Recovery: backup i restauració multi-servei

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | S3 (Cross-Region Replication), RDS (snapshots), EBS (snapshots), Lambda, Step Functions, DynamoDB |
| **IaC** | Terraform |
| **Prerequisits** | Repte 4 (recomanat) |

**Descripció**: Dissenyar i implementar un pla de Disaster Recovery per a una infraestructura completa (EC2, RDS, S3, DynamoDB). Automatitzar backups amb Step Functions que orquestren: snapshots d'EBS, snapshots de RDS, backups de DynamoDB a S3, i replicació cross-region de S3. Crear un runbook de restauració i **practicar-lo** restaurant tot a una altra VPC/regió.

**Passos integrats de reflexió**:
1. Defineix el RPO i RTO per a cada component i justifica els valors.
2. Practica la restauració completa i mesura el temps real. Compara amb el RTO objectiu.
3. Identifica les dependències entre components durant la restauració (ordre correcte).

**Secció de reflexió**:
- Quina diferència hi ha entre backup i Disaster Recovery? Per què un backup no és suficient?
- Com provaries el teu pla de DR sense afectar producció?
- Quin és el cost d'emmagatzemar backups durant un any? Com l'optimitzaries amb lifecycle policies?

**Alternativa on-premises**: Restic/borgbackup amb repositoris remots (Backblaze B2, rsync.net). Scripts d'orquestració amb Ansible. Documentar i practicar el procés de restauració.

**Adaptació AWS Academy**: Treballar dins d'una sola regió simulant la restauració en una altra VPC. Cross-Region Replication pot no estar disponible.

---

### Repte 44 — API GraphQL serverless amb AppSync/Lambda, Cognito i DynamoDB

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 7-8 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | AppSync (o API Gateway + Lambda), Cognito, DynamoDB, S3 |
| **IaC** | Terraform |
| **Prerequisits** | Repte 18 (recomanat) |

**Descripció**: Construir una API GraphQL completa (amb queries, mutations i subscriptions en temps real) per a una aplicació de gestió de projectes (estil Trello simplificat). Autenticació amb Cognito (usuaris registrats + API key per a públic). Resolvers connectats a DynamoDB amb relacions entre entitats (projectes → tasques → comentaris).

**Passos integrats de reflexió**:
1. Dissenya l'esquema GraphQL complet (types, queries, mutations, subscriptions) abans d'implementar.
2. Implementa les relacions entre entitats a DynamoDB sense usar JOINs. Explica el patró (single-table design o múltiples taules).
3. Testa les subscriptions en temps real amb dos clients i verifica la latència.

**Secció de reflexió**:
- Quina diferència hi ha entre REST i GraphQL? Quan escolliries cadascun?
- Quins problemes de rendiment pot causar GraphQL (N+1 queries)? Com els resols?
- Per què subscriptions i no WebSockets directament? Quines limitacions tenen les subscriptions de GraphQL?

**Alternativa on-premises**: Apollo Server (Node.js) amb PostgreSQL (Prisma ORM) o MongoDB. Subscriptions amb WebSocket. Autenticació amb JWT.

**Adaptació AWS Academy**: Si AppSync no està disponible, implementar GraphQL amb Lambda + apollo-server-lambda. Tot funciona amb `LabRole`.

---

### Repte 45 — Network Policies i seguretat a EKS amb Calico

| Camp | Valor |
|------|-------|
| **Dificultat** | Difícil |
| **Temps estimat** | 6-7 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | EKS, EC2 |
| **IaC** | Terraform + Calico policies |
| **Prerequisits** | Repte 17 (necessari) |

**Descripció**: Endurecer la seguretat d'un cluster EKS amb Calico: (1) Network Policies per aïllar namespaces i restringir comunicacions entre pods, (2) Pod Security Standards (restricted), (3) RBAC amb ServiceAccounts dedicats per a cada aplicació, (4) Falco per a detecció d'anomalies en temps real. Demostrar que les polítiques funcionen intentant comunicacions no autoritzades.

**Passos integrats de reflexió**:
1. Dissenya la matriu de comunicació entre pods/namespaces ABANS d'escriure les polítiques.
2. Implementa polítiques deny-all per defecte i obre només el necessari. Verifica cada regla.
3. Intenta violar cada política i documenta com el sistema la bloqueja.

**Secció de reflexió**:
- Per què és important aplicar el principi de mínim privilegi a nivell de xarxa?
- Quins atacs es prevenen amb Network Policies que no es prevenen amb Security Groups?
- Com detectaries un pod compromès dins del cluster? Per què Falco és útil aquí?

**Alternativa on-premises**: K3s amb Calico CNI, OPA/Gatekeeper per a polítiques d'admissió, Falco per detecció. RBAC natiu de Kubernetes.

**Adaptació AWS Academy**: Instal·lar Calico com a add-on a EKS. Falco pot consumir recursos; instal·lar-lo en un node dedicat o limitar els recursos.

---

## Nivell 4: Molt Difícil (5 reptes)

---

### Repte 46 — Plataforma PaaS interna amb Kubernetes (estil Heroku)

| Camp | Valor |
|------|-------|
| **Dificultat** | Molt difícil |
| **Temps estimat** | 8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, ECR, RDS, S3, Route53, ALB |
| **IaC** | Terraform + Kubernetes Operators/Helm |
| **Prerequisits** | Repte 17 i 32 (necessaris) |

**Descripció**: Construir una plataforma PaaS interna sobre EKS que permeti als desenvolupadors desplegar aplicacions amb un simple `git push`. Components: (1) Buildpacks (Paketo) per construir imatges automàticament, (2) Knative Serving per a desplegaments serverless-like, (3) Flux CD per GitOps, (4) Portal web (aplicació pròpia) amb dashboard d'aplicacions, logs i mètriques. El desenvolupador fa push, el sistema construeix, desplega i configura el domini automàticament.

**Passos integrats de reflexió**:
1. Dissenya el flux complet des del `git push` fins a l'aplicació accessible per URL. Cada pas ha d'estar justificat.
2. Construeix una imatge amb Paketo Buildpacks sense Dockerfile i entén les diferències amb Docker build.
3. Desplega 3 aplicacions (Node.js, Python, Go) i verifica que la plataforma les gestiona totes correctament.
4. Identifica i documenta els 5 punts de fallada més probables de la plataforma i proposa mitigacions.

**Secció de reflexió**:
- Per què una empresa construiria un PaaS intern en lloc d'usar Heroku/Railway/Render?
- Quin és el cost de manteniment d'una plataforma així vs pagar per un PaaS comercial?
- Com gestionaries el multitenancy (aïllament entre equips) a la plataforma?
- Quines funcionalitats de producció falten (que tu no has implementat) per fer-la production-ready?

**Alternativa on-premises**: K3s amb Buildpacks, Knative o OpenFaaS, Flux CD, Gitea. Portal amb Backstage (Spotify) o Portainer. Tot a Proxmox amb VMs.

**Adaptació AWS Academy**: Costós en recursos. Usar nodes t3.large. Buildpacks i Knative consumeixen memòria. Limitar a 2-3 aplicacions desplegades.

---

### Repte 47 — Arquitectura event-driven completa amb CQRS i Event Sourcing

| Camp | Valor |
|------|-------|
| **Dificultat** | Molt difícil |
| **Temps estimat** | 8 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | EKS, DynamoDB (event store), SQS, SNS, Lambda, API Gateway, ElastiCache, S3 |
| **IaC** | Terraform |
| **Prerequisits** | Repte 23 i 34 (recomanats) |

**Descripció**: Implementar una aplicació de gestió d'inventari amb els patrons CQRS (Command Query Responsibility Segregation) i Event Sourcing. El write-side rep comandes (Lambda) i genera events immutables a DynamoDB (event store). Events es publiquen via SNS a múltiples consumers: (1) projector que actualitza la read-database (DynamoDB read model), (2) notificador, (3) analytics a S3. La query-side llegeix del read model optimitzat. Frontend a EKS o S3.

**Passos integrats de reflexió**:
1. Explica CQRS i Event Sourcing amb un exemple real (no copiat) i per què resolen problemes que CRUD no pot.
2. Implementa el "replay" d'events: reconstrueix l'estat complet d'una entitat a partir dels seus events.
3. Afegeix un nou projector (nova vista de lectura) i demostra que no cal modificar el write-side.
4. Identifica els trade-offs: consistència eventual, complexitat, debugging.

**Secció de reflexió**:
- Per què Event Sourcing guarda events i no l'estat actual? Quins avantatges reals aporta?
- Com gestionaries un event incorrecte que ja s'ha guardat? (pista: compensating events)
- En quins projectes reals NO usaries CQRS/Event Sourcing? Per què?
- Compara DynamoDB Streams amb SNS/SQS per a la propagació d'events.

**Alternativa on-premises**: EventStoreDB (event store dedicat) o PostgreSQL amb taula d'events append-only. RabbitMQ per a propagació. Projectores en serveis Node.js/Python.

**Adaptació AWS Academy**: Tots els serveis funcionen. L'event store a DynamoDB funciona bé amb mode on-demand. Utilitzar DynamoDB Streams si disponible per a la propagació.

---

### Repte 48 — Cluster EKS federat amb multi-cluster management (Submariner o Skupper)

| Camp | Valor |
|------|-------|
| **Dificultat** | Molt difícil |
| **Temps estimat** | 8 h |
| **Especialitat** | SIS (principal) |
| **Serveis AWS** | EKS (2 clusters), VPC Peering, Route53, S3 |
| **IaC** | Terraform + Submariner/Skupper |
| **Prerequisits** | Repte 17 i 45 (necessaris) |

**Descripció**: Crear dos clusters EKS en VPCs separades connectades amb VPC Peering. Implementar comunicació entre serveis de clusters diferents amb Submariner (L3 networking) o Skupper (L7 Virtual Application Network). Desplegar una aplicació distribuïda: frontend al cluster A, backend al cluster B, base de dades al cluster A. Configurar DNS cross-cluster, failover entre clusters, i monitorització unificada.

**Passos integrats de reflexió**:
1. Justifica per què necessitaries múltiples clusters en lloc d'un de sol amb namespaces separats.
2. Configura Submariner/Skupper pas a pas i entén el model de xarxa que crea.
3. Talla la connexió entre clusters i documenta com es comporta l'aplicació (degradació graciosa vs fallo).
4. Mesura la latència cross-cluster i compara-la amb comunicació dins del mateix cluster.

**Secció de reflexió**:
- Quins escenaris reals justifiquen multi-cluster? (compliance, blast radius, equips independents)
- Compara Submariner amb Skupper: model de xarxa, complexitat, i casos d'ús.
- Com gestionaries els CRDs i Operators que necessiten estar a tots els clusters?
- Quin és el cost de mantenir 2 clusters vs 1 cluster més gran?

**Alternativa on-premises**: Dos K3s clusters en VMs separades amb WireGuard/Tailscale per connectivitat, Skupper per a service mesh multi-cluster. Consul per service discovery.

**Adaptació AWS Academy**: Molt costós (2 control planes EKS + nodes). Alternativa: un EKS real + un K3s dins d'una EC2 com a segon cluster.

---

### Repte 49 — Plataforma de ML/Data amb EKS, S3 i Lambda (MLOps bàsic)

| Camp | Valor |
|------|-------|
| **Dificultat** | Molt difícil |
| **Temps estimat** | 8 h |
| **Especialitat** | DEV (principal) + SIS (secundària) |
| **Serveis AWS** | EKS, S3, Lambda, API Gateway, DynamoDB, ECR, Step Functions |
| **IaC** | Terraform |
| **Prerequisits** | Repte 17 i 34 (recomanats) |

**Descripció**: Construir una plataforma MLOps simplificada: (1) Jupyter Hub a EKS per a experimentació, (2) Pipeline d'entrenament amb Step Functions que llegeix dades de S3, entrena un model (scikit-learn/PyTorch simple), guarda el model a S3, (3) Servei de predicció: el model es desplega com a contenidor a EKS o com a Lambda, (4) API Gateway com a entry point, (5) Monitorització del model (data drift) amb mètriques a CloudWatch.

**Passos integrats de reflexió**:
1. Dissenya el pipeline MLOps complet (dades → entrenament → validació → desplegament → monitorització) i explica cada etapa.
2. Implementa l'entrenament d'un model simple i empaqueta'l per a servei (no importa la qualitat del model, importa la infraestructura).
3. Compara el rendiment de servir el model via Lambda (cold start) vs EKS (persistent).
4. Defineix una estratègia de versionat de models i dades. Justifica-la.

**Secció de reflexió**:
- Per què és important automatitzar l'entrenament i desplegament de models? Què passa si es fa manualment?
- Què és data drift i model drift? Com els detectaries en producció?
- Per què JupyterHub a Kubernetes i no simplement a una EC2?
- Compara aquesta solució amb SageMaker: complexitat, control i cost.

**Alternativa on-premises**: JupyterHub amb Docker, MLflow per a experiment tracking, MinIO per a artefactes, Flask/FastAPI per servir models, Airflow per a pipelines. Tot en Docker Compose o K3s.

**Adaptació AWS Academy**: JupyterHub requereix nodes amb prou memòria. Step Functions funciona bé. Si el model és gran, usar Lambda amb contenidors d'imatges (fins a 10 GB).

---

### Repte 50 — Infraestructura completa com a producte: multi-entorn, CI/CD, observabilitat i DR

| Camp | Valor |
|------|-------|
| **Dificultat** | Molt difícil |
| **Temps estimat** | 8 h |
| **Especialitat** | SIS (principal) + DEV (secundària) |
| **Serveis AWS** | EKS, RDS, ElastiCache, S3, CloudFront, Route53, Cognito, Lambda, CloudWatch, ECR |
| **IaC** | Terraform (mòduls reutilitzables) |
| **Prerequisits** | Reptes 17, 19, 32, 41, 43 (recomanats) |

**Descripció**: Integrar tot el que s'ha après en un projecte capstone. Desplegar una aplicació web completa (e-commerce, SaaS simplificat, o plataforma educativa) amb: (1) Infraestructura Terraform modular amb 3 entorns (dev/staging/prod), (2) EKS amb l'aplicació en microserveis, (3) GitOps amb ArgoCD, (4) CI/CD amb GitHub Actions, (5) Observabilitat completa (mètriques, logs, traces), (6) Autenticació amb Cognito, (7) CDN amb CloudFront, (8) Pla de DR documentat i provat, (9) Documentació d'arquitectura completa.

**Passos integrats de reflexió**:
1. Dedica la primera hora a planificar l'arquitectura completa en paper. Presenta-la a un company/professor abans de començar a implementar.
2. Pren decisions d'arquitectura i documenta els trade-offs de cada decisió (ADR - Architecture Decision Records).
3. Implementa un chaos experiment (matar un pod, tallar una connexió) i verifica que el sistema es recupera.
4. Calcula el cost mensual total de la infraestructura per als 3 entorns.
5. Presenta el projecte com si fos un producte real: demo + documentació + diagrames.

**Secció de reflexió**:
- Si haguessis de començar de nou, què faries diferent? Per què?
- Quina és la part més fràgil de la teva arquitectura? Com la milloraries amb més temps?
- Quin és el punt d'equilibri entre complexitat i valor? Has sobredimensionat alguna part?
- Com formaries un nou membre de l'equip per mantenir aquesta infraestructura?
- Compara el cost total amb una solució PaaS (Heroku, Railway): quan val la pena construir vs comprar?

**Alternativa on-premises**: Infraestructura completa en Proxmox: K3s, PostgreSQL, Redis, MinIO, Gitea, ArgoCD, Prometheus stack, Keycloak, Nginx. Terraform amb Proxmox provider.

**Adaptació AWS Academy**: Aquest repte és un projecte final que consumirà molts crèdits. Planificar bé els recursos, implementar primer en dev, i desplegar staging/prod només per a la demo final. Documentar què faries en un compte real sense restriccions.

---

## Resum de reptes

| # | Repte | Dificultat | Temps | Especialitat |
|---|-------|-----------|-------|-------------|
| 1 | WordPress a EC2 amb RDS | Fàcil | 4-5 h | SIS + DEV |
| 2 | Web estàtica amb Amplify + Lambda | Fàcil | 4-5 h | DEV + SIS |
| 3 | Contenidors Docker a ECS Fargate | Fàcil | 5-6 h | SIS + DEV |
| 4 | Backup automatitzat amb S3 i Lambda | Fàcil | 4-5 h | SIS |
| 5 | HedgeDoc a ECS amb Cognito | Fàcil | 5-6 h | SIS + DEV |
| 6 | Gestió centralitzada amb Systems Manager | Fàcil | 4-5 h | SIS |
| 7 | Aplicació CRUD serverless completa | Fàcil | 5-6 h | DEV + SIS |
| 8 | Nextcloud a EC2 amb S3 | Fàcil | 5-6 h | SIS |
| 9 | Pipeline CI/CD amb CodePipeline i ECS | Fàcil | 5-6 h | DEV + SIS |
| 10 | Monitorització amb CloudWatch i SNS | Fàcil | 4-5 h | SIS |
| 11 | Cua de missatges: SQS + Lambda | Fàcil | 4-5 h | DEV + SIS |
| 12 | Multi-contenidor amb Docker Compose a EC2 | Fàcil | 4-5 h | SIS + DEV |
| 13 | Web estàtica amb S3, CloudFront i HTTPS | Fàcil | 4 h | DEV + SIS |
| 14 | Automatització amb Lambda i EventBridge | Fàcil | 4-5 h | SIS + DEV |
| 15 | Base de dades DynamoDB amb API REST | Fàcil | 4-5 h | DEV |
| 16 | WordPress a ECS Fargate amb EFS i Cognito | Mitjana | 6-7 h | SIS + DEV |
| 17 | Cluster EKS bàsic amb Ingress | Mitjana | 6-8 h | SIS + DEV |
| 18 | Serverless amb autenticació completa | Mitjana | 6-7 h | DEV + SIS |
| 19 | Infraestructura multi-entorn amb Terraform | Mitjana | 6-7 h | SIS |
| 20 | Grafana + Prometheus a ECS | Mitjana | 6-7 h | SIS + DEV |
| 21 | WebSockets amb API Gateway i Lambda | Mitjana | 6-7 h | DEV |
| 22 | Authentik/Keycloak a ECS com a IdP | Mitjana | 6-7 h | SIS |
| 23 | Arquitectura event-driven amb EventBridge | Mitjana | 6-7 h | DEV + SIS |
| 24 | Gitea + Woodpecker CI a EKS | Mitjana | 7-8 h | SIS + DEV |
| 25 | API Gateway amb microserveis Lambda | Mitjana | 6-7 h | DEV + SIS |
| 26 | Uptime Kuma + Alertmanager a ECS | Mitjana | 5-6 h | SIS |
| 27 | Migració de monòlit a contenidors ECS | Mitjana | 6-7 h | SIS + DEV |
| 28 | Processament d'imatges amb S3 i Lambda | Mitjana | 5-6 h | DEV + SIS |
| 29 | VPC avançada amb subnets i NAT | Mitjana | 5-6 h | SIS |
| 30 | Desplegament blue-green amb ECS i ALB | Mitjana | 6-7 h | SIS + DEV |
| 31 | WordPress multi-tenant a EKS amb Helm | Difícil | 7-8 h | SIS + DEV |
| 32 | GitOps amb ArgoCD a EKS | Difícil | 7-8 h | SIS + DEV |
| 33 | Service mesh (Istio) a EKS | Difícil | 7-8 h | SIS + DEV |
| 34 | Serverless amb Step Functions (Saga) | Difícil | 7-8 h | DEV + SIS |
| 35 | EKS amb Karpenter per autoescalat | Difícil | 7-8 h | SIS |
| 36 | Multi-regió amb DynamoDB Global Tables | Difícil | 7-8 h | SIS + DEV |
| 37 | Vault a EKS per gestió de secrets | Difícil | 7-8 h | SIS |
| 38 | Wiki.js a EKS amb OpenSearch | Difícil | 7-8 h | SIS + DEV |
| 39 | CI/CD amb ArgoCD + Tekton + image signing | Difícil | 7-8 h | DEV + SIS |
| 40 | Aurora Serverless + ElastiCache | Difícil | 6-7 h | DEV + SIS |
| 41 | Observabilitat completa a EKS | Difícil | 7-8 h | SIS + DEV |
| 42 | Mastodon a EKS amb serveis AWS | Difícil | 7-8 h | SIS + DEV |
| 43 | Disaster Recovery multi-servei | Difícil | 7-8 h | SIS |
| 44 | API GraphQL serverless (AppSync) | Difícil | 7-8 h | DEV + SIS |
| 45 | Network Policies i seguretat a EKS | Difícil | 6-7 h | SIS |
| 46 | Plataforma PaaS interna (estil Heroku) | Molt difícil | 8 h | SIS + DEV |
| 47 | CQRS + Event Sourcing complet | Molt difícil | 8 h | DEV + SIS |
| 48 | Multi-cluster EKS federat | Molt difícil | 8 h | SIS |
| 49 | Plataforma MLOps amb EKS | Molt difícil | 8 h | DEV + SIS |
| 50 | Projecte capstone: infraestructura completa | Molt difícil | 8 h | SIS + DEV |

---

## Dependències entre reptes (progressivitat)

Repte 1 (WordPress EC2) ─────────────────────── independent
Repte 3 (ECS Fargate) ──┬── Repte 9 (CI/CD) ── Repte 30 (Blue-Green)
                         ├── Repte 16 (WordPress ECS)
                         ├── Repte 20 (Prometheus ECS)
                         └── Repte 27 (Migració monòlit)
Repte 7 (CRUD serverless) ── Repte 18 (Auth completa) ── Repte 21 (WebSocket)
                              └── Repte 25 (Microserveis Lambda)
Repte 11 (SQS) ── Repte 23 (Event-driven) ── Repte 34 (Step Functions)
                                               └── Repte 47 (CQRS)
Repte 17 (EKS bàsic) ──┬── Repte 24 (Gitea+Woodpecker)
                        ├── Repte 31 (WordPress multi-tenant)
                        ├── Repte 32 (ArgoCD) ── Repte 39 (CI/CD complet)
                        ├── Repte 33 (Istio)
                        ├── Repte 35 (Karpenter)
                        ├── Repte 37 (Vault)
                        ├── Repte 38 (Wiki.js+OpenSearch)
                        ├── Repte 41 (Observabilitat)
                        ├── Repte 42 (Mastodon)
                        ├── Repte 45 (Network Policies)
                        ├── Repte 46 (PaaS intern)
                        ├── Repte 48 (Multi-cluster)
                        ├── Repte 49 (MLOps)
                        └── Repte 50 (Capstone)
Repte 19 (Multi-entorn Terraform) ── Repte 50 (Capstone)
Repte 4 (Backup) ── Repte 43 (Disaster Recovery)

---

## Notes per al professorat

1. **Avaluació de reflexions**: Les seccions de reflexió s'han d'avaluar presencialment (viva voce) o amb resposta escrita a mà. No acceptar respostes generades per IA.

2. **Progressió recomanada**: Començar amb 2-3 reptes fàcils, passar a mitjans, i reservar els difícils per a l'últim trimestre. Els molt difícils són optatius o per a alumnat avançat.

3. **Treball en parelles**: Els reptes difícils i molt difícils es poden fer en parelles, amb rols de "sistemes" i "desenvolupament" repartits.

4. **Gestió de crèdits AWS Academy**: Fer un seguiment setmanal del consum de crèdits. Ensenyar a l'alumnat a apagar recursos amb scripts automatitzats (repte 14).

5. **Documentació**: Cada repte hauria d'anar acompanyat d'un document que inclogui: diagrama d'arquitectura, decisions tècniques, log de troubleshooting, i respostes a les reflexions.

6. **Rúbrica suggerida**: 40% implementació funcional, 20% IaC (Terraform), 20% reflexions, 10% documentació, 10% alternativa on-premises (documentada o implementada).