Amazon DEA-C01: Orquestração de Dados e Gerenciamento de Fluxo de Trabalho — Guia de estudos

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Faz parte do Amazon Data Engineer Associate DEA-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Orquestração e gerenciamento de workflows são centrais para a construção de plataformas de dados confiáveis e de fácil manutenção: eles coordenam jobs de extração, transformação e carga (ETL), gerenciam dependências, lidam com falhas e integram processos orientados a eventos. Este domínio abrange as opções gerenciadas da AWS para ETL em lote, DAGs complexos, máquinas de estado serverless e agendamento de eventos — cada uma com diferentes semânticas de execução, durabilidade e trade-offs de escalabilidade. Entender quando usar AWS Glue Workflows, MWAA, Step Functions ou EventBridge Scheduler — e como configurar o tratamento de erros e a observabilidade — é crucial para ter pipelines previsíveis e controlar os custos operacionais.

AWS Glue Workflows e triggers

Os AWS Glue Workflows agrupam jobs, crawlers e triggers do Glue em um grafo de dependências e permitem que você execute ETL de forma coordenada. Crie workflows através do console ou da CLI (

undefined

). Os triggers (gatilhos) se anexam aos workflows e existem em três tipos: agendado (scheduled), sob demanda (on-demand) e condicional (conditional). Exemplo de criação via CLI para um trigger agendado:

undefined

Triggers condicionais usam um Predicate que referencia o nome e o estado (state) do job (SUCCEEDED, FAILED). Exemplo de JSON para um predicate:

undefined

. Por padrão, os triggers condicionais do Glue disparam em caso de sucesso; para lidar com falhas, configure as condições com State=FAILED ou crie um trigger FAILED explícito para rotear erros para jobs de remediação ou alertas do SNS.

Padrões operacionais e critérios de decisão:

Use Glue Workflows quando precisar de orquestração nativa de jobs/crawlers do Glue e linhagem de dados (lineage); escolha triggers para agendamento cron ou para encadear jobs após sua conclusão.
Para invocação ad-hoc, use

undefined

para triggers sob demanda.

Para ramificações complexas ou tarefas que não são do Glue, prefira Step Functions ou MWAA; os workflows do Glue são ideais quando o pipeline é centrado no Glue.

Tratamento de erros: adicione triggers FAILED, emita métricas do CloudWatch para sucesso/falha do job e envie falhas para uma fila de mensagens mortas (dead-letter queue) do SQS/SNS via Lambda para novas tentativas automatizadas e investigação.

Amazon MWAA (Managed Airflow) para DAGs complexos

O MWAA fornece um ambiente gerenciado do Apache Airflow para expressar DAGs complexos, dependências de tarefas, sensores (sensors) e operadores (operators) customizados. Crie ambientes com

undefined

e forneça um caminho S3 para os DAGs e uma execution role. Detalhes importantes de dimensionamento e rede:

O MWAA requer uma VPC com sub-redes privadas e um NAT gateway para acesso à internet; configurações usando apenas sub-redes públicas não são suportadas.
O comportamento do worker e do scheduler é controlado através das opções de configuração do Airflow fornecidas na criação do ambiente (AirflowConfigurationOptions). Ajuste as configurações de celery.worker_concurrency, celery.worker_autoscale e do scheduler para corresponder à concorrência de tarefas e à complexidade do DAG.
Monitore as métricas do CloudWatch (SchedulerHeartbeat, TasksFailed, TasksRunning, QueuedTasks) e escale o autoescalonamento dos workers ou aumente o número máximo de workers ao observar crescimento na fila.

Critérios de decisão:

Use o MWAA quando precisar dos recursos do Airflow: DAGs complexos, operadores ricos, dependências entre DAGs, sensores de SLA/tarefas perdidas e lógica Python customizada.
Se as tarefas forem de curta duração e de altíssima vazão (throughput), prefira o Step Functions Express (serverless) ou o Glue para operações de ETL gerenciadas.
Mantenha tarefas pesadas e de longa duração em computação gerenciada (Glue/EMR/EKS) e use as tarefas do MWAA apenas para orquestração — evite executar transformações de dados massivas nos próprios workers do MWAA.

Tratamento de erros no Airflow: use novas tentativas (retries) de tarefa e retry_delay nas definições do DAG, defina on_failure_callback para notificar ou enviar para uma fila de mensagens mortas do SQS e configure o tratamento de SLA no nível da tarefa para disparar DAGs de remediação.

AWS Step Functions para orquestração serverless

O Step Functions fornece orquestração com estado (stateful) com uma linguagem baseada em JSON chamada Amazon States Language e se integra amplamente com os serviços da AWS. Escolha entre workflows Standard e Express:

Workflows Standard: projetados para máquinas de estado duráveis e de longa duração (meses a anos), com semântica de execução do tipo “exatamente uma vez” (exactly-once/unique), histórico de execução integrado e rastreamento/logging por execução. Inicie com

undefined

Workflows Express: otimizados para processamento de alta vazão (throughput), baixa latência e curta duração, e com custo-benefício em escala; eles usam semântica de execução do tipo “pelo menos uma vez” (at-least-once), portanto, as tarefas devem ser idempotentes ou usar padrões de desduplicação.

Casos de uso e critérios de decisão:

Use o tipo Standard quando precisar de workflows duráveis e auditáveis que podem ser executados por longos períodos e exigem semântica de execução única.
Use o tipo Express para micro-orquestrações orientadas a eventos com milhares de execuções por segundo, onde a curta duração e a eficiência de custos são importantes, e você pode projetar tarefas idempotentes ou fazer a desduplicação no sistema de destino (downstream).

Tratamento de erros e padrões de integração:

Use blocos Retry na ASL para definir novas tentativas com ErrorEquals, IntervalSeconds, BackoffRate e MaxAttempts.
Use blocos Catch para redirecionar falhas para ramificações alternativas ou para um estado de Falha (Fail) ou Sucesso (Success), e para preencher o ResultPath com detalhes do erro para diagnóstico.
Para tratamento assíncrono de mensagens mortas (dead-lettering), envie mensagens com falha para o SQS/SNS ou projete um padrão do Step Functions que envia os payloads de erro para uma DLQ do SQS para processamento offline. Habilite os logs do CloudWatch e o rastreamento do X-Ray via LoggingConfiguration e TracingConfiguration para observabilidade.