Paniere domande

✅ B. Il terzo parametro `true` di addEventListener attiva la fase di CAPTURING (discesa dalla radice al target). Con `false` (default) è il BUBBLING (risalita dal target alla radice). Non esistono «thread separati» nel modello di eventi DOM — JavaScript è single-threaded. ❌ A: il bubbling corrisponde al valore `false`. ❌ C: i thread separati non esistono per i gestori DOM normali. ❌ D: la coda microtask è per Promise/queueMicrotask, non per addEventListener.

✅ B. In fase di BUBBLING l'evento parte dal target (figlio) e risale verso gli antenati: prima gestore del figlio, poi del padre. In capturing (terzo parametro `true`) è l'opposto. ❌ A: descrive il comportamento in fase capturing, non bubbling. ❌ C: thread separati non esistono per il DOM. ❌ D: il padre riceve l'evento tramite bubbling, salvo `stopPropagation()`.

✅ B. `stopPropagation()` impedisce che l'evento si propaghi (né bubbling né capturing). `preventDefault()` annulla l'azione di default del browser (es. submit del form, follow di un link). Sono indipendenti: si possono usare entrambi, uno solo, o nessuno. ❌ A: sono metodi distinti con effetti diversi. ❌ C: li inverte. ❌ D: stopPropagation non ferma «tutti gli script», agisce solo sulla catena di propagazione dell'evento corrente.

✅ B. JS ha un singolo thread principale (main thread). L'event loop gestisce una coda di callback/messaggi eseguendoli uno alla volta. I Web Workers sono thread separati ma NON accedono al DOM direttamente. Le Promise non cambiano questo — usano la coda delle microtask nello stesso thread. ❌ A e D: il DOM non è thread-safe; l'accesso parallelo causerebbe race condition. ❌ C: anche le Promise girano nel main thread tramite microtask queue.

✅ C. La firma digitale = hash del documento cifrato con la CHIAVE PRIVATA del mittente. Solo il mittente conosce la propria chiave privata → autenticazione. Il destinatario verifica decifrando con la chiave PUBBLICA del mittente e confrontando con l'hash ricalcolato. ❌ A: cifrare l'hash con la propria chiave pubblica non darebbe autenticazione (chiunque ha la chiave pubblica). ❌ B: cifrare con la chiave pubblica del destinatario è la cifratura per RISERVATEZZA, non firma. ❌ D: la chiave privata del destinatario è segreta e usata per decifrare messaggi ricevuti.

✅ D. Per verificare la firma di Mario si usa la CHIAVE PUBBLICA di Mario (pubblica = accessibile a tutti). Il destinatario: 1) decifra la firma con la chiave pubblica di Mario → ottiene l'hash originale; 2) calcola l'hash del documento ricevuto; 3) se i due hash coincidono, la firma è valida. ❌ A: la chiave privata del destinatario serve per decifrare messaggi cifrati per lui. ❌ B: la chiave privata di Mario è segreta, non accessibile al destinatario. ❌ C: la propria chiave pubblica non ha relazione con la firma di Mario.

✅ C. Per riservatezza: si cifra con la CHIAVE PUBBLICA del destinatario (Sara). Solo Sara, con la propria chiave privata, potrà decifrarlo. ❌ A: cifrare con la propria chiave privata crea una firma (autenticazione), non riservatezza. ❌ B: cifrare con la propria chiave pubblica sarebbe decifrabile solo con la propria chiave privata — inutile per la comunicazione. ❌ D: la chiave privata di Sara è segreta e non accessibile al mittente.

✅ B (24TB). RAID 5: capacità = (N-1) × dimensione_disco = (7-1) × 4TB = 6 × 4TB = 24TB. Un disco equivalente è usato per la parità (distribuita tra tutti). ❌ A (28TB): sarebbe la capacità totale senza ridondanza (RAID 0). ❌ C (20TB): sarebbe (N-2)×4=20 → formula del RAID 6. ❌ D (16TB): formula errata.

✅ C (12TB). RAID 6: doppia parità → capacità = (N-2) × dimensione = (8-2) × 2TB = 6 × 2TB = 12TB. Tollera la perdita di 2 dischi contemporaneamente. ❌ A (16TB): è la capacità totale (RAID 0). ❌ B (14TB): formula (N-1) corretta per RAID 5, non RAID 6. ❌ D (10TB): formula errata.

✅ C. RAID 1 puro (mirroring) con 4 dischi: tutti i dischi contengono gli stessi dati → capacità = 1 disco = 1TB. Può perdere fino a 3 dischi su 4 (rimane almeno 1 copia). ❌ A (4TB): è la capacità totale senza ridondanza. ❌ B: RAID 1 con 2 dischi avrebbe 1TB e tollera 1 guasto; con 4 dischi la capacità rimane 1TB ma la tolleranza è maggiore. ❌ D: con 4 dischi in mirror si tollerano 3 guasti (non 2).

✅ B. RAID 10 = RAID 1 (mirroring) + RAID 0 (striping). I dati sono distribuiti in stripe su più coppie di dischi specchiati. Con 4 dischi: capacità = 50% del totale, tollera la perdita di 1 disco per ogni coppia. ❌ A: la parità distribuita è RAID 5. ❌ C: solo mirroring è RAID 1. ❌ D: striping con parità singola è RAID 5.

✅ B. REPEATABLE READ garantisce che le righe lette nella transazione non cambino se rilette → previene dirty read e non-repeatable read. NON previene i phantom read (nuove righe inserite da altre transazioni che appaiono in query successive con predicati di range). ❌ A: solo dirty read è READ COMMITTED. ❌ C: tutti e tre sono prevenuti da SERIALIZABLE (non da REPEATABLE READ). ❌ D: solo phantom read non corrisponde a nessun livello standard.

✅ B. READ COMMITTED previene SOLO i dirty read (lettura di dati non ancora committati). Non previene: non-repeatable read (stessa riga riletta dà valori diversi) né phantom read (nuove righe appaiono). ❌ A: tutti e tre prevenuti = SERIALIZABLE. ❌ C: non-repeatable read non è prevenuto da READ COMMITTED. ❌ D: i phantom read non sono prevenuti da READ COMMITTED.

✅ C. Phantom read = nuove righe (o righe eliminate) inserite/cancellate da altre transazioni compaiono (o scompaiono) tra due esecuzioni della stessa query con predicato (es. WHERE età > 30). ❌ A: è la definizione di dirty read. ❌ B: è la definizione di non-repeatable read (stessa riga, valore diverso). ❌ D: gli indici obsoleti sono un problema di implementazione, non un'anomalia di isolamento.

✅ B. Il principio fondamentale del layered architecture: ogni strato usa i servizi del layer SOTTO e espone servizi al layer SOPRA. La dipendenza è unidirezionale verso il basso. Questo garantisce separazione delle responsabilità e sostituibilità dei layer. ❌ A: l'accesso arbitrario tra strati elimina i vantaggi del layering. ❌ C: la comunicazione bidirezionale con TUTTI violerebbe l'incapsulamento. ❌ D: l'indipendenza totale non è corretta — ogni layer dipende da quello sotto.

✅ C. SHA-256 (SHA-2 family) produce sempre un hash di 256 bit = 32 byte. ❌ A (128 bit): è MD5 (sconsigliato, vulnerabile a collisioni). ❌ B (160 bit): è SHA-1 (deprecato). ❌ D (512 bit): è SHA-512 (stessa famiglia SHA-2 ma digest più lungo).

✅ B. La catena di fiducia PKI: il certificato del server è firmato da una CA intermedia, che è firmata dalla CA radice (root CA). Il client verifica la catena risalendo fino alla root CA che ha in memoria come fidata. ❌ A: la PKI gestisce l'autenticazione/identità; la cifratura usa le chiavi derivate dall'handshake TLS. ❌ C: le chiavi private NON vengono mai distribuite dalla CA — restano sempre sul proprietario. ❌ D: il rinnovo è un processo separato (ACME, SCEP).

✅ B. TLS 1.3 riduce a 1 round-trip (1-RTT) l'handshake rispetto ai 2 di TLS 1.2, con «0-RTT» per le sessioni ripristinate. Elimina algoritmi deboli (RSA key exchange, RC4, MD5/SHA-1) e usa solo suite sicure (ECDHE, AES-GCM, ChaCha20). ❌ A: TLS usa sempre sia asimmetrica (key exchange) sia simmetrica (dati). ❌ C: i certificati X.509 rimangono fondamentali per l'autenticazione. ❌ D: MD5 è eliminato da TLS 1.3, non adottato.

✅ C. HTTP 401 (Unauthorized) = manca l'autenticazione o le credenziali sono errate. Il client deve autenticarsi. ❌ A: l'autenticato senza permessi riceve 403 (Forbidden). ❌ B: risorsa inesistente = 404 Not Found. ❌ D: errore interno server = 500 Internal Server Error.

✅ B. Stateless = il server non mantiene stato della sessione tra richieste. Ogni richiesta è autosufficiente (include token di autenticazione, parametri, etc.). Questo facilita scalabilità orizzontale. ❌ A: il DB è separato dallo stato della sessione. ❌ C: il client può usare cookie/localStorage; il vincolo riguarda il server. ❌ D: le risorse REST hanno stato (possono essere modificate via PUT/PATCH/DELETE).

✅ B. La concatenazione diretta dell'input utente nella stringa SQL è la causa classica di SQL injection. Un input come `' OR '1'='1` modifica la logica della query. ❌ A, C, D: tutte usano parametri — il DBMS interpreta il valore dell'utente come dato puro, mai come codice SQL. Questo è il modo corretto (prepared statements / parametrized queries).

✅ B. XSS stored (persistente): lo script malevolo è salvato nel DB (es. in un commento) e viene servito a tutti gli utenti che visitano la pagina → più pericoloso. XSS reflected: il payload è nel request (URL, form) e il server lo «rimanda» (reflect) nella risposta → colpisce solo chi clicca il link malevolo. ❌ A: è l'opposto. ❌ C: non è richiesto accesso fisico. ❌ D: né l'uno né l'altro cifra il payload.