Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company's network security policy requires encryption for all data in transit. The company must encrypt data that is sent between Amazon EC2 instances and Amazon Elastic Blo...
To meet the requirement of encrypting data in transit between Amazon EC2 instances and Amazon EBS volumes, we need to examine what is possible and relevant within AWS.
Key Requirement:
> Encrypt data in transit between EC2 and EBS.
---
Option Analysis:
---
A) Configure Amazon EC2 to enable encryption in the EC2 network interface properties.
❌ Rejected.
Reason: There is no such setting in EC2 network interface properties to enable encryption for data in transit to EBS. EC2 network interfaces (ENIs) can be used to manage networking, but not encryption of data to EBS volumes.
When applicable: Not applicable in this context.
---
B) Configure Amazon EBS to enable volume encryption with AWS Key Management Service (AWS KMS) for data at rest.
❌ Rejected.
Reason: This enables encryption at rest, not in transit. It uses AWS KMS and protects stored data, but does not meet the requirement to encrypt data in transit between EC2 and EBS.
When applicable: Use this for data at rest encryption compliance.
---
C) Configure Amazon EBS to enable TLS encryption in the volume configuration properties.
❌ Rejected.
Reason: There is no such option in Amazon EBS configuration to enable TLS encryption. EBS volumes do not have TLS properties for encryption in transit configurable by the user.
When applicable: Not a valid option; AWS does not offer manual TLS ...
Author: David · Last updated May 23, 2026
A company runs a web application on a fleet of Amazon EC2 instances that are in an Auto Scaling group. The EC2 instances are in the same VPC subnet as other workloads.
A security engineer deploys an Amazon GuardDuty detector in the same AWS Region as the EC2 instances. The security engineer also sets up an AWS Security Hub integration with GuardDuty.
The security engineer needs to implement an automated solution to detect and appropriately respond to anomalous traffic patterns for t...
To determine the best solution, we must align the options with AWS best practices for incident response, minimal disruption, and automated mitigation. Here's a breakdown of the options and key factors in choosing the correct one:
---
✅ Option B:
Create an Amazon EventBridge rule that invokes an AWS Lambda function when GuardDuty detects anomalous traffic. Program the Lambda function to disassociate the identified instance from the Auto Scaling group and to isolate the instance by using a new restricted security group.
Why it's selected:
Automated detection and response using GuardDuty + EventBridge + Lambda.
Follows AWS security incident response best practices:
Isolating the compromised instance (change to restricted security group).
Avoiding disruption to the rest of the application by not changing the entire subnet, Auto Scaling group, or VPC behavior.
Disassociation from Auto Scaling allows analysis without interference from scaling policies.
Minimizes disruption: Removes only the suspicious instance instead of modifying broader infrastructure like subnet NACLs.
---
❌ Option A:
Disable the EC2 instance profile access keys via Lambda.
Why it's rejected:
Only addresses IAM credential compromise, not network behavior or traffic anomalies.
GuardDuty "Behavior\:EC2/TrafficVolumeUnusual" is related to traffic patterns, not access keys mis...
Author: Ishaan · Last updated May 23, 2026
A company has an application that needs to read objects from an Amazon S3 bucket. The company configures an IAM policy and attaches the policy to an IAM role that the application uses. When the application tries to read objects from the S3 bucket, the application receives AccessDenied errors.
A security engineer must...
To resolve the `AccessDenied` errors when an application tries to read from an Amazon S3 bucket without decreasing security, let's analyze the options step by step, focusing on key AWS factors such as IAM policy scope, role assumption, resource policy requirements, region independence, and access control mechanisms.
---
Option A: Attach a resource policy to the S3 bucket to grant read access to the role.
Use case: This is appropriate if the bucket policy is missing or incorrectly configured to allow access to the IAM role.
Strength: Explicitly grants access to a specific IAM role, preserving security boundaries.
Limitation: Might be unnecessary if the IAM policy already grants permission and the issue lies elsewhere (like incorrect role assumption).
Security consideration: Adding resource policies must be done carefully to avoid over-permissioning or accidental public access.
✅ Use this when: The IAM role has proper policies, but S3's bucket policy is blocking access.
---
Option B: Launch a new deployment of the application in a different AWS Region. Attach the role to the application.
Use case: This doesn't address the core access issue. S3 is a global service, but bucket data is region-specific. Changing regions won’t help unless the bucket is replicated.
Limitation: Introducing regional differences adds unnecessary complexity.
Security concern: Unnecessary redeployments could introduce operational and compliance risks.
❌ Reject this – it doesn't solve the permissions issue.
---
Option C: Review the IAM policy by using AWS IAM Access Analyzer to ensure that the policy grants the right permissions. Validate that the application is assuming the role correctly.
...
Author: Sophia Clark · Last updated May 23, 2026
A security engineer is designing a solution that will provide end-to-end encryption between clients and Docker containers running in Amazon Elastic Container Service (Amazon ECS). This solution will also handle vol...
To determine the most scalable and lowest latency solution for end-to-end encryption between clients and ECS containers that also handles volatile traffic patterns, let's evaluate each option:
---
🔹 Option A: Configure a Network Load Balancer (NLB) to terminate the TLS traffic and then re-encrypt the traffic to the containers.
Pros:
NLBs are highly scalable and optimized for volatile traffic patterns (millions of requests per second).
Can handle sudden bursts and very high throughput with low latency.
Cons:
TLS termination at NLB breaks true end-to-end encryption.
Re-encryption adds complexity and potential latency.
Security concern: decrypted data exists temporarily on the load balancer.
> Use case: Suitable if inspection, logging, or WAF needs to occur at the LB layer, but not true E2E encryption.
---
🔹 Option B: Configure an Application Load Balancer (ALB) to terminate the TLS traffic and then re-encrypt the traffic to the containers.
Pros:
ALB supports HTTP/HTTPS and is suitable for application-layer routing.
Termination and re-encryption possible with ALB + service mesh (e.g., App Mesh).
Cons:
Higher latency than NLB due to application-layer processing.
Not as well-suited for volatile or high-volume traffic as NLB.
Still breaks end-to-end encryption unless a custom re-encryption system is in place.
> Use case: Good for HTTP routing and session-based applications, but not ideal for TLS passthrough or low-latency needs.
---
🔹 Option C: Configure a Network Load Balancer with a TCP listener to pass through TLS traffic to the containers.
Pros:
True end-to-end encryption: TLS is terminated in...
Author: Aditya · Last updated May 23, 2026
A company has a large fleet of Amazon Linux 2 Amazon EC2 instances that run an application. The application processes sensitive data and has the following compliance requirements:
* No remote access management ports to the EC2 instances can be exposed internally or externally.
* All remote session activity must be recorded in an audit log.
* All remote access to the EC2 instances must be authenticated and authorized by AWS IAM Identity Center.
The company's ...
To determine the correct solution, let's break down the compliance requirements and analyze each option based on how well it meets them.
---
Compliance Requirements:
1. No remote access management ports (e.g., SSH/RDP) can be exposed internally or externally.
2. All remote session activity must be recorded in an audit log.
3. All remote access must be authenticated and authorized by AWS IAM Identity Center.
---
Option Analysis:
---
A) EC2 Serial Console with IAM Policy
Pros:
EC2 Serial Console access can be controlled via IAM.
No need to open SSH or RDP ports.
Cons:
The serial console provides low-level access (e.g., kernel boot issues), not standard shell access.
Limited to Nitro-based instances and certain troubleshooting scenarios, not ideal for general DevOps tasks.
Does not integrate with IAM Identity Center for authentication/authorization.
Audit logging is limited compared to Systems Manager Session Manager.
> ✅ Use case: Deep kernel-level or boot troubleshooting, not standard remote access.
---
B) EC2 Instance Connect with Security Group and Console Access
Pros:
Provides browser-based SSH access without exposing permanent SSH keys.
Cons:
Requires port 22 (SSH) to be open, at least to internal IPs, which violates the “no remote access port” requirement.
IAM policies can grant access, but does not natively support IAM Identity Center authorization.
No built-in session recording or logging unles...
Author: ShadowWolf101 · Last updated May 23, 2026
A data engineer uses Amazon Kinesis Data Streams to ingest and process records that contain user behavior data from an application every day.
The data engineer notices that the data stream is experiencing throttling because hot shards receive much ...
To resolve the throttling issue in Amazon Kinesis Data Streams due to hot shards, we must understand the cause: records are unevenly distributed among shards, meaning some shards are overloaded while others are underutilized. This results in throttling errors like `ProvisionedThroughputExceededException`.
---
Option A: Use a random partition key to distribute the ingested records.
✅ This is a strong option.
Why it's effective: Kinesis uses the partition key (hashed using MD5) to determine which shard a record goes to. If the same key is reused (e.g., user ID), it can send many records to a single shard, creating a hot shard. Using a random partition key helps evenly distribute records across all shards, reducing throttling.
Best used when: The application can tolerate random partitioning and doesn’t need records to be grouped by key for ordering or session state.
Limitation: If downstream consumers rely on ordered records by key (e.g., all actions by a user), this could break that logic.
---
Option B: Increase the number of shards in the data stream. Distribute the records across the shards.
✅ Also a good option, especially in combination with Option A.
Why it can help: Adding more shards increases capacity, allowing more records to be ingested per second.
However: Simply increasing shards without ensuring even record distribution (e.g., if partition key logic isn’t fixed) can still result in hot shards.
Best used when:...
Author: Sofia · Last updated May 21, 2026
A company has a data processing pipeline that includes several dozen steps. The data processing pipeline needs to send alerts in real time when a step fails or succeeds. The data processing pipeline uses a combination of Amazon S3 buckets, AWS Lambda functions, and AWS Step Functions state machine...
To determine the best option for real-time alerting in a data processing pipeline using Amazon S3, AWS Lambda, and AWS Step Functions, we must consider real-time responsiveness, integration capabilities, reliability, and appropriate service usage.
---
Option Analysis
---
A) Configure the Step Functions state machines to store notifications in an Amazon S3 bucket when the state machines finish running. Enable S3 event notifications on the S3 bucket.
Why reject it:
S3 is not optimized for real-time alerting; it introduces latency.
S3 event notifications only trigger on object operations (e.g., PUT), not specifically tied to state machine outcomes.
It adds unnecessary complexity and delay to the notification flow.
When it could be used:
For logging or archiving results, not real-time alerting.
---
B) Configure the AWS Lambda functions to store notifications in an Amazon S3 bucket when the state machines finish running. Enable S3 event notifications on the S3 bucket.
Why reject it:
Similar issues as (A) — delayed notifications via S3.
Adds more overhead by involving Lambda to generate and store notifications unnecessarily.
Still relies on S3 event triggers, which aren't purpose-built for status change notifications.
When it could be used:
Suitable if you want to retain a log of...
Author: VioletCheetah55 · Last updated May 21, 2026
A company has an application that uses an Amazon API Gateway REST API and an AWS Lambda function to retrieve data from an Amazon DynamoDB instance. Users recently reported intermittent high latency in the application's response times. A data engineer finds that the Lambda function experiences frequent throttling when the company's other Lambda functions experience increased invocations.
The com...
To determine the most cost-effective solution that ensures one Lambda function is not impacted by the load of other Lambda functions, let's analyze each option:
---
❌ A) Increase the number of read capacity units (RCU) in DynamoDB
Why it's rejected:
Key factor: The issue is Lambda throttling, not DynamoDB read performance.
Increasing RCU would help if the bottleneck was DynamoDB read throughput (e.g., `ProvisionedThroughputExceededException`), but that is not the case here.
It doesn’t prevent Lambda function throttling due to concurrency limits or resource contention.
When to use:
Use this option if DynamoDB read requests are throttled (CloudWatch metrics: `ReadThrottleEvents`).
---
✅ B) Configure provisioned concurrency for the Lambda function
Why it’s not selected (even though it can help):
Provisioned concurrency keeps a set number of Lambda instances initialized and ready to serve requests.
It helps reduce cold starts and latency, but does not isolate concurrency from other functions or prevent throttling due to overall account concurrency limits.
When to use:
Use this when the concern is cold start latency and you want consistent performance.
Drawback:
More expensive than reserved concurrency ...
Author: Aria · Last updated May 21, 2026
A company has as JSON file that contains personally identifiable information (PII) data and non-PII data. The company needs to make the data available for querying and analysis.
The non-PII data must be available to everyone in the company. The PII data must be available on...
To determine the best solution with the least operational overhead, let's analyze each option carefully using the key factors:
Key Factors to Consider
Operational Overhead: Effort required to implement and maintain the solution.
Data Access Control: Fine-grained access control over PII vs non-PII.
Scalability: Ability to scale as data or users grow.
Automation & Governance: Ability to manage data cataloging, classification, and permissioning centrally.
Cost-efficiency: Avoiding unnecessary services or duplication of data.
---
Option A: S3 + AWS Glue to split PII and non-PII, separate buckets with IAM access
Pros:
Clear separation of data (PII vs non-PII).
S3 is scalable and cost-effective.
Cons:
Requires custom ETL logic in Glue to split the data.
Maintaining and updating the splitting logic increases operational overhead.
Managing separate buckets and ensuring data consistency between them adds complexity.
> Use Case Fit: Suitable if manual control of data partitioning is acceptable and custom transformation logic is required. But not ideal for low operational overhead.
---
Option B: S3 + Amazon Macie to identify PII and manage access
Pros:
Macie automatically detects PII data.
Cons:
Macie is primarily a PII discovery tool, not a data access control or enforcement tool.
Does not grant or restrict access directly — you'd still need to set up policies manually.
High cost and unnecessary if access control is the primary need.
> Use Case Fit: Best fo...
Author: Jack · Last updated May 21, 2026
A company uses AWS Key Management Service (AWS KMS) to encrypt an Amazon Redshift cluster. The company wants to configure a cross-Region snapshot of the Redshift cluster as part of disaster recovery (DR) strategy.
A data engineer needs to use the AWS CLI...
To determine the correct combination of steps for setting up cross-Region snapshot copying for an Amazon Redshift cluster encrypted with AWS Key Management Service (KMS), we need to focus on how snapshot encryption and cross-Region snapshot copy work in Redshift.
---
Key Concepts to Consider:
Redshift automated/manual snapshots can be automatically copied across Regions for DR purposes.
If KMS encryption is used, Redshift must be granted permission to use a KMS key in the destination Region for encrypting the copied snapshot.
This is done using a snapshot copy grant, which is created in the source Region to refer to the destination Region's KMS key.
Multi-AZ is not supported in Redshift; it's only available in services like RDS, so such options are invalid.
---
Option Analysis:
✅ A) Create a KMS key and configure a snapshot copy grant in the source AWS Region.
✅ Valid.
You must create a snapshot copy grant in the source Region, even though the KMS key it refers to is in the destination Region.
This grant allows Redshift to encrypt snapshots during the copy process using the KMS key in the destination Region.
Key factor: Snapshot copy grants are created in the source Region.
❌ B) In the source AWS Region, enable snapshot copying. Specify the name of the snapshot copy grant...
Author: Ethan · Last updated May 21, 2026
A company is using Amazon S3 to build a data lake. The company needs to replicate records from multiple source databases into Apache Parquet format.
Most of the source databases are hosted on Amazon RDS. However, one source database is an on-premises Microsoft SQL Server Enterprise instance. The company needs to implement a solution to replicate existi...
To determine the most cost-effective and technically appropriate solution for replicating existing data and future changes from both Amazon RDS and an on-premises Microsoft SQL Server to Amazon S3 in Parquet format, let’s evaluate each option against the key factors:
---
✅ Key Requirements
1. Replicate existing data and future changes
2. Source: Amazon RDS and on-premises SQL Server
3. Target: Amazon S3 in Apache Parquet format
4. Solution must be cost-effective
5. Should work with heterogeneous sources
6. Should support ongoing replication (CDC)
---
Option A) Use one AWS Glue job to replicate existing data. Use a second AWS Glue job to replicate future changes.
❌ AWS Glue is great for ETL and transformation, but:
It does not natively support CDC (Change Data Capture).
Glue jobs are batch-oriented and not designed for near-real-time replication.
Connecting to on-premises SQL Server adds network and security complexity.
Would require custom polling logic to track changes — increases cost and complexity.
✅ Works for batch ETL of existing data, but not for future changes efficiently.
> ✅ Use case: One-time bulk ETL tasks, or periodic data loads where latency is acceptable.
---
Option B) Use AWS Database Migration Service (AWS DMS) to replicate existing data. Use AWS Glue jobs to replicate future changes.
❌ AWS DMS is designed for both full load and CDC.
Using it only for existing data underutilizes its full capability.
❌ Future changes using AWS Glue (as above) suffer from the same issues — no native CDC, not designed for streaming changes.
❌ Adds operational overhead and cost by splitting logic between two services.
> ✅ Use case: Transitional architectures where you phase in CDC later using another tool — but not cost-effective long-term.
---
✅ Option C) Use AWS Database Migration Service (AWS DMS) to replicate existing data and future changes.
✅ DMS is specifically ...
Author: Kunal · Last updated May 21, 2026
A data engineer needs to optimize the performance of a data pipeline that handles retail orders. Data about the orders is ingested daily into an Amazon S3 bucket.
The data engineer runs queries once each week to extract metrics from the orders data based the order date for multiple date ranges. The data engineer needs an optimization solution tha...
To determine the most cost-effective and scalable solution for optimizing query performance on a growing dataset of retail orders ingested daily into Amazon S3, we need to evaluate each option on several key factors:
---
🔑 Key Factors to Consider:
Query pattern: Weekly queries based on order date ranges.
Data ingestion location: Amazon S3.
Scalability & performance: Must maintain good performance as data volume grows.
Cost-effectiveness: Must be optimized for cost.
Partitioning strategy: Must match query patterns (i.e., order date).
---
✅ Option A: Partition the data based on order date. Use Amazon Athena to query the data.
Why it's suitable:
Athena is serverless and cost-effective (pay-per-query).
Partitioning by order date aligns directly with query patterns, improving performance and reducing scanned data.
Supports direct querying of data in S3 (no data movement).
Scales automatically with data volume.
Best Use Case: Ad hoc analytics or scheduled queries on large datasets stored in S3, especially when you don’t want to manage infrastructure.
✅ Meets all requirements effectively and cost-efficiently.
---
❌ Option B: Partition the data based on order date. Use Amazon Redshift to query the data.
Why it's less suitable:
Redshift is a data warehouse and may require ETL to ingest data from S3, adding complexity and cost.
Although it performs well...
Author: Ming · Last updated May 21, 2026
A data engineer has two datasets that contain sales information for multiple cities and states. One dataset is named reference, and the other dataset is named primary.
The data engineer needs a solution to determine whether a specific set of values in the city and state columns of the primary dataset exactly match the same specific values in the reference datas...
Let's carefully analyze the problem and the options provided:
---
Problem Recap:
Two datasets: primary and reference.
Columns: `city` and `state` in both datasets (reference columns named `ref_city`, `ref_state`).
Need to check if a specific set of values in primary’s city and state exactly match the same values in reference.
Want to use Data Quality Definition Language (DQDL) rules in an AWS Glue Data Quality job.
Check if the city-state pairs in primary are exactly present in reference.
---
Key concepts:
DatasetMatch rule: Compares entire datasets or subset of columns between two datasets for similarity/match ratio. Useful for row-level or full dataset similarity checks.
ReferentialIntegrity rule: Validates that foreign keys in one dataset (primary) exist in the referenced dataset (reference), i.e., for each (city,state) in primary, the same pair exists in reference. This is a typical referential integrity check.
The value `1.0` or `100` indicates the threshold for the rule to be considered passing — meaning 100% matches.
---
Now, let's analyze each option:
---
Option A:
`DatasetMatch "reference" "city->ref_city, state->ref_state" = 1.0`
Checks if the primary dataset matches the reference dataset in city and state columns with a similarity threshold of 1.0 (100%).
Problem: DatasetMatch compares the whole datasets; it’s not designed for referential integrity checks (checking existence of values from primary in reference).
The syntax seems off (the value 1.0 vs 100), and it's ambiguous if the percentage is properly interpreted.
When to use: Checking if datasets are identical in specific columns.
Why rejected: We want to check if city-state pairs from primary exist in reference, not that the entire datasets match exactly. DatasetMatch is not ideal here.
---
Option B:
`ReferentialIntegrity "city,state" "reference.{ref_city,ref_state}" = 1.0`
ReferentialIntegrity rule that checks if every (city,state) pair in primary dataset exists in reference dataset's (ref\_city...
Author: FlamePhoenix2025 · Last updated May 21, 2026
A company has an on-premises PostgreSQL database that contains customer data. The company wants to migrate the customer data to an Amazon Redshift data warehouse. The company has established a VPN connection between the on-premises database and AWS.
The on-premises database is continuously updated. The co...
To determine the best solution for migrating continuously updated data from an on-premises PostgreSQL database to Amazon Redshift, we must evaluate each option based on data freshness, latency, automation, and ongoing sync support.
---
✅ Option B) Create an AWS Database Migration Service (AWS DMS) full-load task. Set Amazon Redshift as the target. Configure the task to use the change data capture (CDC) feature.
Why it's selected:
Key Feature: Change Data Capture (CDC): Allows near real-time replication of changes from PostgreSQL to Redshift.
Low latency: Changes are replicated continuously after initial full load.
Automation: Fully managed and integrated with AWS services.
Supports continuous synchronization: Ideal for scenarios where the source database is frequently updated.
Recommended use case: For near real-time replication and minimum lag between source and target systems.
---
❌ Option A) Use pg\_dump + AWS SCT + nightly cron job
Why it’s rejected:
Batch-based, not real-time: `pg_dump` is a snapshot-based tool; it doesn’t support incremental or continuous sync.
Latency: Updates happen only nightly—doesn't meet the "as quickly as possible" requirement.
Operational complexity: Requires scheduling, scripting, and manual setup.
Recommended use case: One-time migrations or nightly reporting with tolerance for stale data.
---
❌ Option C) pg\_dump + S3 + C...
Author: Emma · Last updated May 21, 2026
A company has several new datasets in CSV and JSON formats. A data engineer needs to make the data available to a team of data analysts who will analyze the data by using SQL queries....
Let's break down each option with key factors: cost-effectiveness, ease of SQL querying, data format support, and analyst accessibility.
---
Option A: Create an Amazon RDS MySQL cluster, use AWS Glue to transform and load CSV/JSON into tables, and provide access.
Pros:
Structured, relational database allows efficient SQL queries.
Supports complex joins and indexing for faster queries.
Cons:
High operational cost: managing RDS instances (compute, storage, backups).
Requires ETL process (AWS Glue) to transform and load data into RDS, adding complexity and cost.
Less flexible with semi-structured JSON data; often requires flattening or schema design.
When to use:
When data requires frequent transactional updates or complex relational integrity.
When analysts need very low-latency querying on a relational DB.
Why rejected:
Not the most cost-effective for new datasets stored as CSV/JSON in S3.
Setup and maintenance overhead are significant compared to serverless querying options.
---
Option B: Create an AWS Glue DataBrew project and share with analysts.
Pros:
Great for data cleaning, profiling, and transformation without coding.
Provides a UI for data wrangling.
Cons:
Not primarily a SQL query engine — analysts cannot run arbitrary SQL queries easily.
Licensing and usage costs can grow with scale.
Meant for data preparation, not for direct querying and analysis.
When to use:
When analysts or data engineers need to clean and prepare data interactively before analysis.
Why rejected:
Does not fulfill the requirement for analysts to analyze data by using SQL queries.
Not cost-effective as a direct query platform.
---
Option C: Store data in S3, use AWS Glue crawler to catalog data as tables, and query with Amazon Athena.
Pros:
Serverless and pay-per-query → very cost-effective.
Supports querying CSV and JSON natively via Athena using SQL.
Glue crawler automatically discovers schema, so no manual...
Author: Sofia2021 · Last updated May 21, 2026
A retail company stores order information in an Amazon Aurora table named Orders. The company needs to create operational reports from the Orders table with minimal latency. The Orders table contains billions of rows, and over 100,000 transactions can occur each second.
A marketing team needs to join the Orders data with an Amazon Redshift table named Campaigns in the marke...
Let's analyze the scenario and each option carefully.
---
Scenario Summary:
Source: Amazon Aurora with billions of rows, high transaction volume (>100,000 TPS).
Target: Amazon Redshift (marketing data warehouse).
Goal:
Create operational reports from the Orders table with minimal latency.
Marketing team wants to join Orders data with Campaigns in Redshift.
Operational Aurora database must not be affected by reporting workloads.
Least operational effort is desired.
---
Key Factors for decision:
1. Latency & freshness: Operational reports require near real-time or low latency data access.
2. High transaction throughput: >100,000 transactions per second means heavy load on Aurora.
3. Minimal impact on Aurora: Reporting must not degrade OLTP performance.
4. Ease of setup and maintenance: Minimize operational effort.
5. Data volume: Billions of rows, so solutions need to be scalable.
---
Option Analysis:
A) Use AWS DMS Serverless to replicate Orders to Redshift + materialized view in Redshift
Pros:
DMS is designed for continuous replication with minimal lag.
Serverless DMS reduces operational overhead (no infrastructure to manage).
Data is replicated asynchronously, so Aurora OLTP workload is not impacted.
Once data is in Redshift, creating materialized views is straightforward.
Cons:
Some latency is introduced due to replication (usually seconds or more).
DMS is not designed for ultra-low latency real-time reporting but is quite efficient.
Use case: Near real-time reporting with minimal Aurora impact and moderate operational effort.
B) Use Aurora zero-ETL integration with Redshift + materialized view in Redshift
Pros:
Zero-ETL is a new Aurora feature to directly replicate changes to Redshift with minimal latency.
No manual ETL or replication infrastructure to maintain.
Very low latency replication.
Minimal operational effort.
Cons:
Currently, zero-ETL integration may have limitations on scale or availability depending on A...
Author: Aarav · Last updated May 21, 2026
A data engineer is using an AWS Glue ETL job to remove outdated customer records from a table that contains customer account information. The data engineer is using the following SQL command to remove customers that exist in a table named monthly_accounts_update table from the customer accounts table:
MERGE INTO accounts t USING monthly_a...
Let's analyze the SQL command and how it behaves in the context of AWS Glue ETL jobs, particularly focusing on support for the MERGE statement.
---
SQL Command (from the question):
```sql
MERGE INTO accounts t
USING monthly_accounts_update s
ON t.customer = s.customer
WHEN MATCHED THEN DELETE
```
The logic here is:
If a customer exists in both `accounts` and `monthly_accounts_update`, delete it from `accounts`.
---
Key Considerations:
1. MERGE statement support in AWS Glue:
As of AWS Glue 3.0+ with Apache Spark and Spark SQL, MERGE INTO is supported only on tables stored in Apache Hudi, Iceberg, or Delta Lake format.
It is not supported for traditional Glue tables stored in formats like plain Parquet or CSV in S3 (i.e., non-transactional formats).
Also, some syntax errors in the question (like `=3D` instead of `=`, and hyphens `-` where line breaks are intended) might break execution unless cleaned up.
2. MERGE INTO ... WHEN MATCHED THEN DELETE is valid SQL (Spark 3+) — if used on supported table formats.
But the question does not specify if `accounts` is stored in Hudi/Iceberg/Delta — so we must assume it's a typical Glue table (e.g., backed by S3 in Parquet or similar), which does not support such operations natively.
---
Option Analysis:
---
A) All customer records that exist in both the customer accounts table and the monthly\_accounts\_update table will be deleted from the accounts table.
This would be true if the `MERGE INTO ... DELETE` operation is supported and the data source format allows it.
But in standard AWS Glue tables, `MERGE` is not valid unless using supported formats (Hudi, Iceberg, De...
Author: Oliver · Last updated May 21, 2026
A company builds a new data pipeline to process data for business intelligence reports. Users have noticed that data is missing from the reports.
A data engineer needs to add a data quality check for columns that contain null values and for referential integrity at a stage ...
Let's analyze each option carefully considering the requirements:
Requirements:
Add data quality checks for null values in columns.
Add referential integrity checks (i.e., foreign key constraints or matching references).
Checks must happen before data is stored.
Solution should have least operational overhead (easy to maintain, automated, minimal custom coding).
---
Option A) Use Amazon SageMaker Data Wrangler to create a Data Quality and Insights report.
Pros: Data Wrangler is good for data exploration, profiling, and creating reports.
Cons: It's primarily a manual or semi-automated tool designed for data scientists to profile and transform data interactively. It’s not optimized for automated, continuous validation in a production pipeline before storage. Operational overhead can be high because it may require manual intervention or custom automation workflows.
Use case: Best for exploratory data analysis and data profiling in a manual or semi-automated setting, less ideal for automated production quality checks.
---
Option B) Use AWS Glue ETL jobs to perform a data quality evaluation transform on the data. Use an IsComplete rule on the requested columns. Use a ReferentialIntegrity rule for each join.
Pros: Glue Data Quality feature supports built-in rules like `IsComplete` (for null checks) and `ReferentialIntegrity` (for foreign key validation). These are declarative, easy to implement, and designed specifically for data quality validation in Glue pipelines.
This allows automated, repeatable quality checks inside ETL jobs before storing data.
Low operational overhead because Glue manages the execution, scaling, and monitoring.
Use case: Best for automated production-grade ...
Author: Noah Williams · Last updated May 21, 2026
A company is setting up a data pipeline in AWS. The pipeline extracts client data from Amazon S3 buckets, performs quality checks, and transforms the data. The pipeline stores the processed data in a relational database. The company will use th...
Let's analyze each option based on the requirements and key factors:
Requirements Recap:
Extract client data from S3 buckets.
Perform quality checks.
Transform data.
Store processed data in a relational database (for future queries).
Be cost-effective.
---
Option A:
AWS Glue ETL for extraction and transformations.
AWS Glue Data Quality for quality checks.
Store processed data and quality check results in Amazon RDS for MySQL.
Pros:
AWS Glue ETL is a fully managed, serverless ETL service that integrates well with S3 and RDS.
Glue Data Quality can enforce data quality rules natively in the ETL pipeline.
Storing both processed data and quality results in RDS centralizes data for querying.
Cons:
Glue Data Quality is a newer service; it may incur additional costs.
Storing quality check results in RDS might increase database storage and management overhead, possibly increasing costs.
Use Case: Good when tight integration between ETL and data quality is needed, and you want all results in a relational DB for easy querying.
---
Option B:
AWS Glue Studio for extraction.
AWS Glue DataBrew for transformations and quality checks.
Load processed data into RDS, quality check results into S3.
Pros:
Glue Studio provides visual ETL development with ease.
DataBrew specializes in visual data prep, transformations, and quality checks with low-code/no-code.
Separating quality check results into S3 can save RDS storage costs.
This can be cost-effective if quality check results are large or less frequently queried.
Cons:
Using two separate tools (Glue Studio and DataBrew) adds complexity.
DataBrew can be more expensive for large-scale processing compared to Glue ETL.
Having quality data separate might complicate combined analysis.
Use Case: When you want easy, visual data prep with separation of data and quality logs, especially if quality logs are large or accessed separately.
---
Option C:
AWS Glue ETL for extraction and transformations.
AWS Glue DataBrew for quality checks.
Load processed data and quality check results into S3.
Pros:
Fully serverless, managed, and decoupled solution.
Cost-effective since S3 storage is cheaper than RDS.
Good for large datasets or when relational querying is not immediately needed.
Cons:
Does not meet the requirement of storing processed data in a relational database for future queries.
Querying data in S3 may require Athena or Redshift Spectrum, adding complexity an...
Author: IronLion88 · Last updated May 21, 2026
A company uses Amazon Redshift as a data warehouse solution. One of the datasets that the company stores in Amazon Redshift contains data for a vendor.
Recently, the vendor asked the company to transfer the vendor's data ...
Let's analyze each option based on the key factors:
Requirement Recap:
Data is stored in Amazon Redshift.
Vendor wants their dataset exported weekly to their Amazon S3 bucket.
The solution should transfer data from Redshift to S3 on a schedule.
---
Option A: AWS Lambda with Redshift COPY command
COPY command in Redshift is used to load data from S3 into Redshift, not to export data out.
Lambda can run scheduled tasks, but COPY is the wrong command for export.
This option is invalid because COPY is for ingestion into Redshift, not export.
Conclusion: Reject because COPY cannot export data to S3.
---
Option B: AWS Glue job using Redshift UNLOAD command
The UNLOAD command is specifically designed to export data from Redshift to S3.
AWS Glue can be scheduled, can connect to Redshift, and run the UNLOAD command on a schedule.
This is a fully managed ETL solution that can handle transforming and exporting data.
Fits the requirement perfectly: scheduled export from Redshift to vendor's S3 bucket.
Conclusion: Suitable and meets the requirement directly.
---
Option C: Amazon Redshift Data Sharing with S3 bucke...
Author: Ryan · Last updated May 21, 2026
A company uses an Amazon Redshift cluster as a data warehouse that is shared across two departments. To comply with a security policy, each department must have unique access permissions.
Department A must have access to tables and views for Department A. Department B must have access to tables and views for Department B.
The company often ru...
Let's analyze each option against the requirements and key factors:
---
Requirements Recap:
Two departments (A and B) share the Redshift cluster.
Each department must have unique access permissions to their own tables and views.
Queries often access objects from both departments simultaneously.
The solution must have least operational overhead.
Permissions must be manageable and enforce separation.
---
Option A: Group tables and views into dedicated schemas per department and manage permissions at schema level
Pros:
Schemas in Redshift are designed for logical grouping and access control.
Permissions can be granted or revoked easily on a per-schema basis.
Allows users to access objects across multiple schemas in a single query without switching databases.
Least overhead as you manage permissions once per schema.
Cons:
Requires creating and maintaining schemas, but this is lightweight and standard practice.
Fits well when:
You want department-level logical separation.
Queries need to join or access data from both departments in one query.
Operational simplicity in permission management is key.
---
Option B: Group tables and views into dedicated databases per department and manage permissions at database level
Pros:
Strong isolation between departments at database level.
Cons:
Redshift does not support cross-database queries natively (unlike some other databases).
Users cannot easily run queries joining objects from both departments if they are in separate databases.
Operational overhead is high because managing multiple databases is more complex.
Fits well when:
Departments require strict physical separation and no cross-access is needed.
No cross-database queries ...
Author: FlamePhoenix2025 · Last updated May 21, 2026
A company wants to ingest streaming data into an Amazon Redshift data warehouse from an Amazon Managed Streaming for Apache Kafka (Amazon MSK) cluster. A data engineer needs to develop a solution that provides low data access time and that opt...
Let's analyze each option based on low data access latency, optimized storage costs, and least operational overhead for streaming data ingestion from Amazon MSK to Amazon Redshift:
---
Option A:
Create an external schema that maps to the MSK cluster. Create a materialized view referencing the external schema to consume streaming data from MSK topic.
Feasibility:
Redshift external schemas typically map to data catalogs like AWS Glue for querying external data in S3 via Redshift Spectrum, or to federated query sources via Redshift Federated Query.
There is no direct external schema mapping to an MSK cluster. Redshift cannot directly query Kafka topics via external schema.
Operational overhead:
Complex or unsupported, likely not possible natively.
Latency and storage:
Even if somehow possible, materialized views require refreshes which can add latency.
Conclusion:
Rejected due to lack of direct support for MSK as an external schema source and likely high complexity.
---
Option B:
Develop an AWS Glue streaming ETL job to process incoming data from MSK, load into Amazon S3, then use Redshift Spectrum to read data from S3.
Feasibility:
Glue Streaming ETL supports consuming from MSK and writing to S3 in near real-time.
Redshift Spectrum allows querying data directly from S3 without loading it into Redshift tables.
Latency:
Near real-time ingestion, but some delay due to Glue streaming and S3 eventual consistency.
Query latency depends on the size and format of data in S3.
Storage optimization:
Data stored in cost-effective S3.
No need to load all data into Redshift storage, saving storage costs.
Operational overhead:
Glue manages scaling and streaming, reducing overhead.
No manual ingestion pipelines needed.
Conclusion:
Meets low data access time (near real-time), cost-optimized storage (S3), and least...
Author: Elijah · Last updated May 21, 2026
A sales company uses AWS Glue ETL to collect, process, and ingest data into an Amazon S3 bucket. The AWS Glue pipeline creates a new file in the S3 bucket every hour. File sizes vary from 200 KB to 300 KB. The company wants to build a sales prediction model by using data from the previous 5 years. The historic data includes 44,000 files.
The company builds a second AWS Glue ETL pipeline by using the smallest worker type. The second pipeline retrieves the historic files from the S3 bucket and processes the files for downstream ...
Let's analyze the problem and each option carefully.
---
Problem summary:
A sales company runs an AWS Glue ETL pipeline creating small files (\~200-300 KB) every hour.
The historical dataset includes 44,000 small files over 5 years.
The second AWS Glue ETL pipeline uses the smallest worker type to process these many small files.
The second pipeline faces significant performance issues.
The company wants to improve performance in a cost-effective manner.
---
Key factors:
Small files: 200-300 KB is quite small, which leads to overhead in processing many small files.
Large number of files: 44,000 files is a lot of individual files to process.
Worker type currently smallest, which may not be powerful enough.
Cost-effectiveness is important.
The performance bottleneck is probably due to overhead in managing too many small files, or under-provisioned compute resources.
---
Evaluation of options:
---
A) Use a larger worker type.
Larger worker types provide more compute power per worker.
This can improve performance per worker because bigger workers have more CPU and memory.
However, larger worker types cost more per hour.
Given that many small files incur overhead, the bottleneck might not just be raw compute power but inefficient processing of many small files.
Using a larger worker type might improve speed but may not be the most cost-effective since cost scales up quickly.
This is a straightforward solution, but not necessarily the most cost-effective.
Use case: When CPU or memory is clearly a bottleneck and processing each file is CPU-intensive.
---
B) Increase the number of workers in the AWS Glue ETL jobs.
Adding more workers horizontally scales the job.
More workers allow more parallel processing of files, especially helpful when you have many small files.
With more parallelism, many small files can be processed simultaneously.
This can greatly improve performance.
Cost increases with more workers but this is linear and can be optimized by balancing number of workers vs job duration.
Using many smaller workers (instead of a few large ones) is often more cost-effective for many small tasks.
This option addresses the "many small files" problem by increasing parallelism.
Use case: When workload is embarrassingly parallel (e.g., many independent files), increasing worker count scales horizontally and improves throughput.
---
C) Use the AWS Glue DynamicFrame grouping option.
...
Author: Noah · Last updated May 21, 2026
A company wants to combine data from multiple software as a service (SaaS) applications for analysis.
A data engineering team needs to use Amazon QuickSight to perform the analysis and build dashboards. A data engineer needs to extract the data from the SaaS applications and make the d...
Let's analyze the options to determine the most operationally efficient solution for extracting data from multiple SaaS apps for use in Amazon QuickSight.
---
Key Factors to Consider:
Operational efficiency: Minimal manual intervention, automation, scalability.
Integration with SaaS: Native connectors or easy API integration.
Data cataloging & querying: Make data easily queryable by QuickSight.
Maintenance overhead: Lower is better.
Scheduling & automation: Ability to keep data updated without manual work.
---
Option A: AWS Lambda functions to call SaaS APIs → S3 → Glue catalog → QuickSight
Pros: Full control over data extraction logic. Glue catalog enables schema and querying.
Cons: Requires building and maintaining Lambda code for each SaaS API integration (complex and time-consuming). Handling API changes, pagination, error handling adds operational overhead. Less scalable for many SaaS apps.
Use case: When SaaS APIs are custom or no native connectors exist; teams want complete control and customization.
---
Option B: AWS Lambda federated Athena queries against SaaS APIs → Athena → QuickSight
Pros: Query SaaS data in place without ETL. Federated query is powerful for real-time access.
Cons: Setting up and maintaining federated query Lambda connectors is complex. Performance depends on APIs, and high query latency can degrade QuickSight experience. Operational overhead to keep connectors updated.
Use case: When near real-time access is critica...
Author: Aarav · Last updated May 21, 2026
A company runs multiple applications on AWS. The company configured each application to output logs. The company wants to query and visualize the application lo...
Let's analyze each option carefully based on the requirements:
Requirements Recap:
Multiple applications running on AWS output logs.
The company wants to query and visualize the application logs in near real-time.
---
Option A:
Configure apps to output logs to CloudWatch Logs. Export logs on a schedule (via Lambda) to S3. Use Athena to query logs in S3.
Pros: Athena is great for querying large volumes of data stored in S3 using SQL.
Cons: Exporting logs from CloudWatch Logs to S3 via Lambda runs on a schedule, meaning this is not near real-time. There will be a delay between logs generated and when they appear in S3 and can be queried.
Use case scenario: Good for historical or batch analytics on logs, not real-time or near real-time visualization.
---
Option B:
Create Amazon OpenSearch Service domain. Stream logs from CloudWatch Logs via subscription filters to OpenSearch. Use OpenSearch queries and dashboards.
Pros: OpenSearch supports near real-time ingestion and querying of log data. Subscription filters enable streaming logs directly as they are generated. Visualization can be done via Kibana dashboards.
Cons: Requires managing an OpenSearch cluster, but this is a common and powerful solution for log analytics.
Use case scenario: Ideal for near real-time log analytics and visualization at scale.
---
Option C:
Output logs to CloudWatch Logs. Use CloudWatch Logs Anomaly Detection to qu...
Author: Zara · Last updated May 21, 2026
An ecommerce company processes millions of orders each day. The company uses AWS Glue ETL to collect data from multiple sources, clean the data, and store the data in an Amazon S3 bucket in CSV format by using the S3 Standard storage class. The company uses the stored data to conduct daily ...
Let's analyze each option carefully with key factors such as cost optimization for storage and retrieval, data access patterns, and suitability for daily analysis.
---
A) Transition the data to Amazon S3 Glacier Flexible Retrieval
Pros:
Glacier Flexible Retrieval (formerly Glacier) is very cost-effective for long-term archival storage.
Low storage cost compared to S3 Standard.
Cons:
Glacier retrieval times range from minutes to hours, not suitable for frequent or daily data access.
Since the company uses the data for daily analysis, Glacier's slow retrieval and higher retrieval costs make it a poor fit.
Scenario suitable for:
Archival data that is rarely accessed and does not require immediate retrieval.
Conclusion: Not ideal due to frequent daily access requirement.
---
B) Transition the data from Amazon S3 to an Amazon Aurora cluster
Pros:
Aurora is a relational database optimized for OLTP and complex queries.
Can speed up analytics if you need low-latency queries on structured data.
Cons:
Storing large volumes of raw data (millions of orders daily) in Aurora is costly and not typical for raw data storage.
Aurora is more expensive than S3 for storage and doesn't optimize storage costs.
Data ingestion and schema management can become complex at scale.
Scenario suitable for:
When the data needs to be accessed with relational queries frequently and requires transactional consistency.
Conclusion: Not cost-effective or scalable for raw data storage and simple analytics where large raw data is stored in S3.
---
C) Configure AWS Glue ETL to transform the incoming data to Apache Parquet format
Pros:
Parquet is a columnar storage format that significantly reduces storage size compared to CSV (better compression).
Parquet enables faster query performance and lower data scan costs during analysis, especially with tools like Athena or Redshift Spectrum....
Author: NebulaEagle11 · Last updated May 21, 2026
A data engineer is optimizing query performance in Amazon Athena notebooks that use Apache Spark to analyze large datasets that are stored in Amazon S3. The data is partitioned.
An AWS Glue crawler updates the partitions.
The data engineer wants to minimize the amo...
Let's analyze each option carefully in the context of optimizing query performance in Athena when querying partitioned data stored in S3, with an AWS Glue crawler updating partitions.
---
Key factors to consider:
Athena charges based on the amount of data scanned.
Minimizing data scanned means efficient partition pruning and filtering.
AWS Glue crawler updates partitions metadata in the Glue Data Catalog, which Athena uses.
Spark in this scenario is used for analyzing data, but Athena itself is a serverless interactive query engine directly querying S3.
Partitioning and correct filtering can reduce data scanned significantly.
Directory structure affects partitioning but Athena partitions are registered in Glue catalog.
In-memory caching affects Spark but not Athena directly.
Frequency of Glue crawler updates affects metadata freshness, not data scanned per query.
---
Option A: Apply partition filters in the queries
Why it fits:
Athena is very efficient at pruning partitions if partition filters are applied in the WHERE clause of the query.
This directly limits the partitions scanned, hence reducing the amount of data read from S3.
Example scenario: Query with `WHERE year=2025 AND month=08` only scans the relevant partitions.
Key factor: Partition pruning is the most effective way to reduce scanned data in Athena.
---
Option B: Increase frequency of AWS Glue crawler invocations
Why it doesn’t fit for scanning reduction:
Glue crawler updates partition metadata, which is important for accuracy and availability of partitions but does not reduce the amount of data scanned during a query.
More frequent crawling might help with data freshness but does not optimize query cost or performance directly.
Could add cost and overhead if run too frequently without benefit to scanning size.
---
Option C: Organize the data in Amazon S3 by using a nested directory structure
Why...
Author: Maya2022 · Last updated May 21, 2026
A company manages an Amazon Redshift data warehouse. The data warehouse is in a public subnet inside a custom VPC. A security group allows only traffic from within itself. An ACL is open to all traffic.
The company wants to generate several visualizations in Amazon QuickSight for an upcoming sales event. The company will run QuickSight Enterprise edition in a second AWS account inside a public subnet within a second custom VPC. The new public subnet has a security group that allows outbound traffic to the existing...
Let's analyze each option carefully based on the architecture and requirements:
---
Scenario Recap:
Redshift cluster: in public subnet of custom VPC, security group allows only traffic from itself.
Network ACL: open to all traffic.
QuickSight Enterprise: in a second AWS account, in a public subnet of a different custom VPC.
QuickSight security group: allows outbound traffic to Redshift.
Goal: QuickSight must query Redshift to refresh dashboards.
---
Option A:
"Configure the Redshift security group to allow inbound traffic on the Redshift port from the QuickSight security group."
Pros:
Security groups can reference other security groups across accounts only if they are in the same VPC or peered VPCs.
This would allow QuickSight instances to connect on the Redshift port securely.
Cons:
QuickSight and Redshift are in different VPCs in different accounts with no VPC peering mentioned.
Security groups referencing across accounts but across VPCs require VPC peering or Transit Gateway connectivity.
Without network-level connectivity (peering), this won't work.
Conclusion:
This option requires network connectivity between VPCs which isn't stated as established. So, it's not sufficient by itself.
---
Option B:
"Assign Elastic IP addresses to the QuickSight visualizations. Configure the QuickSight security group to allow inbound traffic on the Redshift port from the Elastic IP addresses."
Issues:
QuickSight is a managed service, you don't control or assign Elastic IPs to QuickSight endpoints or visualizations.
QuickSight doesn't expose Elastic IPs that you can whitelist for inbound rules.
Also, the Redshift cluster's security group currently only allows traffic from itself, so you'd have to change it to allow inbound traffic from these EIPs, which is not feasible since you can't assign static EIPs for QuickSight visualizations.
Conclusion:
This is not possible due to how QuickSight is managed and the inability to assign or rely on Elastic IPs in this context.
---
Option C:
"Confirm that the CIDR ranges of the Redshift VPC and the QuickSight VPC are the same. If CIDR ranges are different, reconfigure one CIDR range to match the other. Establish network peering between the VPCs."
Pros:
VPC p...
Author: Zain · Last updated May 21, 2026
A data engineer is building a data pipeline. A large data file is uploaded to an Amazon S3 bucket once each day at unpredictable times. An AWS Glue workflow uses hundreds of workers to process the file and load the data into Amazon Redshift. The...
Let's analyze each option carefully based on the problem requirements and key factors:
Problem recap:
Large data file arrives once per day at unpredictable times in an S3 bucket.
AWS Glue workflow uses hundreds of workers to process the file and load into Redshift.
The goal is to process the file as quickly as possible once it arrives.
---
Option A:
Create an on-demand Glue trigger + Lambda runs every 15 minutes to check S3 + start Glue workflow if file exists.
Pros:
Relatively simple to implement.
Glue workflow only starts if file is present.
Cons:
Potential delay up to 15 minutes before Lambda detects file and triggers Glue workflow.
Inefficient polling approach—not event-driven, so not immediate.
Use case:
When event-driven triggers are not possible and low frequency checks are acceptable.
---
Option B:
Create an event-based Glue trigger. Configure S3 to log PutObject events to CloudTrail, then use EventBridge rule to forward PutObject events to Glue trigger.
Pros:
Event-driven — Glue workflow triggers immediately after file upload.
No polling or delays.
Scalable and cost-efficient.
Cons:
Slightly complex setup involving CloudTrail and EventBridge.
Requires correct event pattern filtering.
Use case:
When immediate processing after file upload is critical.
When you want fully automated event-driven pipelines.
---
Option C:
C...
Author: Maya · Last updated May 21, 2026
A data engineer needs to run a data transformation job whenever a user adds a file to an Amazon S3 bucket. The job will run for less than 1 minute. The job must send the output through an email message to the data engineer. The data engineer expects users to add one ...
Let's analyze each option based on operational efficiency, cost, complexity, and scalability given the requirements:
Requirements Recap:
Run a data transformation job whenever a file is added to S3.
Job runs for less than 1 minute.
Output sent via email to the data engineer.
File arrival frequency: about once every hour (low frequency).
Solution must be operationally efficient (minimal maintenance/management).
---
Option A: EC2 instance polling S3 and sending emails via OS commands
Polling approach is inefficient and not event-driven; this causes unnecessary compute usage.
Running a constantly-on EC2 instance for just one file per hour is overkill and not cost-efficient.
Managing the EC2 instance (patches, scaling, monitoring) increases operational overhead.
Sending emails via OS commands requires setup and management of email servers or external SMTP.
Best for: Long-running or high-frequency batch jobs, or when custom OS-level control is required.
Rejected because: inefficient, costly, and operationally complex for a simple hourly event-triggered job.
---
Option B: ECS task polling S3 and sending emails via OS commands
Similar to Option A but using containers on ECS.
Polling is still inefficient and not event-driven.
ECS adds some operational overhead: cluster management or using Fargate (serverless containers).
Requires custom email sending setup.
Best for: Containerized workloads needing some scalability, but still not ideal for event-driven, infrequent triggers.
Rejected because: same reasons as A — inefficient polling, unnecessary complexity, and operational overhead.
---
Option C: Lambda triggered by S3 Event Notification + SNS for email delivery
Lambda can be triggered immediately on new object creation (event-driven).
Lambda has sub-second startup times, perfect for short (<1 minute) j...
Author: Ethan · Last updated May 21, 2026
A company uses Amazon S3 and AWS Glue Data Catalog to manage a data lake that contains contact information for customers. The company uses PySpark and AWS Glue jobs with a DynamicFrame to run a workflow that processes data within the data lake.
A data engineer notices that the workflow is generating errors as a result of how customer postal codes are stored in the data lake. Some pos...
Let's analyze each option in the context of the problem:
Problem Recap:
The company uses AWS Glue + PySpark with DynamicFrames to process customer contact data.
Postal codes have invalid characters or extra numbers causing processing errors.
The goal is to clean or correct postal codes in the data lake during processing to avoid errors.
---
Option A:
Create a schema definition for PySpark that matches the format the processing workflow requires for postal codes. Pass the schema to the DynamicFrame during processing.
This option involves defining a strict schema for the postal code field to enforce correct data types and formats.
However, schema definition alone won't fix or clean invalid postal codes; it will more likely cause job failures if data doesn't match the schema.
This approach validates the format but doesn't correct errors.
Also, DynamicFrames generally infer schema or use Glue catalog schema but do not automatically clean data.
This option does not address cleaning or correcting data, only structure validation.
Rejection reason: Doesn't correct data, only schema validation; errors likely continue.
---
Option B:
Use AWS Glue workflow properties to allow job state sharing. Configure the AWS Glue jobs to read values from the postal code column by using the properties from a previously successful run of the jobs.
This option is about sharing state or metadata between Glue jobs within a workflow.
It doesn't relate directly to cleaning or validating postal codes.
Reading previous run properties doesn't fix bad postal codes in current data.
This is more suitable for job orchestration or parameter passing, not data correction.
Rejection reason: Doesn't fix or clean postal code data; unrelated to data correction.
---
Option C:
Configure the column.push\_down\_predicate setting and the catalogPartitionPredicate settings for the postal code column in the DynamicFrame.
Push-down predicates allow filtering data at the source before reading it into the job.
Using predicates on postal code could filter out bad records, but it doesn't cl...
Author: Andrew · Last updated May 21, 2026
A data engineer is troubleshooting an AWS Glue workflow that occasionally fails. The engineer determines that the failures are a result of data quality issues. A business reporting team needs to receive an email notific...
Let's analyze each option carefully based on the requirement:
Requirement Summary:
Notify a business reporting team via email whenever an AWS Glue workflow fails.
The solution should be reliable for occasional failures caused by data quality issues.
Notification on job state FAILED.
---
Option A
Create an SNS FIFO topic.
Subscribe the team's email to SNS.
Trigger an AWS Lambda function on Glue job state FAILED.
Lambda publishes to SNS topic.
Pros:
Lambda allows custom logic if needed.
SNS supports email subscriptions.
Cons:
FIFO SNS topics do not support email subscriptions. SNS FIFO topics only support application, SQS, Lambda, and HTTP/S endpoints, not email.
This means email notifications cannot be sent directly from SNS FIFO.
Lambda is an extra component here that might not be needed if EventBridge can trigger SNS directly.
Conclusion:
SNS FIFO is not suitable for email notifications. Lambda adds complexity unnecessarily.
---
Option B
Create an SNS standard topic.
Subscribe the team's email to SNS.
Create an EventBridge rule that triggers on AWS Glue job FAILED state.
Set SNS as the EventBridge target.
Pros:
SNS standard topics support email subscriptions directly.
EventBridge can detect Glue job state changes easily.
No extra Lambda needed; direct notification.
Simple, scalable, and reliable.
Well suited for the use case of triggering notifications on specific event states.
Conclusion:
This is a clean, direct, and appropriate solution.
-...
Author: MoonlitPantherX · Last updated May 21, 2026
A company uses AWS Glue jobs to implement several data pipelines. The pipelines are critical to the company.
The company needs to implement a monitoring mechanism that will alert stakeholders if the pipeline...
Let's analyze each option carefully with respect to least operational overhead, effectiveness, and simplicity for monitoring AWS Glue job failures.
---
Option A
Create an EventBridge rule to match AWS Glue job failure events.
Target: Lambda function processes events and sends notifications to SNS.
Pros:
Directly reacts to Glue job failure events.
Customizable Lambda function logic for filtering or formatting alerts.
Reliable and near real-time.
Cons:
Requires managing and maintaining a Lambda function.
Lambda introduces operational overhead (code updates, monitoring, error handling).
Slightly more complex setup than direct notification.
When to use: When custom processing of failure events or complex alert logic is needed.
---
Option B
Use CloudWatch Logs log group for Glue jobs.
Create EventBridge rule on new log creation events.
Lambda reads logs, filters failures, sends notifications via SNS.
Pros:
Works at log level, very flexible for complex log analysis.
Can detect nuanced failure types or partial failures.
Cons:
More complex: requires parsing logs inside Lambda.
Higher operational overhead (managing Lambda, log parsing logic).
Potential latency (waits for logs to be created and ingested).
Overkill if you only need simple failure notifications.
When to use: When detailed log analysis or specific failure pattern detection is necessary.
---
Option C
Create EventBridge rule to match Glue job failure events.
Define CloudWatch metric from these events.
Set CloudWatch alarm on this metric to send notifications to SNS.
Pros:
Serverless, no Lambda needed — les...
Author: Amira · Last updated May 21, 2026
A company uses AWS Glue Apache Spark jobs to handle extract, transform, and load (ETL) workloads. The company has enabled logging and monitoring for all AWS Glue jobs.
One of the AWS Glue jobs begins to fail. A data engineer investigates the error and wants to...
Let's analyze each option carefully, focusing on how a data engineer can access stage-level metrics in an AWS Glue Apache Spark job:
---
A) Examine the AWS Glue job and stage details in the Spark UI.
Why this is relevant:
AWS Glue Spark jobs run on Apache Spark, which provides a Spark UI with detailed job, stage, and task metrics.
The Spark UI offers granular insight into each stage's runtime, shuffle read/write, task success/failure, and more.
This is the best source for stage-level metrics because it is specifically designed to show the breakdown of Spark job execution.
Limitations:
The Spark UI is ephemeral and available only during or shortly after job execution unless logs are preserved or pushed to an external system.
Requires enabling Glue job bookmarks or configuring the job to allow Spark UI access.
---
B) Examine the AWS Glue job and stage metrics in Amazon CloudWatch.
Why this is relevant:
CloudWatch collects metrics at the job level, such as job duration, success/failure, and resource usage.
It provides overall Glue job metrics but does not provide detailed Spark stage-level metrics.
Limitations:
CloudWatch is great for monitoring job success/failure, errors, and resource usage but lacks fine-grained Spark stage breakdown.
Not suitable for troubleshooting individu...
Author: MysticJaguar44 · Last updated May 21, 2026
A data engineer notices slow query performance on a highly partitioned table that is in Amazon Athena. The table contains daily data for the previous 5 years, partitioned by date.
The data engineer wants to improve query ...
Let's analyze each option carefully against the key requirements:
Scenario:
Table is highly partitioned by date (daily partitions for 5 years = \~1825 partitions).
Query performance is slow.
Automation of partition management is needed.
---
Option A: Use an AWS Lambda function that runs daily to manually create new partitions in AWS Glue.
Pros: Automates partition creation, so no manual intervention needed.
Cons:
Manual partition management can become complex and error-prone at scale, especially with many partitions.
Each partition must be explicitly added, which adds overhead and maintenance complexity.
Doesn't directly improve query performance beyond automating partition creation.
When to use: Good for scenarios with infrequent or unpredictable partition additions or where dynamic partitioning isn't supported.
Why rejected:
Manual partition management can be a maintenance burden.
Slow query performance due to large partition count is not solved by just automating partition addition.
---
Option B: Use partition projection in Athena with a date range from 5 years ago to present.
Pros:
Automatically projects partitions without needing to add them to the Glue Data Catalog manually.
Eliminates the overhead of managing partitions in Glue, which reduces query planning time.
Significantly improves query performance by avoiding costly metadata calls for thousands of partitions.
Automates partition management via configuration rather than code.
Cons: Requires partition scheme to follow a predictable pattern (which it does — daily date partitions).
When to use: Highly partitioned tables with predictable partition key formats and large partition counts.
Why selected:
Addresses both requirements: improves query performance by reducing metadata lookups and automates partition management through projection.
---
Option C: Reduce number of partitions by changing from daily to month...
Author: Ella · Last updated May 21, 2026
A company has two teams: Team A and Team B. Team A has VPCs that run in Account A. The team uses a transit gateway (TGW-A) to route traffic between workloads that run in the different VPCs. Similarly, Team 'B' has VPCs that run in Account B. Team 'B' uses a different transit gateway (TGW-B) to route traffic between workloads that run in the different VPCs.
The company's network team manages the routing for Team A and Team 'B'. The netwo...
To determine the best solution with the least operational overhead, we need to evaluate the options based on key AWS networking factors:
---
Key Factors for Evaluation:
1. Operational overhead – simplicity and ease of migration.
2. Reuse of existing infrastructure – reusing TGW-A is preferred over creating a new TGW.
3. Resource sharing – AWS RAM (Resource Access Manager) can share TGWs across accounts.
4. Routing configuration complexity – fewer changes to routing tables reduce effort and risk.
5. Future scalability – using centralized routing may help but adds complexity.
---
Option Analysis:
A) Use TGW-A, share with Account B, attach VPCs, update routes, retire TGW-B. ✅
Pros:
Leverages existing TGW-A.
No need to build a new TGW.
Minimal changes: only add VPC attachments and update routes.
Simplifies overall architecture into a single TGW.
Least operational overhead.
Cons:
Routing changes must still be tested carefully.
Best used when: One TGW is already working well, and you want a fast, low-complexity consolidation.
B) Use TGW-A and "replicate" TGW-B config to TGW-A before deleting TGW-B. ❌
Pros:
Keeps TGW-B temporarily until TGW-A is ready.
Cons:
"Replicating configuration" is not automatic in AWS – it’s a manual and error-prone process.
...
Author: Zara1234 · Last updated May 16, 2026
A company has an AWS environment that includes multiple VPCs that are connected by a transit gateway. The company wants to use a certificate-based AWS Site-to-Site VPN connection to establish connectivity between an on-premises environment and the AWS environment. The company does not have a static public IP address for the on-premises environment.
Wh...
To establish a certificate-based Site-to-Site VPN between an on-premises environment with no static public IP and an AWS Transit Gateway, we must carefully evaluate the requirements and constraints of AWS VPN capabilities.
---
🔍 Key Factors to Consider:
1. Certificate-Based Authentication:
AWS Site-to-Site VPN supports mutual authentication using X.509 certificates (instead of PSK).
For certificate-based VPN, the certificate must come from a trusted CA and be associated with a VPN endpoint, not directly to the customer gateway.
2. Dynamic IP Address (No Static IP):
Site-to-Site VPN traditionally requires a static public IP on the customer side to configure the Customer Gateway (CGW).
However, AWS supports dynamic CGW IP when you do not specify an IP and instead associate it with a certificate.
3. Transit Gateway Integration:
Transit Gateways support Site-to-Site VPN attachments just like Virtual Private Gateways.
---
✅ Option Analysis:
---
A) Create a public certificate in AWS Certificate Manager (ACM).
❌ Incorrect.
Reason: AWS Site-to-Site VPN does not support ACM certificates for VPN endpoints. It uses certificates from AWS Private Certificate Authority (Private CA), not public ACM.
When used: ACM public certificates are used for services like CloudFront, API Gateway, ALB, not for VPN authentication.
---
B) Create a private certificate in AWS Certificate Manager (ACM).
✅ Correct.
Reason: AWS Site-...
Author: Daniel · Last updated May 16, 2026
A company operates in multiple AWS Regions. The company has deployed transit gateways in each Region. The company uses AWS Organizations to operate multiple AWS accounts in one organization.
The company needs to capture all VPC flow log data when a new VPC is created. The company needs to sen...
To determine the best solution with the least administrative effort, let’s analyze each option using key factors like automation, scalability, central management, compliance enforcement, and required operational overhead.
---
Option A: Update IAM permissions for each user to include a condition that ensures users can create VPCs only when VPC Flow Logs is enabled and configured correctly.
✅ Pros:
Provides proactive control by preventing non-compliant VPC creation.
Enforces compliance at the time of resource creation.
❌ Cons:
High administrative overhead: Requires managing complex IAM policies across multiple accounts and users.
Doesn’t automatically apply flow logs; just prevents creation unless conditions are met.
Limited flexibility if VPC creation is triggered by automated systems or third-party tools.
Use case:
Suitable when the organization wants tight control over user actions via IAM and has a small number of users or accounts.
---
Option B: Create a custom AWS Config rule with automatic remediation that verifies VPC Flow Logs is enabled and configured correctly. Apply the AWS Config rule to the organization.
✅ Pros:
Centralized management via AWS Config conformance packs.
Automated remediation ensures non-compliant VPCs are corrected without manual intervention.
Scales across multiple accounts and regions using AWS Organizations.
Ensures continuous compliance, even if VPCs are created outside approved workflows (e.g., via automation).
❌ Cons:
Slight upfront effort to define the custom AWS Config rule and remediation logic.
AWS Config has a cost associated with rule evaluations and recording configuration changes.
Use case:
Ideal for enterprise-scale, multi-account environments needing ongoing compliance checks with low manual effort.
---
...
Author: Arjun · Last updated May 16, 2026
A company wants to analyze TCP internet traffic. The traffic originates from Amazon EC2 instances in the company's VPC. The EC2 instances initiate connections through a NAT gateway.
The company wants to capture data about the traffic including source and destination IP addresses ports, and the first 8 bytes of the TCP segments...
To determine the correct solution, let's evaluate each option based on the key requirements:
Requirements Recap:
Analyze TCP internet traffic.
Traffic originates from EC2 instances in a VPC.
Initiates connections through a NAT Gateway.
Must capture source/destination IPs, ports, and first 8 bytes of TCP segments.
Must collect, store, and analyze the data.
---
Option A:
> Configure the EC2 instances to be VPC traffic mirror sources. Deploy software on the traffic mirror target to forward the data to Amazon CloudWatch Logs. Analyze the data by using CloudWatch Logs Insights.
✅ Traffic Mirroring captures full packets, including first 8 bytes of TCP segment—meets this requirement.
❌ CloudWatch Logs is not ideal for storing raw mirrored packet data; it's better suited for log entries, not binary traffic captures.
❌ Forwarding full packet data to CloudWatch Logs is expensive, not scalable, and not recommended for packet-level analysis.
✅ Correct data capture, but storage/analysis layer is inefficient for packet data.
Use case: Good for near-real-time troubleshooting at small scale if integration with CloudWatch is essential.
---
Option B:
> Configure the NAT gateway to be a VPC traffic mirror source. Deploy software on the traffic mirror target to forward the data to an Amazon S3 bucket. Analyze the data by using Amazon Athena.
✅ Traffic Mirroring from the NAT Gateway works: NAT Gateway handles outbound traffic, which meets the use case.
✅ Captures packet-level data including source/destination IPs, ports, and first 8 bytes.
✅ Storing in S3 is scalable and cost-effective.
✅ Athena supports querying structured data formats derived from mirrored traffic (e.g....
Author: Scarlett · Last updated May 16, 2026
A media company is planning to host an event that the company will live stream to users. The company wants to use Amazon CloudFront.
A network engineer creates a primary origin and a secondary origin for CloudFront. The engineer needs to ensure that the primary origin can fail over to the secondary ...
To determine the best solution with the least operational overhead to fail over between origins in Amazon CloudFront, we must consider how CloudFront origin failover works natively, and compare that to the complexity and reliability of the other options.
---
✅ Option C: Set the CloudFront origin connection timeout value to 5 seconds. Set the origin connection attempts value to 2.
Explanation:
CloudFront has native support for origin failover when two origins are configured in an origin group.
When the primary origin fails, CloudFront automatically retries the secondary origin based on connection timeout and attempt values.
In this option:
Setting the origin connection timeout to 5 seconds and
Setting origin connection attempts to 2 means that failover can happen in about 10 seconds.
This solution uses built-in CloudFront features, which provides reliable failover with minimal operational overhead (no code or infrastructure to maintain).
This approach also meets the requirement of failing over within 15 seconds.
---
❌ Option A: Lambda\@Edge for health checks every 10 seconds
Why it's rejected:
Lambda\@Edge is not designed for continuous health monitoring.
It introduces significant operational overhead: managing health checks, rerouting logic, monitoring Lambda execution.
There's also inherent latency and complexity in doing this manually via Lambda\@Edge.
This approach reinvents functionality that CloudFront already supports natively.
Use case where it might apply:
Custom failover logic based on application-level health (not network-based), or content inspection.
-...
Author: Lina Zhang · Last updated May 16, 2026
AnyCompany deploys and manages networking resources in its AWS network account, named Account-A. AnyCompany acquires Example Corp, which has an application that runs behind an Application Load Balancer (ALB) in Example Corp's AWS account, named Account-B.
Example Corp needs to use AWS Global Accelerator to create an accelerator to publish the applicati...
To solve this scenario, let's break down the key requirements and constraints:
---
✅ Key Requirements:
Global Accelerator must be used to expose the application to users.
The application runs behind an ALB in Account-B (Example Corp).
The accelerator must be managed by AnyCompany's networking team in Account-A.
The solution should incur the least management overhead.
---
🔍 Option Analysis:
---
Option A:
> Create an accelerator in Account-B. Use a cross-account role from Account-A to grant the networking team access to manage the accelerator.
✅ Cross-account IAM role allows Account-A users to manage resources in Account-B.
❌ The accelerator exists in Account-B, not Account-A, so the ownership remains in the application account.
❌ This creates cross-account role complexity and more overhead for permissions, audits, and role switching.
❌ Does not align with requirement that Account-A manages the accelerator directly.
Use case: Useful if Account-B owns and manages the accelerator but wants to delegate some permissions to Account-A.
---
Option B:
> Deploy a Network Load Balancer (NLB) in Account-A to route traffic to the ALB in Account-B. Create an accelerator, and set the NLB as the endpoint in Account-A.
✅ This gives Account-A full control over the accelerator and its endpoints.
❌ Adds significant complexity: requires transit routing or VPC peering, setting up NLB → ALB forwarding, managing target groups, and ensuring cross-VPC connectivity.
❌ Not the "least management overhead" – introduces extra infrastructure and operational burden.
✅ Technically viable for scenarios where central traffic management is needed.
Use case: When you need all traffic to flow through a centralized NLB in a n...
Author: SolarFalcon11 · Last updated May 16, 2026
A company has two AWS Direct Connect connections between Direct Connect locations and the company's on-premises environment in the US. The company uses the connections to communicate with AWS workloads that run in the us-east-1 Region. The company has a transit gateway that connects several VPCs. The Direct Connect connections terminate at a Direct Connect gateway and the transit VIFs to the transit gateway.
The company recently acquired a smaller company that is based in Europe. The newly acquired company has only on-premises workloads. The newly acquired company does not expect to run workloads on AWS for the next 3 years. However, the newly acquired company requires connectivity to the parent company's AWS res...
To determine the best solution with the LEAST operational overhead for providing connectivity between the newly acquired company in Europe and:
1. AWS workloads in us-east-1, and
2. The parent company’s on-premises environment in the US,
while considering that the acquired company:
Has on-premises workloads only (no AWS VPCs),
Needs connectivity to both AWS and US on-prem, and
Requires low operational overhead,
let’s evaluate each option.
---
✅ Option A: Associate new transit VIFs to the existing Direct Connect gateway. Configure the new transit VIFs to use Direct Connect SiteLink.
Key features:
Transit VIFs terminate at Direct Connect gateway, not specific to any AWS Region.
SiteLink allows inter-region or inter-location communication without going through AWS VPCs or the public internet.
How it helps:
Europe site’s transit VIFs can connect directly to US Direct Connect location through SiteLink.
Allows connectivity to parent company’s US on-premises through existing Direct Connect and transit gateway connections.
No need to deploy new AWS infrastructure (like VPCs or transit gateways) in Europe.
Simplifies routing — all VIFs connect to a single DX gateway.
Operational overhead: Very low — no new AWS VPCs or TGWs to manage in Europe.
---
❌ Option B: Associate new transit VIFs to a new Direct Connect gateway and to a new transit gateway in eu-west-1. Use transit gateway peering.
Key features:
Creates new AWS infrastructure (new DX gateway, new TGW).
Requires TGW peering across regions (Europe ↔ US).
Why it’s not ideal:
Requires creating and managing a new transit gateway and DX gateway in Europe.
Adds complexity: inter-region peering, propagation policies, routing.
New VPCs mi...
Author: CrystalWolfX · Last updated May 16, 2026
A company is establishing hybrid cloud connectivity from an on-premises environment to AWS in the us-east-1 Region. The company is using a 10 Gbps AWS Direct Connect dedicated connection. The company has two accounts in AWS. Account A has transit gateways in four AWS Regions. Account 'B' has transit gateways in three Regions. The company does not plan to expand.
To...
To determine the most cost-effective solution for hybrid cloud connectivity between on-premises and AWS, while maintaining separate infrastructure per account (to meet security requirements), we need to evaluate each option based on:
---
Key Factors for Evaluation
1. Security Isolation – Separate cloud infrastructure per account.
2. Cost – Minimize Direct Connect (DX) infrastructure and port charges.
3. Scalability/Future-proofing – Although no expansion is planned, future flexibility is still a consideration.
4. AWS Best Practices – Using Direct Connect Gateway with Transit Gateway and AWS RAM.
5. Direct Connect Gateway Association Limits – Each DX Gateway can support up to 3 Transit Gateway attachments.
---
Option Analysis
---
Option A
> One DX Gateway shared via AWS RAM. Two transit VIFs (one per account). Each account attaches its regional Transit Gateways to the shared DX Gateway.
✅ Security: Separate transit VIFs for each account ensure traffic separation.
✅ Cost: Only one 10 Gbps DX connection and one DX Gateway.
✅ Scalable within current footprint (7 TGW attachments total: within 3 TGWs per VIF limit).
✅ Meets AWS best practices for multi-account connectivity.
✅ Efficient use of RAM for resource sharing.
⚠️ Slightly more complex to manage in terms of RAM and attachment mappings.
→ Best overall balance of cost, security, and simplicity (given no expansion planned).
---
Option B
> Two DX Gateways (one per account), both sharing same DX physical link. One transit VIF per DX Gateway.
✅ ...
Author: NebulaEagle11 · Last updated May 16, 2026
A company runs an application across multiple AWS Regions and multiple Availability Zones. The company needs to expand to a new AWS Region. Low latency is critical to the functionality of the application.
A network engineer needs to gather metrics for the latency between the existing. Regions and the new...
To determine the best solution for measuring inter-Region latency with historical metrics for at least the past 30 days, we need to evaluate each option based on key factors like latency visibility, historical data availability, metric granularity, and multi-Region performance monitoring.
---
A) Configure an AWS Network Access Analyzer Network Access Scope, and use the analysis to review the latency.
Why Rejected:
Network Access Analyzer is used to identify unintended network paths or validate network access according to policy, not for performance or latency metrics.
It doesn't provide latency measurements or historical performance data.
Use Case: Security auditing, network access visibility — not performance monitoring.
---
B) Set up AWS Network Manager Infrastructure Performance. Publish network performance metrics to Amazon CloudWatch.
Why Selected:
AWS Network Manager Infrastructure Performance is designed to monitor network latency and performance between AWS Regions and between AWS and on-premises.
It supports active monitoring using probes between AWS Global Network Regions.
Metrics are published to CloudWatch, allowing retention, visualization, and analysis for up to 15 months.
Enables historical analysis, satisfying the requirement for a...
Author: BlazingPhoenix22 · Last updated May 16, 2026
A company is implementing an application on Amazon EC2 instances. The application needs to process incoming transactions. When the application detects a transaction that is not valid, the application must send a chat message to the company's support team. To send the message, the application needs to retrieve the access token to authenticate by using the chat API.
A developer needs to implement a solution to store the access token. The access t...
When choosing the solution to store the access token, key factors to consider include:
1. Encryption at rest and in transit: The solution should encrypt the token both at rest and during transit to meet the security requirements.
2. Accessibility from multiple AWS accounts: The token must be accessible by resources across AWS accounts, so cross-account access is required.
3. Minimal management overhead: Ideally, the solution should minimize complexity and manual intervention.
Option A: AWS Systems Manager Parameter Store SecureString
- Advantages:
- Encryption: Supports encryption with AWS KMS managed keys.
- Cross-account access: Resource-based policies allow you to grant access to other AWS accounts.
- Minimal setup: No need for managing a separate service like DynamoDB or S3. Only the EC2 instance needs access permissions to Parameter Store.
- Low management overhead: Once set up, it requires minimal management, especially for transient secrets like an access token.
- Disadvantages:
- Scalability: While good for small numbers of secrets, if the application scales to require complex secret management, you may need to migrate to a more specialized solution.
Option B: DynamoDB with AWS KMS
- Advantages:
- Encryption: Supports encryption at rest via AWS KMS.
- Scalability: DynamoDB is designed for high throughput and scale.
- Disadvantages:
- Complexity: Requires managing a DynamoDB table for a single access token. This introduces unnecessary complexity for what is essentially a single secret.
- Overhead: Both managing DynamoDB permissions and dealing with KMS decryption adds extra layers of management and overhead compared to simpler solutions.
Option C: AWS Secrets Manager
- Advantages:
- Encryption: Provides en...
Author: Aria · Last updated May 18, 2026
A company is running Amazon EC2 instances in multiple AWS accounts. A developer needs to implement an application that collects all the lifecycle events of the EC2 instances. The application needs to store the lifecycle events in a single Amazon Simple Queue Service (Amaz...
Let's evaluate each option based on the requirements:
Requirements:
1. Collect lifecycle events of EC2 instances from multiple accounts: The solution must be able to gather lifecycle events from EC2 instances in various AWS accounts.
2. Store lifecycle events in a single SQS queue in the main account: The events need to be centralized and placed in an SQS queue for further processing.
3. Minimize management overhead: The solution should not require excessive manual intervention or complex setup.
Option A: Use Amazon EventBridge in the main account with an SQS target
- EventBridge setup: Amazon EC2 lifecycle events are automatically sent to EventBridge in the respective accounts. In the main account, EventBridge can be configured to accept these events.
- Centralized SQS target: The rule in EventBridge of the main account can have the SQS queue as the target.
- Cross-account access: No additional steps needed for permissions since EventBridge is designed for cross-account event routing.
- Management overhead: The setup is centralized in the main account, and it requires minimal ongoing maintenance after configuration.
Why this is a good option: This solution allows you to easily collect EC2 lifecycle events from multiple accounts and forward them to a centralized SQS queue with minimal configuration. EventBridge also has native cross-account capabilities, which reduces complexity.
Option B: Use SQS resource policies and EventBridge rules in each account
- SQS access configuration: You would need to set up SQS resource policies to allow write access from each AWS account. This can be cumbersome as you need to maintain access control for each account.
- EventBridge in each account: You also need to configure EventBridge rules in each account to forward lifecycle events to the main account's SQS queue.
- Management overhead: This solution involves more configuration at the individual account level, and the access control with SQS can be more error-prone, especially as the number of accounts grows.
Why this is not ideal: The added complexity of configuring individual EventBridge rules and managing SQS resource policies increases the management overhead, which is less efficient compared to a simpler centralized approach.
Option C: Use AWS Lambda to scan EC2 instances and detect lifecycle changes
- Lambd...
Author: Liam123 · Last updated May 18, 2026
An application is using Amazon Cognito user pools and identity pools for secure access. A developer wants to integrate the user-specific file upload and download features in the application with Amazon S3. The developer must ensure that the files are saved and retrieved in a secure manner and that users can access only...
Requirements:
- Secure file upload and download: The solution must ensure files are uploaded and downloaded securely.
- User-specific access: Users should only have access to their own files, not the files of other users.
- File size range: The file sizes range from 3 KB to 300 MB, meaning the solution needs to handle both small and large files efficiently.
- Integration with Amazon Cognito: The solution must integrate with Cognito user pools and identity pools for secure access.
Option A: Use S3 Event Notifications to validate the file upload and download requests and update the user interface (UI)
- Event Notifications: S3 Event Notifications can notify the application when files are uploaded or downloaded.
- Validation in UI: However, relying on S3 event notifications for validation of access rights isn't ideal for ensuring secure file access since event notifications are typically used for processing asynchronous events rather than validating access control.
- Lack of direct access control: It doesn't provide a mechanism to enforce security directly in the file access process.
Why this is not ideal: While event notifications can be useful for processing events asynchronously, they don't directly address the security requirements of restricting file access or validating the user’s permissions during the file upload or download process. It adds complexity without a proper access control mechanism.
Option B: Save the details of the uploaded files in a separate Amazon DynamoDB table. Filter the list of files in the user interface (UI) by comparing the current user ID with the user ID associated with the file in the table
- DynamoDB for file metadata: This option involves saving metadata about the uploaded files in DynamoDB and comparing user IDs in the UI.
- Access control: While storing metadata in DynamoDB can help manage file information, it doesn't directly prevent unauthorized file access. Files themselves are still stored in S3, and this solution doesn't integrate access control mechanisms for the actual file retrieval process.
- Complexity: Managing metadata in DynamoDB adds another layer of complexity that doesn't provide direct file security.
Why this is not ideal: While DynamoDB can store metadata about the files, this doesn't effectively enforce security on the files themselves or ensure that the user cannot access files belonging to other users. It adds unnecessary complexity without addressing the core security concerns around file storage and retrieval.
Option C: Use Amazon API Gateway and an AWS Lambda function to upload and download files. Validate each request in the La...
Author: Benjamin · Last updated May 18, 2026
A company is building a scalable data management solution by using AWS services to improve the speed and agility of development. The solution will ingest large volumes of data from various sources and will process this data through multiple business rules and transformations.
The solution requires business rules to run in sequence and to handle reprocessing of data if errors occur when the business rules run. The company needs the solution...
Key Requirements:
1. Scalable: The solution must handle large volumes of data.
2. Business rules running in sequence: Business rules should execute in a specific order.
3. Reprocessing capability: The solution should handle reprocessing of data if errors occur.
4. Least maintenance: The solution should be low-maintenance and minimize manual interventions.
Option A: AWS Batch
- What it is: AWS Batch is a fully managed service for running batch computing workloads at any scale.
- Pros: It can scale to process large volumes of data in parallel, and it is optimized for batch processing jobs.
- Cons: AWS Batch does not provide a built-in mechanism to define complex workflows or ensure the sequential execution of tasks. Handling error recovery and reprocessing would need to be implemented manually, which increases complexity and maintenance overhead. It's not primarily focused on orchestrating workflows or data transformations in a sequence.
Why this is not ideal: While AWS Batch can handle large-scale data processing, it is more suited for batch jobs rather than orchestrating complex workflows with sequential dependencies. It would require additional services or custom logic for error handling and reprocessing, leading to higher maintenance.
Option B: AWS Step Functions
- What it is: AWS Step Functions is a serverless orchestration service that allows you to coordinate multiple AWS services into workflows, including the sequential execution of business rules.
- Pros:
- Step Functions provides a visual workflow interface to define and manage the execution of tasks in sequence.
- It natively supports error handling, retries, and manual interventions for reprocessing tasks.
- It integrates well with other AWS services like AWS Lambda, Amazon SNS, and Amazon SQS, making it highly extensible.
- Step Functions automatically scales as needed, handling workflows with varying complexity.
- It is a fully managed service, reducing operational overhead and maintenance.
Why this is the best option: Step Functions is designed specifically for orchestrating workflows with dependencies, making it an ideal choice for managing the sequential execution of business rules. It simplifies error handling and provides built-in capabilities for reprocessing data, ensuring that the solution is both scalable and requires minimal maintenance.
Option ...
Author: Leah Davis · Last updated May 18, 2026
A developer has created an AWS Lambda function that is written in Python. The Lambda function reads data from objects in Amazon S3 and writes data to an Amazon DynamoDB table. The function is successfully invoked from an S3 event notification when an object is created. Howe...
Key Requirements:
- The Lambda function is successfully invoked by an S3 event.
- The Lambda function reads data from Amazon S3.
- The function attempts to write data to Amazon DynamoDB, but it fails during this step.
Option A: The Lambda function's concurrency limit has been exceeded
- Concurrency limit: This issue arises when the function is invoked more times than the maximum allowed concurrency for that Lambda function, which could cause throttling.
- Reason for rejection: If the concurrency limit were exceeded, the function would either fail immediately or invoke with throttling errors, but it would not affect a specific part of the Lambda's execution (such as just the write to DynamoDB). The function would not complete the entire process if concurrency were the issue.
Why this is not the cause: If the function were hitting the concurrency limit, the issue would likely affect all parts of the Lambda function and not just the specific DynamoDB write operation. The problem here seems isolated to the DynamoDB interaction.
Option B: DynamoDB table requires a global secondary index (GSI) to support writes
- Global secondary index (GSI): GSIs are used to allow queries on different attributes of the table. However, writing to DynamoDB does not require a GSI unless you are querying the table in a way that requires it.
- Reason for rejection: GSIs are necessary for querying data in specific patterns, but not for general write operations. If the Lambda function is simply writing to the table (inserting data), it does not require a GSI.
Why this is not the cause: Writing data to a DynamoDB table does not require a GSI unless you are specifically querying by attributes not part of the primary key. A write operation itself will succeed without a GSI, so this is unlikely to be the issue.
Option C: The Lambda function does not have IAM permissions to write to DynamoDB
- IAM permissions: Lambda functions interact with AWS services (like DynamoDB) via IAM roles. If the IAM role associated with the Lambda function does...
Author: Krishna · Last updated May 18, 2026
A developer is creating an AWS CloudFormation template to deploy Amazon EC2 instances across multiple AWS accounts. The developer must choose the EC2 instances from a list of approved instance types.
How can th...
Let's analyze each option and evaluate which one best meets the requirements:
A) Create a separate CloudFormation template for each EC2 instance type in the list.
- This option would lead to a complex setup, where the developer would have to maintain multiple CloudFormation templates for different EC2 instance types. Managing many templates would be cumbersome and error-prone. Additionally, it doesn't allow for easy customization or flexibility, as each template would only support a specific instance type.
- Rejection reason: It is not efficient to create separate templates for each EC2 instance type.
B) In the Resources section of the CloudFormation template, create resources for each EC2 instance type in the list.
- In this case, creating resources for each EC2 instance type in the template would result in a very large and complex template with multiple EC2 resources. This could also lead to unwanted EC2 instances being created if the template is accidentally used in environments that don’t need all of them. Furthermore, it doesn't provide a way to restrict the EC2 instance type selection dynamically.
- Rejection reason: This would unnecessarily complicate the template and increase the chances of deploying unwanted resources.
C) In the CloudFormation template, create a separ...
