Development with AWS Services practice questions

Answer: A) A ProjectionExpression that names only the three attributes the function needs

A ProjectionExpression makes DynamoDB return only the attributes you name, which shrinks the response. Read capacity consumption doesn't change, because RCUs are based on the full item size.

• ACorrect. By default DynamoDB returns all attributes of an item. A projection expression limits the response to the attributes you name, which makes the payload smaller. It does not lower consumed read capacity, though: DynamoDB calculates capacity units from the full item size, not from the amount of data returned.
• BIncorrect. Eventually consistent reads use half the read capacity of strongly consistent reads, but they still return every attribute of the item. They don't change the size of the response payload.
• CIncorrect. More read capacity raises the available throughput. Each read still returns the whole item unless a projection expression is used.
• DIncorrect. A stream view type controls what goes into stream records for downstream consumers. It has no effect on the attributes that GetItem or Query return.

Answer: A) An S3 event notification for s3:ObjectRemoved:* events, filtered on the audit/ prefix, with the SNS topic as its destination

Configure an S3 event notification with the s3:ObjectRemoved:* event type and a prefix filter, and set the SNS topic as its destination. S3 publishes only the event types and key prefixes you specify.

• AS3 event notifications let you choose event types, including object removal events, and filter them by key prefix. SNS topics are a supported destination, so this sends only deletions under audit/ to the topic.
• BObjectCreated events fire when objects are added, not deleted. S3 sends notifications only for the event types you specify, so deletions wouldn't produce any messages.
• CA Lifecycle rule only manages transitions and expirations on a schedule. It has no SNS destination of its own, and it wouldn't capture deletions that users or applications make.
• DA subscription filter policy only filters messages that have already been published to the topic. S3 doesn't publish anything to the topic unless the bucket has a notification configuration for it.

Answer: A) Custom message trigger, returning emailSubject and emailMessage that include the codeParameter placeholder

The custom message trigger runs before Cognito sends verification, invitation and MFA messages. It can return a dynamic emailSubject and emailMessage (with SES/DEVELOPER email sending) as long as the codeParameter placeholder is included.

• ACognito invokes the custom message trigger before it sends verification, invitation and MFA messages (triggerSource CustomMessage_SignUp after sign-up). The function can return emailSubject and emailMessage, which must contain the codeParameter placeholder. These fields require EmailSendingAccount to be DEVELOPER, which is the SES setup described in the stem.
• BThe pre sign-up trigger runs before the user is created. Its response supports only autoConfirmUser, autoVerifyEmail and autoVerifyPhone, so it can't set message content.
• CPost confirmation runs only after the user has confirmed, so the verification code has already been sent. It can't change that message.
• DPre token generation changes claims in the ID and access tokens issued at sign-in. It has no part in building or sending verification emails.

Answer: A) Configure an S3 Inventory report on the bucket with a weekly frequency and the audit bucket as the destination

S3 Inventory is the scheduled, file-based alternative to the synchronous List APIs. It writes a daily or weekly list of objects with chosen metadata, such as size, storage class, and encryption status, to a destination bucket without adding List request load.

• ACorrect. S3 Inventory writes CSV, ORC, or Parquet files on a daily or weekly schedule to a destination bucket. Size, storage class, and encryption status are optional metadata fields you can include. Inventory doesn't use the List API operations and doesn't affect the bucket's request rate.
• BIncorrect. Storage Lens gives aggregated usage and activity metrics at the account, bucket, and prefix level. It doesn't produce a list of individual objects with their keys and per-object metadata.
• CIncorrect. Server access logs record the requests made to a bucket. They don't list every stored object, and objects that nobody accessed would never show up in them.
• DIncorrect. CloudTrail data events record object-level API activity such as GetObject and PutObject. They are an activity log, not a list of every object in the bucket with its metadata.

Answer: A) DynamoDB Streams

• AStreams captures a time-ordered sequence of item-level modifications (inserts, updates, deletes) and retains them for 24 hours, letting downstream consumers like Lambda or Kinesis Data Streams process each change event.
• BGSIs provide alternate query access patterns on current data; they don't provide a change-event log for downstream processing.
• CDAX is a read-through cache for improving read latency; it doesn't capture a change log.
• DBackups are point-in-time snapshots for recovery, not a continuous, ordered stream of individual item-level changes.

Answer: A) Remove the CORS headers from the function code and keep all CORS settings in the function URL configuration

For non-preflight requests, a Lambda function URL returns both its configured CORS headers and any CORS headers the function returns, which can duplicate Access-Control-Allow-Origin. AWS recommends configuring CORS only on the function URL.

• ACorrect. For non-preflight requests such as GET, Lambda returns both the CORS headers configured on the function URL and any CORS headers the function returns, so the header is duplicated. AWS recommends putting all CORS settings on the function URL instead of adding them in the function response.
• BIncorrect. AuthType controls whether Lambda authenticates callers with IAM. It has nothing to do with how CORS response headers are merged, so the duplicate header would still be there.
• CIncorrect. Preflight requests already succeed, and for preflight requests the function URL's configured CORS headers take precedence anyway. The failure is on GET responses, where the header from the configuration and the header from the code are both returned.
• DIncorrect. This fixes the duplicate on GET but leaves preflight OPTIONS requests without any configured CORS handling, so the cross-origin flow can break. AWS recommends doing the opposite: configure CORS on the function URL and don't send the headers manually.

Answer: A) 3 WCUs, because the item size is rounded up to the next 1 KB

For writes, DynamoDB rounds item size up to the next 1 KB, and each 1 KB costs one WCU, so a 2.3 KB standard write uses 3 WCUs. Transactional writes would double this.

• ACorrect. One WCU covers one write of an item up to 1 KB. For writes, DynamoDB rounds the item size up to the next 1 KB multiple, so 2.3 KB counts as 3 KB, which is 3 WCUs.
• BIncorrect. DynamoDB does not use fractional write units for item size. It rounds the size up to the next 1 KB first and charges whole units.
• CIncorrect. The 4 KB unit applies to reads. Writes are measured in 1 KB units, so a 2.3 KB item needs more than one WCU.
• DIncorrect. Only transactional writes (TransactWriteItems) cost double, because they prepare and then commit. A standard PutItem of a 2.3 KB item uses 3 WCUs, not 6.

Answer: A) Create an AWS AppSync GraphQL API with DynamoDB and Lambda data sources

AWS AppSync is the managed GraphQL service. It provides built-in resolvers for data sources such as DynamoDB and Lambda, plus real-time subscriptions. API Gateway options would require custom GraphQL handling.

• AAppSync is a managed GraphQL service. It resolves fields against data sources such as DynamoDB and Lambda and delivers subscriptions over serverless WebSockets, so there's no GraphQL server to run.
• BWebSocket APIs provide two-way, real-time messaging. However, they have no GraphQL schema or resolver model, so the developer would have to write the GraphQL parsing and subscription handling themselves.
• CREST API service integrations can call DynamoDB directly, but they are resource and method based. They don't provide GraphQL schema resolution or subscription delivery.
• DThis setup is a self-managed GraphQL server that the developer must maintain, which the requirements rule out. HTTP APIs also don't provide GraphQL subscriptions.

Answer: A) The update is applied only if the item's current attributes satisfy the expression; otherwise the request fails

A ConditionExpression makes DynamoDB apply a write only when the item's current state matches the condition. Otherwise the write fails with ConditionalCheckFailedException, which allows optimistic locking that prevents lost updates.

• ACorrect. A conditional write succeeds only if the item's attributes meet the condition. Otherwise DynamoDB returns a ConditionalCheckFailedException, so a stale writer can't overwrite newer data.
• BIncorrect. DynamoDB doesn't queue or retry a failed conditional write. It returns ConditionalCheckFailedException, and the application decides what to do next.
• CIncorrect. When a ConditionExpression evaluates to false, DynamoDB still consumes write capacity. The amount depends on the size of the existing item, with a minimum of 1.
• DIncorrect. Conditional writes are optimistic. They check the condition against the latest version of the item when the write runs and don't hold locks that block other readers or writers.

Answer: A) It polls the table's status until it is ACTIVE, because CreateTable returns while the table is still CREATING

DynamoDB CreateTable is asynchronous and returns while the table is still CREATING. A waiter polls until the table is ACTIVE, which prevents the race where writes happen before the table can accept them.

• ACreateTable is asynchronous. It returns right away with TableStatus CREATING, and reads and writes only work on an ACTIVE table. The waiter keeps checking the table until it reaches the desired state (or gives up), so the writes run only after the table is ready.
• BThat describes the SDK's built-in retry behavior for transient and throttling errors. A waiter doesn't retry your writes. It checks a resource's state before your code continues.
• CWaiters don't subscribe to events or receive push notifications. They repeatedly call a describe-style API until the resource reaches the target state or the waiter times out.
• DThe waiter doesn't change CreateTable, which still returns immediately with status CREATING. The waiter is a separate polling step that runs after CreateTable returns.