Why would you create a custom operator in Apache Airflow instead of using built-in operators?
Think about when you need to do something unique or repetitive in your workflows.
Custom operators let you package specific task logic that is not covered by Airflow's built-in operators, making your DAGs cleaner and more reusable.
Given this custom operator code snippet, what will be printed when the task runs?
from airflow.models import BaseOperator from airflow.utils.decorators import apply_defaults class HelloOperator(BaseOperator): @apply_defaults def __init__(self, name: str, **kwargs): super().__init__(**kwargs) self.name = name def execute(self, context): print(f"Hello, {self.name}!") # Assume this operator is used in a DAG with name='Airflow'
Look at how the name parameter is used in execute.
The operator prints the greeting using the name passed during initialization, so it prints 'Hello, Airflow!'.
Which option correctly defines a custom operator that accepts a file_path parameter and passes other arguments properly to the base class?
Remember to call super().__init__ before using self attributes.
Option A correctly calls super().__init__(**kwargs) first and then assigns file_path. This is the recommended pattern.
What error will this custom operator code raise when instantiated?
class BadOperator(BaseOperator): def __init__(self, param, **kwargs): self.param = param super().__init__(**kwargs)
Check the order of super().__init__ call and attribute assignment.
Because super().__init__ is called after assigning self.param, Airflow's BaseOperator may not initialize properly, causing a TypeError about missing arguments.
What is the correct order of steps to create and use a custom operator in Airflow?
Think about writing code, importing it, then using it in the DAG.
First, define the operator class. Then import it in your DAG file. Next, create an instance with parameters. Finally, add it to the DAG's task flow.