AWS 5: Data Protection: 160 practice questions
48 hours only — 15% off every course with code SAVE15. Browse courses →48h · 15% off all courses · code SAVE15 →
Certifications Tools Flashcards Career Paths Exam Guides Blog Pricing For Teams About

AWS 5: Data Protection: 160 practice questions

AWS 160 questions 12 shown free

12 of the 160 5: Data Protection questions in the Certsqill AWS bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS? Take the free 5-min readiness check →

1. Use CloudFront OAC with always-sign requests and set: Which configuration satisfies all requirements?

Medium
An enterprise SaaS provider serves customer assets through CloudFront from a regular Amazon S3 bucket. Requirements state that viewers must use HTTPS, CloudFront-to-S3 traffic must use HTTPS, and S3 objects use SSE-KMS. The bucket uses Bucket owner enforced Object Ownership, and the distribution already has permission to use the KMS key. The team must replace an older origin access identity configuration with the recommended supported design. Which configuration satisfies all requirements?
  1. Retain OAI, set the viewer policy to HTTPS only, and leave the S3 origin protocol behavior unchanged.
    OAI is not the recommended design and does not satisfy the stated SSE-KMS and modern origin-control requirements reliably.
  2. Use CloudFront OAC with always-sign requests and set the viewer protocol policy to HTTPS only. ✓
    OAC always-sign requests ensures HTTPS to S3, while HTTPS-only viewer policy requires encrypted client-to-CloudFront connections.
  3. Use CloudFront OAC with do-not-sign requests and set the viewer policy to redirect HTTP to HTTPS.
    The viewer redirect protects eventual viewer traffic, but do-not-sign requests does not ensure HTTPS from CloudFront to S3.
  4. Use OAC with always-sign requests and allow HTTP viewers because CloudFront encrypts the origin connection.
    Origin encryption does not protect viewer-to-CloudFront traffic, so allowing HTTP violates the viewer requirement.
The trap
This confuses encryption on one connection leg with end-to-end transport requirements. This treats viewer encryption and legacy origin authorization as equivalent to OAC configuration. This assumes viewer protocol settings automatically enforce origin encryption.

OAC always-sign requests secures the CloudFront-to-S3 leg, while HTTPS-only viewers secure the client-facing leg.

2. Use AWS Verified Access with identity and device trust: Which AWS design best satisfies these access requireme

Medium
A media company exposes an internal editorial application to employees and contractors working from unmanaged networks. Security requires no client VPN, per-request authorization, and evaluation of user and device security signals before each application request. The application runs behind an internal load balancer and must remain private rather than publicly reachable. Which AWS design best satisfies these access requirements?
  1. Use AWS Client VPN with mutual certificate authentication and route users to the internal load balancer.
    Client VPN provides private network access but does not inherently evaluate every application request using identity and device signals.
  2. Publish the load balancer through AWS PrivateLink and grant endpoint access to contractor accounts.
    PrivateLink controls private service connectivity but does not provide the required user and device posture evaluation.
  3. Place the application behind an internet-facing load balancer and enforce security groups for contractor source addresses.
    Source-address filtering neither evaluates device posture nor provides the required per-request identity authorization.
  4. Use AWS Verified Access with identity and device trust providers evaluating each application request. ✓
    Verified Access provides VPN-less private application access with continuous request evaluation using identity and device context.
The trap
This substitutes network location for user and device trust signals. This confuses private network exposure with identity-aware application access. This treats network admission as equivalent to per-request application authorization.

AWS Verified Access provides private, VPN-less application access while evaluating identity and device context on each request.

3. Configure mutual TLS between the two application services: Select TWO configurations that satisfy the requirem

Medium
A hybrid identity deployment connects its data center to a VPC through AWS Direct Connect. Security requirements explicitly mandate IPsec encryption for traffic crossing the hybrid connection and TLS encryption between two application services inside the VPC. Direct Connect alone is not considered encrypted, and both services support certificate-based TLS. The team wants complementary controls rather than relying on private routing. Select TWO configurations that satisfy the requirements.

Select two. More than one option is correct — every correct one is ticked below.

  1. Use security groups to restrict the Direct Connect path and application traffic.
    Security groups authorize traffic but do not provide the required IPsec or service-to-service TLS encryption.
  2. Configure mutual TLS between the two application services with trusted certificates. ✓
    Mutual TLS encrypts and authenticates the application connection independently of the VPC network path.
  3. Enable Direct Connect MACsec and omit TLS on the application connection.
    MACsec can protect a supported Direct Connect connection, but omitting required internal TLS leaves the application requirement unmet.
  4. Run a Site-to-Site VPN over Direct Connect for the hybrid traffic. ✓
    A VPN over Direct Connect provides the required IPsec protection while retaining the private path.
  5. Use a VPC endpoint policy to protect traffic between the application services.
    Endpoint policies control access to supported AWS services through endpoints and do not encrypt arbitrary application-to-application traffic.
The trap
Confuses filtering with cryptographic protection. Confuses endpoint authorization with transport encryption. Treats link encryption as protection for every internal application flow.

Use IPsec over Direct Connect for hybrid traffic and mutual TLS for the application connection.

4. Use the external-store KMS key and add a restore testing: Which implementation completes both requirements?

Medium
A centralized security operations team protects regulated backup data across accounts. The selected backup resource supports the already configured and tested external key store. The external key manager, XKS proxy, KMS key, vault, and cross-account permissions are ready. Exhibit: `backup plan: scheduled; vault: Compliance mode; restore testing plan: absent`. Which implementation completes both requirements?
  1. Use an AWS-managed KMS key and add a scheduled restore testing plan for audit evidence.
    The restore plan is appropriate, but an AWS-managed key does not satisfy the external-custody requirement.
  2. Use the external-store KMS key and add a restore testing plan. ✓
    The external key store keeps key material outside AWS, and the restore testing plan schedules restore jobs and records their results.
  3. Use a standard customer-managed KMS key and add scheduled restore tests while retaining the vault's compliance mode.
    Customer-managed KMS administration does not place key material outside AWS, even though restore testing is addressed.
  4. Use the external-store KMS key and treat Vault Lock compliance mode as restore validation.
    Vault Lock protects retention but does not execute or validate restores.
The trap
Confuses immutability with recoverability testing. Prioritizes testing while selecting the wrong key-custody model. Confuses customer administration with external custody.

Use the configured external key and add an AWS Backup restore testing plan.

5. Enable S3 Versioning and Object Lock in Compliance mode: Which design best meets the integrity requirements?

Medium
A regulated research workload archives finalized experiment records in Amazon S3. Records must remain readable, protected against deletion or overwrite during a defined retention period, and resilient against privileged-user tampering. New records must continue arriving during retention, while each archived version must retain its own protection. Which design best meets the integrity requirements?
  1. Enable S3 Versioning and use Object Lock in Governance mode with administrator bypass permissions.
    Governance mode permits authorized privileged users to bypass retention, conflicting with resistance to privileged-user tampering.
  2. Enable S3 Versioning and Object Lock in Compliance mode with an appropriate default retention period. ✓
    Versioning preserves distinct object versions, while Compliance-mode Object Lock protects each retained version from deletion or overwrite during its retention period, including by privileged users.
  3. Apply legal holds to current versions in a versioned bucket, without default retention for new uploads.
    Current legal holds do not automatically apply a defined retention period to newly arriving versions.
  4. Enable S3 Versioning without Object Lock and restrict deletes using an IAM permissions boundary.
    Versioning preserves history, but a permissions boundary does not provide immutable object retention against privileged actions.
The trap
Confuses identity least privilege with object-level WORM protection. Protects only selected existing versions rather than all incoming records. Mistakes administrative control over governance retention for immutable compliance protection.

Pair S3 Versioning with Compliance-mode Object Lock and defined retention.

6. Use seven-year Compliance Object Lock with legal holds: Which design best satisfies these requirements?

Medium
An incident response team stores investigation artifacts in Amazon S3. Legal requires WORM retention for seven years, investigators need object-level legal holds, administrators must not shorten retention after deployment, and backup recovery points must resist deletion by compromised credentials. Which design best satisfies these requirements? S3 Versioning and backup plans producing the required recovery points are already configured.
  1. Use S3 Lifecycle expiration after seven years and protect recovery points with a Compliance-mode Vault Lock.
    Vault Lock protects recovery points, but S3 Lifecycle expiration does not provide WORM protection or object-level legal holds for investigation artifacts.
  2. Enable S3 Versioning and Object Lock in Governance mode with seven-year retention; protect recovery points with a Governance-mode Vault Lock.
    Both governance modes can be changed or bypassed by sufficiently authorized principals, so they do not meet the requirement that administrators and compromised credentials cannot shorten retention or delete backups.
  3. Use seven-year Compliance Object Lock with legal holds and finalized Compliance Vault Lock for backups. ✓
    S3 Object Lock supplies immutable version retention and object-level legal holds. Compliance mode prevents retention bypass, while AWS Backup Vault Lock protects separate recovery points from deletion after its grace period.
  4. Use seven-year Compliance Object Lock with legal holds but retain recovery points in an unlocked vault.
    The S3 artifacts are protected, but the separate backup recovery points remain deletable because the destination vault has no immutable Vault Lock.
The trap
Uses administrative governance controls where immutable compliance controls are required. Treats lifecycle expiration as a substitute for S3 Object Lock. Protects the primary store while leaving backup copies exposed.

Use S3 Object Lock Compliance mode and Compliance-mode AWS Backup Vault Lock.

7. Configure live Cross-Region Replication with destination: Select TWO actions.

Medium
A federated partner sends encrypted customer documents to an Amazon S3 bucket in Account A. Existing objects must be copied to Account B, new objects must replicate continuously across Regions, and Account B must own replicas. Periodic AWS Backup restore tests and application validation already provide recovery-usability evidence. The remaining work is object replication. Both accounts use customer managed KMS keys with compatible policies and grants already configured. Select TWO actions.

Select two. More than one option is correct — every correct one is ticked below.

  1. Configure live Cross-Region Replication with destination ownership and destination-key encryption. ✓
    Live replication handles eligible new writes after the rule is enabled, with the required cross-account ownership and encryption settings.
  2. Configure S3 Same-Region Replication for new objects and use AWS Backup restore testing to backfill existing objects.
    Same-Region Replication does not meet the cross-Region requirement, and restore testing validates recovery rather than copying existing S3 objects into the destination bucket.
  3. Create an additional periodic backup schedule without configuring live or batch S3 replication.
    Backup recovery points do not supply the requested live replicas and historical-object backfill in the destination bucket.
  4. Configure live Cross-Region Replication with ownership override and destination KMS encryption, then rely on S3 RTC reports as evidence that restored data is usable.
    S3 RTC monitors replication timing; it does not restore data or demonstrate that restored data is usable, and live replication alone omits preexisting objects.
  5. Run S3 Batch Replication for existing objects using the configured cross-account replication rule. ✓
    Batch Replication backfills eligible existing objects; the replication rule supplies the intended destination ownership and encryption.
The trap
Confuses replication monitoring with recovery validation. Confuses backup recovery with object replication. Uses the wrong replication scope and confuses testing with object replication.

Use live CRR for future writes and Batch Replication for the existing object backlog.

8. Use a Lambda rotation function with alternating: Which design should the security architect recommend?

Hard
A container platform stores database credentials in AWS Secrets Manager. The database supports two active credentials during rotation, applications cache credentials for up to five minutes, and the security team requires automatic rotation without application redeployment. The credential type is not one of the managed secret types. The platform permits a VPC-connected rotation function to reach the database, and the application already supports retrieving refreshed secrets and retrying authentication. Which design should the security architect recommend?
  1. Update only the stored secret and wait for application caches to expire.
    Changing Secrets Manager alone does not change the database credential, so refreshed clients would receive an unusable credential.
  2. Move the credential to Parameter Store and schedule value updates with EventBridge.
    Scheduled value updates do not coordinate changing the database credential with changing the stored secret or provide the required rotation workflow.
  3. Use a Lambda rotation function with alternating credentials and client refresh. ✓
    Lambda rotation supports custom secret types, alternating credentials preserve availability, and the stated client refresh and retry behavior handles cached credentials without redeployment.
  4. Have an administrator update the database password and stored secret during a recurring manual change window.
    This can coordinate the two values, but it is a manual process rather than the required automatic rotation.
The trap
Confuses periodic manual change with automated rotation. Confuses secret-value replacement with target-system rotation. Confuses scheduling with credential rotation.

Use custom Lambda rotation with alternating database credentials and client refresh behavior.

9. Import material: Which design meets these requirements?

Hard
An internal business application uses a symmetric customer managed KMS key with imported key material. The security policy requires the organization to retain the original material outside AWS, expire AWS availability on a schedule, and later make the same logical KMS key usable again after reimporting material. The team must avoid external key-store availability dependencies. Which design meets these requirements?
  1. Use an AWS-generated key with automatic rotation and schedule deletion.
    AWS-generated material cannot be retained externally or reimported, and deletion is not reversible restoration of the same key.
  2. Import material, set expiration, retain the source, and reimport it later. ✓
    Imported material can expire without deleting the KMS key, while retained source material can later be reimported into the same logical key.
  3. Use a custom key store for imported material and enable automatic rotation.
    Imported material is not placed in a custom key store, and automatic rotation does not provide the required scheduled expiration and reimport workflow.
  4. Use an external key store and disable its external manager on schedule.
    This provides external control but introduces the external key-store availability dependency explicitly excluded by the scenario.
The trap
Selects external custody despite the stated operational constraint. Confuses rotation and deletion with imported-material lifecycle. Combines incompatible key-store and lifecycle features.

Use imported material with expiration, external retention, and later reimport into the same KMS key.

10. Replicate an AWS-generated symmetric multi-Region key: Which design is best?

Hard
A cross-Region archive must decrypt ciphertext in a secondary Region during a primary-Region outage. The organization requires cryptographic material generated by AWS and wants rotation to preserve access to previously encrypted objects without re-encrypting the archive. The archive uses symmetric KMS encryption, and the client-side encryption software in both Regions supports related multi-Region KMS keys. Which design is best?
  1. Replicate an AWS-generated symmetric multi-Region key and enable rotation on its primary. ✓
    Related AWS-generated multi-Region keys share key material and key ID across selected Regions. Rotation changes current material while KMS continues decrypting ciphertext protected by earlier material.
  2. Create imported symmetric multi-Region keys with matching material, replicate the primary, and reimport material after each rotation.
    Imported material violates the requirement that AWS generate the cryptographic material, and the proposed reimport workflow is unnecessary for the required AWS-generated-key design.
  3. Use separate Regional keys and re-encrypt.
    Separate single-Region keys do not share cryptographic material, and re-encryption violates the requirement to preserve access without rewriting the archive.
  4. Use AWS-managed service keys in both Regions with automatic rotation and have clients select the matching Regional key.
    AWS-managed keys are single-Region resources and do not form a customer-configurable related multi-Region key set for this client-side archive.
The trap
Confuses authorization with shared cryptographic material. Assumes AWS-managed keys form a shared multi-Region set. Chooses imported material despite the required material origin.

Use related AWS-generated symmetric multi-Region keys with rotation enabled on the primary.

11. Grant investigators `logs: Select TWO actions.

Hard
A generative AI application sends prompts to Amazon Bedrock and writes application logs to CloudWatch Logs. The security review identified email addresses and AWS access key patterns in logs. Existing events must remain unchanged, future events must be masked for ordinary analysts, authorized investigators need controlled unmasking, and the team wants detection metrics. Exhibit: current log group is `/prod/genai`; analysts have `logs:StartQuery`; investigators can receive a separate IAM permission. Select TWO actions.

Select two. More than one option is correct — every correct one is ticked below.

  1. Apply an Amazon SNS message data protection policy to prompts before sending them to Amazon Bedrock.
    SNS message data protection is unavailable to new customers and would not mask the CloudWatch log group’s future events.
  2. Grant investigators `logs:Unmask` only through a narrowly scoped IAM policy for the protected log group. ✓
    The logs:Unmask permission allows authorized investigators to view protected values while ordinary analysts continue seeing masks.
  3. Attach a CloudWatch Logs data protection policy to `/prod/genai` with email and AWS credential identifiers. ✓
    The policy detects and masks selected sensitive identifiers at ingestion across supported log access and egress paths.
  4. Apply the data protection policy and expect previously ingested log events to become masked automatically.
    CloudWatch Logs data protection masks matching data at ingestion, so events stored before policy creation remain unmasked.
  5. Create a CloudWatch Logs metric filter that replaces email addresses in matching log events.
    Metric filters can count matches but cannot rewrite or mask the underlying CloudWatch Logs events.
The trap
Confuses detection metrics with data transformation. Assumes protection policies retroactively transform existing log data. Chooses an unavailable or wrong-path control for the actual logging workload.

Protect the log group with data identifiers and grant narrowly scoped logs:Unmask access to investigators only.

12. Request ACM private certificates from the Regional CAs: Which design should the team implement?

Hard
A retail security team operates an application active-active in two AWS Regions. Regional load balancers require certificates that renew automatically, and the team wants one consistent trust hierarchy for privately authenticated service connections. The organization has an authorized subordinate AWS Private CA in each Region, both chained to the same trusted root. Certificates must be issued by that private CA, while public web certificates must use ACM-managed renewal. Which design should the team implement?
  1. Request ACM private certificates from the Regional CAs and DNS-validated public certificates in each Region. ✓
    ACM can request private certificates from the organization’s Private CA, and ACM public certificates are Regional and eligible for managed renewal when DNS validated and associated with the load balancer.
  2. Use imported private certificates and one Regional ACM public certificate for both load balancers.
    Imported certificates are not eligible for ACM managed renewal, and a Regional ACM certificate cannot serve both Regions.
  3. Call AWS Private CA IssueCertificate for private certificates and request one public ACM certificate in a single Region.
    Certificates issued directly through IssueCertificate are not eligible for ACM managed renewal, and ACM certificates are Regional.
  4. Request private certificates from the Regional Private CA and use externally automated public certificates, deploying each certificate to its local load balancer.
    The private certificates can satisfy the trust requirement, but externally automated public certificates do not satisfy the requirement for ACM-managed renewal.
The trap
Confuses certificate import and Regional certificate scope with managed issuance. Uses direct CA issuance instead of ACM private certificate requests. Replaces ACM-managed public renewal with customer automation.

Use ACM private certificate requests through each Regional Private CA and separate DNS-validated ACM public certificates per Region.

148 more 5: Data Protection questions

The remaining 148 questions in this domain are part of the full AWS bank — 890 questions, every option explained. Start with the free five-minute check and see your score per domain.

Test your AWS readiness — free

Other AWS domains

Part of the Certsqill AWS question bank · 5: Data Protection · Every answer, right and wrong, comes with its own explanation.