TS-TIC 2025 practica

La finalitat de la planificació estratègica de SI/TI és alinear les TIC amb els objectius i l'estratègia de l'organització (tema §1), sota el lideratge de l'alta direcció. Un "pla TIC autònom i independent del lideratge i direcció de l'organització" contradiu això mateix i per tant NO és un benefici: és l'oposat de l'alineació. Les altres tres sí són beneficis reals que el tema recull: alinear la inversió amb l'estratègia del negoci, augmentar la implicació de la direcció, i millorar la visibilitat i el reconeixement de les TIC a l'organització.

La correcta és l'opció 3: garantir alhora la qualitat del producte i del projecte, el compliment de terminis, el pressupost i la satisfacció del client. L'èxit d'un projecte estratègic no es redueix a un sol indicador. L'opció 0 és incorrecta perquè restringir els canvis del negoci contradiu l'adaptabilitat que demana un projecte d'alta inversió. L'opció 1 mesura només el ROI al final, cosa que no garanteix l'èxit durant l'execució ni cap altra restricció. L'opció 2 sacrifica terminis i pressupost per la qualitat i, a més, és contradictòria: diu «en cascada» i alhora «acceptant canvis i replantejaments en tot moment», quan el predictiu és precisament l'enfocament que tracta el canvi com a excepció.

Les úniques categories de seguretat que preveu l'ENS (art. 40 i annex I) són Bàsica, Mitjana i Alta, segons el perjudici que causaria un incident a cada dimensió. «Insegura/segura/molt segura», «baixa/intermèdia/avançada» i «fàcil/mitjana/complexa» sonen versemblants però no són termes de la norma: l'ENS no gradua per «facilitat» ni per «seguretat» sinó pel perjudici.

L'art. 31 de l'ENS exigeix una auditoria de seguretat regular ordinària, com a mínim cada dos anys, per verificar el compliment de l'esquema. Les altres opcions inventen figures que l'ENS no preveu (auditoria d'accessibilitat, anàlisi de disponibilitat, anàlisi de despesa): l'ENS audita compliment de seguretat, no accessibilitat ni pressupost.

La correcta és l'opció 1: Inici-Planificació-Execució-Seguiment i Control-Tancament, els cinc grups de processos del PMBOK v6. L'opció 0 substitueix «Seguiment i Control» per «Gestió de riscos», que és una àrea de coneixement, no un grup de processos. L'opció 2 fa servir noms que no són els del PMBOK («Conceptualització», «Avaluació»). L'opció 3 en dona només quatre i hi inclou «Iteració», que no és cap dels cinc grups.

La influència dels interessats sobre les característiques finals del producte és màxima al principi i decreix amb el temps, exactament com recull l'apartat 1 del tema: és l'opció 0. L'opció 1 inverteix el patró de cost i personal, que són baixos a l'inici i assoleixen el màxim durant l'execució, no alts des del primer moment. L'opció 2 inverteix el patró de risc, que és màxim al començament i disminueix a mesura que avança el projecte, no al revés. L'opció 3 nega del tot la influència dels interessats, quan el que canvia és el seu grau, no la seva existència.

Tenir un valor optimista (150.000 €), un de pessimista (300.000 €) i un de més probable (250.000 €) i combinar-los per arribar a una xifra única és, per definició, l'estimació per tres valors (PERT). El judici d'experts és l'opinió d'una persona experta sense aquesta estructura de tres escenaris; l'estimació per punts-funció és paramètrica i mesura la mida funcional del programari, no el pressupost; l'estimació anàloga compara amb projectes anteriors, i aquí no s'hi compara res: s'ha consultat el mercat. La consulta al mercat és d'on surten les dades; la tècnica és què se'n fa.

Cada punt és una tècnica distinta de Recopilar requisits. (1) Una reunió conjunta amb persones interessades i expertes és un grup focal, no una entrevista, que és individual, ni un estudi comparatiu, que compara organitzacions. (2) Recopilar i revisar documentació existent és anàlisi de dades (anàlisi de documents). (3) Una maqueta funcional és un prototip: es mostra abans de construir per obtenir retroalimentació. (4) Un formulari web per recollir l'opinió de moltes persones usuàries és una enquesta. Les altres tres opcions encerten un o dos punts i intercanvien precisament el prototip amb l'enquesta, que és la confusió que es busca.

La matriu de traçabilitat de requisits és l'única eina que vincula els requisits des del seu origen (objectius) fins als entregables, passant pel disseny i els casos de prova: és exactament «la visió completa i la correspondència» que descriu l'enunciat. La matriu RASCI reparteix responsabilitats entre persones, la de riscos creua probabilitat i impacte, i la d'avaluació d'involucració compara el nivell de participació actual amb el desitjat de cada persona interessada: cap de les tres no relaciona requisits amb lliurables.

La correcta és l'opció 3: volatilitat. Un ERP es caracteritza precisament pel contrari: dades persistents, traçables i auditables sobre una base de dades única, no volàtils. Les altres tres sí que són característiques pròpies d'un ERP: l'opció 0 (modularitat, s'implanta per mòduls), l'opció 1 (integració, els mòduls comparteixen dades) i l'opció 2 (adaptabilitat, es parametritza per ajustar-lo a l'organització).

Estructurar el treball i desglossar-lo en tasques per poder avaluar després terminis i costos és crear l'EDT/WBS. La clau està a triar entre les dues opcions que parlen d'EDT: per la regla del 100 %, l'EDT ha d'incloure tot el treball del projecte, també el de direcció del projecte, i no es limita al pressupost, els riscos i les persones interessades. La matriu de riscos no desglossa l'abast, i el cronograma ordena en el temps un treball que l'EDT ja ha definit: primer es descompon, després es calendaritza.

S'enumeren tots els camins i se sumen les durades: A-B-D-E = 2+3+1+2 = 8; A-B-D-G = 2+3+1+3 = 9; A-C-D-E = 7; A-C-D-G = 8; i A-C-F-H = 2+2+4+2 = 10. El camí més llarg és ACFH amb 10 mesos, i per això marca la durada mínima del projecte. Les altres opcions donen també 10 mesos, però sobre camins que no sumen 10 (ABDGH i ABDEH sumen 11 i 10 comptant una H que no depèn ni de G ni d'E) o que no existeixen a la taula: H té com a predecessora F i només F, de manera que ACFGH no és un camí de la xarxa.

El camí crític és la seqüència més llarga d'activitats i, precisament per ser la més llarga, determina la durada mínima del projecte: no es pot acabar abans. No té res a veure amb els recursos assignats (A), ni amb les tasques paral·leles —que justament són les que tenen folgança i no són crítiques (C)—, ni amb el risc o el benefici (D), que són criteris de priorització, no de xarxa.

És una pregunta en negatiu i l'opció incorrecta falla dues vegades. Primera: limitar el conjunt d'interessats als imprescindibles és el contrari de la bona pràctica, que és identificar-los tots i no un conjunt limitat. Segona: quedar-se només amb els aspectes positius de les seves aportacions contradiu la pràctica de capturar tant el positiu com el negatiu, perquè una objecció detectada aviat val més que un aplaudiment. Les altres tres sí que són tendències recollides a la guia: revisar periòdicament la comunitat d'interessats, cocrear amb els més afectats pel treball i pels resultats, i capturar el positiu i el negatiu.

Els tres conceptes de l'enunciat es corresponen amb la jerarquia de costos del PMBOK: els recursos aprovats a l'inici del projecte, disponibles al contracte adjudicat, són la línia base de costos; l'ampliació del 20 % prevista per fer front a riscos, encara no realitzada ni aprovada en comitè, és la reserva; i el total dels recursos previstos, que inclou les dues anteriors, és el pressupost del projecte. Aquesta darrera relació és literal: el pressupost del projecte és sempre la suma de la línia base de costos més les reserves, mai a l'inrevés.

El risc 1 (migració CPD corporatiu) queda explícitament fora de l'abast del projecte i es trasllada a la Direcció IMI: això és "Escalar". El risc 2 (desconeixement de l'entorn analític) es resol incorporant-lo a la gestió del canvi, és a dir, eliminant la causa del problema: això és "Evitar". El risc 3 (incertesa del producte resultat) es tracta amb un prototip com a acció preventiva, l'exemple clàssic de reduir probabilitat i impacte: això és "Mitigar". Les altres combinacions intercanvien aquestes tres estratègies entre riscos que no els corresponen.

Un SPI de 0,9, per sota d'1, indica que la quantitat de treball realitzat és inferior a la prevista i que el projecte va endarrerit respecte al cronograma. Les opcions que parlen de costos i pressupost confonen l'SPI amb el CPI; l'opció d'avançament inverteix el significat d'un SPI inferior a 1.

Amb el camí crític endarrerit però amb marge de recursos —el consum és inferior a l'esperat—, la tècnica adequada és la intensificació (crashing): afegir recursos disponibles a les activitats del camí crític per escurçar-ne la durada. Reduir l'abast o ampliar el termini no recuperen el temps perdut sense canviar el compromís del projecte, i no actuar sobre el camí crític deixa el retard sense corregir quan hi ha recursos de sobres per fer-ho.

Redactar el pla per a la direcció del projecte és una activitat de planificació, molt anterior al tancament: per això és la sortida INCORRECTA per a aquesta fase. Actualitzar la documentació, gestionar la transferència de coneixement i mesurar la satisfacció dels interessats sí que són activitats pròpies del tancament del projecte.

Segons la Guia Scrum, els pilars són Transparència, Inspecció i Adaptació. Les altres tres combinacions (innovació/implicació/avaluació, voluntarisme/aprenentatge/servei, flexibilitat/experimentació/gestió) no corresponen als termes oficials de la Guia.

La relació correcta és «Unitat cohesionada de professionals enfocats a l'objectiu del producte» = Scrum Team: és la definició mateixa de l'equip. Les altres tres barregen els rols: garantir que se segueix Scrum és de l'Scrum Master (no del Product Owner), definir i comunicar els requeriments és del Product Owner (no dels Developers), i crear el pla de l'Sprint és dels Developers (no de l'Scrum Master).

La relació correcta és 1-Daily Scrum (inspecciona el progrés i adapta el Sprint Backlog), 2-Sprint Review (presenta i inspecciona el resultat) i 3-Sprint Retrospective (identifica millores de qualitat i eficàcia). Les altres combinacions intercanvien parells d'esdeveniments amb el propòsit d'un altre.

L'afirmació correcta és que el gràfic representa a l'eix horitzontal els dies de l'Sprint i a l'eix vertical el treball restant en punts d'història. Les altres opcions inverteixen els eixos, o interpreten malament el pendent: una baixada menys vertical de la prevista significa que s'avança més lentament, no que s'ha fet més feina; i una pujada del pendent significa que ha entrat treball nou o s'ha reestimat a l'alça, no que «el treball planificat porta més temps» (que seria, en tot cas, una baixada més lenta, no una pujada).

Segons la Llei 40/2015, les administracions han de respectar els principis de cooperació, col·laboració i coordinació interadministrativa per oferir serveis digitals integrats (opció D). No es tracta de competència i jerarquia institucional (opció A, que descriu relacions diferents), ni d'autonomia i externalització tecnològica (opció B, inventada), ni de centralització i unificació obligatòria (opció C, contrària a l'esperit de col·laboració entre administracions autònomes).

Segons la Llei 40/2015 (art. 157), les administracions han de posar a disposició d'altres administracions les aplicacions que desenvolupin per a la seva reutilització (opció A). No les han de registrar com a patents d'ús exclusiu (opció B, contrari al principi de reutilització), ni vendre-les a empreses privades (opció C, inventat), ni replantejar-se-les a cada mandat (opció D, sense base normativa).

El requisit tècnic per garantir seguretat i interoperabilitat segons la Llei 40/2015 és el compliment de l'ENS i l'ENI (opció C). No és l'ús prioritari de programari propietari compartit (opció A, contrari a l'esperit obert d'aquestes normes), ni la desconnexió dels sistemes en xarxa (opció B, que impediria precisament compartir informació), ni l'ús de formats tancats (opció D, contrari a la interoperabilitat, que exigeix estàndards oberts).

L'Sprint anterior, 3 persones van completar 18 punts (6 punts/persona). Amb 4 persones, la capacitat prevista és 4 × 6 = 24 punts. Per importància (Alta abans que Mitja, abans que Baixa): A (12) + B (10) = 22, i encara hi caben els 2 de C (Mitja) sense superar els 24 → A-B-C = 24. Afegir D o E superaria la capacitat disponible.

La UNE 166000:2006 té per finalitat definir la terminologia i les definicions de les activitats de R+D+i, base comuna de tota la família de normes. La contractació pública de projectes d'I+D+i la regula la LCSP, no aquesta norma; la propietat intel·lectual de patents és matèria d'una altra norma (UNE 166008, transferència de tecnologia, o la legislació de patents); i cap norma UNE 166000 certifica la qualitat ambiental de productes.

El registre de lliçons apreses és la sortida del tancament que s'incorpora al repositori de coneixement de l'organització i que serveix per millorar la gestió de futurs projectes. L'acta de constitució i el manual de funcionament són documents específics d'aquest projecte, no d'aprenentatge organitzatiu; el registre de canvis aprovats és una eina de control, no de millora contínua.

La transformació digital implica canvis en l'estratègia, en els mètodes de treball i en les capacitats de les persones: la tecnologia n'és l'habilitador, no la finalitat. Per això no es resol contractant una consultora (A), ni adquirint les tendències tecnològiques del mercat (B), ni tractant-la com un procés principalment tecnològic per combatre l'obsolescència (D).

El tema defineix el valor com la suma d'utilitat i garantia (apartat 1.1: «Valor = utilitat + garantia»), totes dues percebudes pel client. Reduir-lo només al cost (A), a la disponibilitat tècnica (C) o considerar-lo fix i independent de la percepció (D) contradiu directament aquesta definició, que exigeix combinar dos factors i que sempre és percebut pel client.

Segons l'apartat 5.4 del tema, els recursos són entrades tangibles que es compren (persones, diners, tecnologia) i les capacitats són habilitats intangibles per utilitzar aquests recursos i generar valor, que es desenvolupen amb el temps. Les altres tres opcions inverteixen aquesta definició o neguen que hi hagi diferència.

La definició literal d'ITIL v3 —«base de dades o document estructurat amb informació sobre tots els serveis TI en explotació, incloent-hi els preparats per al desplegament»— és el catàleg de serveis. La CMDB i el CMS emmagatzemen elements de configuració, no informació de serveis orientada a client i usuari; i no existeix a ITIL cap «base de dades de coneixement centralitzada per al Service Desk» amb aquest nom. Nota sobre l'enunciat oficial, que no es reescriu: l'opció 0 desenvolupa CMDB com a «Change Management Data Base», i el desenvolupament correcte és «Configuration Management Database». L'errada és del text de l'examen, no del corpus.

Assegurar que un servei nou o modificat compleix els requisits definits abans de ser desplegat és exactament el propòsit de Validació i proves del servei. La gestió del canvi autoritza i planifica el canvi, però no en comprova el compliment tècnic; la gestió del coneixement transfereix informació i experiència als equips; i la gestió de la configuració manté el registre dels elements i les seves relacions. Cap d'aquestes tres prova res.

El «pensament basat en el risc» de la ISO 9001 no elimina els riscos ni bloqueja el canvi: exigeix planificar accions per abordar riscos i oportunitats, tal com recull el tema a l'apartat de Planificació de l'Annex SL (§2.1, punt 6). Les auditories mensuals són una eina de seguiment, no la resposta al pensament basat en risc.

El tema (§1) diu que l'alta direcció ha d'assumir la responsabilitat i l'obligació de retre comptes de l'eficàcia del sistema de gestió de la qualitat. Redactar manuals, fer auditories internes o controlar proveïdors són tasques operatives que pot delegar; l'eficàcia del sistema, no.

La gestió del nivell de servei (SLM), un dels processos de provisió del servei que llista el tema (§2.1, 8.2), consisteix a establir i gestionar els acords de nivell de servei amb els clients: què s'ofereix i amb quina qualitat. Ni la seguretat, ni l'automatització dels informes, ni el control d'accessos en són l'objectiu; són matèria d'altres processos.

Correcta (índex 0): segons ISO/IEC 20000-1, la gestió de la disponibilitat ha d'assegurar que els serveis compleixin els requisits de rendiment i temps d'activitat acordats — la norma exigeix documentar els requisits i objectius de disponibilitat del servei. Les altres tres pertanyen a altres processos de la norma: gestionar queixes (opció 1) és gestió de queixes/incidents; controlar costos (opció 2) és gestió financera dels serveis; establir polítiques de seguretat (opció 3) és gestió de la seguretat de la informació.

La gestió d'incidents pertany al domini d'Operació del Servei (ITIL v3): és allà on es viu el dia a dia del servei ja en producció. La disponibilitat i la capacitat són processos de Disseny del Servei —es planifiquen abans, no s'operen— i la gestió del canvi és de Transició del Servei. Cap dels altres tres encaixa a l'Operació.

Davant incidències recurrents, cal derivar-les a la Gestió de Problemes perquè n'investigui la causa arrel: és exactament la funció d'aquesta pràctica. Tancar les incidències per obrir un registre de problema (D) no és correcte perquè un problema no substitueix les incidències, hi conviu; crear una sol·licitud de servei (B) és per a peticions estàndard, no per investigar causes; i assignar-les sempre al mateix equip (C) no ataca la causa, només en trasllada la càrrega.

Segons ITIL v3 el Centre d'Atenció a l'Usuari ha de ser el punt únic de contacte -SPOC, Single Point of Contact- per a les persones usuàries (opció 1, la correcta). Les altres tres el redueixen a menys del que és o l'estiren cap al que no és: no es limita a registrar i transferir (opció 0), perquè també resol al primer nivell i, sobretot, conserva la titularitat del tiquet encara que l'escali; no és una eina tecnològica que automatitzi la resolució (opció 2), sinó una funció organitzativa que l'eina ITSM només sosté; i no és el responsable dels SLA ni de la configuració de la infraestructura (opció 3), que són la gestió del nivell de servei i la gestió tècnica.

El Service Desk d'ITIL v3 coordina la gestió d'incidències, manté la CMDB actualitzada sota els procediments acordats amb la gestió de la configuració, i canalitza les peticions de canvi cap a la gestió de canvis (opció 2, la correcta). Compte amb el verb: les canalitza, no les autoritza. Les altres tres el retallen: l'opció 0 el deixa en un derivador al segon nivell, quan primer intenta resoldre; l'opció 3 el deixa en pura comunicació, sense funcions operatives, quan en té de clares -registre, categorització, priorització, diagnòstic, resolució de primer nivell i escalada-; i l'opció 1 és la distractora fina, perquè accepta el punt únic de contacte i només nega la participació en la CMDB, que és justament una de les seves tasques.

El benefici directe d'implantar observabilitat sobre un servei és poder diagnosticar: es passa d'hores de correlació manual entre sistemes a minuts de navegació guiada entre mètriques, registres i traces correlacionats, i això és reduir el temps mitjà de reparació i respondre més de pressa. Les altres tres opcions poden arribar com a conseqüències indirectes, però no són el que aporta l'eina sobre el servei: l'augment de la productivitat és un efecte de segon ordre sobre l'equip, la millora de la seguretat correspon a eines de detecció i resposta d'incidents de seguretat, i la reducció de costos és discutible perquè la pròpia plataforma d'observabilitat és una despesa nova que cal governar.

Grafana és l'eina de referència, de codi obert i agnòstica de font de dades, dissenyada específicament per visualitzar mètriques, registres i traces en temps real en entorns d'observabilitat, i s'integra amb Prometheus, Loki, Tempo, Elasticsearch i desenes de fonts més. Les altres tres són eines d'anàlisi i informes de negoci sobre dades ja consolidades: Power BI i Tableau construeixen quadres de comandament corporatius a partir de models de dades preparats, i Excel és un full de càlcul. Cap de les tres consulta telemetria en viu amb els llenguatges propis de l'observabilitat, que és el que demana l'enunciat en dir «en temps real».

És l'ordre exacte de les cinc fases del cicle de vida v3 recollit a l'apartat 5.1 del tema: Estratègia, Disseny, Transició, Operació i Millora Contínua del Servei. Les altres tres opcions alteren aquest ordre.

El tema diu literalment que el PDCA —Plan, Do, Check, Act— és «el model de gestió en què es basa la millora contínua del servei» a ITIL. El Model de Qualitat Total i el Model EFQM són marcs d'excel·lència organitzativa (avaluen l'organització sencera), no el cicle iteratiu de millora del servei; i el CMMI mesura la maduresa dels processos, no defineix cap cicle de millora contínua.

Tal com recull el tema, la diferència clau és que la mètrica és una mesura en brut i l'indicador és una mètrica interpretada respecte d'un objectiu —exactament l'opció D. No hi ha cap divisió entre mètriques qualitatives i indicadors quantitatius (A és fals: totes dues poden ser quantitatives); els indicadors no es fan servir només en auditories (B); i el tema defineix explícitament una diferència, de manera que «no n'hi ha cap» (C) també és fals.

SMTP és el protocol de transport de correu electrònic; no serveix per autenticar ni autoritzar accessos. LDAP, OAuth i Kerberos sí són opcions vàlides d'autenticació o autorització en la gestió d'identitats.

El principi de mínim privilegi es defineix per l'abast dels permisos —estrictament els necessaris per exercir les funcions—, no pel nombre de rols que es poden assignar, ni per restringir l'accés total només a persones administradores, ni per una limitació temporal, que és una bona pràctica addicional però no la definició del principi.

L'àmbit de l'ENS (art. 2) és tot el sector públic i, a més, els proveïdors del sector privat que li presten serveis TIC. «Tots els proveïdors TIC» ho estén sense el requisit de prestar servei al sector públic; «els ciutadans» no hi estan subjectes en cap cas; i «empreses privades de qualsevol sector que gestionin dades sensibles» confon l'ENS amb el RGPD —l'ENS no s'aplica per gestionar dades sensibles, sinó per prestar servei a l'Administració.

Les categories del sistema que fixa l'ENS (art. 40) són Bàsica, Mitjana i Alta. «Pública/privada/confidencial» barreja la idea de confidencialitat de dades; «crítica/essencial/secundària» és terminologia d'infraestructures crítiques (Llei 8/2011), no de l'ENS; i «interna/externa/mixta» no existeix a la norma.

La correcta (opció C) diu que el perjudici és el bloqueig o xifrat maliciós de dades amb petició de rescat: és, literalment, la definició de ransomware. A descriu un DDoS (saturació d'amplada de banda), no un ransomware. B descriu una intrusió física, no un atac informàtic. D és un problema de configuració, no un atac.

La correcta és la de 72 hores: l'art. 33 RGPD obliga a notificar la violació de seguretat a l'autoritat de control sense dilació indeguda i, com a màxim, en 72 hores des que se'n té constància — no des que es produeix l'incident. Les altres tres inventen supòsits que la norma no preveu: no existeix cap notificació anual acumulada dels incidents de l'any anterior, sí que hi ha un termini legal (l'opció que ho nega és falsa), i el termini no és d'un mes.

La correcta és la 1a opció: un sistema de gestió de compliance és l'estructura certificable, cíclica i documentada (tipus ISO 37301) que inclou la supervisió contínua i l'avaluació de riscos, i que conté i manté el programa de compliance. Les altres inverteixen o simplifiquen la distinció: no és el programa el que és "més flexible" que el sistema (2a, invers del que cal memoritzar), el programa no es limita a la formació (3a, massa restrictiu) i el sistema, precisament perquè és documentat, sí que exigeix documentació (4a, contrària a la seva pròpia definició).

UiPath Studio és l'entorn de desenvolupament on es dissenyen i desenvolupen els fluxos de treball d'automatització. Orchestrator gestiona i executa robots en remot (no els dissenya), Assistant només llança robots ja fets, i l'opció «Notes» no és un component d'UiPath.

La gestió de la demanda és un procés de l'Estratègia del Servei: entén i influeix en la demanda del client per dimensionar la capacitat. Els altres tres —gestió del canvi, gestió de la configuració i gestió de versions i desplegaments— són tres dels set processos de la Transició del Servei, juntament amb planificació i suport a la transició, validació i proves del servei, avaluació del canvi i gestió del coneixement.

«Avaluar i evolucionar constantment» el servei és, literalment, el propòsit de la Millora Contínua del Servei (CSI), la cinquena fase del cicle de vida v3 (apartat 5.1 del tema): alinear contínuament els serveis amb les necessitats canviants del negoci. Les altres tres fases tenen un propòsit diferent i puntual, no d'avaluació constant.

Els robots RPA interactuen amb els sistemes exactament com ho faria una persona, a través de la interfície gràfica (clics, escriptura, lectura de pantalla), executant fluxos predefinits sobre les aplicacions ja existents. No criden APIs d'integració (l'opció SOAP/REST descriu una integració clàssica, no RPA), no accedeixen directament a bases de dades com a mecanisme principal, ni fan servir agents d'IA —això seria una altra tecnologia (agents d'IA), no RPA clàssic.

La correcta és la 1a opció: el canal d'alertes és el mecanisme confidencial per comunicar possibles incompliments, amb prohibició de represàlies. No serveix per recollir suggeriments de millora (2a, això és un canal de millora contínua), ni per informar de canvis normatius (3a, vigilància normativa), ni específicament per comunicar vulnerabilitats de seguretat (4a, que té els seus propis canals de gestió d'incidents).

El primer pas per incorporar un servei nou és justificar-lo amb un cas de negoci que n'avaluï el valor i el risc, no registrar-lo directament al catàleg —que és la part activa del cicle de vida, reservada als serveis ja operatius o llestos per desplegar-se. Un servei nou entra primer al pipeline de la cartera de serveis, i aquesta entrada es justifica amb el cas de negoci. Definir l'SLA o assignar un gestor de canvis són passos posteriors, un cop decidit que el servei tirarà endavant.

L'aplicació pràctica més habitual d'un llac de dades (data lake) és servir de plataforma centralitzada per a projectes d'aprenentatge automàtic i ciència de dades: hi conviuen dades en brut de qualsevol format i origen, que és el que aquests projectes necessiten. Precisament per això la primera opció és falsa —el llac no es limita a dades relacionals, sinó que n'admet d'estructurades, semiestructurades i no estructurades—; la tercera confon el llac amb un gestor documental, que resol conservació, versions i cicle de vida de documents; i la quarta descriu una restricció de xarxa que no té res a veure amb la definició del concepte.

El que millora l'experiència d'usuari en una aplicació mòbil és prioritzar la usabilitat (facilitat d'ús, navegació clara) i l'accessibilitat. «Afegir la màxima quantitat de funcions possibles» és fals: sobrecarrega la interfície i empitjora la usabilitat. «Reduir la seguretat per fer-la més ràpida» és fals: la seguretat no és intercanviable per rendiment, i reduir-la és un risc, no una millora d'experiència. «Utilitzar només colors vius» és fals: l'estètica per si sola no és disseny centrat en la persona usuària i pot perjudicar l'accessibilitat (contrast, llegibilitat).

La resposta correcta és la 2: les plataformes no-code no requereixen escriure gens de codi, mentre que les low-code sí que poden requerir-ne en casos avançats. És l'única diferència de fons entre totes dues —no-code és exclusivament visual; low-code deixa escriure codi per a la lògica, les integracions i les extensions que la interfície gràfica no cobreix—, i d'aquí en surt tota la resta (qui les pot fer servir, fins on arriben i quan es queden curtes). Les altres tres són falses: l'opció 0 inverteix els termes (és a l'inrevés: la que permet codi és la low-code); l'opció 1 confon la diferència amb el públic habitual, i a més l'inverteix, perquè el low-code el fan servir sobretot perfils tècnics i no gent sense experiència; i l'opció 3 redueix el low-code a «pàgines web senzilles», quan cobreix aplicacions departamentals i corporatives senceres, amb integracions.

La resposta correcta és la 3: una plataforma No-Code, perquè l'enunciat posa dues condicions alhora —que ho creïn «els usuaris de negoci» i «sense escriure cap línia de codi»— i només el no-code les compleix per definició. A més, el cas descrit és el seu cas natural: un tràmit intern simple de formulari i aprovació, sense lògica complexa ni integracions profundes. Les altres tres no compleixen el requisit, i cap de les dues últimes és tan sols una eina per construir aplicacions: l'opció 0 (un framework tradicional com Spring Boot) construeix l'aplicació però exigeix programar-la, que és justament el que l'enunciat descarta; l'opció 1 (un sistema de gestió de la qualitat del programari) serveix per governar la qualitat del desenvolupament, no per desenvolupar; i l'opció 2 (un repositori Git) és una eina de control de versions del codi, no de desenvolupament visual.

En una cultura DevOps, el fonamental per a una entrega contínua i fiable és automatitzar les proves i els desplegaments (integració i entrega contínues), que redueix errors humans i escurça els cicles de lliurament. Separar completament desenvolupament i operacions, desplegar només un cop l'any o evitar la comunicació entre equips són, precisament, les pràctiques que DevOps busca eliminar.

El supòsit demana el concepte d'infraestructura que fa que els entorns de desenvolupament, proves i producció es creïn i es gestionin de manera idèntica i automatitzada: això és exactament la infraestructura com a codi (IaC), que declara l'entorn en fitxers versionats en lloc de configurar-lo a mà, un cop per entorn. El serverless elimina la gestió de servidors però no diu res sobre com es creen els entorns; un monòlit és un estil arquitectònic, no un concepte d'infraestructura; i l'arquitectura basada en esdeveniments és un patró de comunicació entre serveis, no una manera de definir entorns.

El valor de la integració contínua és detectar aviat els problemes d'integració i el codi conflictiu, que amb molts equips desenvolupant microserveis en paral·lel és precisament el risc principal: com més tard es descobreix un conflicte, més car és resoldre'l. Limitar la despesa al núvol és FinOps; redefinir requisits cada dia no és cap objectiu de la integració contínua; i evitar proves n'és l'oposat exacte, perquè les proves automàtiques en són el nucli.

Estar dissenyada per escalar automàticament segons la demanda és, literalment, una de les característiques essencials d'una aplicació nativa al núvol. Les altres tres neguen el que fa que una aplicació sigui cloud native: executar-se exclusivament en servidors físics dedicats és el contrari de l'elasticitat del núvol; no poder utilitzar contenidors nega un dels seus pilars tecnològics; i haver-se de desplegar manualment cada vegada és el contrari de l'automatització que exigeix el model.

Els microserveis són el paradigma arquitectònic habitual en el desenvolupament d'aplicacions natives al núvol: descomponen l'aplicació en serveis petits i desplegables per separat, que és precisament el que permet escalar i desplegar de manera independent i elàstica. El monolític i el client-servidor tradicional són estils previs, pensats per a desplegaments únics i coordinats, no per a l'elasticitat cloud native; una aplicació d'escriptori ni tan sols és un paradigma de comunicació entre serveis.

La infraestructura immutable substitueix completament els servidors en lloc de modificar-los: per aplicar un canvi es construeix una instància nova a partir de la imatge actualitzada i es reemplaça l'antiga. Modificar els servidors manualment és exactament la infraestructura mutable, el contrari del concepte; que les aplicacions només puguin executar-se en una sola màquina i que no es puguin utilitzar serveis gestionats no tenen relació amb la immutabilitat i, a més, són falses en el context natiu al núvol.

La característica essencial és la independència de desplegament i escalat de cada microservei, opció A (tema, apartat 1, primera de les vuit característiques essencials). Compartir una única base de dades centralitzada (opció B) és l'antipatró que produeix un monòlit distribuït. Obligar el mateix llenguatge de programació a tots els serveis (opció C) contradiu l'heterogeneïtat tecnològica que permeten els microserveis. Limitar la comunicació a trucades síncrones (opció D) és fals: el tema recull també la comunicació asíncrona (missatgeria, flux d'esdeveniments) com a opció habitual.

Una entitat, en el model Entitat-Relació, és un objecte del món real —físic o conceptual— identificable i del qual interessen algunes propietats (p. ex. «Persona», «Expedient»). La primera opció descriu un atribut d'una relació, no una entitat; la tercera descriu un domini de valors (el que pot prendre un atribut); la quarta confon entitat amb tipus de dada. Aquesta pregunta és de modelatge de dades (diagrama entitat-relació): la respon el tema de gestió de dades a l'Administració, no aquest, que no tracta el modelatge entitat-relació.

En la notació de Chen del diagrama entitat-relació, la relació entre dues entitats es representa amb un romb, tal com recull l'apartat de modelatge de dades del tema. Un cercle no és cap element de la notació; un rectangle representa una entitat, no una relació; i una línia doble no existeix en aquesta notació (la notació de peu de corb usa una línia simple amb símbols de cardinalitat als extrems, no una línia doble).

Un atribut identificador únic ha de tenir un valor diferent per a cada ocurrència de l'entitat. El número d'identificació (DNI) compleix aquesta condició perquè és irrepetible per persona. El nom, la data de naixement i el telèfon es poden repetir entre alumnes diferents (dos alumnes poden tenir el mateix nom o haver nascut el mateix dia), per la qual cosa no serveixen com a identificador únic.

El patró database per service de l'arquitectura de microserveis estableix que cada microservei ha de tenir la seva pròpia base de dades independent, per mantenir l'acoblament feble entre serveis i que cap no depengui de l'esquema intern d'un altre. Compartir una única base de dades entre tots els microserveis trenca aquest acoblament feble i reintrodueix l'acoblament que els microserveis busquen evitar; repartir les bases de dades per llenguatge de programació no és el criteri del patró —el criteri és el servei, no la tecnologia amb què està implementat—; i prescindir de bases de dades no és una pràctica de microserveis, és no tenir persistència.

La funció principal de l'API Gateway (tema, apartat 3.1) és actuar com a punt d'entrada únic que encamina les peticions dels clients cap als microserveis interns, opció D. No emmagatzema dades (opció A): cada servei posseeix la seva pròpia base de dades, i el Gateway no n'és el magatzem. No controla l'accés a "la" base de dades centralitzada (opció B) perquè en microserveis no n'hi ha cap de centralitzada. No sincronitza llenguatges de programació (opció C): és una funció aliena al Gateway i contrària a l'heterogeneïtat tecnològica dels microserveis.

El que distingeix SOA d'una arquitectura monolítica (tema, apartat 2) és la reutilització de components mitjançant serveis independents amb interfícies estandarditzades, opció B: és l'avantatge principal de SOA. Una sola base de dades centralitzada (opció A) és tret d'un monòlit, no de SOA. Exigir el mateix llenguatge a tots els serveis (opció C) no és un tret de SOA, que precisament permet interoperabilitat entre sistemes heterogenis. Que no permeti integració amb sistemes externs (opció D) és fals: la interoperabilitat amb sistemes externs és justament l'objectiu de SOA.

El protocol habitual per a la comunicació entre serveis en SOA (tema, apartat 2) és SOAP, opció C, típicament sobre XML i HTTP amb contractes WSDL. FTP (opció A) és un protocol de transferència de fitxers, no de missatges entre serveis. SMTP (opció B) és el protocol de correu electrònic. SSH (opció D) és un protocol d'accés remot segur a sistemes. Cap dels tres té relació amb l'intercanvi de missatges entre serveis SOA.

La qualitat funcional (adequació funcional a la ISO/IEC 25010) es defineix pel grau en què el programari compleix els requisits funcionals i les especificacions definides — l'opció correcta. Les altres opcions descriuen altres característiques de qualitat, no la funcional: operar en diferents plataformes i dispositius és portabilitat; la facilitat de modificació per corregir errors és mantenibilitat; la robustesa i la seguretat del codi són fiabilitat i seguretat.

Definir requeriments, revisar el codi font i gestionar els canvis són activitats pròpies de la gestió de la qualitat del programari (planificació, control i millora al llarg del cicle de vida). El disseny gràfic del logotip corporatiu no té cap relació amb el programari ni amb el seu procés de qualitat: és una tasca d'identitat corporativa, aliena a l'àmbit — per això és la resposta correcta a «quina NO forma part».

El propòsit de les proves no és només comprovar els requisits funcionals bàsics (opció 0, incompleta: també hi ha proves no funcionals), ni estalviar temps prescindint de documentació (opció 2, és el contrari del que recomana el tema), ni automatitzar completament tot el desenvolupament (opció 3, confon un mitjà —l'automatització— amb el fi). La correcta és validar i verificar que el programari compleix els requisits i detectar errors abans de producció, que és la definició literal del propòsit de les proves recollida al tema.

Les proves de caixa blanca analitzen l'estructura interna del codi (camins, condicions, complexitat ciclomàtica); les de caixa negra es basen només en l'especificació externa, sense conèixer el codi. La primera opció inverteix aquesta definició; la segona confon la tècnica amb la fase del cicle de vida en què s'aplica (ambdues es poden usar en qualsevol fase); la tercera nega una diferència que sí existeix.

El cicle TDD és roig → verd → refactor. El primer pas (roig) és triar un requisit i escriure'n la prova, que ha de fallar perquè encara no hi ha implementació (opció 0, correcta). Escriure la implementació (opció 1) és el segon pas (verd); refactoritzar (opció 2) és el tercer; executar totes les proves automatitzades (opció 3) és una activitat de regressió contínua, no el primer pas del cicle.

La correcta és l'encadenament de blocs mitjançant hashing criptogràfic: el tema explica que la immutabilitat de la blockchain ve de l'encadenament de hashos (cada bloc conté el hash del bloc anterior) combinat amb el consens distribuït, no del xifratge. Els Smart Contracts són programes que s'executen sobre la cadena, no la font de la immutabilitat; el throughput és una mesura de rendiment de la xarxa; i la dependència d'un node centralitzat és el contrari del que fa la blockchain resistent a manipulacions.

El supòsit demana quin component de SAP FI implementa el llibre major, on cada pàgina és un compte comptable: això és exactament FI-GL (General Ledger), el submòdul de comptabilitat general on es registren tots els assentaments. FI-SF (SuccessFactors) és gestió de capital humà, no comptabilitat; FI-TRM (Tax Revenue Management) és recaptació d'ingressos públics; i FI-BPC (Business Planning and Consolidation) és planificació i consolidació pressupostària, no el llibre major.

Un data lake permet emmagatzemar dades de qualsevol format i origen sense estructura predefinida, i és precisament aquesta integració de grans volums heterogenis el que fa possible analítiques avançades i descobrir patrons complexos. Les altres opcions inverteixen l'avantatge real: no limita l'accés a analistes, no redueix la flexibilitat d'integració —l'augmenta— i no es restringeix a dades transaccionals, que és justament l'àmbit del data warehouse/OLTP.

La correcta és que tots els nodes tenen la mateixa còpia del registre i participen en la validació: el tema defineix la descentralització de la blockchain com l'absència d'una autoritat central que validi les transaccions, ja que la validació la fan els nodes mitjançant un mecanisme de consens. Les altres tres opcions descriuen precisament un esquema centralitzat (un node central, una autoritat externa o una entitat central de confiança), que és el que la descentralització evita.

El supòsit pregunta pel mòdul responsable de la gestió pressupostària en una organització amb comptabilitat pressupostària com un ajuntament: és EA-PS, l'extensió específica per al sector públic (amb Funds Management com a component que la implementa). MM és compres i logística, CO és la comptabilitat analítica interna i FI és la comptabilitat financera externa general: cap dels tres és l'extensió pensada per a la gestió pressupostària pública.

La correcta és la gestió de la cadena de subministrament per rastrejar productes: el tema la cita explícitament com a cas d'ús real de blockchain (traçabilitat d'aliments i medicaments). Emmagatzemar fotos al núvol, enviar correus massius o editar documents col·laborativament són tasques que ja resol bé una infraestructura convencional —núvol, correu, edició en línia— sense necessitat de blockchain, tal com adverteix el tema al punt «Quan no cal».

SAP-HCM és un mòdul dins d'un producte més gran de SAP, i aquest producte és un ERP (Enterprise Resource Planning): un sistema integrat que gestiona sobre una única base de dades tots els processos de l'organització —finances, compres, logística i també recursos humans—, no només un d'ells. Les altres tres són falses perquè descriuen productes d'un altre tipus: un CRM se centra en la relació amb el client (vendes, màrqueting, atenció), un BPM en el modelatge i l'automatització de processos de negoci, i una BI en l'anàlisi de dades per a la presa de decisions. Cap dels tres integra la totalitat dels processos de l'empresa com fa un ERP.

Un CPD TIER III necessita dues vies de subministrament elèctric, una activa i una de reserva (passiva), que és el que li permet fer manteniment planificat sense aturar el servei. Una via sola (opció A) és pròpia de TIER I/II; quatre vies independents (C) no existeixen a la classificació; tres vies totes actives (D) confon TIER III amb TIER IV, que en té dues però totes dues actives.

RAID 0 fa striping pur: reparteix les dades entre discos sense mirroring ni paritat, per la qual cosa no té cap tolerància a fallades i la pèrdua d'un sol disc suposa perdre totes les dades del conjunt; per això és el nivell inadequat per a sistemes crítics. RAID 1 (mirroring) tolera la fallada d'1 disc, RAID 5 (paritat distribuïda) tolera 1 disc, i RAID 6 (doble paritat) en tolera 2: els tres ofereixen redundància.

La diferència que marca el tema entre RAID 5 i RAID 6 és el nombre de paritats: RAID 6 en manté dues d'independents i per tant suporta la fallada simultània de dos discos, mentre que RAID 5 només en té una i tolera un disc. Les altres opcions són falses: RAID 5 no fa servir miralls sinó paritat (igual que RAID 6, no «en lloc de»); no hi ha cap restricció que lligui RAID 6 als discos SSD; i el mínim de discos de RAID 5 és tres, no «més de 6».

El model 3-2-1 és 3 còpies, en 2 suports o formats diferents, amb 1 fora de línia/de la seu: l'opció correcta ("3 còpies en 2 formats diferents i 1 fora de línia") és l'única que recull els tres números amb el criteri correcte a cadascun (suports diferents, no ubicacions al núvol; fora de línia, no en el mateix dispositiu). "2 servidors al núvol i 1 en SSD" no diversifica el suport, situa les tres còpies en línia; "3 còpies diàries en 2 hores i 1 setmanal" parla de freqüència, no de suports ni ubicació; "el mateix dispositiu" contradueix directament el "2 suports diferents".

Abans de restaurar cal assegurar-se que el punt de restauració està net i no compromès (identificar un punt anterior a la intrusió i verificar-ne la integritat): restaurar sobre una còpia ja infectada reprodueix l'atac. Reinstal·lar l'antivirus no garanteix que la còpia estigui neta; fer còpia de les dades ja xifrades és conservar el dany, no repara res; tancar sessions és una mesura de contenció anterior, no el pas específic previ a la restauració.

Demana quina acció redueix el risc que el ransomware xifri les còpies de seguretat automàticament. La triada (índex 2, "utilitzar còpies versionades i fora de línia") combina dues mesures diferents i complementàries: el versionat (conservar diverses còpies puntuals, de manera que si una versió queda xifrada es pot restaurar-ne una anterior neta) i estar fora de línia (aïllades, sense connexió permanent, de manera que el ransomware no hi pot arribar per xifrar-les automàticament). Les altres tres opcions descriuen exactament el que cal EVITAR: una carpeta compartida (índex 0) i unes còpies connectades al sistema (índex 1) són accessibles des de la xarxa compromesa, igual que la resta de dades, i el ransomware les xifra igual; un disc sense encriptar (índex 3) no té relació amb el xifratge automàtic per part de l'atacant —xifra igual un disc encriptat que un que no ho és— i, a més, no xifrar les còpies és en si mateix una mala pràctica de confidencialitat, no una protecció.

L'orquestració d'un SDDC automatitza el desplegament, la configuració i el control coordinat dels recursos TI (còmput, emmagatzematge i xarxa) sense intervenció manual. Un SDDC no elimina el maquinari físic (A, fals: la infraestructura sempre hi és, el que es virtualitza és la seva gestió), no defineix polítiques públiques d'ús del núvol (B, és un concepte de govern extern al SDDC) ni es limita a apagar equips en hores vall (D, que és només una mesura d'eficiència puntual).

L'enunciat descriu una gestió flexible, escalable i automatitzada dels recursos de dades independentment del maquinari físic on s'executen: és, literalment, la definició de SDS (Software-defined storage). VPC i CDN són tecnologies de xarxa i distribució de contingut, no d'emmagatzematge. NAS és el contrari del que descriu l'enunciat: maquinari concret d'accés a fitxer, no una capa de gestió independent del maquinari.

El RPO (Recovery Point Objective) és el punt en el temps, anterior a la interrupció, al qual es poden recuperar les dades: dit d'una altra manera, la quantitat màxima acceptable de pèrdua de dades, i el determina la freqüència de la còpia o de la replicació. «La data límit de recuperació» i «el temps total per restaurar serveis» descriuen el RTO, que mesura temps sense servei i mira cap endavant des del desastre, mentre que el RPO mira cap enrere. «El nombre màxim de còpies de seguretat» és una política de retenció, que no és cap objectiu de recuperació.

L'anàlisi d'impacte en el negoci (BIA) és el document que identifica els processos crítics de la missió i avalua l'impacte i la probabilitat que una interrupció els afecti, i del qual surten el MTD, el RTO i el RPO que després condicionen tota l'estratègia. Als set passos de la planificació de contingència el BIA és el segon, just abans de crear les estratègies. El DRP no avalua res: és el resultat, el pla que s'escriu un cop es coneixen els requisits. Una auditoria tècnica comprova el compliment de controls ja implantats. El pla de comunicació interna regula els missatges durant la crisi.

El temps màxim acceptable d'interrupció d'un servei crític abans que les conseqüències siguin inacceptables és el MTD (Maximum Tolerable Downtime), anomenat MTPD a la ISO 22301. És el sostre que fixa el negoci. El RTO és l'objectiu tècnic de recuperació, que s'ha d'encabir dins del MTD (RTO ≤ MTD): no és el màxim tolerable, sinó el que ens proposem. El RPO mesura pèrdua de dades, no durada de la caiguda. L'SLA és l'acord de nivell de servei en operació normal, no el llindar de tolerància davant d'un desastre.

Correcta: és possible mitjançant la creació d'un núvol privat (opció 0). El tema (§3) diu que un núvol privat pot estar allotjat als CPD propis de l'organització: implementar-hi serveis cloud sobre infraestructura on-premise és exactament crear-hi un núvol privat. Les opcions 1 i 2 neguen aquesta possibilitat sense motiu: el núvol públic no és l'únic model, ni cal que la infraestructura sigui de tercers. L'opció 3 contradiu directament l'existència del núvol privat i de l'híbrid, que el tema desenvolupa en aquest mateix apartat.

Correcta: s'ha de composar de dues o més infraestructures de núvol diferents (opció 0), la característica imprescindible que dona el tema (§3) seguint la definició del NIST: la combinació d'infraestructura pròpia i externa amb integració i portabilitat. Les opcions 1 i 2 descriuen usos exclusius —d'un sol núvol públic, o d'una sola organització— que és justament el que NO fa híbrida una infraestructura. L'opció 3 exigeix un model de servei concret (PaaS) des de l'on-premise, un requisit que no forma part de la definició de núvol híbrid.

La Wi-Fi Alliance bateja com «Wi-Fi 6» l'estàndard IEEE 802.11ax. 802.11ac és Wi-Fi 5 (només 5 GHz) i 802.11n és Wi-Fi 4 (2,4 i 5 GHz); 802.11g és anterior a aquesta numeració comercial i no en rep cap.

L'espai privat de classe C de la RFC 1918 és 192.168.0.0 – 192.168.255.255, i la 192.168.0.1 hi cau. La 192.169.0.1 i la 192.167.255.255 queden just fora del rang per un valor al segon octet, i la 193.168.0.1 ni tan sols comença per 192.

L'Endpoint Configuration Manager (ECM) —el nom modern de SCCM, integrat amb Intune— té com a objectiu principal gestionar, desplegar i protegir dispositius i aplicacions a gran escala: inventari, distribució de programari, polítiques de configuració i seguretat sobre tot el parc d'estacions i servidors. Gestionar la identitat digital és funció del directori i de la gestió d'identitats, automatitzar el suport telefònic no té res a veure amb la gestió d'endpoints, i dissenyar infraestructures físiques de xarxa és una funció de xarxes, no de gestió de dispositius.

El MDM distribueix les configuracions de xarxa o VPN mitjançant perfils de configuració que s'apliquen de manera remota i automàtica al dispositiu inscrit, sense intervenció de la persona usuària: és exactament "desplegament remot automatitzat", opció D. Les opcions A i B exigeixen que la persona usuària intervingui a cada dispositiu -el contrari de "centralitzada"-; C confon la configuració amb el firmware i proposa un mitjà (USB) que trenca la centralització en no passar pel servidor MDM.

L'espai de treball col·laboratiu de Teams és l'EQUIP: crear-ne un i afegir-hi els membres dels departaments implicats dona d'una tirada xat persistent, canals per temes, reunions i el lloc de SharePoint on aniran els fitxers. Les altres opcions no creen cap espai compartit: enviar un enllaç a una carpeta per correu és compartir fitxers, no coordinar; una VPN és connectivitat de xarxa i no aporta cap funció col·laborativa; i repartir fitxers per memòria USB és transport de còpies, amb el problema afegit de versions divergents.

La funcionalitat que permet la col·laboració en temps real quan una persona obre un document de Word des de OneDrive és la coautoria: diverses persones usuàries editen el mateix document alhora, veient els canvis de les altres a mesura que es produeixen, amb indicadors de presència i desat automàtic. La còpia de seguretat local, el bloqueig per a una única persona usuària i l'enviament automàtic per correu són funcionalitats reals de la suite però cap d'elles fa possible que dues persones treballin sobre el mateix document simultàniament: el bloqueig, de fet, és precisament el que la coautoria evita.

El que fa Planner útil en un equip multidisciplinari és l'assignació de tasques a persones concretes i les notificacions automàtiques dels canvis i venciments: cadascú sap què li toca i tothom veu l'estat al tauler compartit. Les altres opcions descriuen altres eines: penjar documents en portals és SharePoint; automatitzar processos dins de la suite és l'eina de fluxos automatitzats; i convocar reunions i recollir-ne notes són el calendari i el quadern de notes.

Una base de dades SQL (relacional) es defineix per organitzar les dades en taules amb files i columnes relacionades per claus foranes, amb un esquema fix. Emmagatzemar en fitxers de text sense estructura definida és la lògica d'un data lake (schema-on-read), no d'una SQL; una relacional precisament garanteix la integritat i la coherència gràcies a les propietats ACID, no el contrari; i l'accés no es limita a interfícies gràfiques, es fa amb el llenguatge de consulta SQL.

La diferència fonamental és l'esquema: les relacionals exigeixen un esquema fix definit per endavant; les NoSQL estan pensades per a esquemes flexibles. És fals que les relacionals admetin dades sense estructura —és justament el tret de les NoSQL—; NoSQL no vol dir que només s'hi pugui consultar amb SQL, precisament el nom significa «Not Only SQL»; i són les NoSQL, no les relacionals, les pensades per a l'escalabilitat horitzontal.

SQL (Structured Query Language) es divideix en DDL —crear i modificar l'estructura de les taules— i DML —consultar, inserir, actualitzar i esborrar registres—: les tres primeres opcions són exactament això. Programar i gestionar automàticament les còpies de seguretat de la base de dades, en canvi, és una tasca d'administració del SGBD (Sistema de Gestió de Base de Dades), no una operació del llenguatge SQL: les còpies es configuren amb eines i procediments del gestor, no amb sentències SELECT, INSERT, UPDATE, DELETE, CREATE o ALTER.

La característica per la qual destaca SAP HANA és l'emmagatzematge de les dades a la memòria principal (RAM) per accelerar consultes i transaccions, de manera que la correcta és la 1. Les altres tres descriuen emmagatzematges que HANA justament no fa servir com a principal: l'opció 0 posa fitxers de text plans, que cap motor analític seriós no usa com a emmagatzematge principal; l'opció 2 és el parany clàssic d'aquesta pregunta, perquè un disc d'estat sòlid (SSD) accelera molt però segueix sent disc i no memòria, i la distinció que fa HANA és precisament aquesta; i l'opció 3 proposa taules orientades a files amb accés seqüencial, que és el contrari del model columnar de HANA.

L'àmbit de l'ENS (art. 2) inclou totes les administracions públiques i els seus proveïdors de serveis. Restringir-ho a «només empreses privades» ho inverteix; a «ajuntaments de més de 50.000 habitants» hi afegeix un llindar que la norma no fixa (l'ENS no distingeix per grandària del municipi); i «només els ciutadans» és fals, l'ENS no obliga la ciutadania.

La disponibilitat estimada d'un CPD TIER III segons l'Uptime Institute és del 99,982 % (uns 1,6 h/any d'indisponibilitat). El 99,671 % correspon a TIER I, el 99,741 % a TIER II i el 99,995 % a TIER IV: cada xifra és d'un nivell diferent de la mateixa taula. Les quatre opcions són percentatges, i qualsevol pista que orientés entre elles seria pràcticament donar la resposta (C-10): es deixa sense pista a propòsit.

RAID 0 només aplica striping (divisió i repartiment de blocs entre discos) sense cap mecanisme de redundància, per maximitzar rendiment i capacitat. «Alta tolerància a fallades» i «mirall de dades» descriuen RAID 1/10, i «emmagatzematge de paritat» descriu RAID 5/6, no RAID 0.

El site survey s'ha de fer abans de desplegar la xarxa precisament per avaluar com es propaga la radiofreqüència a l'edifici real (parets, materials, interferències) i decidir on cal ubicar cada punt d'accés. No serveix per estalviar-se proves de rendiment posteriors (la validació post-desplegament és una fase diferent), ni té relació amb complir automàticament la normativa de protecció de dades, ni instal·la fibra òptica.

Una base de dades documental emmagatzema cada registre com un document autocontingut, típicament en JSON, amb una estructura flexible que pot variar entre documents. No es tracta de documents ofimàtics com PDF, txt o Word; no hi ha cap ús intern de fitxers de text per «compatibilitat universal» —això és invenció—; i no és un gestor de documentació digital amb les seves metadades, que és un concepte diferent (gestió documental, no base de dades).

La disponibilitat és una de les dimensions de seguretat de l'art. 1 de l'ENS. Escalabilitat, compatibilitat i eficiència són qualitats tècniques generals d'un sistema, no dimensions de seguretat de l'esquema.