DVA-C02 Exam Dumps : AWS Certified Developer - Associate

To meet the requirement that developers cannot view credit card numbers while the fraud detection account can, the solution must (1) ensure the sensitive data is masked at ingestion/storage in CloudWatch Logs, and (2) allow only an authorized principal to view unmasked values.

First, the developers must attach the data protection policy to the CloudWatch log group that receives the API Gateway HTTP API access logs (and/or the Lambda log group if credit card numbers can appear there). A CloudWatch Logs data protection policy is applied at the log group level and instructs CloudWatch Logs to identify sensitive data using managed data identifiers (for example, CreditCardNumber) and then apply the configured de-identification action (here, masking). Without attaching the policy to the log group, the masking/redaction behavior will not be enforced for newly ingested log events, and developers could still see raw request parameters.

Second, to permit only the fraud detection account to reveal the masked values when necessary, the IAM role that the fraud detection account assumes must have the specific CloudWatch Logs permission to unmask protected data. Granting logs:Unmask to that role enables authorized access to view the sensitive values while keeping them masked for everyone else who lacks that permission (such as developer accounts assuming other roles).

Options A and E are not required for CloudWatch Logs data protection enforcement; the core controls are log-group policy attachment (to perform masking) and IAM authorization (to permit unmasking only for the fraud role). Therefore, the correct combination is C (apply the policy to the log group that captures the HTTP API logs) and B (grant logs:Unmask to the fraud detection role).

AWS Amplify is a set of tools and services that enables developers to build and deploy full-stack web and mobile applications that are powered by AWS. AWS Amplify supports hosting static websites on Amazon S3 and Amazon CloudFront, with HTTPS enabled by default. AWS Amplify also integrates with various version control systems, such as AWS CodeCommit, Bitbucket, and GitHub, and allows developers to connect different branches to different environments. AWS Amplify automatically builds and deploys the website whenever code changes are merged to a connected branch, enabling phased releases with minimal operational overhead. Reference: AWS Amplify Console

The base table’s primary key is UserID, which means efficient Query operations on the table natively require specifying UserID (partition key equality). The required access pattern, however, is to retrieve many users for a given Location and then filter/sort by RegistrationDate (users who registered after a given date). Because Location is not part of the table’s primary key, the efficient DynamoDB approach is to create an index that supports this access pattern.

A global secondary index (GSI) can have a different partition key and sort key than the base table. By creating a GSI with Location as the partition key and RegistrationDate as the sort key, the application can use the Query operation to fetch all users in a specific location (Location = :loc) and apply a sort key condition such as RegistrationDate > :date (or BETWEEN), which is efficient and avoids a full-table scan. This design is the canonical pattern for optimizing DynamoDB queries: model the table and indexes around known access patterns so the application can use Query instead of Scan.

Option C (LSI) is not valid for this requirement because an LSI must use the same partition key as the base table (UserID). Since the access pattern is by Location, an LSI cannot make Location the partition key. Option B (Scan + filter) is inefficient at scale because Scan reads every item (or every item in the scanned segments) and then filters results, consuming read capacity and increasing latency. Option D (BatchGetItem) requires the caller to already know the primary keys of the items to retrieve; it cannot discover “all users in a location after a date” and does not support filtering in the way Query on an index does.

Therefore, A is the correct and most efficient solution: a GSI on (Location, RegistrationDate) and Query with a date range condition.