Edge Security Cloudfront Waf Shield

Why Edge Security Matters for SCS-C02

Edge security is the discipline of pushing protective controls as far away from your origin as possible — to the AWS global edge network, where requests first arrive. For the SCS-C02 exam, edge security is one of the highest-yield areas in Domain 3 (Infrastructure Security, 20%), and edge security questions routinely appear across other domains as well, because every public workload that runs on AWS must answer an edge security question first: who is allowed to talk to my application, from where, at what rate, and through which protocol?

In this guide we go deep on edge security from an SCS-C02 perspective. We cover Amazon CloudFront as the front door, AWS WAF as the inspection layer, AWS Shield Standard and Shield Advanced as the DDoS layer, Route 53 as the resolution layer, and Elastic Load Balancing (ALB and NLB) as the regional fan-out layer. We map every control to OWASP Top 10 categories, distributed denial of service (DDoS) attack vectors, geographical restrictions, rate limiting, signed URLs and signed cookies, managed rule groups, Bot Control, and CAPTCHA. Finally we discuss edge logging and monitoring.

This is not a marketing tour. It is a deeply opinionated walk through edge security with the trade-offs that the exam tests. By the end you will be able to design layered edge security for a public website, a serverless app, and a mobile app backend, and you will know exactly when Shield Advanced is worth $3,000 a month and when it is not.

Layered Web Application Architecture (Defense in Depth)

The reference architecture for almost every SCS-C02 edge security question looks like this:

Client
  │
  ▼
Route 53 (DNS, DNSSEC, geo-routing)
  │
  ▼
CloudFront (TLS, edge caching, OAC, signed URLs)
  │
  ▼
AWS WAF (Web ACL, managed rules, rate-based, Bot Control)
  │
  ▼
AWS Shield Standard / Advanced (L3/L4/L7 DDoS)
  │
  ▼
ALB / NLB / API Gateway (regional load balancing, edge association)
  │
  ▼
Auto Scaling Group / Lambda / ECS (compute)
  │
  ▼
RDS / DynamoDB / S3 (data tier)

Each layer enforces a different control. Edge security is not a single product — it is a stack. The exam loves to test whether you understand which control belongs at which layer. For example, geo-restriction can be enforced at CloudFront geo-restriction or at AWS WAF geo-match rules; the choice depends on whether you want a polite 403 page (CloudFront) or whether you want to combine geography with other request attributes such as URI path or header (WAF). Edge security at scale is about choosing the right layer for the right control.

Why defense in depth at the edge

A single layer can fail. Edge security assumes that:

• DNS can be poisoned, so we use DNSSEC at Route 53.
• TLS can be downgraded, so we enforce TLSv1.2 and above at CloudFront and at ELB.
• WAF rules can have blind spots, so we layer Shield for volumetric DDoS.
• Shield cannot stop application-layer abuse, so we add Bot Control and rate-based rules in WAF.
• WAF cannot fix vulnerable code, so we still patch and harden the origin.

Each layer is independent. If WAF misses a signature, Shield still absorbs the volumetric attack. If Shield mitigates the volume, CloudFront absorbs the residual at the edge cache. This is edge security in the AWS sense.

Amazon CloudFront as the Front Door

CloudFront is the AWS content delivery network (CDN) and is the canonical edge security entry point. From an SCS-C02 perspective, CloudFront does five jobs at once: TLS termination, caching, request inspection hand-off to AWS WAF, DDoS absorption with AWS Shield, and origin authentication via Origin Access Control (OAC).

TLS termination and modern protocols

CloudFront supports TLSv1.2 and TLSv1.3 via security policies. The exam expects you to know that the TLSv1.2_2021 and newer security policies are the only acceptable choices for compliance workloads (HIPAA, PCI DSS, FedRAMP). Custom SSL certificates must come from AWS Certificate Manager (ACM) in us-east-1 for use with CloudFront — that detail is a recurring exam trick.

Origin Access Control (OAC) replaces Origin Access Identity (OAI)

For S3 origins, the modern best practice is OAC, which uses SigV4 to authenticate CloudFront to S3. OAC supports KMS-encrypted buckets and cross-Region buckets, while the legacy OAI cannot sign requests with SigV4 and cannot read KMS-encrypted objects with aws:kms keys for some operations. New designs should always use OAC. Migration from OAI to OAC is documented and is a frequent question scenario.

Signed URLs and signed cookies

CloudFront signed URLs and signed cookies allow you to authorize individual viewers without IAM. Signed URLs are used for one-off downloads (an installer, a private video, a PDF report). Signed cookies are used when many objects must be authorized for a session, such as adaptive bitrate video streaming. Both rely on a private key that signs a policy describing the resource, expiry time, optional IP address restriction, and optional date-time window.

For SCS-C02, remember that signed URLs and signed cookies are independent of WAF; they enforce viewer authorization at the CloudFront layer. They are also the canonical edge security answer for "I want to share a private S3 object with an external user without IAM credentials."

Field-Level Encryption

Field-level encryption (FLE) encrypts up to 10 sensitive fields in application/x-www-form-urlencoded POST bodies at the CloudFront edge using a public RSA key. Only services that hold the private key can decrypt those fields. FLE is rarely the right answer for general TLS, but it is the right edge security answer when the question says "we cannot trust intermediate microservices to see the credit card number."

CloudFront geo-restriction

CloudFront geo-restriction (also known as the geo-blocking feature) is a distribution-level allow list or deny list of country codes (ISO 3166-1 alpha-2). It returns a 403 page to blocked viewers. It is simple, free, and enforced at the edge.

AWS WAF: Web ACL, Rules, and Managed Rule Groups

AWS WAF is the request inspection layer for edge security. It protects CloudFront distributions, Application Load Balancers, API Gateway REST APIs, AppSync GraphQL APIs, Cognito user pools, App Runner services, and Verified Access instances. The unit of policy is the Web Access Control List (Web ACL), which contains an ordered list of rules and a default action.

Web ACL scope: CLOUDFRONT vs REGIONAL

A Web ACL has a scope. The CLOUDFRONT scope is global and is created in us-east-1 regardless of where you operate; it can only be associated with CloudFront distributions. The REGIONAL scope is per-Region and can only be associated with regional resources (ALB, API Gateway, AppSync, Cognito, App Runner). You cannot share a single Web ACL between a CloudFront distribution and a regional ALB; you would deploy two Web ACLs and use AWS Firewall Manager to keep them in sync.

Rule statements and actions

Each AWS WAF rule has a statement (the match condition) and an action. Statements include byte-match, SQL injection, cross-site scripting (XSS), size constraint, geo-match, IP set, regex pattern set, label match, and rate-based. Actions include Allow, Block, Count, CAPTCHA, and Challenge. CAPTCHA presents a visual puzzle to the viewer; Challenge is a silent JavaScript proof-of-work that detects headless browsers and bots without user friction.

AWS Managed Rules

AWS Managed Rules are curated rule groups maintained by the AWS Threat Research Team. The most exam-relevant managed rule groups for edge security are:

• AWSManagedRulesCommonRuleSet (CRS) — covers OWASP Top 10 generic categories, including SQL injection (SQLi_BODY, SQLi_QUERYARG) and XSS.
• AWSManagedRulesSQLiRuleSet — deeper SQL injection coverage.
• AWSManagedRulesKnownBadInputsRuleSet — well-known exploits like Log4Shell and remote code execution payloads.
• AWSManagedRulesAmazonIpReputationList — IP reputation list of known bots and threat actors.
• AWSManagedRulesAnonymousIpList — VPN, proxy, Tor exit nodes, hosting providers.
• AWSManagedRulesBotControlRuleSet — Bot Control common feature.
• AWSManagedRulesATPRuleSet — Account Takeover Prevention (login endpoint protection).
• AWSManagedRulesACFPRuleSet — Account Creation Fraud Prevention (sign-up form protection).

Bot Control, ATP, and ACFP are paid rule groups (per-request fees apply); the others are free. All managed rule groups support overrides at the rule level (action override, scope-down statements) without forking.

Rate-based rules: 5-minute window and aggregate keys

Rate-based rules count requests over a rolling 5-minute window per aggregate key. The default key is the source IP address, but you can also aggregate by forwarded IP (when CloudFront is in front), by header value (x-api-key), by query argument, or by a composite key combining several attributes. Rate-based rules are the canonical edge security answer for credential stuffing, scraping, and basic DDoS at L7.

A rate-based rule with a limit of 2,000 means: if a single aggregate key exceeds 2,000 requests in the last 5 minutes, the rule triggers (Block, CAPTCHA, Challenge, or Count). It does not fire at exactly request 2,001 — it fires after 30 seconds to one minute of evaluation lag, which the exam may use as a distractor.

Scope-down statements

A scope-down statement narrows where a rate-based rule (or a managed rule group) applies. For example, you may want a rate-based rule only on /login and not on /static/*. The scope-down statement is a regular AWS WAF statement (URI, header, method) that pre-filters traffic before the rate is computed.

Label-driven rules

Bot Control, ATP, and several CRS rules emit labels (e.g. awswaf:managed:aws:bot-control:bot:category:scraping_framework). Subsequent rules in the Web ACL can match on those labels and take different actions. Label-driven rules let you build a single decision pipeline: "if Bot Control says verified-search-engine, allow; if Bot Control says automated-tool and rate exceeds 200, block; otherwise count". Labels are an SCS-C02 favorite.

CAPTCHA and Challenge actions

CAPTCHA presents a puzzle to the viewer when triggered. Successful solutions are stored in a CAPTCHA token cookie that is valid for the configured immunity time (default 300 seconds). Challenge is silent: it injects JavaScript that performs a proof-of-work and stores a Challenge token. CAPTCHA is the right edge security answer when human interaction is acceptable; Challenge is the right answer for APIs and back-end calls where human friction is not.

AWS Shield: Standard vs Advanced

AWS Shield is the DDoS protection service. There are two tiers, and the exam tests them constantly.

Shield Standard

Shield Standard is automatic, free, and on by default for every AWS account. It protects against common L3 and L4 DDoS such as SYN floods, UDP reflection, and amplification attacks. It is integrated into Route 53, CloudFront, and ELB; you cannot turn it off and you cannot configure it. Shield Standard is the baseline edge security DDoS layer.

Shield Advanced

Shield Advanced is a paid subscription at $3,000 per month per organization (with a 1-year commitment) that adds:

• Protection at L3, L4, and L7 (the latter via tight integration with AWS WAF).
• Application-layer DDoS detection backed by health-check-based detection.
• Access to the AWS Shield Response Team (SRT), formerly DRT, who can write or modify Web ACL rules during an attack on your behalf (with your approval).
• Cost protection: refund of scaling costs (CloudFront data transfer, ALB capacity units, Route 53 queries, EC2 charges) attributable to a DDoS event.
• Global threat dashboard and detailed attack diagnostics.
• Automatic application-layer DDoS mitigation: when enabled, Shield Advanced can automatically create rate-based rules in your Web ACL during an event.
• Coverage for Elastic IPs on EC2/NLB, AWS Global Accelerator, CloudFront, Route 53 hosted zones, and ALB.

When Shield Advanced is the right answer

The exam will give you scenarios. Shield Advanced is the right edge security answer when at least two of the following are true: the workload is public-facing and revenue-critical; the customer wants 24x7 SRT engagement; the customer requires cost protection against scaling-out under attack; the customer needs centralized visibility across an AWS Organization. If only one of those is true, Shield Standard plus AWS WAF rate-based rules is usually enough.

Route 53 Security Features

Route 53 is the DNS layer of edge security on AWS. From an SCS-C02 perspective, the relevant Route 53 controls are DNSSEC for hosted zones, health-check-driven failover, and geolocation routing.

DNSSEC for hosted zones

Route 53 supports DNSSEC signing for public hosted zones. Enabling DNSSEC creates a Key-Signing Key (KSK) in AWS KMS and publishes a Delegation Signer (DS) record at the parent zone. This protects against DNS spoofing and cache poisoning. For domains registered with Route 53 Domains, the DS record is published automatically at the registry; for externally registered domains, you must publish the DS record manually at your registrar.

Health checks and failover

Route 53 health checks evaluate endpoint reachability over HTTP, HTTPS, or TCP and can also evaluate the state of a CloudWatch alarm. Combined with failover routing policies, Route 53 can automatically remove unhealthy endpoints from DNS responses. From an edge security standpoint this is important because health-check failure during a DDoS event can be used to trigger Shield Advanced application-layer detection.

Geolocation routing

Geolocation routing answers different IP addresses based on the viewer's country (from the EDNS Client Subnet extension). It is the right edge security answer when you must keep a national audience inside a specific Region for data-sovereignty reasons. It is not a security control on its own; it must be combined with WAF geo-match rules to actually block traffic.

Edge Load Balancing: ALB, NLB, and API Gateway

Edge security continues at the regional load balancer. Three patterns dominate:

• ALB (Application Load Balancer) at L7: supports AWS WAF associations, listener rules, mutual TLS (mTLS) for HTTPS, and target group health checks.
• NLB (Network Load Balancer) at L4: cannot be associated with WAF directly. Use CloudFront in front of NLB or move WAF to API Gateway.
• API Gateway: REST APIs support WAF and signed requests; HTTP APIs use Lambda authorizers and JWT validation.

ALB has supported mTLS since 2023, which is the right edge security answer for IoT devices, B2B partners, or fleet management where the client must authenticate to the load balancer with an X.509 certificate. For SCS-C02, mTLS at ALB is sometimes the correct alternative to API Gateway client certificates.

Geo-Restriction: Where to Apply It

Geo-restriction can be enforced at three places. Each has trade-offs:

• CloudFront distribution-level geo-restriction (allow list or deny list of country codes) — simplest, free, returns 403, applies to entire distribution.
• AWS WAF geo-match rule — flexible, can combine with path/method/header, supports multiple actions (Allow, Block, Count, CAPTCHA), can be scoped down.
• Route 53 geolocation routing — does not block traffic, only resolves to different IPs; not a security control.

For SCS-C02 the rule of thumb is: if the requirement is "block all traffic from country X," CloudFront geo-restriction is enough. If the requirement is "allow country X to access /api/public/* but force CAPTCHA on /api/login," you must use WAF.

Rate Limiting: Shapes and Patterns

Rate limiting is the most common edge security control after TLS. AWS WAF rate-based rules support several shapes:

• Per-source-IP — the default; one limit per IP. Catches single-IP abuse.
• Per-forwarded-IP — when CloudFront is in front, evaluates X-Forwarded-For. Required when WAF is on ALB behind CloudFront.
• Per-aggregate-key — composite of headers, query args, IP, country, and label. Use for API key rate limits.
• Per-header (e.g. Authorization) — useful for token rate limits.
• Custom keys with RateBasedStatementCustomKey — multi-dimensional aggregation.

Pair rate-based rules with scope-down statements so that the limit only applies where you want. A common edge security pattern is: 100 req/5min on /login per source IP with CAPTCHA action; 5,000 req/5min on /api/* per Authorization header with Block action; no limit on /static/*.

OWASP Top 10 Mapping at the Edge

OWASP Top 10 (2021 edition) is the single most cited threat model in SCS-C02 edge security questions. The mapping to AWS edge controls:

• A01 Broken Access Control — partial: signed URLs/cookies for object access; ALB authentication for ALB-fronted apps; Verified Access for fine-grained.
• A02 Cryptographic Failures — TLS policy at CloudFront and ALB; ACM certificate management; FLE for sensitive fields.
• A03 Injection — CRS and SQLi managed rule groups; custom regex pattern sets.
• A04 Insecure Design — out of edge scope; address at code review.
• A05 Security Misconfiguration — Known Bad Inputs rule group; AWS Config rules at edge resources.
• A06 Vulnerable Components — Known Bad Inputs (Log4Shell, Spring4Shell); Inspector at compute layer.
• A07 Identification and Authentication Failures — ATP rule group; rate-based rules on /login; Cognito MFA.
• A08 Software and Data Integrity Failures — code signing; CloudFront signed URLs.
• A09 Security Logging and Monitoring Failures — WAF logs to S3/Firehose/CloudWatch; CloudFront access logs; Shield Advanced metrics.
• A10 Server-Side Request Forgery (SSRF) — origin-side IMDSv2; not directly an edge control.

For SCS-C02, A03 and A07 are the highest-leverage edge controls because they are entirely solvable with AWS WAF. The exam will rarely ask about A04 because it is a code issue.

DDoS Layered Defense in Practice

A real-world DDoS playbook combines all the layers:

• L3/L4 volumetric (UDP flood, SYN flood) — Shield Standard absorbs at the edge automatically. CloudFront, Global Accelerator, and Route 53 are anycast networks with massive aggregate capacity.
• L7 HTTP flood (GET flood) — CloudFront caches absorb cacheable traffic; AWS WAF rate-based rules block uncacheable hot keys; Bot Control labels organized bot fleets.
• L7 sophisticated (low-and-slow, slowloris) — Shield Advanced application-layer mitigation, plus ALB connection idle-timeout tuning.
• Reflection and amplification — Shield Standard at the edge blocks at the network border.

Edge Logging and Monitoring

You cannot defend what you cannot see. Edge logging is a Domain 2 and Domain 3 overlap on the SCS-C02 exam.

CloudFront access logs

CloudFront writes per-request access logs to an S3 bucket (standard logs, near real-time within minutes) or to CloudWatch Logs and Kinesis Data Streams (real-time logs, sub-second latency). Standard logs are free; real-time logs incur a per-log-line charge but allow streaming SIEM integration. For SCS-C02, real-time logs are the right edge security answer when the requirement is "alert within 60 seconds of an attack."

AWS WAF logs

AWS WAF can log to three destinations: an S3 bucket (via Kinesis Data Firehose), Amazon CloudWatch Logs, or Kinesis Data Firehose to a custom destination. Each log line includes the matched rule, action, labels, and the (truncated) request. Sampled requests in the console are different from full logs — sampled requests are a sample for diagnostic purposes only. The exam will ask which destination supports which feature; remember that S3 via Firehose is the most economical for compliance retention.

Shield Advanced metrics and logs

Shield Advanced surfaces application-layer DDoS metrics in CloudWatch and emits events on EventBridge when an attack is detected or mitigated. The Global Threat Dashboard shows attack patterns across the AWS network. Engagement with the Shield Response Team is via the AWS Support Center; the SRT can review your Web ACL during an event.

Firewall Manager for centralization

AWS Firewall Manager applies WAF Web ACLs, Shield Advanced protections, security group baselines, Network Firewall policies, and DNS Firewall rules across an AWS Organization. For SCS-C02, Firewall Manager is the right edge security answer when the requirement is "enforce WAF rate-based rules across 200 ALBs in 12 accounts." Firewall Manager requires AWS Organizations and an AWS Config-enabled member account.

Designing Edge Security for Three Common Workloads

The SCS-C02 exam guide explicitly mentions three workloads. Here is how the edge security stack changes for each.

Public website (marketing or e-commerce)

• CloudFront distribution with TLSv1.2_2021 security policy and ACM certificate in us-east-1.
• AWS WAF Web ACL with CRS, IP Reputation, Anonymous IP, Known Bad Inputs.
• Rate-based rule on /checkout/* aggregated by Authorization header.
• Bot Control common feature for scraping protection.
• Shield Standard included by default; Shield Advanced if the site is revenue-critical.
• Route 53 with DNSSEC for the apex domain.
• CloudFront access logs to S3 with 1-year lifecycle retention.

Serverless app (API Gateway + Lambda)

• API Gateway REST API (or HTTP API for cost) with custom domain and ACM certificate.
• AWS WAF Web ACL on the API Gateway stage; managed rules CRS + Known Bad Inputs.
• Rate-based rules per x-api-key header; throttle quotas at API Gateway usage plans.
• Lambda authorizer for token validation; Cognito user pool authorizer for user-level authn.
• Shield Standard on API Gateway (free); Shield Advanced if the API is critical.
• WAF logs to Kinesis Firehose to S3.

Mobile app backend

• CloudFront in front of ALB or API Gateway for global TLS termination and DDoS sponge.
• AWS WAF with ATP rule group on /login and ACFP rule group on /signup.
• Mutual TLS at ALB for device-bound certificates (high-assurance), or App Attest / Play Integrity validation at Lambda authorizer.
• Bot Control targeted feature for client-side challenge.
• Cognito user pools with MFA for end-user identity.
• Real-time WAF and CloudFront logs to a SIEM via Kinesis.

Common Exam Traps and Anti-Patterns

Other common anti-patterns to avoid:

• Putting an ACM certificate in eu-west-1 for use with CloudFront (must be us-east-1).
• Forgetting that Web ACL scope must match the resource type (CLOUDFRONT vs REGIONAL).
• Expecting Shield Standard to mitigate L7 DDoS — it does not.
• Relying on CloudFront geo-restriction when path-based exceptions are required.
• Using OAI for new S3 origins instead of OAC.
• Configuring rate-based rules without a scope-down on a static-asset path, which floods the rule with cache hits.

FAQ

Q1: When should I choose Shield Advanced over Shield Standard for edge security?

Shield Advanced is justified when at least two of the following are true: the workload is revenue-critical, the customer requires 24x7 SRT engagement, the customer needs cost protection against scaling charges incurred during a DDoS, or the customer must centralize protections across an AWS Organization with Firewall Manager. The $3,000-per-month list price plus required Business or Enterprise Support means Shield Advanced rarely makes sense for non-revenue or internal workloads.

Q2: Where should I enforce geo-restriction — CloudFront or AWS WAF?

Use CloudFront distribution-level geo-restriction when the requirement is a blanket country block on the entire distribution. Use AWS WAF geo-match rules when the requirement combines geography with path, method, or header, or when you need different actions per country (Allow, Block, CAPTCHA, Challenge, Count). WAF geo-match also gives you a count-only mode so you can observe the impact before enforcement.

Q3: Can AWS WAF stop OWASP A01 Broken Access Control?

Only partially. WAF can enforce signed URL or signed cookie rules at the CloudFront edge, and it can rate-limit unauthenticated paths to slow enumeration attacks. True access control is a code-level concern that belongs at the application authorizer (Lambda authorizer, Cognito, IAM authorizer, or Verified Permissions). For SCS-C02, the correct answer to "stop broken access control" rarely points at WAF alone.

Q4: What is the difference between CAPTCHA and Challenge actions in AWS WAF?

CAPTCHA presents a visible puzzle to the viewer that they must solve; success creates a CAPTCHA token cookie valid for the configured immunity time. Challenge is a silent JavaScript proof-of-work that runs in the viewer's browser; success creates a Challenge token. Use CAPTCHA when human friction is acceptable (login, sign-up). Use Challenge for API endpoints and back-end calls where invisible verification is preferred. Both add per-request charges.

Q5: How does Shield Advanced cost protection actually work?

When AWS Shield detects a DDoS event against a protected resource and that event causes scaling-related cost increases (CloudFront data-out, Route 53 queries, ALB capacity units, EC2 hours), you can submit a credit request via AWS Support. AWS reviews the attack signature in their detection systems and issues service credits for the incremental cost attributable to the attack. Cost protection requires Business or Enterprise Support and an active Shield Advanced subscription on the resource at the time of the event.

Q6: Is AWS WAF logging the same as CloudFront access logging?

No. AWS WAF logs record per-request inspection results, including the matched rule, action, and labels — they answer "did WAF block this and why?" CloudFront access logs record every viewer request to the distribution — they answer "what did the edge serve?" For complete edge-security visibility, you need both. WAF logs go to S3 (via Firehose), CloudWatch Logs, or a custom Firehose destination. CloudFront standard logs go to S3 directly; real-time logs go to Kinesis Data Streams.

Q7: Can I share one Web ACL between a CloudFront distribution and an ALB?

No. Web ACL scope is binary: a CLOUDFRONT-scoped Web ACL only attaches to CloudFront distributions; a REGIONAL-scoped Web ACL only attaches to regional resources (ALB, API Gateway, AppSync, Cognito, App Runner, Verified Access). To enforce identical edge security policies on both, build two Web ACLs and use AWS Firewall Manager to keep them aligned across an AWS Organization.

Summary: Edge Security Answer Patterns

When you read an SCS-C02 edge security question, run through this checklist:

• Is there public traffic? → CloudFront in front, full stop.
• Is there L7 inspection needed (SQLi, XSS, OWASP)? → AWS WAF with managed rules.
• Is the workload revenue-critical with 24x7 SLO? → Shield Advanced.
• Is geo-restriction required? → CloudFront for blanket; WAF for nuanced.
• Is rate limiting required? → WAF rate-based rules with scope-down.
• Is bot abuse a concern? → Bot Control + ATP/ACFP for high-value forms.
• Is centralization across accounts required? → Firewall Manager.
• Is real-time alerting required? → CloudFront real-time logs + WAF logs to CloudWatch.

Edge security on AWS is not magic. It is a disciplined stack of controls — DNS, TLS, request inspection, DDoS absorption, rate limiting, bot defense, and centralized visibility — that you compose for each workload. Master the layers and the trade-offs between them, and the SCS-C02 edge security questions become predictable. Good luck.