SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
SCS-C03 · Domain 5

Data Protection practice questions

Data Protection is worth 18% of the SCS-C03 exam — the 2nd-heaviest of the 6 domains. Encryption in transit and at rest, plus protecting confidential data, credentials, secrets, and cryptographic key materials. 6 fully worked examples are further down this page, answers included.

Exam weight
18%
the 2nd-heaviest of the 6 domains
Questions
112
across 3 topics
Free, no account
5/day
sign up free to remove the cap
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 6 domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Data Protection questions, fully explained

Questions from the SCS-C03 bank mapped to domain 5, with the answer key and the reasoning behind every option. None of them repeat the examples on the main SCS-C03 practice page.

Question 1Data Protection

A security team must ensure that an internet-facing Application Load Balancer negotiates only TLS 1.2 or TLS 1.3 with clients. Customers who still open the site from old http:// bookmarks must arrive at the HTTPS version of the page instead of receiving an error. Which listener configuration meets both requirements?

Choose one.

  • a
    HTTPS:443 with ELBSecurityPolicy-TLS13-1-2-2021-06, and an HTTP:80 listener whose default action redirects to HTTPS:443 Correct

    The predefined policy ELBSecurityPolicy-TLS13-1-2-2021-06 allows TLS 1.3 and TLS 1.2 only. A redirect action on the HTTP:80 listener returns an HTTP 301 to the HTTPS URL, so bookmark users reach the secure site instead of an error.

  • b
    HTTPS:443 with ELBSecurityPolicy-TLS13-1-2-2021-06, and the HTTP:80 listener deleted so that plaintext requests are refused

    The TLS minimum is right, but with no listener on port 80 an http:// request is refused at the connection level. Users with old bookmarks get a browser error instead of being moved to HTTPS, which breaks the second requirement.

  • c
    HTTPS:443 with ELBSecurityPolicy-2016-08, and an HTTP:80 listener whose default action redirects to HTTPS:443

    The redirect is right, but ELBSecurityPolicy-2016-08 still accepts TLS 1.0 and TLS 1.1, so it does not meet the TLS 1.2 minimum.

  • d
    HTTPS:443 with ELBSecurityPolicy-TLS13-1-2-2021-06, and an HTTP:80 listener that forwards to an HTTPS target group

    An HTTPS target group encrypts only the ALB-to-target hop. The client's request on port 80 is still served over plaintext HTTP; nothing sends the user to the HTTPS URL.

The concept

On an ALB, the HTTPS listener's security policy sets the minimum TLS version and cipher list, and moving HTTP users to HTTPS is a redirect action on a separate HTTP:80 listener.

Why that’s the answer

Two controls are needed: a TLS 1.2+ security policy on the HTTPS listener (ELBSecurityPolicy-TLS13-1-2-2021-06 offers TLS 1.3 and 1.2 only) and a port-80 listener with a redirect action. Deleting the port-80 listener enforces HTTPS but turns bookmark visits into errors. ELBSecurityPolicy-2016-08 keeps the redirect but still negotiates TLS 1.0/1.1. Forwarding port 80 to an HTTPS target group encrypts the back-end hop while the client keeps using HTTP.

How to reason it out
  1. Split the requirement into the client TLS version and the treatment of plaintext requests.
  2. The TLS version is set by the security policy on the HTTPS listener, so pick a TLS 1.2+ policy.
  3. Plaintext requests need a listener on port 80 that answers with a redirect, not a forward and not a missing listener.
  4. Check that the chosen policy name does not still allow TLS 1.0/1.1.

Exam tip: ALB TLS minimum = listener security policy; HTTP to HTTPS = a redirect action on the port-80 listener.

Data in Transit on AWS: TLS, ACM, and End-to-End Encryption Design — the lesson that teaches this.

Question 2Data Protection

A CloudFront distribution serves a site from a custom origin on an internet-facing Application Load Balancer. Visitors who type an http:// address must end up on the HTTPS page rather than being refused, and CloudFront must never fetch from the origin over plaintext, whichever protocol the visitor first used. Which pair of settings meets both requirements?

Choose one.

  • a
    Viewer protocol policy Redirect HTTP to HTTPS, and origin protocol policy HTTPS only Correct

    Redirect HTTP to HTTPS sends HTTP visitors a 301 to the HTTPS URL, and HTTPS only makes every origin fetch use TLS. Both requirements are met.

  • b
    Viewer protocol policy HTTPS only, and origin protocol policy HTTPS only

    The origin leg is encrypted, but an HTTPS-only viewer policy answers HTTP requests with 403 Forbidden instead of sending visitors to the HTTPS page, so the first requirement fails.

  • c
    Viewer protocol policy HTTP and HTTPS, and origin protocol policy HTTPS only on port 443

    The origin leg is encrypted, but visitors who arrive over HTTP are served over HTTP and are never moved to HTTPS.

  • d
    Viewer protocol policy Redirect HTTP to HTTPS, and origin protocol policy HTTP only

    Visitors are redirected correctly, but HTTP only makes CloudFront fetch from the origin in plaintext on every cache miss, which breaks the second requirement.

The concept

CloudFront has two independent protocol settings: the viewer protocol policy (cache behavior) controls the visitor-to-edge leg, and the origin protocol policy controls the edge-to-origin leg.

Why that’s the answer

Each requirement maps to one setting. "End up on HTTPS rather than refused" is the viewer policy Redirect HTTP to HTTPS; HTTPS only returns 403 to HTTP visitors. "Never fetch from the origin over plaintext" is the origin policy HTTPS only; HTTP only sends origin fetches in plaintext. Of the four combinations, only redirect plus HTTPS-only origin satisfies both.

How to reason it out
  1. Map the visitor requirement to the viewer protocol policy and the origin requirement to the origin protocol policy.
  2. For visitors: redirect moves HTTP users to HTTPS; HTTPS only refuses them with 403; HTTP and HTTPS leaves them on HTTP.
  3. For the origin: HTTPS only always uses TLS; HTTP only never does.
  4. Pick the combination that satisfies both legs.

Exam tip: CloudFront protects two legs separately: viewer policy for visitors, origin policy for the fetch to the origin.

Data in Transit on AWS: TLS, ACM, and End-to-End Encryption Design — the lesson that teaches this.

Question 3Data Protection

A company runs Amazon RDS for PostgreSQL 13 with a custom DB parameter group copied from the defaults. A compliance rule says the database itself must refuse any client session that is not encrypted; auditors reject connection-string settings such as sslmode because each client controls them. Which change meets the rule?

Choose one.

  • a
    Set ssl_min_protocol_version to TLSv1.2 in the DB parameter group attached to the instance

    ssl_min_protocol_version sets the lowest TLS version for sessions that use TLS. It does not make TLS mandatory, so a client that connects without SSL is still accepted.

  • b
    Enable IAM database authentication on the instance and grant rds_iam to the application users

    IAM database authentication requires SSL for the users who sign in with it, but users who keep password authentication, such as the master user, can still connect in plaintext. It does not make the engine refuse every unencrypted session.

  • c
    Set rds.force_ssl to 1 in the DB parameter group that is attached to the instance Correct

    rds.force_ssl is the RDS for PostgreSQL parameter that makes the engine reject connections that do not use SSL/TLS. On PostgreSQL 13 its default is 0, so the copied parameter group must be changed.

  • d
    Set require_secure_transport to ON in the DB parameter group attached to the instance

    require_secure_transport is the equivalent parameter for RDS for MySQL and MariaDB. It does not exist for the PostgreSQL engine, so it cannot enforce TLS here.

The concept

RDS enforces encrypted client connections with an engine parameter in the DB parameter group: rds.force_ssl for PostgreSQL (and SQL Server), require_secure_transport for MySQL and MariaDB.

Why that’s the answer

Only rds.force_ssl = 1 makes the PostgreSQL engine refuse non-TLS sessions for every user. On PostgreSQL 15 and later it defaults to 1, but on version 13 it defaults to 0, which is why the copied group needs the change. ssl_min_protocol_version only raises the version floor for clients that already use TLS. IAM authentication forces TLS for IAM users only. require_secure_transport is the MySQL/MariaDB parameter.

How to reason it out
  1. The rule needs a server-side setting, so look for an engine parameter rather than client configuration.
  2. Match the parameter to the engine: PostgreSQL uses rds.force_ssl; MySQL and MariaDB use require_secure_transport.
  3. Separate "require TLS" from "minimum TLS version": ssl_min_protocol_version only governs sessions that already use TLS.
  4. Check coverage: a control that applies to some users only does not meet "any client session".

Exam tip: RDS PostgreSQL: rds.force_ssl = 1 (default on 15+). RDS MySQL/MariaDB: require_secure_transport = ON.

Data in Transit on AWS: TLS, ACM, and End-to-End Encryption Design — the lesson that teaches this.

Question 4Data Protection

An Application Load Balancer's HTTPS listener forwards to a target group that uses the HTTPS protocol. The EC2 targets present self-signed certificates generated at boot, and no trust store or CA bundle has been configured anywhere on the load balancer. What happens to the requests that the ALB forwards to the targets?

Choose one.

  • a
    Requests fail until the targets' self-signed certificates are added to a trust store on the ALB

    ALB trust stores hold CA bundles for verifying client certificates in mutual TLS. They are not used to validate target certificates, so no trust store is needed for an HTTPS target group.

  • b
    Requests succeed, but the ALB falls back to plain HTTP for targets whose certificates it does not trust

    The ALB does not downgrade the target protocol. An HTTPS target group always uses TLS to the target; it just does not verify the certificate the target presents.

  • c
    Requests succeed, and the ALB re-encrypts to each target without validating the target certificate Correct

    With an HTTPS target group the ALB opens a second TLS session to each target and does not validate the target's certificate, so self-signed or private-CA certificates work and the hop is encrypted.

  • d
    Requests fail, because an ALB does not open TLS sessions to targets; TLS target groups need an NLB

    ALBs support HTTPS target groups and re-encrypt to targets. A Network Load Balancer is not required for back-end encryption.

The concept

An ALB always terminates the client's TLS session. With an HTTPS target group it opens a new TLS session to each target, and it does not validate the target's certificate.

Why that’s the answer

The ALB encrypts the back-end hop but does not check the target certificate's issuer, name or expiry, so self-signed certificates generated at boot work. Trust stores exist on ALBs, but for verifying client certificates in mutual TLS, not targets. The ALB never silently downgrades to HTTP, and it fully supports HTTPS target groups.

How to reason it out
  1. Identify the hop in question: ALB to target, configured as an HTTPS target group.
  2. Recall that the ALB re-encrypts to HTTPS targets but does not validate their certificates.
  3. Place trust stores correctly: they validate client certificates for mTLS, not target certificates.
  4. Conclude that self-signed target certificates work and the hop stays encrypted.

Exam tip: ALB to HTTPS target = encrypted but not validated; self-signed target certificates are fine.

Data in Transit on AWS: TLS, ACM, and End-to-End Encryption Design — the lesson that teaches this.

Question 5Data Protection

A regulator requires that each client's TLS session ends only on the backend EC2 instances, with no AWS-managed component holding a private key or seeing plaintext. The application needs no path-based routing or AWS WAF, and the front end must spread traffic across Availability Zones. Which front-end configuration meets the requirement?

Choose one.

  • a
    An Application Load Balancer with an HTTPS listener forwarding to an HTTPS target group on 443

    Both hops are encrypted, but the ALB terminates the client's session, holds the certificate's private key and sees plaintext before re-encrypting. That breaks the requirement.

  • b
    A Network Load Balancer with a TCP listener on 443, with the certificates installed on the instances Correct

    A TCP listener forwards the encrypted bytes without decrypting them, so the client's TLS session terminates on the instance that holds the key. The NLB still spreads connections across Availability Zones.

  • c
    A Network Load Balancer with a TLS listener on 443 and an ACM certificate, forwarding to TLS targets on 443

    A TLS listener makes the NLB terminate the client's session with the ACM certificate and open a new session to the target. That is two sessions with decryption at the load balancer.

  • d
    A CloudFront distribution in front of the instances, with its origin protocol policy set to HTTPS

    CloudFront terminates the viewer's TLS session at the edge and opens a separate session to the origin, so an AWS component decrypts the traffic.

The concept

Only TCP passthrough on a Network Load Balancer keeps a single TLS session from client to target. Every option that attaches a certificate to an AWS component terminates TLS there.

Why that’s the answer

An NLB TCP listener on 443 forwards encrypted bytes untouched, so the session terminates on the instances, which hold the certificates. The NLB TLS listener, the ALB with an HTTPS target group and CloudFront with an HTTPS-only origin all encrypt every hop, but each terminates the client's session and re-encrypts, which a no-intermediate-decryption rule forbids.

How to reason it out
  1. Read the requirement as one TLS session, not "encrypted on every hop".
  2. Remove any option where an AWS component holds a certificate for the client session: ALB, NLB TLS listener, CloudFront.
  3. Keep the option that forwards at Layer 4 without terminating: NLB with a TCP listener.
  4. Confirm the remaining constraints (no Layer 7 features, multi-AZ) are met by an NLB.

Exam tip: "No device in the middle decrypts" means an NLB TCP listener with certificates on the targets.

Data in Transit on AWS: TLS, ACM, and End-to-End Encryption Design — the lesson that teaches this.

Question 6Data Protection

A team changes a CloudFront distribution's origin protocol policy to HTTPS only. The custom origin is a fleet of EC2 instances that present a self-signed certificate. CloudFront now returns 502 errors, yet an internal Application Load Balancer with an HTTPS target group pointing at the same instances serves requests normally. What explains the difference?

Choose one.

  • a
    CloudFront checks that the origin certificate chains to a trusted CA and matches the origin domain Correct

    CloudFront validates the origin's certificate: it must be issued by a publicly trusted CA and cover the origin domain name. A self-signed certificate fails that check, so the origin fetch fails with 502. The ALB does not validate target certificates, which is why it works.

  • b
    CloudFront trusts origin certificates from AWS Private CA but rejects certificates from other private issuers

    CloudFront requires a publicly trusted CA for custom origin certificates. A certificate from AWS Private CA fails the same way a self-signed one does.

  • c
    CloudFront requires the origin certificate to be imported into ACM in us-east-1, like viewer certificates

    The us-east-1 rule applies to viewer certificates attached to the distribution. The origin presents its own certificate during the TLS handshake; it does not need to be in ACM at all.

  • d
    CloudFront requires the origin certificate to list the distribution's cloudfront.net name as a SAN

    CloudFront matches the origin certificate against the origin domain name (or Host header) it connects to, not against the distribution's cloudfront.net domain.

The concept

CloudFront validates a custom origin's TLS certificate (trusted CA, name match, not expired); an ALB with an HTTPS target group does not validate target certificates.

Why that’s the answer

The 502 comes from CloudFront rejecting the origin certificate: a self-signed certificate does not chain to a trusted CA. The ALB path works because ALBs encrypt to targets without validating them. The other options invent requirements: private CA certificates are not trusted by CloudFront for origins, the us-east-1 rule is for viewer certificates, and the name checked is the origin domain, not cloudfront.net.

How to reason it out
  1. Note the symptom: 502 from CloudFront only after switching the origin to HTTPS only.
  2. Compare the two clients of the same instances: CloudFront fails, the ALB succeeds.
  3. Recall which one validates the server certificate: CloudFront does; the ALB does not.
  4. Conclude that the origin needs a publicly trusted certificate that matches the origin domain.

Exam tip: CloudFront validates origin certificates; ALBs do not validate target certificates.

Data in Transit on AWS: TLS, ACM, and End-to-End Encryption Design — the lesson that teaches this.

What SCS-C03 domain 5 tests, topic by topic

The official exam guide breaks Data Protection into 3 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published SCS-C03 practice questions per topic in Data Protection
TopicWhat it coversQuestions
Design and implement controls for data in transitExam guide task 5.1 (SCS-C03). Requiring encryption when connecting to resources (Elastic Load Balancing [ELB] security policies, enforcing TLS configurations); secure and private access to resources (AWS PrivateLink, VPC endpoints, AWS Client VPN, AWS Verified Access); inter-resource encryption in transit (inter-node encryption for Amazon EMR, Amazon EKS, SageMaker AI, Nitro encryption).36
Design and implement controls for data at restExam guide task 5.2 (SCS-C03). Data encryption at rest — selecting the appropriate encryption key service (AWS CloudHSM, AWS KMS) and encryption type (client-side vs server-side); protecting data integrity (S3 Object Lock, S3 Glacier Vault Lock, versioning, digital code signing, file validation); automatic lifecycle management and retention (S3 Lifecycle policies, S3 Object Lock, Amazon EFS Lifecycle policies, Amazon FSx for Lustre backup policies); secure data replication and backup (Amazon Data Lifecycle Manager, AWS Backup, ransomware protection, AWS DataSync).38
Design and implement controls to protect confidential data, credentials, secrets, and cryptographic key materialsExam guide task 5.3 (SCS-C03). Management and rotation of credentials and secrets (AWS Secrets Manager); managing and using imported key material (rotating imported key material, external key stores); differences between imported key material and AWS generated key material; masking sensitive data (CloudWatch Logs data protection policies, Amazon SNS message data protection); creating and managing encryption keys and certificates across a single AWS Region or multiple Regions (AWS KMS customer managed keys, AWS Private Certificate Authority).38
Total112

Revise Data Protection before you drill it

Data in Transit on AWS: TLS, ACM, and End-to-End Encryption DesignExpect requirement-driven stems. A rule that the server must refuse plaintext points to a server-side setting (bucket-policy deny, engine parameter, transit encryption mode), never a client connection string. Termination questions turn on two requirements: whether any intermediate hop may decrypt, and where the certificate's private key is allowed to live. Organization-wide TLS minimums point to SCP condition keys on listeners. Private-access stems turn on where the caller sits (in the VPC, on-premises, another account) and whether users need a network or an application. Inter-node stems turn on what each control does: Nitro and VPC Encryption Controls encrypt and evidence, mesh mTLS authenticates, network isolation only restricts.Encryption at Rest on AWS: KMS Keys, Key Policies, and Service IntegrationConcepts tested: choosing between AWS managed keys, customer managed keys, imported key material, custom key stores and CloudHSM used directly by who controls the key policy, rotation and HSM users and which APIs the application calls; client-side versus server-side encryption; diagnosing KMS AccessDenied through the key policy (account-principal delegation, deleted principals), IAM policies on the key ARN, grants and kms:CreateGrant for service integrations, encryption context conditions, VPC endpoint policies and key state. How S3 Bucket Keys reduce KMS calls, and how a bucket policy pins one KMS key; why encrypting existing EBS volumes and RDS instances means making an encrypted copy, and why sharing encrypted snapshots needs a customer managed key; organization-wide enforcement with SCPs and Config rules. Object Lock retention modes, legal holds, delete markers and default retention; MFA delete's limits; Vault Lock grace time and min/max retention in AWS Backup and Amazon Glacier; S3 Lifecycle with versioning, EFS lifecycle policies and FSx for Lustre backup lifetimes; DLM and AWS Backup cross-account copy; logically air-gapped vaults; Lambda code signing policies and layers; container image signing; full-object versus composite S3 checksums; CloudTrail log file validation and DataSync verification.Protecting Secrets, Confidential Data, and Cryptographic Key MaterialSCS-C03 tests this task through custody and failure scenarios. Know which rotation form a secret needs (service-managed, AWS template, managed external secret or custom function) and read a failing rotation by its step and symptom: a timeout before createSecret, a timeout in setSecret, a fast KMS access error, a missing RotationToken, a stale AWSPENDING label or a client that cached the old value. Expect cross-account and replicated secrets where the KMS half is what breaks, key-custody requirements where only an external key store keeps material outside AWS, imported-material lifecycle questions about import parameters, on-demand rotation and expiry, multi-Region key properties that are shared versus per-Region, CloudWatch Logs and SNS data protection policy design, and certificate custody choices across ACM, exportable certificates and AWS Private CA hierarchies.

Other SCS-C03 domains

Domain 1: Detection16% of the exam · 97 questionsDomain 2: Incident Response14% of the exam · 88 questionsDomain 3: Infrastructure Security18% of the exam · 114 questionsDomain 4: Identity and Access Management20% of the exam · 128 questionsDomain 6: Security Foundations and Governance14% of the exam · 90 questionsAll SCS-C03 practice questionsMixed sessions across all 6 domains — the way the real exam interleaves them.

Data Protection: your questions

Data Protection is domain 5 of the SCS-C03 exam guide and carries 18% of the scored content — the 2nd-heaviest of the 6 domains. On a 65-question paper that works out to roughly 12 questions, though AWS does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official SCS-C03 exam guide.