MWAA Integration Quiz

This quiz tests your understanding of what Amazon MWAA does and doesn't give you access to, how an MWAA DAG can still drive workloads on an EKS cluster via KubernetesPodOperator, what an IAM identity mapping accomplishes, and when to choose MWAA versus self-managed Airflow on EKS.

Multiple Choice Questions

1. What does Amazon MWAA specifically NOT give you direct access to?
   • A) The DAGs themselves
   • B) The Airflow control plane (scheduler, api-server, dag-processor, workers) — it runs on AWS-managed infrastructure outside your EKS cluster
   • C) The Airflow REST API
   • D) CloudWatch logs for the environment

Show Answer

Answer: B) The Airflow control plane (scheduler, api-server, dag-processor, workers) — it runs on AWS-managed infrastructure outside your EKS cluster

Explanation: MWAA provisions and runs the scheduler, api-server, dag-processor, and worker fleet entirely on AWS-managed infrastructure, not inside your VPC's EKS cluster. As a result, there's no kubectl view into the Airflow control plane itself — you can't inspect the MWAA scheduler's pods the way you would for a self-managed deployment. Health, scaling, and patching of these components are AWS's responsibility, surfaced via CloudWatch and the MWAA console/API instead of Kubernetes primitives.

2. How can an MWAA-hosted DAG still create and manage pods on a customer-owned EKS cluster?
   • A) It cannot — MWAA has no way to reach any Kubernetes cluster
   • B) By using KubernetesPodOperator with in_cluster=True, since MWAA runs inside every EKS cluster automatically
   • C) By using KubernetesPodOperator with in_cluster=False and a kubeconfig file pointed at the target EKS cluster
   • D) By installing a Kubernetes Operator directly inside the MWAA environment

Show Answer

Answer: C) By using KubernetesPodOperator with in_cluster=False and a kubeconfig file pointed at the target EKS cluster

Explanation: Because MWAA's execution environment has no in-cluster Kubernetes API access, KubernetesPodOperator must authenticate the same way any external client would: with in_cluster=False and a config_file pointing at a kubeconfig generated via aws eks update-kubeconfig and uploaded to the environment's S3 bucket alongside the DAGs. in_cluster=True only works when the operator runs inside the same cluster it's targeting, which is never true for MWAA.

3. What does running eksctl create iamidentitymapping for the MWAA execution role accomplish?
   • A) It gives the MWAA execution role AdministratorAccess in the AWS account
   • B) It maps the MWAA execution role's IAM ARN to a Kubernetes username/group so the EKS cluster's RBAC recognizes and can authorize that identity
   • C) It uploads the kubeconfig file to the MWAA environment's S3 bucket
   • D) It upgrades the EKS cluster to a version compatible with MWAA

Show Answer

Answer: B) It maps the MWAA execution role's IAM ARN to a Kubernetes username/group so the EKS cluster's RBAC recognizes and can authorize that identity

Explanation:eksctl create iamidentitymapping adds an entry to the cluster's aws-auth configuration, associating an IAM role ARN with a Kubernetes username and group. This only decides who the MWAA execution role is inside the cluster — a separate ClusterRole/ClusterRoleBinding bound to that group is what actually decides what it's permitted to do (e.g., create pods in a specific namespace, rather than something as broad as system:masters).

4. Which of the following is a real constraint MWAA imposes that self-managed Airflow on EKS (Parts 1–3) does not have?
   • A) MWAA cannot run any Python code at all
   • B) MWAA requires plugins as a zipped plugins.zip uploaded to S3, and Python dependencies via a requirements.txt resolved at build time with no root/system-package installs
   • C) MWAA cannot use the KubernetesPodOperator
   • D) MWAA does not support the Airflow REST API

Show Answer

Answer: B) MWAA requires plugins as a zipped plugins.zip uploaded to S3, and Python dependencies via a requirements.txt resolved at build time with no root/system-package installs

Explanation: Self-managed Airflow lets you bake a plugins folder and arbitrary system packages directly into your image. MWAA instead requires plugins as a plugins.zip in S3 and Python dependencies as a requirements.txt in S3, subject to MWAA's build-time dependency resolution — there's no way to install root or system-level packages. KubernetesPodOperator and the REST API are both still available in MWAA.

5. How does MWAA deliver DAG files to the scheduler, in contrast to Part 3's GitDagBundle?
   • A) MWAA also supports GitDagBundle natively
   • B) MWAA syncs DAGs from an S3 bucket only; it has no git-sync or DAG-bundle support of any kind
   • C) MWAA requires DAGs to be baked into a custom container image
   • D) MWAA pulls DAGs directly from GitHub without any intermediate storage

Show Answer

Answer: B) MWAA syncs DAGs from an S3 bucket only; it has no git-sync or DAG-bundle support of any kind

Explanation: Part 3 covered Airflow 3's native GitDagBundle, which lets a self-managed dag-processor pull DAGs directly from a git repository on its own polling interval — no S3 step involved. MWAA has no equivalent capability: every DAG change must first land as a file in the environment's S3 bucket, whether via manual aws s3 sync or a CI step, adding one more moving part between merging code and having it run.

6. Which release did MWAA add support for in April 2026, and how does that illustrate MWAA's version-currency trade-off?
   • A) Airflow 2.11, roughly three months after Airflow's 2.11 release
   • B) Airflow 3.2, roughly three months after Airflow's own 3.2 release, after previously bridging forward with Airflow 2.11 in January 2026
   • C) Airflow 4.0, ahead of the upstream release
   • D) MWAA does not track specific Airflow versions

Show Answer

Answer: B) Airflow 3.2, roughly three months after Airflow's own 3.2 release, after previously bridging forward with Airflow 2.11 in January 2026

Explanation: MWAA added Airflow 3.2 support in April 2026, about three months behind upstream Airflow's own 3.2 release, and only after MWAA had first moved its 2.x line forward to Airflow 2.11 in January 2026 as a bridge release. This lag is the concrete version-currency trade-off you accept by choosing MWAA over self-managed Airflow, which can adopt an upstream release the moment it ships.

7. When is Amazon MWAA the better fit compared to self-managed Airflow on EKS?
   • A) When you need custom executors and per-task Docker image isolation
   • B) When you need multi-cloud portability
   • C) When your DAGs are simple, pure-Python/PyPI workloads and your team has low appetite for operating the Airflow control plane's infrastructure
   • D) When you want the newest upstream Airflow feature the same month it ships

Show Answer

Answer: C) When your DAGs are simple, pure-Python/PyPI workloads and your team has low appetite for operating the Airflow control plane's infrastructure

Explanation: MWAA fits AWS-only shops running simple DAGs with no custom executors or system-level dependencies, where teams would rather not patch, scale, or manage the availability of the Airflow control plane at all. Custom executors, per-task image isolation, multi-cloud portability, and same-month adoption of new upstream features are all reasons favoring self-managed Airflow on EKS instead.

8. Which statement about the cost trade-off between self-managed Airflow on EKS and MWAA is most accurate?
   • A) Self-managed Airflow is always 30–60% cheaper than MWAA in every scenario
   • B) Well-tuned self-managed deployments have reported 30–60% lower spend than a poorly-tuned MWAA setup at scale, but this depends heavily on traffic pattern and tuning effort and isn't guaranteed
   • C) MWAA has no meaningful cost, since AWS absorbs all compute costs
   • D) Cost is identical between the two approaches regardless of scale

Show Answer

Answer: B) Well-tuned self-managed deployments have reported 30–60% lower spend than a poorly-tuned MWAA setup at scale, but this depends heavily on traffic pattern and tuning effort and isn't guaranteed

Explanation: The 30–60% figure is a real, reported outcome for teams running large, well-tuned self-managed deployments compared against a poorly-tuned MWAA setup — but it's context-dependent, not a universal guarantee, and it must be weighed against the ongoing engineering effort self-hosting requires.

Short Answer Questions

9. What must be added to an MWAA environment's requirements.txt for a DAG to be able to use KubernetesPodOperator?

Show Answer

Answer: apache-airflow[cncf.kubernetes]

Explanation: The cncf.kubernetes provider package supplies KubernetesPodOperator and related Kubernetes integration classes. Without adding it to requirements.txt, the import in the DAG file would fail during parsing.

10. What KubernetesPodOperator parameter must be set to False when the operator runs from MWAA and targets a separate EKS cluster, since MWAA never runs inside that cluster?

Show Answer

Answer: in_cluster

Explanation:in_cluster=True tells the operator to use the Kubernetes API access available from inside the same cluster it's running in — which is never the case for MWAA, since MWAA's control plane runs on separate AWS-managed infrastructure. Setting in_cluster=False and providing config_file pointing at an uploaded kubeconfig is what lets the operator authenticate to an external EKS cluster instead.

Hands-on Questions

11. Write the eksctl command that binds an MWAA execution role (arn:aws:iam::123456789012:role/mwaa-execution-role-my-environment) into the RBAC of an EKS cluster named data-eks-cluster in us-east-1, mapping it to the Kubernetes group mwaa-pod-launcher.

Show Answer

Answer:

eksctl create iamidentitymapping \
  --cluster data-eks-cluster \
  --region us-east-1 \
  --arn arn:aws:iam::123456789012:role/mwaa-execution-role-my-environment \
  --username mwaa-executor \
  --group mwaa-pod-launcher

Explanation: This adds an entry to the cluster's aws-auth configuration so the EKS cluster's RBAC recognizes the MWAA execution role's IAM ARN as the Kubernetes user mwaa-executor belonging to group mwaa-pod-launcher. A separate ClusterRole/ClusterRoleBinding bound to mwaa-pod-launcher — scoped narrowly to what the DAGs actually need, not something as broad as system:masters — determines what that identity can actually do.

12. Write a KubernetesPodOperator task definition for an MWAA DAG that runs the image 123456789012.dkr.ecr.us-east-1.amazonaws.com/data-etl:latest in the data-processing namespace of an external EKS cluster, using a kubeconfig staged at /usr/local/airflow/dags/kube_config.yaml.

Show Answer

Answer:

from airflow.providers.cncf.kubernetes.operators.pod import KubernetesPodOperator

process_data = KubernetesPodOperator(
    task_id="process_data_on_eks",
    name="process-data",
    namespace="data-processing",
    image="123456789012.dkr.ecr.us-east-1.amazonaws.com/data-etl:latest",
    cmds=["python", "process.py"],
    in_cluster=False,
    config_file="/usr/local/airflow/dags/kube_config.yaml",
    is_delete_operator_pod=True,
)

Explanation:in_cluster=False tells the operator not to assume it's running inside the target cluster. config_file points at the kubeconfig MWAA synced down to the DAGs folder alongside the DAG code itself, generated ahead of time via aws eks update-kubeconfig and uploaded to the environment's S3 bucket. is_delete_operator_pod=True cleans up the pod after the task finishes, which is standard practice to avoid leaving completed task pods around on the target cluster.

---

Return to Learning Materials