TS-TIC 2021 practica

Decidim és la plataforma de participació i democràcia digital de l'Ajuntament: programari lliure, configurable per adaptar-se a l'estratègia definida i part de l'estratègia digital de la ciutat. Twitter és una xarxa social comercial, no una plataforma de procés participatiu i no és sobirana. Barcelona OpenData publica conjunts de dades i BCNROC és el repositori documental: cap dels dos serveix per articular la participació.

En creuar ocupació i perfil, el perfil avançat de l'estudi del 2020 està compost principalment per població ocupada (un 68,4 %), seguida de la població estudiant: l'opció D és la correcta. A és falsa perquè els perfils són quatre —avançat, mitjà, bàsic i baix—, no tres. B també: els perfils surten de trams d'un indicador numèric de 30 punts, de manera que són nivells excloents i no grups que s'encavalquin. I C es queda curta: la composició dels perfils s'analitza per gènere, edat, nivell d'estudis, ocupació i renda.

decidim.barcelona es publica sota AGPL v3 (Affero General Public License, versió 3), una llicència amb copyleft que a més obliga a alliberar el codi quan el programa s'ofereix com a servei per la xarxa, que és el cas d'una plataforma web. La GPL i la LGPL no cobreixen aquest supòsit —i la LGPL, a més, és la variant més permissiva per a biblioteques—. La versió 2.4 de l'AGPL no existeix.

L'estudi del 2020 conclou que les llars no connectades es concentren en les formades per persones de més de 74 anys —un 55 % d'aquestes llars—. B és falsa perquè les llars de renda baixa han passat del 75 % al 91 % de connexió i ja no són el nucli de la desconnexió. C i D també ho són: l'estudi remarca que, un cop reduïda la bretxa d'accés, l'edat, la renda i el nivell formatiu segueixen condicionant l'accés i l'ús de les tecnologies.

BCNROC és el repositori institucional d'accés obert de l'Ajuntament, mitjançant el qual posa d'accés lliure i gratuït els seus documents digitals de difusió pública: l'enunciat n'és la definició literal. Opendata publica conjunts de dades, no documents; la seu electrònica serveix per tramitar; i el portal de transparència dona compliment a la publicitat activa d'informació obligatòria, que no és el mateix que fer de repositori documental.

La correcta és l'opció 2: projecte = tasca temporal amb principi i final; programa = conjunt de projectes relacionats entre si; portfoli = grup de projectes i programes relacionats amb un objectiu estratègic organitzacional. L'opció 0 diu que un programa «pot incloure treball no relacionat amb el projecte», quan la definició exigeix que estiguin relacionats. L'opció 1 inverteix parcialment la jerarquia: descriu bé programa i portfoli combinant-ne elements, però no diu que el portfoli es defineixi per un objectiu estratègic, el tret que el distingeix del programa. L'opció 3 defineix el projecte per estar «contractat» (no és el tret definitori) i inverteix la jerarquia dient que un programa combina portfolis, quan és al revés.

Els interessats ajuden a determinar els requisits, els supòsits i les restriccions del projecte i els entregables del producte. Les altres tres opcions els atribueixen feina que no és seva: el cronograma l'elabora el director del projecte amb l'equip; les necessitats i restriccions de recursos són de la gestió de recursos, no de la d'interessats; i aprovar l'acta de constitució és del patrocinador, mentre que crear els plans de gestió és del director.

Elaborar un pressupost detallat és el procés Determinar el pressupost, del grup de planificació. A la iniciació només es fixa un pressupost resumit i d'alt nivell a l'acta de constitució; l'execució gasta aquest pressupost, no el crea; i «abans del procés de direcció de projectes» no és cap grup.

En l'ordre de planificació, un cop hi ha cronograma i pressupost encara queden processos de planificació pendents, i el següent d'aquests quatre és determinar els requisits de les comunicacions. Identificar els riscos i, sobretot, analitzar-los ve després, quan ja se sap qui participa i com es comunica. Començar les iteracions és execució, no planificació. I el diagrama de Gantt no és un pas nou: és només una representació del cronograma que ja s'acaba de fer.

L'acta de constitució del projecte (project charter) és el document que autoritza formalment l'existència del projecte i dona al director l'autoritat per aplicar-hi recursos. Surt del procés «Desenvolupar l'acta de constitució del projecte», que pertany a l'àrea de coneixement d'Integració i al grup de processos d'Inici, que és el que es demana. No pot ser Planificació, que ja pressuposa un projecte autoritzat; ni Execució, que pressuposa un pla aprovat; ni Tancament, que és l'últim grup i no el primer.

L'acta de constitució del projecte inclou, entre altres coses, el cas de negoci del projecte (per què val la pena fer-lo). No hi porta encara una estratègia detallada de gestió de riscos, ni estimacions dels paquets de treball, ni estimacions detallades de recursos: aquest detall arriba després, a la planificació, quan ja hi ha acta i s'ha autoritzat el projecte.

La correcta és l'opció 2: assegura l'acceptació del client, mostra que l'entregat compleix amb les especificacions i proporciona una oportunitat perquè apareguin les diferències d'opinió — el benefici clau de Validar l'abast segons el PMBOK v6. L'opció 0 barreja els dos processos: descriu la sortida de Controlar la qualitat (entregables verificats) com si fos la definició de Validar l'abast, i inverteix la relació (Validar l'abast és el que rep com a entrada els entregables verificats, no una sortida de Controlar la qualitat). L'opció 1 hi afegeix «es completa en temps», que és cronograma, no abast. L'opció 3 inverteix dues relacions alhora: Validar l'abast no és una sortida de Controlar la qualitat sinó que en rep l'entrada, i no es dona abans de Definir l'abast sinó molt després, durant el seguiment i control.

El projecte està dins de les línies base: no hi ha desviació d'abast, de temps ni de cost que explicar, i tot i així el client està descontent. Això vol dir que el problema és d'expectatives i de comunicació, no de mesura, i la primera cosa és reunir-se amb el client per saber què espera. Analitzar-ho amb l'equip mira cap endins quan la insatisfacció ve de fora; recalcular les línies base manipula la referència sense cap causa que ho justifiqui; i renegociar el contracte és actuar sobre un diagnòstic que encara no s'ha fet.

Quan la composició de l'equip canvia de manera imprevista, el document que cal actualitzar és el pla de gestió de recursos: és on consten les necessitats de personal, i revisar-lo és el pas per decidir com es cobreix el buit i es continua el projecte. El pla de comunicacions no recull necessitats de personal; l'histograma de recursos mostra l'ús per període però no és un pla que s'actualitzi per decidir com continuar; i la matriu d'assignació de responsabilitats reparteix rols sobre un equip ja donat, no decideix com recompondre'l.

L'histograma de recursos és el gràfic de barres que mostra la quantitat de recursos —persones o hores— emprats en cada període de temps. La matriu d'assignació de responsabilitats reparteix rols, no quantitats; l'organigrama del projecte mostra l'estructura jeràrquica, no l'ús per període; i un diagrama de barres genèric no és el terme que fa servir el PMBOK per a aquesta informació concreta.

Els camins de la xarxa són dos: 1-2-4-5 = 3+3+8+4 = 18 setmanes i 1-3-5 = 3+6+4 = 13 setmanes. El camí crític és el més llarg, i per tant la ruta crítica dura 18 setmanes; l'activitat 3 té 5 setmanes de folgança total. Les altres xifres surten de sumar només un dels camins (13) o de barrejar activitats dels dos.

L'òrgan consultiu, integrat en el Consell de Ciutat i format per persones expertes externes a l'Ajuntament, que atén les queixes sobre l'aplicació de la normativa de participació és la Comissió d'empara (opció C), creada pel Reglament de participació ciutadana com a garantia dels drets de participació. No és la comissió de seguiment (opció A, que fa seguiment de projectes, no atén queixes de drets), ni l'assessora de processos participatius (opció B, d'assessorament tècnic), ni la de garanties (opció D, nom versemblant però no és l'oficial). La pregunta va estar classificada a barcelona/municipio-y-regimen-especial-de-barcelona amb una justificació que deia que no era matèria d'aquell tema; és de la participació ciutadana de Barcelona, que desenvolupa barcelona/carta-municipal al títol IV.

Tenir ja la ruta crítica i les estimacions i acordar les dates de calendari de cada activitat és el procés Desenvolupar el cronograma, que produeix la línia base del cronograma. Seqüenciar les activitats només n'estableix l'ordre lògic i és anterior; Definir l'abast és d'una altra àrea; i l'acta de constitució és el document d'inici del projecte.

Les 5 estrelles de Tim Berners-Lee: 1★ disponible al web amb llicència oberta, en qualsevol format —també un de propietari com l'XLS, i també un PDF escanejat—, 2★ estructurat i llegible per màquina, 3★ en un format no propietari (CSV en lloc d'XLS), 4★ amb URI per identificar les coses, 5★ enllaçat a altres dades. La clau oficial és la b): tres estrelles és, exactament, el format estructurat i no propietari. La a) confon la primera estrella amb la processabilitat automàtica, que és la segona, i la d) nega el caràcter incremental del model, que és el seu fonament.

La c) també diu una cosa certa: la cinquena estrella sí que és l'enllaç amb altres dades. Les dues afirmacions són correctes sobre el model, així que la pregunta només es decideix per la clau oficial, no pel contingut. Es deixa dit perquè no s'ha de tornar a mirar: la justificació anterior tractava la b) de distractora i contradeia la clau que ella mateixa acompanyava.

Quan la durada necessària supera el temps disponible, el que toca és analitzar les opcions de compressió del cronograma —crashing i fast tracking—, valorar-ne el cost i el risc i presentar l'opció resultant a qui decideix. Reduir l'abast del producte (A) és una decisió del patrocinador i mai la primera resposta; dir simplement que no es pot (B) és renunciar sense analitzar; i les hores extraordinàries (C) no són una tècnica de direcció de projectes, són un pedaç.

La identificació de riscos és iterativa, no un acte únic de la planificació: la majoria es detecten al procés "Identificar els riscos" (la identificació inicial) i es reforcen contínuament a "Monitorar els riscos" (reidentificació i reavaluació durant tot el projecte, no només a l'inici). Les altres combinacions inclouen processos d'anàlisi (qualitativa o quantitativa), que prioritzen o quantifiquen riscos ja identificats, no en generen de nous.

EV = PV + SV = 600.000 − 120.000 = 480.000 €. AC = EV / CPI = 480.000 / 1,2 = 400.000 €. CV = EV − AC = 480.000 − 400.000 = 80.000 €. Les altres opcions surten d'aplicar malament algun d'aquests passos (per exemple, confondre l'AC amb l'EV o aplicar el CPI a la variable equivocada). Sense pista: les quatre opcions són xifres.

El pla d'involucració de les persones interessades és on consten, per a cada interessat, els requisits de comunicació: quina informació vol, amb quina freqüència i per quin mitjà. La matriu d'avaluació de la involucració només compara el nivell actual (C) amb el desitjat (D); el diagrama RACI reparteix responsabilitats sobre activitats, no preferències de comunicació; i el pla de gestió dels recursos va de l'equip i dels recursos físics.

El seguiment continu del cost real respecte al pla es fa mitjançant revisions de l'acompliment del projecte (l'anàlisi de variacions EVM: CV, SV, CPI, SPI). Crear el sistema de control de canvis és una activitat prèvia de planificació. Recomanar accions correctives i actualitzar la línia base de costos són sortides que poden derivar-se d'aquesta revisió, no l'activitat de vigilància en si mateixa.

El cost de la qualitat (COQ) és una tècnica que s'utilitza en la planificació de la gestió de la qualitat, no una eina del procés Controlar la qualitat. Inspecció, histograma i diagrama de causa-efecte sí que són eines pròpies de Controlar la qualitat: la inspecció i l'histograma hi apareixen directament, i el diagrama de causa-efecte és una de les set eines bàsiques de la qualitat que s'utilitzen per analitzar defectes ja detectats en un entregable.

Les cinc dimensions de SERVQUAL són fiabilitat, capacitat de resposta, seguretat, empatia i elements tangibles. La trampa és que l'opció correcta diu «intangibilitat», que és el contrari de la dimensió real: el model mesura precisament els tangibles.

La correcta és l'opció 2: el pla per a la direcció del projecte. El pla descrit a l'enunciat (com s'implementarà la política de qualitat, responsabilitat, procediments) és el pla de gestió de la qualitat, que segons el PMBOK v6 és un pla subsidiari, un component del pla per a la direcció del projecte. Si un pla subsidiari canvia, el document que l'integra —el pla per a la direcció del projecte— canvia amb ell. Les opcions 0 i 3 («pla d'assegurament de la qualitat», «pla de control de qualitat») nomenen artefactes que el PMBOK no reconeix com a documents independents: l'assegurament i el control són processos, no plans amb nom propi. L'opció 1 confon l'enunciat amb la pregunta: el pla descrit JA ÉS el pla de gestió de la qualitat, no un altre pla que en depengui.

Verificar si un lliurable concret compleix una mètrica de qualitat i reunir-se amb les parts implicades per analitzar l'incompliment és exactament la definició de Controlar la qualitat: verificar que l'entregable compleix les especificacions, amb orientació de detecció. Gestionar la qualitat és preventiu i actua sobre els processos, no sobre un entregable concret ja produït; Realitzar el control integrat de canvis només entra en joc si es formalitza una sol·licitud de canvi, cosa que encara no ha passat; i Planificar la gestió de la qualitat és l'etapa prèvia on es defineixen els estàndards, no on es detecten incompliments.

Per gestionar un problema de rendiment amb una persona concreta, la pràctica recomanada és una conversa informal i verbal: directa, immediata i sense escalar-la innecessàriament a un procediment formal. Una comunicació formal (escrita o verbal) és desproporcionada per a un primer avís, i una comunicació informal per escrit perd la immediatesa i el to de la conversa cara a cara.

El coneixement tàcit inclou emocions, experiència i habilitats: és difícil de codificar i es transmet per interacció directa. Les altres tres opcions descriuen el coneixement explícit —de base fàctica, fàcil de comunicar amb paraules i símbols— i les lliçons apreses en són un exemple típic de coneixement explícit, no tàcit.

En el moment del supòsit, Microsoft ja havia acabat el suport de Windows 7 i el suport de Windows 10 depèn de l'edició (Home, Pro, Enterprise) i de la versió concreta, cadascuna amb la seva data de fi de servei segons el cicle de vida modern. És fals que doni suport complet a totes les versions de Windows 10 i limitat a Windows 7: el suport estès de Windows 7 va acabar el 2020. És fals que el suport sigui il·limitat en el temps: tot producte té data de fi de suport publicada. I és fals que només se'n doni a l'última versió de Windows 10: les versions de servei estès conserven suport durant anys. La matèria és de gestió del parc de llocs de treball, no de continuïtat.

El supòsit descriu la migració de Windows 7 a diverses versions de Windows 10 (1907 i 1607) a les estacions corporatives, i sobre aquest escenari la pregunta es contesta amb un fet general del cicle de vida de Windows 10: la disponibilitat dels pedaços depèn de la versió instal·lada i no és indefinida. Cada versió (feature update) rep actualitzacions només durant un període de servei limitat —que varia segons l'edició—, i passat aquest període deixen d'arribar fins i tot els de seguretat, encara que el seu període sol ser més llarg que el de la resta d'actualitzacions. Per això no és cert ni que Microsoft posi «sempre» tots els pedaços a disposició, ni que només limiti en el temps els de seguretat: la limitació afecta totes dues coses, amb un termini diferent per a cadascuna.

El tema tracta precisament d'aquesta eina: System Center Configuration Manager (SCCM) és el producte de Microsoft per distribuir programari i gestionar les estacions de treball, per això l'opció 1 és la correcta. Les altres tres opcions —«Central de Distribució de Software (CDS)» i «Software Central Point (SCP)»— són noms inventats, sense correspondència amb cap producte real de Microsoft.

La pregunta encadena amb l'eina de gestió centralitzada de llocs de treball de la pregunta anterior del supòsit, i la resposta correcta és la més àmplia: una suite moderna de gestió d'endpoints administra equips amb Windows, macOS, Linux i Unix i també dispositius mòbils. Limitar-ho a sistemes operatius Microsoft o només a Windows 10 descriu una eina antiga i contradiu el catàleg de la majoria de productes actuals. «Qualsevol sistema operatiu del mercat» però només a estacions i servidors deixa fora els mòbils, que sí que s'hi gestionen. La matèria és la de tic/gestion-centralizada-de-endpoints.

En el context de teletreball que descriu el supòsit 2 —amb 12.000 persones usuàries i connexions VPN i escriptoris virtuals com a vies d'accés extern—, l'eina de gestió centralitzada de dispositius permet agafar el control remot de qualsevol estació suportada i prèviament habilitada, sigui quina sigui la seva localització, incloses les estacions virtuals, sempre que tinguin una connexió activa amb la xarxa corporativa —física, per VPN o per qualsevol altre mètode—. No és cert que calgui cable RJ45 (precisament el teletreball hi arriba sense cable), ni que només valgui per a VPN SSL en concret, ni que la llei prohibeixi el control remot d'una estació corporativa: és una funció habitual i legítima de gestió, no un acte prohibit.

Quan el canal habitual -el client VPN corporatiu- és precisament el que falla, cal una via alternativa que no en depengui: el servei d'atenció a l'usuari disposa d'una eina de control remot diferent, portàtil i sense instal·lació, per resoldre aquest tipus d'incidència. És l'opció B. La A no serveix perquè el producte de gestió centralitzada tampoc no hi arriba si la VPN no funciona; C i D converteixen en "única opció" un desplaçament físic quan hi ha una alternativa tècnica disponible.

Depèn de l'edició contractada: les llicències E3 i E5 donen dret a instal·lar la suite en local, i el dret és per usuari —fins a 5 ordinadors—, no per equip; l'edició E1 no el dona i obliga a treballar amb les versions web i mòbil. A i B són els dos extrems falsos («cap» i «totes»); C inventa una llicència addicional que no existeix, perquè el dret d'instal·lació ja va inclòs a les edicions que el porten.

A la línia d'ordres de Windows, REN (o RENAME) canvia el nom de fitxers, però per a carpetes l'ordre que funciona de manera fiable dins d'un script és MOVE, indicant el mateix directori pare amb un nom nou de destinació. RENDIR no existeix. I és fals que només es pugui fer amb l'explorador d'arxius: tota l'operació és automatitzable des d'un script. La matèria és d'administració de llocs de treball, no de continuïtat.

Per executar una acció sobre els subdirectoris d'una carpeta ja definida en un script, la comanda és FOR /D %variable in (<scope>) do <acció>. FOR /R fa el mateix però de manera recursiva per tot l'arbre de directoris, no només sobre els subdirectoris immediats; FOR /L recorre un rang numèric (inici, pas, fi), no una llista de carpetes; i «FOR/D» sense espai, amb <fitxer> com a àmbit, no és sintaxi vàlida de l'ordre.

El tema defineix MDT com el conjunt d'eines gratuït de Microsoft per automatitzar el desplegament de sistemes operatius Windows (secció «Desplegament del sistema operatiu»), que és el que diu l'opció 2. La 1 el confon amb SCCM, que sí que distribueix qualsevol tipus de programari; la 3 el confon amb una eina de gestió de dispositius mòbils (pròpia d'Intune/MDM), que no és el seu àmbit; i com que la 2 és certa, la 4 («cap resposta és correcta») és falsa.

El format d'imatge que fa servir SCCM/MDT per aplicar el sistema operatiu és WIM (Windows Imaging), com diu la secció «Desplegament del sistema operatiu» del tema: la resposta correcta és l'opció 2 (.WIM). .MSI és el format d'instal·lador d'aplicacions, no d'imatges de sistema operatiu; .EXE és un executable genèric; .IMAGET no és cap format real de Microsoft.

En migrar el servidor d'Exchange de 2010 a 2013 només calia actualitzar el client local de Microsoft Outlook a la versió compatible: la resta de mòduls de la suite ofimàtica (full de càlcul, processador de textos) no dialoguen amb el servidor de correu i no es veuen afectats. Actualitzar tota la suite era innecessari i car. No actualitzar res tampoc valia, perquè el client de correu antic no connectava correctament amb el servidor nou. I l'accés web no obliga a canviar tots els navegadors de les estacions. La matèria és de plataforma de correu i llocs de treball, no de continuïtat.

Hi ha diferències TANT de funcionalitat COM d'interfície entre el client instal·lat a l'estació i el client web: el client d'escriptori manté el treball sense connexió, els complements i la gestió avançada de regles i arxivat que la versió web no cobreix del tot. B nega les dues diferències; C només admet la d'interfície i nega la de funcionalitat; D és falsa perquè POP3 és un protocol de descàrrega de missatges que redueix funcionalitats en lloc d'igualar-les —no sincronitza carpetes, ni calendari, ni contactes.

És la descripció literal del perfil mòbil (roaming profile): en autenticar-se la persona usuària, es copien els fitxers de %USERPROFILE% i s'importa la part d'usuari del registre (HKCU) des d'una ubicació de xarxa; en tancar la sessió, reiniciar o apagar l'estació, els canvis locals es tornen a pujar a aquesta ubicació. És l'opció A. B, C i D inventen ubicacions -el núvol d'Azure, el mateix dispositiu mòbil, una "base de dades"- que no és on es guarda un perfil mòbil clàssic de domini.

Quan totes les actuacions manuals fallen i l'estat de l'estació ja no està controlat, el pas correcte és reinicialitzar l'estació amb la imatge corporativa i el perfil de la persona usuària, deixant que el sistema de gestió centralitzada torni a instal·lar automàticament el programari, aplicar les polítiques i fer les configuracions oportunes: és la manera de tornar a un estat conegut i controlat, en lloc d'acumular pedaços manuals sobre un sistema ja indeterminat. Obrir un projecte de canvi de programari, escalar a suport «premium» de Microsoft o abandonar el cas són desproporcionats o directament una renúncia, i cap dels tres resol la incidència concreta que descriu l'enunciat.

Davant una persona usuària a qui li falta un executable d'un producte que es distribueix per l'eina centralitzada, el primer pas és comprovar a la consola de l'eina si l'aplicació hi és realment distribuïda i, si no ho és, forçar-ne la distribució —per control remot o amb instruccions a la persona usuària— i verificar que la incidència queda resolta. Escalar sense comprovar res, o enviar els binaris perquè la persona usuària s'ho instal·li pel seu compte, salta el pas de diagnòstic i trenca precisament el que la gestió centralitzada vol evitar: instal·lacions manuals fora de control.

En el model d'impressió centralitzada segura, el contingut de la impressió queda retingut al servidor fins que la persona usuària s'autentica a la impressora on vol que surti, i només llavors s'envia cap a la seva IP o el seu nom: és l'opció A. La B nega qualsevol paper al servidor, que és fals en aquest model concret (al contrari que en el model directe); C i D donen per fet que tots els productes admeten indistintament els dos modes dins de la mateixa implantació, cosa que l'enunciat no afirma.

Per reduir el risc que es robin les credencials en el moment mateix d'introduir-les des d'un equip personal, cal que aquest equip no estigui infectat per programari capaç de capturar-les: un antivirus actualitzat i actiu, opció C. Un gestor de contrasenyes en un USB no protegeix el moment de teclejar la contrasenya; escriure-la en una llibreta no és una mesura tècnica per a l'accés remot; el segon factor (D) és la resposta a la pregunta següent -evita que unes credencials ja robades es puguin fer servir, no n'evita el robatori.

Un cop les credencials ja s'han pogut robar, el que impedeix que s'utilitzin des de fora és exigir un factor addicional que l'atacant no té: el segon factor d'autenticació, opció D. Les altres tres -gestor de contrasenyes, llibreta i antivirus- actuen abans del robatori, no aturen un accés fet amb una contrasenya que ja s'ha compromès.

Una VPN d'accés remot dona confidencialitat, integritat i autenticació del túnel, però no detecta intrusions: això és feina d'un IDS/IPS. Xifrar el trànsit no diu res sobre si el que hi viatja és maliciós.

Es demana quina eina NO pot detectar i bloquejar programari maliciós desconegut. La resposta del solucionari és l'EDR (Endpoint Detection and Response) considerat en el seu paper original de detecció i resposta a posteriori, orientat a donar visibilitat i telemetria per investigar, mentre que la prevenció en temps real correspon a la plataforma de protecció. Les altres dues opcions inclouen justament components de prevenció: l'EPP clàssic i, sobretot, el NGEPP, que afegeix anàlisi de comportament i aprenentatge automàtic per aturar amenaces sense signatura coneguda. I «cap de les anteriors» queda descartada perquè sí que n'hi ha una que encaixa. Aquesta pregunta està enllaçada al tema de continuïtat però la seva matèria és la de tic/gestion-centralizada-de-endpoints, que la cobreix molt millor.

Els tres factors clàssics d'autenticació són alguna cosa que es coneix, alguna cosa que es té i alguna cosa que s'és. El codi de persona usuària (opció C) no és cap d'aquests tres: és la identificació -qui dius que ets-, no la prova que ho ets. A, B i D sí que corresponen, respectivament, a un secret, un objecte i una característica biomètrica.

L'ENS gradua l'exigència d'autenticació segons el nivell del sistema: la categoria BÀSICA es pot cobrir amb un únic factor —una contrasenya robusta—, i és a partir del nivell MITJÀ que l'annex II reforça el mecanisme d'autenticació (op.acc.5) exigint un segon factor, reforç que es manté a ALT. Per això la resposta és «MITJÀ i ALT». Les altres opcions deixen fora un dels dos nivells exigents o hi inclouen el BAIX, que no el necessita. El criteri de fons és la proporcionalitat del compliment dels requisits mínims (art. 28, no l'art. 11, que és el de diferenciació de responsabilitats): l'esforç ha de ser proporcional al perjudici, i mai decreix en pujar de categoria.

La mesura de bloqueig per inactivitat només és eficaç si el temps el fixa l'organització; si la persona usuària el pot canviar des de la configuració de l'estació, pot allargar-lo indefinidament i buidar la mesura de contingut. És l'opció C, la que va en detriment. Les altres tres descriuen com HA de funcionar correctament la mesura -cancel·lar sessions remotes, bloquejar automàticament i mantenir el bloqueig fins a la reautenticació-, no com es vulnera.

Segons l'ENS (mesura mp.si.5), quan un suport no es pot esborrar de manera segura per impossibilitat tècnica, no es pot reutilitzar en cap altre sistema: l'alternativa és la destrucció segura, opció B. Cedir els equips a una altra organització (A) trasllada el risc sense eliminar-lo; l'esborrament amb productes certificats (C) és el reforç exigit quan SÍ és possible esborrar, no quan la impossibilitat tècnica ho impedeix; transferir la informació a un altre lloc (D) no elimina el suport original, que és el que cal protegir.

A la xarxa corporativa, l'estació es connecta per cable, la persona usuària s'autentica al directori i una política en baixa el certificat des del mateix directori: és l'opció B, el procediment habitual amb mètodes alternatius per a casos especials. Les altres tres inventen mecanismes que no en formen part -NFC amb la targeta de marcatge o amb la idCAT, o que la persona usuària es tramiti pel seu compte un certificat de la FNMT-.

L'eina és el visor de successos (eventvwr), i per a un tancament no controlat cal consultar el registre de Sistema, no el de Seguretat: l'esdeveniment porta el codi 6008. És l'opció C. La B assenyala l'eina correcta però el registre equivocat (Seguretat); la A limita la font d'informació a la base de dades del servei d'atenció quan hi ha una via tècnica directa; la D nega totes les respostes, i n'hi ha una de vàlida.

La versió de suport ampliat (ESR, Extended Support Release) manté les mateixes funcionalitats bàsiques però amb un ritme d'actualització de versió molt més lent i un període de suport més llarg, i amb opcions per defecte més restrictives en seguretat i privacitat, perquè està pensada per a desplegaments corporatius gestionats. A redueix la diferència al tipus de suport; C i D diuen que l'ESR és de pagament o de distribució restringida, i totes dues versions són gratuïtes i descarregables lliurement.

Les mesures que sí ha de prendre l'organització davant el robatori de portàtils són tenir-ne inventari, establir un canal per notificar la sostracció al servei de gestió d'incidents de seguretat i obrir l'incident corresponent. Considerar que ja n'hi ha prou amb la denúncia als Mossos d'Esquadra, opció D, renuncia a la resposta interna de seguretat: és la mesura que NO s'ha de prendre com a única resposta.

Quan cal que personal corporatiu i extern comparteixi en teletreball documents confidencials i amb dades LOPD, l'acció que redueix el risc de pèrdua de confidencialitat és donar d'alta les persones externes a la Gestió d'Identitats i habilitar-los un accés remot només de consulta, sense possibilitat de descàrrega: la informació sensible no surt mai del perímetre controlat. Permetre la descàrrega al PC domèstic, fer servir una persona genèrica compartida —que trenca la traçabilitat individual— o copiar els documents a un Dropbox personal i extern són, tots tres, formes de perdre el control sobre on acaba la informació.

En una topologia full-mesh cada punt s'uneix amb tots els altres, i el nombre d'enllaços és n · (n − 1) / 2. Amb n = 216: 216 · 215 / 2 = 23.220. Les altres tres xifres no surten de cap compte coherent: 46.441 i 48.444 dupliquen l'ordre de magnitud (comptarien cada enllaç dues vegades i encara sobrarien) i 16.512 correspondria a un nombre de punts més petit. Sense pista: les quatre opcions són xifres i qualsevol indicació seria donar la fórmula, que és tota la pregunta (C-10).

Quan hi ha dos camins alternatius amb el mateix cost, el protocol no en tria un: fa repartiment de càrrega entre tots dos. Per això no és ni B només ni C només, i D és falsa perquè sí que hi ha alternativa.

Quan els rangs privats dels dos extrems s'encavalquen, cap dels dos pot encaminar cap a l'altre sense ambigüitat, i la solució és que cadascú tradueixi les seves adreces d'origen al seu propi tallafoc, de manera que l'altre les vegi dins d'un rang que no col·lisiona amb el seu. Fer NAT només en un costat deixa el problema a mitges, i traduir el destí no resol l'encavalcament de l'origen.

Cada extrem del cable ha de portar el connector que troba: SC al panell de presentació i LC a l'SFP del commutador. Només l'opció A és un latiguillo híbrid LC-SC, amb un connector de cada tipus. La B és ST-SC —no hi ha cap LC—, la C és LC-LC per tots dos costats i no entra al panell, i la D no és ni fibra: és un cable de coure amb connectors RJ45.

Entre encaminadors del mateix sistema autònom la sessió BGP és iBGP (interna); eBGP és la que s'estableix amb un AS diferent. MP-BGP no és una alternativa sinó una extensió de BGP per transportar altres famílies d'adreces (VPN, IPv6), i OSPF és un IGP que no transporta la taula completa d'Internet.

El LOCAL_PREF és l'atribut que decideix, dins de tot l'AS, per on surt el trànsit, i guanya el valor més alt: apujar-lo a les rutes apreses del CATNIX fa que se surti per allà. L'AS-prepending actua sobre l'AS_PATH que anunciem als altres i per tant influeix en per on ens entra el trànsit, no en per on surt. I no és cert que les rutes del CATNIX siguin sempre un AS més a prop.

Un atac volumètric satura l'enllaç amb l'ISP, de manera que qualsevol defensa instal·lada a casa nostra —tallafocs de nova generació, IPS o gestor d'ample de banda— arriba tard: el tub ja està ple abans. L'única solució que no compromet l'ample de banda de sortida és que l'ISP desviï el trànsit aigües amunt amb un anunci BGP específic i el netegi abans de lliurar-nos-el.

A l'algorisme de selecció de BGP, el tipus de veí només es mira quan weight, local preference, longitud d'AS-path, origen i MED ja han empatat. Aquí és el criteri que desempata: a igualtat de tota la resta, es prefereix la ruta apresa per EBGP davant de la d'IBGP.

Aquí el desempat es produeix abans: el weight és el primer criteri de tot l'algorisme de selecció i és local a l'encaminador. Si un weight és més alt, la resta d'atributs (LocPrf, mètrica, tipus de veí) ja no s'arriben a avaluar.

La wildcard es compara bit a bit amb l'adreça de la sentència. Amb 10.44.38.0 0.0.3.255 es fixen els 6 bits alts del tercer octet, i 38 hi dona el bloc 36-39, que no conté el 40. Amb 0.0.15.255 només es fixen els 4 bits alts: 38 i 40 comparteixen aquests bits (tots dos cauen al bloc 32-47) i hi ha coincidència. La 0.0.1.255 i la 0.0.7.255 donen blocs 38-39 i 32-39, que es queden curts, i la 0.0.5.255 no és una màscara contigua.

RPVST+ (Rapid PVST+) combina les dues coses que demana l'enunciat: la convergència ràpida de RSTP —segons en lloc dels 30-50 s de l'STP clàssic— i un arbre per VLAN. PVST té l'arbre per VLAN però convergeix lent, MST és ràpid però agrupa VLAN i és per a escenaris amb moltes VLAN, i «SPT» no existeix com a variant.

EF (Expedited Forwarding, DSCP 46) és la marca reservada al trànsit de temps real i és la de més prioritat de les que fa servir un telèfon IP. AF46 i AF56 no existeixen: la família Assured Forwarding només arriba fins a AF43 (AF11-AF13, AF21-AF23, AF31-AF33, AF41-AF43). AF22 existeix però és una classe intermèdia, molt per sota d'EF.

Els telèfons IP i els punts d'accés s'alimenten pel mateix cable de xarxa amb PoE (Power over Ethernet), de manera que un sol commutador de 24 ports PoE cobreix la petició amb un únic element. Dos commutadors en són dos, i un commutador sense PoE més 24 injectors són 25 elements per fer exactament el mateix.

El VEC es calcula sense IVA i incloent-hi les pròrrogues previstes: per això són 1.243.000 € i 5 anys, no 3. Les dues variables que el tribunal creua aquí (impost i durada) són l'error més freqüent en plecs reals.

En travessar un encaminador, la IP d'origen i destí no canvien però les MAC sí que es reescriuen a cada salt. Per això al punt de captura s'hi veuen les IP dels dos servidors amb les MAC de les interfícies de l'encaminador, no les dels servidors.

Si el balancejador no toca l'adreça d'origen, els servidors responen directament al client i el tràfic de tornada no passa pel balancejador, que perd el control de la sessió. Fent NAT de la IP d'origen (NAT-Client o SNAT) els servidors veuen el balancejador com a origen i li retornen la resposta. El round robin i la persistència són polítiques de repartiment que no arreglen el camí de tornada, i deixar un servidor de reserva no és balanceig.

PIM-SM (Sparse Mode) comença sempre per l'arbre compartit amb arrel al Rendezvous Point: el receptor s'hi uneix i les primeres imatges hi passen. Un cop identificada la font, l'encaminador de l'últim salt s'hi uneix directament i canvia a l'arbre de camí més curt (SPT), i el RP deixa de portar el trànsit. Per això no és cert ni que hi passi sempre, ni que no hi passi mai, ni que es reparteixi entre els dos camins.

En una VPN IPsec la negociació té dues fases: a la fase 1 actua ISAKMP/IKE, que autentica els extrems i obre el canal segur de gestió, i a la fase 2 es negocien les associacions de seguretat que IPsec farà servir per protegir les dades. La primera opció inverteix l'ordre, dir només «IPSec» deixa fora la negociació, i IPv6 és una versió del protocol IP que no xifra ni autentica per si mateixa.

A la taula d'OSPF cada ruta porta la marca del seu origen: O és intra-àrea, O IA és d'una altra àrea del mateix domini OSPF i O E1 / O E2 són rutes redistribuïdes des de fora del domini OSPF. Una xarxa que entra per redistribució es veu, doncs, com a E1 o E2 —E2 per defecte—, mai com a O ni com a O IA. «NSSA» designa un tipus d'àrea, no la marca d'una ruta en aquesta sortida.

Les dues rutes s'instal·len a la taula, perquè són prefixos diferents: el DT01 té 10.1.0.0/16 i el centre de Serveis Socials, 10.1.30.0/24. Davant de dues rutes que contenen la mateixa adreça, l'encaminador aplica el prefix més llarg, i el /24 és més específic que el /16: el paquet va cap a Serveis Socials i el contesta la impressora, que és qui hi té configurada la 10.1.30.34. Els codis O IA (inter-àrea) i O E2 (externa redistribuïda) són el parany de la pregunta: només ordenarien entre rutes del mateix prefix, i aquí no ho són. Per això no contesta el PC del DT01 ni contesten tots dos, i tampoc és cert que no contesti ningú.

Un bucle de nivell 2 es trenca eliminant un dels enllaços de la LAN, que és on viu el bucle, i deixant l'altre per no perdre la connectivitat. Desconnectar l'encaminador (A) o els dos cables (D) deixa la seu aïllada, i els enllaços WAN de fibra (B) no formen part del domini de difusió.

Es demana el prefix mínim per a cada xarxa, i el criteri és el mateix: el prefix més llarg que encara doni prou adreces útils per als equips de cada supòsit. Amb el recompte de telèfons i de PC del plànol, la xarxa de telefonia necessita un /22 (1.022 útils) i la de PC en té prou amb un /27 (30 útils). Les altres combinacions o bé es queden curtes en una de les dues xarxes o bé reserven molt més del mínim.

Segment Routing és el protocol que va idear l'equip de Clarence Filsfils per portar les xarxes MPLS cap a un model SDN: l'origen codifica el camí en una llista de segments i desapareix l'estat per flux del nucli, i per això no calen LDP ni RSVP-TE. OSPFv3 és OSPF per a IPv6, i SD-Access i SD-WAN són arquitectures comercials, no el protocol pel qual es pregunta.

iBGP exigeix que tots els encaminadors estiguin units entre si, i amb molts PE això és inviable. L'encaminador reflector de rutes (route reflector) trenca aquesta obligació: rep les rutes d'un client iBGP i les reflecteix als altres, de manera que cada PE només manté una sessió amb ell. L'encaminador P és del nucli i no parla BGP de client, l'ASBR és el que connecta amb un altre AS i «encaminador Server» no existeix.

La lectura d'un reflectòmetre: la traça acaba al punt E, i la distància es llegeix en l'escala del gràfic, que dona 0,644 km. B dona la xifra en metres però mal llegida i D confon l'escala per un factor de mil, convertint 3,864 km en un tall inexistent.

Radia Perlman va dissenyar el Spanning Tree Protocol i és l'autora de Interconnections: Bridges and Routers. Vinton Cerf i Robert Kahn són els autors de TCP/IP, i Jeff Doyle és conegut pels seus manuals d'encaminament IP, no per l'STP.

La ruta subòptima no arriba a formar-se perquè EIGRP marca les rutes redistribuïdes des d'un altre protocol com a externes i els assigna una distància administrativa de 170, pitjor que la 110 d'OSPF. R1 continua preferint, doncs, la ruta OSPF nativa cap a 10.1.1.0/24. Per això no cal filtrar a R1, ni manipular distàncies —OSPF ja té la millor—, ni recórrer a les route tags, que són una manera de prevenir bucles però no l'única.

⚠️ Pregunta amb opcions en imatge (quatre esquemes de topologia): cal el PDF. L'arquitectura spine-leaf és la malla de dos nivells on cada leaf es connecta a tots els spine i cap leaf es connecta amb un altre leaf; així qualsevol servidor és sempre a dos salts de qualsevol altre.

VRRP és el protocol estàndard de redundància de la passarel·la per defecte i és per tant l'únic que funciona entre encaminadors de fabricants diferents. HSRP i GLBP són propietaris de Cisco; a més, GLBP està pensat per repartir la càrrega, cosa que l'enunciat diu explícitament que no cal. El policy routing dirigeix trànsit segons criteris, però no crea cap adreça virtual ni cap mecanisme de reserva.

LACP (802.3ad) és el protocol de negociació estàndard i l'únic que entenen alhora un commutador Cisco i un Aruba. PAgP és propietari de Cisco i l'Aruba no el parla. L'spanning tree no agrega enllaços, els bloqueja, i el mode «on» forma l'agregació sense negociar res, que és precisament el que l'enunciat descarta.

Dels quatre valors del Manifest Àgil, el que encaixa amb «les funcionalitats s'aniran definint a mesura que avanci» és la col·laboració amb el client per damunt de la negociació contractual, l'opció 1: si els requisits no es poden tancar abans de començar, el que sosté el projecte és la relació continuada amb qui els ha de dir, no el contracte. Les opcions 0 i 2 són dos valors del manifest invertits —el manifest posa els individus i les interaccions per damunt dels processos i les eines, i respondre al canvi per damunt de seguir un pla—, que és la distractora que el tribunal repeteix. L'opció 3 contradiu la cadència àgil: l'àgil escurça l'interval entre lliuraments, no l'espaia.

Els esdeveniments d'Scrum són exactament cinc: Sprint, Planificació, Scrum diari, Revisió i Retrospectiva. El «seguiment de l'sprint» no existeix com a esdeveniment: el seguiment es fa al Scrum diari.

La correcta és GeoBCN: la llibreria de geocomponents JavaScript (amb paquet per a Angular) i el servei RESTful de geocodificació que l'Ajuntament de Barcelona posa a disposició de les persones desenvolupadores, i que fan servir el Plànol BCN i el Portal d'Informació Urbanística. Les altres tres opcions —BCNLibre, BCN Plus, CartoLib— són noms inventats que no corresponen a cap eina real de l'Ajuntament.

ETRS89 és el sistema de referència geodèsic oficial i obligatori a Espanya des del RD 1071/2007 per a la península i les Balears, i és el datum sobre el qual es projecta la UTM a Barcelona (fus 31 nord, EPSG:25831).

Compte amb el mot «projecció» de l'enunciat: les quatre opcions no són projeccions sinó sistemes de referència. La projecció ja la diu el mateix enunciat —UTM—, i el que hi falta és el datum sobre el qual es projecta. Sistema de referència i projecció són dues capes distintes de la mateixa resposta, no alternatives.

ED50 (European Datum 1950) és el datum antic que ETRS89 va substituir, i encara apareix en cartografia antiga. «ED68» no correspon a cap datum en ús a Espanya, i «ETRS 132» no correspon a res: la sèrie ETRS s'identifica per l'any en què es defineix —d'aquí el 89—, no per un número d'ordre.

Git és l'eina de codi obert de referència per a la gestió descentralitzada de versions: permet organitzar el desenvolupament i gestionar els canvis d'un grup de programadors mitjançant repositoris, branques i historial complet a cada còpia local, exactament el que planteja l'enunciat. «PANTHER», «PUSH» i «GestVers» no són eines reals de gestió de versions: són noms fabricats per a l'examen, sense cap organització, estàndard ni producte darrere.

L'enunciat demana quina afirmació NO és certa sobre les responsabilitats del cap de projecte de l'empresa proveïdora. Segons el marc PMBOK, validar l'abast —donar la conformitat i acceptar formalment els entregables— és una funció del client o patrocinador, no del director de projecte de qui executa el contracte: al supòsit, són les persones usuàries del Departament de Gestió Integral del Soroll qui validen les funcionalitats en les sessions UAT. Per això l'afirmació falsa és que el cap de projecte proveïdor «ha de donar la conformitat última... un cop fetes les validacions per part de la persona usuària»: és just al revés, la conformitat última la dona qui ha validat, no qui ha executat. Els informes de seguiment, estar informat dels plans de proves i respondre de la gestió de riscos sí que són responsabilitats típiques d'un cap de projecte proveïdor.

Sentilo és el nom real de la plataforma de gestió de sensors i actuadors de ciutat, desenvolupada per l'Ajuntament de Barcelona i adoptada per altres ciutats. «ÚNICA», «SONOMÈTRICA» i «PISTILO» no corresponen a cap plataforma coneguda: són noms inventats que sonen versemblants pel context (sonòmetres → «SONOMÈTRICA», Sentilo → «PISTILO»).

La correcta és l'opció 2: CMS (Content Management System). L'enunciat demana una eina per construir un web informatiu amb manteniment manual del contingut, sense necessitat de processos transaccionals ni de programació: això és exactament un CMS. L'opció 0, CRM, gestiona la relació amb els clients, no la publicació de continguts. L'opció 1, ERP, gestiona processos i recursos interns de l'organització (finances, RRHH, logística), no la publicació d'un web. L'opció 3, PMS (Project Manager Suite), és una eina de gestió de projectes, sense relació amb la publicació de continguts web.

Per a una aplicació només per a Android que ha d'accedir al micròfon per mesurar decibels i on la prioritat és el rendiment i una bona experiència d'usuari, la tecnologia correcta és una aplicació nativa: és la que dona accés complet al maquinari —el micròfon, en aquest cas— i el millor rendiment, a canvi de limitar-se a una sola plataforma, que és precisament el que demana l'enunciat. Una híbrida o una eina cross-platform sacrifiquen rendiment i accés directe al maquinari per una portabilitat que aquí no cal, i una webapp té l'accés més limitat de totes al maquinari del dispositiu.

La raó per triar una eina de BI és genèrica i tecnològica: integra informacions de diferents orígens i les converteix en coneixement per a l'organització, que és exactament el que l'equip necessita per relacionar dades i buscar-hi correlacions. Les altres tres opcions no descriuen cap propietat del BI: no hi ha eines de BI especialitzades en soroll (el domini és indiferent a l'eina), la gestió de queixes és una funció d'un sistema de tramitació o de relació amb la ciutadania, i l'accés a internet no hi té cap relació.

La clau oficial és errònia, i està documentada. GeoJSON sí és un format geogràfic vàlid —és l'estàndard de facto per a dades geoespacials en JSON, capaç de representar punts i polígons per a Sistemes d'Informació Geogràfics— i per tant no hauria de ser la resposta a «quin format NO seria adequat». El format que no és geogràfic entre les quatre opcions és MKV (Matroska Video), un contenidor de vídeo sense cap capacitat per emmagatzemar geometries.

La graella de solucions del document oficial marca, tanmateix, l'opció GeoJSON com la incorrecta, i el banc en conserva la clau tal com el tribunal la va donar per bona (norma C-17): la pregunta es manté amb el seu enunciat i la seva resposta oficial, però qui repassa ha d'aprendre que GeoJSON, KMZ i GeoPackage són tots tres formats vectorials vàlids per a SIG, i que l'intrús real de la llista és MKV.

L'ordre de construcció d'un quadre de comandament integral és objectius estratègics → mapa estratègic → selecció i disseny d'indicadors → establiment de metes → plans d'acció. L'única opció que respecta aquesta seqüència és la que, un cop elaborat el mapa estratègic, col·loca els indicadors i tot seguit les metes per a cada indicador en un període determinat. L'opció que comença per la planificació del projecte i acaba als indicadors salta l'establiment de metes i inverteix la relació entre delimitació i estratègia; l'opció que diu que «la definició d'objectius és el més important» no descriu cap seqüència de fases; i la que posa els plans d'acció immediatament després del mapa estratègic es salta els indicadors i les metes, que són justament el que permet saber si cal una mesura correctora.

La satisfacció de la ciutadania davant les actuacions de millora és un indicador de resultats: mesura l'efecte de l'actuació sobre la població, no l'activitat que la va produir. Els indicadors d'organització (o d'estructura) descriurien els mitjans dedicats —persones, pressupost, sonòmetres instal·lats—; els de procés, l'activitat feta —actuacions executades, temps de resposta a una queixa—; i els d'entorn, les variables externes que condicionen el servei —densitat de població, trànsit—, que no són resultat de res que faci l'organització.

El supòsit descriu la fase de transició del sistema de gestió del soroll: proves ja executades, sessions UAT ja validades per les persones usuàries del Departament, i una planificació de la posada en marxa que ja inclou, entre les seves tasques, el Pla de formació i el Pla de suport al costat del desplegament del maquinari. L'afirmació que NO és correcta és que la posada en marxa finalitzi amb l'acceptació tècnica de l'equip d'Operació i Sistemes i que només llavors es pugui executar el Pla de formació: la formació de les persones usuàries s'ha de tenir llesta abans o durant la posada en marxa, no després que el servei ja estigui acceptat i en producció, perquè qui l'ha d'utilitzar des del primer dia necessita saber-ho fer des del primer dia. Que es pugui fer una instal·lació «cega» a producció sense obrir l'accés —per comprovar la configuració abans d'obrir- la a les persones usuàries—, que la documentació de lliurament inclogui tant els manuals d'usuari com els tècnics i el full d'escalats del SAU, i que el Pla de suport s'executi durant i després de la posada en funcionament, són, en canvi, afirmacions correctes sobre com es tanca aquest tipus de projecte.

Per intercanviar informació per mitjans telemàtics amb altres administracions públiques catalanes (com les de l'Àrea Metropolitana), cal integrar-se amb l'EACAT, la plataforma de tramitació interadministrativa del Consorci AOC amb un canal bidireccional segur (opció D). SARA (opció A) és la xarxa de l'Administració General de l'Estat, no del Consorci AOC. Via Oberta (opció B) serveix per consultar dades, no per tramitar expedients entre administracions. Els serveis de transparència i govern obert (opció C) no tenen relació amb l'intercanvi telemàtic d'informació entre administracions.

En un informe de prova de càrrega, mitjana (987) i mediana (961) gairebé iguals indiquen un rendiment estable, no inestable des de l'inici: això descarta les opcions 1 i 2, que parlen d'inestabilitat inicial. Amb un throughput d'1.491.193 peticions per minut i una desviació baixa en relació amb la mitjana, el servei escala i arriba a un rendiment que es llegeix com a acceptable, no com a inacceptable: això descarta l'opció 3. La correcta és la 0.

La pregunta es respon amb el supòsit al davant, no amb matèria del temari. El que s'hi demana és construcció, proves i posada en funcionament: la construcció i les proves són de la Direcció de Desenvolupament i la posada en funcionament, de la Direcció d'Operacions i Sistemes. Estratègia i Nous Projectes intervé en la fase prèvia de definició, i Processos i Millora de la Gestió no participa en aquesta part.

Hadoop és l'ecosistema de referència per al processament distribuït per lots de grans volums de dades, amb el seu sistema de fitxers HDFS i el model MapReduce: és una eina Big Data. Hootsuite, Periscope i Unfold són eines de gestió, difusió i creació de contingut per a xarxes socials, sense cap relació amb l'emmagatzematge o el processament de grans volums de dades.

El càlcul que demana l'enunciat és directe: 200 sonòmetres × 6 lectures per hora × 24 hores = 28.800 registres al dia, i a 30 bytes per registre surt menys d'un megabyte diari. Aquest volum es tracta amb tecnologia convencional, de manera que la resposta no és «sí»: ni per volum (la segona i la tercera opcions), ni pel fet que siguin sensors de ciutat, perquè la necessitat de big data la determinen el volum, la velocitat i la varietat, mai el domini de l'aplicació. El càlcul exacte són 864 KB al dia.

La clau oficial és errònia, i està comprovada contra el PDF. La graella de solucions del document oficial marca la D al supòsit 4, fila 19, i el banc guarda la D: la importació és fidel i no hi ha cap desalineament. El problema és de la pregunta. La D justifica el «no» pel cost de les tecnologies big data en projectes urbans, un criteri que l'enunciat no esmenta enlloc; la A el justifica pel volum diari de pocs megabytes, que és exactament el que l'enunciat demana calcular. Les dues comencen per «No», que és probablement com s'hi va colar.

La pregunta es conserva tal com va caure i la clau no es toca (norma C-17). El que cal aprendre'n és el càlcul, no el criteri del cost.

Correcta: PaaS al cloud públic (opció 1). L'equip de desenvolupament no pot assumir tasques d'infraestructura i cal sortir a temps en una setmana: amb PaaS el proveïdor aporta tot l'entorn d'execució i només cal pujar-hi el codi. IaaS (opció 0) obligaria l'equip a instal·lar i mantenir sistema operatiu i middleware, exactament el que no poden assumir. SaaS (opció 2) no serveix perquè no és una aplicació ja feta que es contracti, és un desenvolupament propi. Ampliar l'on-premise (opció 3) xoca amb l'enunciat, que diu que els servidors corporatius no tenen capacitat, i l'afirmació que el cloud "no és prou segur" és fals de fàbrica.

Quan al plec no hi ha cap clàusula sobre la llicència del programari desenvolupat i s'entén que el codi és propietat de l'Ajuntament (per l'art. 308.1 LCSP, que en aquest supòsit cedeix la propietat intel·lectual a l'Administració llevat de pacte en contra), alliberar-lo com a codi obert exigeix dos passos, no un: primer comprovar que l'empresa desenvolupadora no hi ha incorporat llibreries de tercers amb llicència propietària que n'impedeixi la publicació, i després associar-hi una llicència de programari lliure adequada. Publicar-lo directament sense aquesta comprovació prèvia, alliberar-lo només en format binari, o supeditar la publicació a criteris de bones pràctiques de codi (comentaris, indentació) són, totes tres, respostes incompletes o directament equivocades sobre el procediment real.

La resposta correcta és la A: qualsevol servei whois permet consultar la titularitat d'un domini. La B és falsa perquè el whois del .cat no és l'únic mitjà: hi ha serveis whois genèrics i el RDAP. La C és falsa perquè la consulta no està reservada a les empreses registradores. La D és falsa perquè la titularitat d'un domini és informació pública, accessible via whois o RDAP.

Segons la NTI d'Expedient Electrònic, l'índex electrònic pot incorporar documents que formin part de més d'un expedient —un mateix document pot ser referenciat des de diversos expedients sense duplicar-se—, així que l'afirmació que "no incorpora documents que formin part de més d'un expedient" NO és certa. Les altres tres sí ho són: l'índex numerat garanteix la seqüència cronològica, es forma en format d'intercanvi ENI-XML, i es pot generar un índex provisional abans del tancament de l'expedient.

La correcta és l'única afirmació general i certa per a qualsevol sèrie: qui fixa com s'informen les metadades és sempre l'anàlisi documental de la sèrie corresponent, no una regla universal del MGDE. Les altres es passen de concretes o d'absolutes: que calguin els valors dels audímetres és una decisió d'aquesta anàlisi en concret, no una norma general de les metadades de gestió; dir que les metadades de registre s'omplen soles per a TOTS els documents de l'expedient és fals, perquè només ho fan els documents lligats a l'assentament registral; i l'identificador únic de l'expedient, un cop generat, no se substitueix pel d'un tràmit —és precisament el que en garanteix la identificació unívoca en tot el sistema.

NO és certa l'afirmació que la presentació de documentació requerida per una esmena al Registre electrònic únic «no produeix efectes jurídics» (opció C): és just al revés, l'esmena sí que produeix efectes i és la via per corregir una presentació incompleta. Les altres tres són certes: el registre emet automàticament un rebut amb data, hora i número d'entrada (opció A), cursa els documents sense dilació (opció B), i la seu ha d'informar de qualsevol suspensió temporal del servei (opció D).

La tipologia d'eina que extreu dades d'orígens heterogenis, les transforma —neteja, normalitza, deduplica, aplica regles— i les carrega a un destí comú és l'ETL, i és exactament la funció que descriu l'enunciat: integrar, normalitzar i controlar la integració de fonts diverses. Un GIS és un sistema d'informació geogràfica: representa i analitza dades amb component espacial, però no integra orígens. AGILE no és una eina sinó un enfocament de gestió de projectes. I Kubernetes és un orquestrador de contenidors: executa càrregues de treball, sense saber res del contingut de les dades.

JS (JavaScript) no és un format de dades obertes: és un llenguatge de programació. Entre KML, RDF, CSV i JS, els tres primers descriuen dades —geogràfiques, enllaçades i tabulars, respectivament— i són formats adequats per publicar conjunts de dades obertes; JS, en canvi, manipula dades, no les descriu, i per això no serveix per oferir un dataset amb les dades del soroll.

Correcta: contractar una CDN al núvol (opció 2). El trànsit serà internacional i de volum desconegut però amb creixement exponencial, i cal una mesura ràpida d'implementar: una CDN distribueix el contingut a punts de presència arreu del món i absorbeix el gruix de les peticions abans que arribin a l'origen. "Escalar el servidor al màxim" (opció 0) és escalat vertical amb un sostre físic que no aguanta un creixement exponencial. "Balancejar el servidor" (opció 1) no aporta res sobre un sol servidor sense rèpliques darrere. Una CDN on-premise (opció 3) no dona l'abast geogràfic internacional ni es desplega en pocs dies.

La correcta és l'opció 2 («No és recomanable pujar al núvol dades personals o corporatives, per problemes de seguretat»): un proveïdor «prestigiós» no acredita per si sol conformitat amb l'ENS ni una base jurídica vàlida per a la transferència internacional (RGPD), i les dades de queixes ciutadanes són dades personals. Per defecte, sense haver resolt aquests dos punts, el risc és de seguretat i de conformitat legal. Les altres tres cauen totes en un argument fals i absolut: l'opció 1 diu que el núvol «sempre anirà massa lent», que és fals i, a més, un problema de rendiment, no de sobirania; l'opció 3 dona per fet que «els convenis internacionals de protecció de dades» de Barcelona ja cobreixen la transferència, quan la base jurídica real (decisió d'adequació, clàusules contractuals tipus, EU-US Data Privacy Framework...) s'ha d'acreditar proveïdor a proveïdor, no per adscripció genèrica de la ciutat; l'opció 4 diu que el núvol és «gratuït», fals de base.

La signatura biomètrica manuscrita sobre tauleta permet que la persona interessada s'identifiqui i signi ella mateixa la petició, abans de l'assentament, sense que el funcionariat hagi d'actuar «en nom seu»: és l'única opció que compleix la seqüència que el mateix enunciat exigeix —identificació i signatura de la petició, i només llavors l'assentament registral, amb el justificant segellat amb segell d'òrgan. Les altres tres fallen, cadascuna per un motiu diferent: l'opció 1 inverteix l'ordre —registra primer i fa signar després, i a més la signatura recau sobre el justificant de registre, no sobre la petició—, de manera que l'assentament s'hauria practicat sense la signatura de la sol·licitud que el fonamenta; l'opció 2 confon consentiment amb identificació: marcar una casella d'acord no és cap dels sistemes d'identificació ni de signatura que admet la Llei 39/2015, i deixa l'assentament sense signatura de la persona interessada; l'opció 3 fa que el funcionariat activi l'idCat Mòbil a nom de la persona amb un consentiment de paraula, i l'art. 12.2 de la Llei 39/2015 exigeix, per a l'assistència del funcionariat habilitat, que la persona s'identifiqui davant seu i presti consentiment exprés del qual quedi constància, precisament per als casos de discrepància o litigi.