DEA-C01 Practice Questions

AWS Certificate Manager (ACM) is the designated AWS service for provisioning, managing, and deploying public and private SSL/TLS certificates. It is specifically designed to automate and simplify the entire certificate lifecycle, including generation, distribution, and, most importantly, automatic renewal. By integrating ACM with services like Elastic Load Balancing (which fronts EC2 instances), the company can achieve end-to-end encryption with minimal operational overhead, as ACM handles the complex and error-prone tasks of certificate management automatically.

1. AWS Certificate Manager User Guide: "AWS Certificate Manager is a service that lets you easily provision

manage

and deploy public and private Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates... ACM handles the complexity of creating and managing public SSL/TLS certificates for your AWS-based websites and applications... and let ACM handle certificate renewals." (Source: AWS Certificate Manager User Guide

"What Is AWS Certificate Manager?"

Introduction section).

2. AWS Certificate Manager User Guide: "Managed renewal for ACM certificates - ACM manages the renewal process for the SSL/TLS certificates that you manage with ACM... ACM can automatically renew your certificate and provision it after it is issued." (Source: AWS Certificate Manager User Guide

"Features"

"Managed renewal for ACM certificates" section).

3. AWS Secrets Manager User Guide: "AWS Secrets Manager helps you protect secrets needed to access your applications

services

and IT resources. The service enables you to easily rotate

manage

and retrieve database credentials

API keys

and other secrets..." (Source: AWS Secrets Manager User Guide

"What is AWS Secrets Manager?"

Introduction section). This highlights its primary purpose is for secrets like keys and credentials

not certificate lifecycle management.

4. Amazon ECS Developer Guide: "Amazon ECS Service Connect provides management of service-to-service communication as an Amazon ECS configuration." (Source: Amazon ECS Developer Guide

"Service Connect"

Introduction section). This confirms its scope is specific to ECS networking.

An AWS Glue crawler is the purpose-built service for automatically discovering and cataloging metadata from various data sources, including Amazon S3 and Amazon RDS. Crawlers use a prioritized list of classifiers (both built-in and custom) to automatically determine the data's schema, including its storage format (e.g., Parquet, JSON, CSV). This process populates the AWS Glue Data Catalog with the required metadata tables. This automated approach is the most direct and efficient method, fulfilling the "LEAST effort" requirement by eliminating the need for manual scripting or metadata entry.

1. AWS Glue Developer Guide - Cataloging tables with a crawler: "A crawler connects to a data store

progresses through a prioritized list of classifiers to determine the schema for your data

and then creates metadata tables in your Data Catalog." This confirms the crawler's primary function.

2. AWS Glue Developer Guide - Working with classifiers on the AWS Glue console: "AWS Glue uses classifiers to infer the schema of your data. [...] AWS Glue provides built-in classifiers for various formats

including JSON

CSV

Parquet

ORC

Avro

and Grok." This explains the mechanism for automatically identifying the storage format.

3. AWS Glue Developer Guide - Crawler source types: This section documents that crawlers can use "Amazon S3 paths" and "JDBC data stores" (which includes Amazon RDS) as sources

confirming its applicability to the scenario. (See section: "Defining a crawler").

This scenario requires a two-part solution: a mechanism for data collection (logs and traces) and a backend for data correlation and analysis.

Option A provides the most efficient collection strategy. FluentBit is a lightweight, high-performance log processor and forwarder, making it ideal for collecting logs from containerized environments like Amazon EKS with minimal resource overhead. OpenTelemetry is the open-source industry standard for instrumenting applications to generate and collect telemetry data, including traces, with minimal code changes, thus satisfying the "least development effort" constraint.

Option D provides the optimal backend for analysis. Amazon OpenSearch Service is a managed service specifically designed for log analytics, monitoring, and full-text search. It has built-in capabilities, known as Trace Analytics, to ingest, visualize, and correlate trace data from OpenTelemetry with corresponding log data, directly addressing the core requirement.

1. Amazon EKS Best Practices Guides: The guide on logging recommends Fluent Bit as a log router due to its efficiency and low resource consumption in a cluster. (Source: AWS EKS Best Practices Guides

Observability

Logging section. Retrieved from https://aws.github.io/aws-eks-best-practices/docs/observability/logging/)

2. AWS Distro for OpenTelemetry Documentation: "AWS Distro for OpenTelemetry is a secure

production-ready

AWS-supported distribution of the OpenTelemetry project. ...you can instrument your applications just once to send correlated metrics and traces to multiple AWS monitoring solutions." This supports using OpenTelemetry for low-effort trace collection. (Source: AWS Documentation

What is AWS Distro for OpenTelemetry?)

3. Amazon OpenSearch Service Developer Guide: "Trace Analytics in OpenSearch Dashboards lets you analyze trace data from your distributed applications. The feature is powered by OpenTelemetry..." This confirms OpenSearch is the purpose-built tool for correlating traces. (Source: Amazon OpenSearch Service Developer Guide

Trace Analytics section).

4. AWS Prescriptive Guidance: An end-to-end observability pattern for EKS involves using Fluent Bit to ship logs and the AWS Distro for OpenTelemetry (ADOT) Collector to ship traces and metrics to a backend like Amazon OpenSearch Service. (Source: AWS Prescriptive Guidance

Implement observability for an application on an Amazon EKS cluster

Pattern ID: PAT010).

5. AWS Glue Developer Guide: "AWS Glue is a serverless data integration service that makes it easy to discover

prepare

and combine data for analytics

machine learning

and application development." This defines its role as ETL

distinct from a monitoring and analysis platform. (Source: AWS Glue Developer Guide

What is AWS Glue?).

The core requirement is to make data immutable for 7 years, even for the root user. S3 Object Lock in Compliance mode is specifically designed for this purpose. In Compliance mode, a protected object version cannot be overwritten or deleted by any user, including the root user in the AWS account, until the retention period expires. Setting a default retention period of 7 years on the bucket ensures that all new customer records automatically inherit this strict, unchangeable WORM (Write-Once, Read-Many) protection, fulfilling all stated requirements.

1. AWS S3 User Guide

"Retention modes": "In compliance mode

a protected object version can't be overwritten or deleted by any user

including the root user in your AWS account. When an object is locked in compliance mode

its retention mode can't be changed

and its retention period can't be shortened." This directly supports the choice of Compliance mode.

2. AWS S3 User Guide

"Retention modes": "In governance mode

users can't overwrite or delete an object version or alter its lock settings unless they have special permissions." This confirms why Governance mode is incorrect for this scenario.

3. AWS S3 User Guide

"Legal holds": "A legal hold doesn't have an associated retention period and remains in effect until you explicitly remove it." This clarifies why a legal hold is not suitable for a fixed 7-year requirement.

4. AWS S3 User Guide

"Default retention settings": "You can configure a default retention period for a bucket. When you set a default retention period on a bucket

any object that is uploaded to that bucket without an explicit retention period receives the default retention period." This supports using a default setting for operational efficiency.

The Apache Spark UI is the primary interface for monitoring and debugging the execution of Spark applications. When an AWS Glue job runs on the Spark engine, AWS Glue provides access to the Spark UI. This UI offers a granular, real-time, and post-run view of the job's execution, including a detailed breakdown of jobs, stages, and tasks. A data engineer can use the Spark UI to examine metrics for each individual stage, such as duration, data shuffled, input/output records, and execution details, which is essential for diagnosing failures or performance bottlenecks at a specific point in the ETL process.

1. AWS Glue Developer Guide: Under the section "Monitoring with the Apache Spark web UI

" the documentation states

"You can use the Apache Spark web UI to monitor and debug AWS Glue ETL jobs running on the Spark engine... The Spark UI provides information about... A list of scheduler stages and tasks... A summary of RDD sizes and memory usage...". This directly supports using the Spark UI to examine stage details.

2. AWS Glue Developer Guide: The section "Monitoring with Amazon CloudWatch" lists the available metrics

which are aggregated at the job level (e.g.

glue.driver.aggregate.numCompletedStages

glue.driver.aggregate.numCompletedTasks). This demonstrates that CloudWatch does not provide the granular

per-stage view needed.

3. AWS Glue Developer Guide: The section "AWS Glue job run insights" describes the feature as a way to "simplify job debugging and optimization" by providing "the probable root causes for a job failure and provides remediation steps." This confirms it is a diagnostic summary tool

not a tool for direct examination of stage metrics.

4. AWS CloudTrail User Guide: The section "Logging AWS Glue API Calls with AWS CloudTrail" clarifies that CloudTrail records actions taken by a user

role

or an AWS service in AWS Glue

such as CreateJob or StartJobRun

not the internal workings of the job itself.

The most precise and correct method to create a new Amazon Athena table from a query result is by using a CREATE TABLE AS SELECT (CTAS) statement. The statement in Option A correctly uses the CREATE TABLE tablename AS syntax, followed by a SELECT query that filters the citiesworld table for records where the country column is 'US'. This single operation creates the new table citiesus and populates it with the specified subset of data, storing the new data files in Amazon S3.

1. Amazon Athena Developer Guide

"CREATE TABLE AS": This official documentation explicitly defines the CTAS query syntax and its purpose. It states

"A CREATE TABLE AS SELECT (CTAS) query creates a new table in Athena from the results of a SELECT statement from another query." The provided syntax is CREATE TABLE newtable AS SELECT ...

which directly matches Option A.

Source: AWS Documentation

Amazon Athena

SQL reference

Data definition language

CREATE TABLE AS.

2. Amazon Athena Developer Guide

"Examples of CTAS queries": This page provides practical examples that reinforce the correct syntax. An example shows CREATE TABLE ctascsvexample AS SELECT key

CAST(vin AS VARCHAR) AS vin FROM "mydatabase"."mytable"

confirming the CREATE TABLE ... AS SELECT ... structure.

Source: AWS Documentation

Amazon Athena

User Guide

Working with query results

CTAS and INSERT INTO

Examples of CTAS queries.

3. Amazon Athena Developer Guide

"CREATE TABLE": This document details the syntax for creating tables

including the CREATE TABLE ... LIKE variant. It shows that LIKE is used to copy metadata only

not data

and its syntax does not include a WHERE clause for data filtering

confirming why Option C is incorrect.

Source: AWS Documentation

Amazon Athena

SQL reference

Data definition language

CREATE TABLE.

The most direct and efficient solution is to use Amazon EventBridge. AWS Step Functions natively emits events to EventBridge whenever an execution's status changes (e.g., SUCCEEDED, FAILED, RUNNING). An EventBridge rule can be configured to specifically filter for these status change events from the target state machine. This rule can then invoke a target, such as an Amazon SNS topic, to send notifications in real time. This approach provides a decoupled, event-driven mechanism for monitoring the entire pipeline's orchestration layer without modifying the pipeline's core logic.

1. AWS Step Functions Developer Guide: The guide explicitly details this pattern. It states

"Amazon EventBridge (previously called Amazon CloudWatch Events) can initiate rules when the status of an execution changes... Step Functions sends events to EventBridge for all state transition and execution status changes."

Source: AWS Step Functions Developer Guide

"Monitoring Step Functions Using EventBridge".

2. Amazon EventBridge User Guide: This guide confirms that Step Functions is a native event source for EventBridge and provides the event pattern for matching execution status. The example for a "Step Functions Execution Status Change" event includes a detail-type and a status field (SUCCEEDED

FAILED

etc.) that can be used in a rule.

Source: Amazon EventBridge User Guide

"Events from AWS services"

section on AWS Step Functions events.

3. AWS CloudTrail User Guide: This document clarifies CloudTrail's purpose: "CloudTrail provides a record of actions taken by a user

role

or an AWS service... CloudTrail is best-suited for audit and compliance use cases." This differentiates it from EventBridge's real-time event-driven purpose.

Source: AWS CloudTrail User Guide

"What Is AWS CloudTrail?".

4. AWS Well-Architected Framework

Serverless Applications Lens: This document promotes using services like EventBridge for inter-service communication and eventing. "Use an event-driven architecture to decouple components... Amazon EventBridge provides a serverless event bus that simplifies building event-driven architectures." This supports the design pattern in option D.

Source: AWS Well-Architected Framework

Serverless Applications Lens (latest version)

"REL 11: How do you design your serverless application to be resilient?".

Amazon S3 Storage Lens automatically collects bucket-level metrics, including “Previous version bytes/objects” and “Incomplete multipart upload bytes/objects.” The managed dashboard surfaces these data without scripting or report generation, satisfying both requirements with minimal operational effort. (AWS, “S3 Storage Lens – Metrics and dimensions,” Table: Incomplete MPU bytes; Previous version bytes).

1. Amazon Web Services. “Amazon S3 Storage Lens metrics and dimensions.” User Guide

Sections: “Previous version bytes

” “Incomplete MPU bytes.” https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-lens-metrics-dimensions.html

2. Amazon Web Services. “Configuring Amazon S3 Inventory.” User Guide

Table: Supported fields (no MPU fields). https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-inventory.html

3. Amazon Web Services. “AWS Billing Reports for Amazon S3.” User Guide

“Usage reports” (storage by class only). https://docs.aws.amazon.com/AmazonS3/latest/userguide/usage-report-bucket.html

4. Amazon Web Services. “S3 CLI Reference – ls

list-multipart-uploads.” Requires manual scripting; no aggregation. https://docs.aws.amazon.com/cli/latest/reference/s3/

AWS Glue can connect to the on-premises Oracle database through a JDBC connection.

When job bookmarks are enabled and a monotonically increasing column (e.g., ID or timestamp) is specified, Glue automatically filters out rows it has already processed and copies only the new rows each run. A single nightly Glue job scheduled after the 1–2 AM warehouse refresh appends the daily increments to the existing S3 objects, giving one managed service, no replication instances, and minimal operational overhead while meeting the BI team’s 10 AM–8 PM SLA.

1. AWS Glue Developer Guide

“Job bookmarks for JDBC sources

” Section: Using Job Bookmarks (2023-11-15)

para. 4 – 5: “…for JDBC data sources a column with strictly increasing values lets AWS Glue copy only new rows on subsequent runs.”

2. AWS Glue Developer Guide

“Connecting to data with JDBC

” Example workflow (2023-11-15)

Step 6: “…schedule the job after upstream refresh to capture daily inserts.”

3. AWS DMS User Guide

“Working with an Oracle source” (2023-09-22)

Section: Prerequisites—requires supplemental logging and a replication instance

increasing operational overhead.

The scenario describes a disk space issue (RootDiskUsed alarm) that occurred after adding a new topic, which implies an increase in data volume. The most direct and standard solution for insufficient storage capacity in Amazon MSK is to increase the size of the EBS storage volumes attached to the brokers. Option A proposes exactly this, along with the best practice of enabling automatic storage expansion. This feature uses CloudWatch alarms to monitor disk usage and proactively increases storage, preventing future alarms and potential service disruptions caused by full disks. This directly addresses the root cause—increased data storage requirements from the new topic.

1. Amazon MSK Developer Guide

Troubleshooting

"Broker out of disk space": This official guide states

"This issue can happen when the traffic to your cluster is higher than what the cluster can handle

or when the storage on the cluster is not enough to hold your messages... To resolve this issue

first try to increase the storage of your cluster." This directly supports increasing broker storage.

2. Amazon MSK Developer Guide

"Amazon MSK storage autoscaling": This document describes the feature for automatically expanding storage. It says

"Amazon MSK storage autoscaling uses Amazon CloudWatch alarms to monitor your brokers' storage utilization. When storage utilization reaches a certain threshold

storage autoscaling automatically initiates a storage increase for your cluster." This validates the second part of option A.

3. Amazon MSK Developer Guide

"Updating broker type and storage": This page clarifies the process for modifying a cluster

distinguishing between updating the broker type (for compute) and updating storage. It details the UpdateBrokerStorage operation

which is the action described in option A.

4. Amazon MSK Developer Guide

"Monitoring an Amazon MSK cluster": This section details the available CloudWatch metrics

including RootDiskUsed and KafkaDataLogsDiskUsed. While the question names RootDiskUsed

the context of adding a new topic points to a data volume issue

for which increasing the data log storage is the correct remedy.