【正解】A
【0からの解説】
①前提知識
・Dataflow のジョブは「リージョン」を指定して実行します。リージョンはジョブのメタデータ管理やワーカーの配置先を決めるもので、ゾーンを指定しなければ Dataflow がワーカーの配置を自動で決めます。
・Dataflow Shuffle（バッチジョブの既定）や Streaming Engine を使うジョブには「リージョン配置」が適用され、ワーカー プールはリージョン内の利用可能なすべてのゾーンを使います。ゾーン障害が起きても、ワーカーが他のゾーンで再作成されるため、ジョブは処理を継続できます。シャッフルや状態（ステート）はワーカーのディスクではなく、Dataflow のマネージドなバックエンド サービス側で管理されます。
②問題文の要件の整理
・Cloud Storage → 変換 → BigQuery のステートフルなパイプライン
・高可用性、us-central1 内のゾーン障害への耐性
・ゾーン障害時の中断を最小限にする
③正解の理由
--region=us-central1 だけを指定してゾーンを固定しなければ、Dataflow がリージョン内の複数ゾーンにワーカーを配置・再配置でき、単一ゾーンの障害の影響を受けにくくなります。Dataflow のドキュメントでも、可用性の観点から --worker_zone / --workerZone で単一ゾーンに固定することは推奨されず、--region と Streaming Engine または Dataflow Shuffle を組み合わせて使うよう案内されています。状態の管理は Dataflow のバックエンドが担うため、利用者が状態の保存先を用意する必要もありません。
【誤りの選択肢】
B：単一ゾーンにデプロイすると、そのゾーンの障害でワーカーがすべて停止するため要件を満たしません。また Dataflow には、パイプラインの状態をリージョン永続ディスクに保存するような構成オプションはなく、状態は Dataflow Shuffle / Streaming Engine などのサービス側で管理されます。
C：同じく単一ゾーン配置が単一障害点になります。Cloud Storage バケットはステージングや一時ファイルの場所として指定するものであり、パイプラインの状態の保存先として構成するものではありません。ゾーン障害でワーカーが止まる問題も解決しません。
D：ゾーンを指定するとワーカーがそのゾーンに固定され、ゾーン障害時に処理が中断します。なお、正しいゾーン名の形式は us-central1-a であり、zone オプションは非推奨（Apache Beam SDK 2.17.0 以前向け）です。
【参考】
Dataflow のリージョンバッチジョブの Dataflow Shuffle