Amazon SCS-C02: Sicurezza perimetrale e delle applicazioni — Guida allo studio
Fa parte della AWS Security Specialty SCS-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.
Restrizione Geografica di CloudFront e Blocco a Livello di Paese
CloudFront offre due meccanismi per bloccare il traffico per paese, e la scelta tra i due è importante per costi e funzionalità. La funzionalità integrata di restrizione geografica (chiamata anche geoblocking) è configurata direttamente sulla distribuzione e valuta le richieste all’edge confrontando l’IP del visualizzatore con una allowlist o blocklist di paesi. È gratuita, non richiede la valutazione di regole e restituisce un HTTP 403 prima che avvenga qualsiasi richiesta all’origine. Per semplici scenari di conformità — “blocca i visitatori dal paese X” — questa è l’opzione più economica e semplice.
L’alternativa è un’istruzione di geo match di WAF, che è più flessibile: è possibile combinare le corrispondenze per paese con percorsi URI, header, limiti di frequenza o negarle (“consenti il paese A solo per /admin”). WAF è necessario quando la logica è condizionale; la sola restrizione geografica non può esprimere “blocca il paese X solo per un percorso specifico”. Scegli la restrizione geografica nativa quando il requisito è un blocco di paese generico e vuoi evitare il costo per richiesta di WAF.
URL Firmati vs. Cookie Firmati per Contenuti Privati
CloudFront supporta due modi per servire contenuti privati autorizzati mantenendo l’origine (bucket S3, ALB o origine Media) nascosta dietro un origin access control o un header personalizzato:
URL firmati: ogni URL trasporta una firma e una policy. Ideale per il download di un singolo file o quando è necessario un controllo degli accessi per singolo file (ad es., un link una tantum per l’installazione di un software).
Cookie firmati: il client riceve un set di cookie
CloudFront-Policy,CloudFront-SignatureeCloudFront-Key-Pair-Iduna sola volta dal tuo servizio di autenticazione. Tutte le richieste successive a pattern di percorso corrispondenti vengono autorizzate automaticamente senza riscrivere gli URL.
Per lo streaming video HLS, dove una singola sessione di riproduzione recupera migliaia di segmenti .ts referenziati da un manifest, i cookie firmati sono drasticamente più semplici. Riscrivere ogni URL di segmento nel manifest con un URL firmato distinto è possibile ma aggiunge latenza e complessità. Imposta il cookie dopo che l’utente si è autenticato sul tuo archivio utenti interno, limitando l’ambito al pattern del percorso di streaming.
Una policy canonica per un cookie firmato con wildcard si presenta così:
{
"Statement": [{
"Resource": "https://d123.cloudfront.net/videos/*",
"Condition": {
"DateLessThan": {"AWS:EpochTime": 1735689600},
"IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}
}
}]
}
Abbina questo a un origin access control (OAC) o a un header personalizzato segreto convalidato da WAF all’origine, in modo che gli utenti non possano bypassare CloudFront e raggiungere direttamente l’origine.
AWS WAF: Managed Rules, ATP e Rate-Based Rules
Associa la Web ACL alla distribuzione CloudFront piuttosto che a un ALB regionale quando il workload si trova dietro CloudFront. L’associazione all’edge termina le richieste dannose in uno delle centinaia di POP — più vicino all’attaccante — il che riduce il carico sull’origine durante un DDoS e abbassa l’egress dall’origine perché il traffico bloccato non attraversa mai il tuo VPC. Associare WAF solo all’ALB significa che l’attacco volumetrico raggiunge comunque il load balancer regionale e consuma LCU, e gli attacchi cross-region vengono gestiti da una singola regione anziché dalla rete edge globale.
Gruppi di regole chiave da combinare:
Set di regole gestite da AWS:
AWSManagedRulesCommonRuleSet(in stile OWASP top-10),AWSManagedRulesKnownBadInputsRuleSeteAWSManagedRulesAmazonIpReputationListoffrono un’ampia copertura con una messa a punto quasi nulla.Account Takeover Prevention (ATP):
AWSManagedRulesATPRuleSetispeziona l’endpoint di login che designi, traccia i pattern di credential stuffing, controlla le credenziali inviate confrontandole con un database di credenziali compromesse e blocca i bot che riutilizzano password trapelate. Configuralo con il percorso di login esatto e i nomi dei campi del body JSON per username e password.Regole basate sulla frequenza (rate-based): limitano il numero di richieste da un singolo IP in una finestra di 5 minuti (ad esempio 2.000 richieste). Limitarne l’ambito per URI o metodo in modo che lo scraping di
/searchnon influisca sulla navigazione anonima di/. Le regole basate sulla frequenza mitigano gli attacchi volumetrici di Livello 7 e l’enumerazione brute-force.
Un blocco di regole WAF ridotto:
Rules:
- Name: RateLimitLogin
Priority: 1
Action: { Block: {} }
Statement:
RateBasedStatement:
Limit: 500
AggregateKeyType: IP
ScopeDownStatement:
ByteMatchStatement:
SearchString: /api/login
FieldToMatch: { UriPath: {} }
PositionalConstraint: STARTS_WITH
TextTransformations: [{ Priority: 0, Type: LOWERCASE }]
Certificati ACM, Convalida DNS e CloudFront
Per CloudFront, il certificato deve essere provisionato in ACM in us-east-1 (N. Virginia) indipendentemente da dove si trovi la tua origine — questo è un requisito inderogabile perché CloudFront è un servizio globale che legge i certificati da quella Regione. I servizi regionali come ALB leggono dalla stessa Regione dell’ALB.
Usa sempre la convalida DNS con un record CNAME in Route 53 per qualsiasi certificato pubblico che desideri rinnovare automaticamente. ACM rinnova automaticamente i certificati convalidati tramite DNS finché il CNAME di convalida rimane pubblicato; Route 53 rende questa operazione banale (la console offre “Create records in Route 53” durante la richiesta). La convalida via email, al contrario, invia una conferma a cinque indirizzi del dominio (admin@, administrator@, hostmaster@, postmaster@, webmaster@) più il contatto WHOIS. Queste caselle di posta sono spesso inesistenti o messe in quarantena dai filtri email aziendali, quindi i rinnovi falliscono 60 giorni prima della scadenza e causano interruzioni evitabili. Non c’è modo di automatizzare i clic per la convalida via email.
Il pattern di rinnovo corretto per ALB multi-regione è: richiedere un certificato ACM convalidato tramite DNS per Regione, pubblicare il CNAME di convalida in Route 53 una volta, associare il certificato al listener dell’ALB e lasciare che ACM gestisca il rinnovo e la ridistribuzione. L’intervento umano termina con l’emissione.
DNSSEC e Route 53
Abilita la firma DNSSEC sulla hosted zone di Route 53 per prevenire DNS spoofing e cache poisoning contro il tuo dominio. Route 53 gestisce la KSK in KMS (una chiave asimmetrica ECC in us-east-1); è necessario pubblicare il record DS presso il registrar. Nota che la firma DNSSEC protegge la risoluzione della tua zona — non crittografa il traffico DNS (quello è DoH/DoT) e non influisce sul TLS di CloudFront.
Intestazioni di risposta: Policy vs. Lambda@Edge
CloudFront non inserisce automaticamente intestazioni di sicurezza come Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options o Content-Security-Policy. Se la tua origine non può essere modificata (un sito S3 legacy, un’origine di terze parti), hai due opzioni:
Policy per le intestazioni di risposta: una funzionalità nativa e dichiarativa di CloudFront. Collega una policy gestita o personalizzata a un comportamento della cache (cache behavior) per aggiungere intestazioni HSTS, CORS, di sicurezza e personalizzate. Questa dovrebbe essere la scelta predefinita: nessun codice, nessun avvio a freddo (cold start), nessun costo per invocazione.
Lambda@Edge (viewer response o origin response): da usare quando è necessaria una logica dinamica, come variare i nonce CSP per ogni richiesta o riscrivere le intestazioni in base agli attributi della richiesta. Scambia la semplicità con la flessibilità e aggiunge un costo per richiesta.
La policy gestita per le intestazioni di risposta SecurityHeadersPolicy copre le impostazioni di base più comuni in un unico collegamento (attachment).
Errori Comuni Spiegati
Richiedere certificati ACM pubblici con validazione via email è un processo fragile, proprio perché il rinnovo dipende da persone che leggono email inviate a indirizzi generici che la maggior parte delle organizzazioni non monitora o che finiscono nello spam. La validazione DNS con Route 53 elimina completamente l’intervento umano.
Collegare WAF solo all’ALB sembra equivalente sulla carta, ma forza il traffico di attacco a entrare nella tua Regione e consuma la capacità dell’ALB. Un WAF collegato all’edge su CloudFront blocca il traffico in centinaia di POP, quindi un attacco distribuito (flood) viene assorbito a livello globale e il traffico in uscita (egress) dall’origine rimane basso, un aspetto critico durante un DDoS.
Presumere che CloudFront aggiunga automaticamente le intestazioni di sicurezza porta al fallimento dei penetration test. La distribuzione agisce come proxy per qualsiasi intestazione inviata dall’origine; è necessario collegare esplicitamente una policy per le intestazioni di risposta o una funzione Lambda@Edge per inserire X-Frame-Options: DENY, HSTS e CSP.
Problema Pratico: Scenario d’Uso
Scenario: Meridian Financial gestisce un portale clienti distribuito a livello globale e un portale di report interni su AWS. Il traffico pubblico viene instradato tramite Amazon CloudFront verso Application Load Balancer per le API dinamiche e verso origini S3 per i report privati; il DNS è gestito in Route 53 e i certificati TLS sono emessi da AWS Certificate Manager (ACM).
Sfida: Degli aggressori stanno effettuando scraping e credential stuffing sugli account da diversi paesi, aggirando CloudFront per colpire direttamente gli endpoint di origine per scaricare report privati, causando un sovraccarico dell’origine e l’esposizione dei dati.
Approccio Consigliato:
- Configurare CloudFront come unico punto di ingresso pubblico e applicare la Geo Restriction di CloudFront per bloccare i paesi ostili; abilitare l’Origin Access Control (OAC) e bloccare le policy di origine di S3/ALB in modo che solo CloudFront possa recuperare il contenuto dall’origine.
- Distribuire i report privati per utente con URL firmati (signed URL) di CloudFront (con un TTL breve) invece che con cookie firmati (signed cookie), in modo che ogni download sia autorizzato e verificabile individualmente.
- Collegare AWS WAF alla distribuzione CloudFront utilizzando le AWS Managed Rules, abilitare AWS WAF Bot Control (protezione avanzata dalle minacce) e creare regole basate sulla frequenza (rate-based) più challenge CAPTCHA per mitigare lo scraping e il credential stuffing.
- Effettuare il provisioning dei certificati TLS in ACM (in us-east-1 per le distribuzioni CloudFront) utilizzando la validazione DNS tramite Route 53, e pubblicare record Alias di Route 53 che puntano alla distribuzione CloudFront.
- Abilitare DNSSEC sulla hosted zone di Route 53, abilitare i log di accesso di CloudFront e WAF su S3, e creare allarmi CloudWatch e, opzionalmente, AWS Shield Advanced per la visibilità e gli allarmi DDoS.
Motivazione: Forzare tutto il traffico attraverso CloudFront con OAC e WAF impone l’accesso all’origine secondo il principio del privilegio minimo (least-privilege); la Geo Restriction e le protezioni basate sulla frequenza/WAF bloccano il traffico abusivo; gli URL firmati forniscono un’autorizzazione per singolo oggetto; e la validazione ACM+DNS con DNSSEC garantisce l’integrità del TLS e del DNS secondo le best practice di AWS.
Regole AWS WAF e Integrazione con ALB e CloudFront
AWS WAF è un firewall di Livello 7 che valuta le richieste HTTP(S) rispetto a una Web ACL composta da regole ordinate. Ogni regola ispeziona gli attributi della richiesta (URI, intestazioni, corpo, stringa di query, IP di origine) e restituisce un’azione terminale (Allow, Block, Challenge, CAPTCHA) o un’azione non terminale (Count). Le Web ACL si collegano a distribuzioni CloudFront, Application Load Balancer, API Gateway, AppSync, user pool di Cognito e servizi App Runner. Quando collegata a CloudFront, la ACL viene eseguita sull’edge e deve essere creata nello scope us-east-1 (Globale); per l’ALB, deve trovarsi nella stessa Regione del load balancer.
Le regole basate sulla frequenza (rate-based) tracciano il numero di richieste provenienti da un singolo IP (o da un’intestazione IP inoltrata, o da una chiave aggregata come una combinazione URI + IP) in una finestra mobile di cinque minuti. Quando il conteggio supera la soglia configurata, l’azione della regola si attiva finché la frequenza non scende di nuovo al di sotto del limite. Poiché AWS WAF aggiorna continuamente l’elenco degli IP malevoli in pochi secondi, le regole basate sulla frequenza sono la risposta canonica per abusi ad alto volume provenienti da un piccolo insieme di IP a rotazione — non è necessario curare manualmente un set di IP e l’overhead operativo è essenzialmente nullo dopo l’implementazione della regola iniziale.
{
"Name": "RateLimitPerIP",
"Priority": 10,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitPerIP"
}
}
Gli IP set sono elenchi riutilizzabili di intervalli CIDR a cui le regole fanno riferimento con un IPSetReferenceStatement. Sono il componente di base (primitiva) giusto quando si dispone di una lista deterministica di IP da bloccare/consentire — ad esempio, endpoint di amministrazione con restrizioni geografiche o intervalli di IP noti come malevoli provenienti da feed di threat intelligence. Le regole personalizzate combinano più istruzioni (statement) con operatori logici AndStatement, OrStatement e NotStatement, consentendo di esprimere condizioni come “blocca le richieste a /login provenienti da paesi diversi dagli Stati Uniti che non hanno anche una specifica intestazione.”
CloudFront come livello di mitigazione DDoS e protezione dell’origine
CloudFront assorbe gli attacchi volumetrici e di esaurimento dello stato (state-exhaustion) sull’edge di AWS, ben prima che il traffico raggiunga il tuo ALB o la tua flotta EC2. Ogni edge location esegue AWS Shield Standard automaticamente, fornendo mitigazione da attacchi SYN flood e di riflessione (reflection attack) senza costi aggiuntivi. Mettere CloudFront di fronte a un ALB riduce la superficie di attacco alla rete edge e abilita WAF a livello di edge, restrizioni geografiche (geo-restriction) e terminazione TLS.
La mitigazione è efficace solo se gli aggressori non possono bypassare CloudFront colpendo direttamente il nome DNS dell’ALB. Due meccanismi rafforzano questo percorso. Primo, configurare CloudFront per iniettare un header di origine personalizzato segreto (ad esempio X-Origin-Verify: <valore-casuale>) e configurare una regola nel listener dell’ALB che restituisca 403 per qualsiasi richiesta priva di quel preciso valore nell’header. Ruotare il segreto periodicamente tramite AWS Secrets Manager. Secondo, limitare il security group dell’ALB alla lista di prefissi gestita da AWS com.amazonaws.global.cloudfront.origin-facing, che contiene gli intervalli IP dell’edge di CloudFront.
ALBListenerRule:
Type: AWS::ElasticLoadBalancingV2::ListenerRule
Properties:
Actions:
- Type: fixed-response
FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
Conditions:
- Field: http-header
HttpHeaderConfig:
HttpHeaderName: X-Origin-Verify
Values: ["!Ref OriginSecret"]
- Field: http-header
HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
Priority: 1
Collegare semplicemente una WAF ACL all’ALB senza forzare il traffico attraverso CloudFront lascia l’endpoint dell’ALB risolvibile pubblicamente. Gli aggressori che scoprono il nome DNS (tramite i log di trasparenza dei certificati, DNS storici o enumerazione di sottodomini) possono attaccarlo direttamente, bypassando tutte le protezioni a livello di edge. Questo è l’errore architetturale più comune nelle progettazioni “CloudFront + ALB”.
Metriche, allarmi e notifiche di Shield Advanced
Shield Advanced aggiunge rilevamento avanzato, accesso 24/7 allo Shield Response Team, protezione dei costi per il dimensionamento durante gli attacchi e visibilità degli attacchi a livello di applicazione. Tuttavia, non invia automaticamente e-mail o SMS quando si verifica un attacco. Le notifiche devono essere configurate esplicitamente tramite CloudWatch.
Shield Advanced pubblica la metrica DDoSDetected (valore 1 mentre un attacco è in corso) e le metriche DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond e DDoSAttackRequestsPerSecond per ogni risorsa protetta nel namespace AWS/DDoSProtection. Creare un allarme CloudWatch su DDoSDetected >= 1 con un topic SNS come azione dell’allarme; SNS si occupa poi di inoltrare la notifica a e-mail, SMS, chat o a un responder Lambda.
aws cloudwatch put-metric-alarm \
--alarm-name ShieldDDoSDetected \
--namespace AWS/DDoSProtection \
--metric-name DDoSDetected \
--statistic Maximum --period 60 --threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts
Presumere che Shield Advanced “ti invierà semplicemente un’e-mail” è un malinteso frequente: senza l’allarme CloudWatch e la sottoscrizione SNS, l’unico segnale è la console di Shield e l’evento nell’AWS Health Dashboard.
AWS Network Firewall con blocco automatizzato tramite Lambda
Network Firewall è un firewall stateful, collegato a un VPC, che opera a livello 3-7 e ispeziona il traffico che attraversa le tabelle di routing delle subnet. La sua policy è composta da gruppi di regole stateless e stateful; i gruppi di regole stateful utilizzano una sintassi compatibile con Suricata. Poiché i gruppi di regole sono gestiti tramite API, sono bersagli ideali per l’automazione guidata dagli eventi (event-driven).
Un pattern comune risponde ai risultati (finding) di GuardDuty (ad esempio UnauthorizedAccess:EC2/RDPBruteForce o Backdoor:EC2/C&CActivity). Security Hub aggrega il finding, EventBridge individua una corrispondenza con un pattern di evento e invoca una funzione Lambda, e la Lambda chiama UpdateRuleGroup per inserire una regola di drop che ha come bersaglio l’IP dell’aggressore o l’ENI dell’istanza compromessa.
def handler(event, _):
ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
nfw.update_rule_group(
RuleGroupArn=RG_ARN,
UpdateToken=rg["UpdateToken"],
RulesSource={"RulesString": rules})
Network Firewall è la scelta corretta quando è necessario bloccare il traffico bidirezionale da/verso un’istanza EC2 o un CIDR a livello di edge del VPC: WAF ispeziona solo le richieste HTTP destinate a endpoint di livello 7 supportati, quindi non può fermare il traffico C2 in uscita o protocolli non-HTTP.
Registrazione, monitoraggio e rollout sicuro con Count
Abilita la registrazione di WAF su ogni Web ACL e invia il flusso a CloudWatch Logs, S3 o Kinesis Data Firehose. I log includono la regola che ha prodotto la corrispondenza, l’azione, gli header della richiesta e (con le regole di redazione) i body sanificati. Le richieste campionate nella console offrono una vista rapida ma conservano solo le ultime 3 ore e 100 campioni per regola; i log completi sono necessari per audit e analisi forense.
L’azione Count è essenziale per un rollout sicuro delle regole. Effettua il deploy di nuovi gruppi di regole gestite (ad esempio AWSManagedRulesCommonRuleSet o il gruppo Bot Control) impostando inizialmente l’override dell’azione della regola su Count. Monitora la metrica CloudWatch CountedRequests e le voci di log per individuare i falsi positivi, ovvero il traffico legittimo che sarebbe stato bloccato. Solo dopo aver perfezionato le esclusioni si passa a impostare le azioni su Block. Il deploy di regole gestite direttamente in modalità Block, senza una fase di Count, causa regolarmente interruzioni di servizio quando una regola come SizeRestrictions_BODY blocca un endpoint legittimo per upload di grandi dimensioni, o quando CrossSiteScripting_BODY si attiva su un payload di un editor rich-text. La soluzione non è disabilitare l’intero gruppo, ma aggiungere una dichiarazione di scope-down o un override dell’azione per la regola specifica che genera l’errore.
Associa le metriche di WAF (BlockedRequests, AllowedRequests, CountedRequests) agli allarmi di CloudWatch in modo che un picco improvviso di blocchi — o un crollo improvviso del traffico consentito — allerti l’ingegnere di turno, chiudendo il cerchio tra la protezione perimetrale (edge) e la consapevolezza operativa.
Problema pratico: scenario d’uso
Scenario: Meridian Financial gestisce un’applicazione web rivolta ai clienti in un VPC multi-AZ utilizzando Application Load Balancer (ALB) davanti a servizi ECS e distribuisce contenuti statici e dinamici tramite CloudFront. Il team utilizza AWS WAF ma ha avuto un’automazione limitata per le minacce a livello di rete e una registrazione incoerente tra i vari servizi.
Sfida: Un recente picco di traffico volumetrico e a livello di applicazione ha preso di mira gli endpoint di login, causando l’esaurimento della CPU dell’ALB durante la ricerca di vulnerabilità per il credential stuffing; il team di sicurezza necessita di una mitigazione DDoS rapida, di una protezione coerente dell’origine, del blocco automatico di IP malevoli e di rollout sicuri per regole più restrittive.
Approccio consigliato:
- Abilitare CloudFront davanti all’ALB per la mitigazione perimetrale (edge) globale, configurare l’ALB per accettare traffico solo da CloudFront convalidando un header di origine personalizzato e limitando l’accesso in entrata con una prefix list gestita da CloudFront o con intervalli IP noti.
- Effettuare il deploy di AWS WAFv2 con i set di regole gestite da AWS più regole personalizzate basate sulla frequenza (rate-based) e di rilevamento bot; associare il WAF sia alla distribuzione CloudFront che all’ALB. Impostare inizialmente le nuove regole personalizzate in modalità COUNT per raccogliere dati di telemetria.
- Registrare l’account in AWS Shield Advanced e associare la distribuzione CloudFront e l’ALB; creare allarmi sulle metriche di CloudWatch utilizzando le metriche di Shield/DDoS e inoltrare gli allarmi a un topic SNS per le notifiche al personale di turno e per l’attivazione di runbook.
- Centralizzare i log: inviare in streaming i log di CloudFront, ALB, WAF e AWS Network Firewall a Kinesis Data Firehose → S3 e abilitare le metriche/dashboard di CloudWatch per monitorare il numero di corrispondenze delle regole dalla modalità COUNT.
- Effettuare il deploy di AWS Network Firewall nel VPC con gruppi di regole stateful e abilitarne la registrazione; creare filtri per le metriche di CloudWatch per i pattern sospetti e una funzione Lambda che venga attivata dagli allarmi per aggiornare automaticamente il gruppo di regole di Network Firewall aggiungendo gli IP malevoli a una deny list.
- Dopo aver osservato il traffico in modalità COUNT e le dashboard per una finestra di osservazione concordata, passare le regole WAF ad alta affidabilità in modalità BLOCK e mantenere gli aggiornamenti automatici di Network Firewall con rollback sicuri e versionamento dei gruppi di regole.
Motivazione: L’utilizzo di CloudFront come livello perimetrale (edge) con WAF e Shield Advanced fornisce una protezione DDoS stratificata, mentre la registrazione centralizzata, la convalida delle regole in modalità COUNT e gli aggiornamenti automatici di Network Firewall guidati da Lambda offrono una difesa di rete sicura, osservabile e automatizzata, in linea con le best practice di AWS.
← Networking e sicurezza VPC · Tutti i domini · Governance →
Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Supera l'esame →