卒業クイズ:自動化パイプラインを構築しよう
ストーリー
「最終試験だ。今月学んだCI/CDとIaCの全範囲から出題する」
木村先輩が真剣な表情で言った。
「ここを突破すれば、自動化パイプラインのミッション完了だ。 CI/CDの概念、GitHub Actionsの実践、Terraformの基礎と応用...... 全ての知識を総動員して挑んでくれ」
「やってみます!」
「合格したら、チームのCI/CDパイプラインの構築を 任せられるレベルだ。自信を持て」
クイズの説明
今月の全ステップの内容から出題します。
- 全8問
- 合格ライン: 80%(7問正解)
- 不合格の場合は、該当ステップを復習してから再挑戦してください
問題
Q1. CI/CDパイプラインにおいて「テストピラミッド」の考え方に基づく正しいテスト配分はどれですか?
- A) E2Eテスト70%、結合テスト20%、単体テスト10%
- B) 単体テスト70%、結合テスト20%、E2Eテスト10%
- C) 全てのテストを均等に33%ずつ
- D) E2Eテストのみ100%
正解: B
テストピラミッドでは、底辺に位置する単体テストを最も多く(約70%)、次に結合テスト(約20%)、最上部のE2Eテスト(約10%)という配分が推奨されます。単体テストは実行が速く、コストが低く、問題の特定が容易です。E2Eテストは実行に時間がかかり不安定になりやすいため、重要なシナリオに限定します。
</details>Q2. 以下のGitHub Actionsワークフローで、deploy ジョブが実行される条件として正しいものはどれですか?
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- run: npm test
deploy:
needs: test
if: github.event_name == 'push' && github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- run: echo "Deploying..."- A) PRが作成された時にtestとdeployの両方が実行される
- B) mainブランチへのpush時にtest成功後にdeployが実行される
- C) 全てのブランチへのpushでdeployが実行される
- D) testジョブが失敗してもdeployは実行される
正解: B
deploy ジョブには2つの条件があります: (1) needs: test でtestジョブの成功が必須、(2) if でpushイベントかつmainブランチの場合のみ実行。PR時はtestジョブのみ実行され、deployのif条件を満たさないため実行されません。mainへのpush(マージ)時にtest成功後にdeployが実行されます。
Q3. GitHub Actionsのマトリクス戦略で以下の定義をした場合、生成されるジョブの数はいくつですか?
strategy:
matrix:
node-version: [18, 20]
os: [ubuntu-latest, macos-latest]
exclude:
- node-version: 18
os: macos-latest- A) 2
- B) 3
- C) 4
- D) 6
正解: B
マトリクスの全組み合わせは 2 x 2 = 4 ですが、exclude で Node 18 + macOS の組み合わせが除外されるため、実際に生成されるジョブは3つです。(1) Node 18 + ubuntu, (2) Node 20 + ubuntu, (3) Node 20 + macOS。
Q4. Terraformで既存のAWSリソースをTerraform管理下に取り込むコマンドはどれですか?
- A)
terraform get - B)
terraform import - C)
terraform refresh - D)
terraform taint
正解: B
terraform import は、手動やAWSコンソールで作成された既存のリソースをTerraformのStateに取り込むコマンドです。例えば terraform import aws_instance.web i-0abc123 で、既存のEC2インスタンスをTerraform管理下に置くことができます。取り込んだ後は、対応する .tf ファイルにリソース定義を記述する必要があります。
Q5. Terraformのリモートバックエンド(S3 + DynamoDB)でDynamoDBが果たす役割はどれですか?
- A) Stateファイルのバックアップ保存
- B) Terraformの実行ログの保存
- C) 同時実行時の排他制御(ロック)
- D) AWSリソースの作成キューの管理
正解: C
DynamoDBテーブルは、Terraformの State ロックに使用されます。複数の開発者やCI/CDパイプラインが同時に terraform apply を実行した場合、DynamoDBのロック機構により1つの実行だけがStateを変更でき、State の競合や破損を防ぎます。Stateファイル自体はS3に保存されます。
Q6. 以下のTerraformコードのセキュリティ上の問題点はどれですか?
resource "aws_security_group" "web" {
name = "web-sg"
vpc_id = aws_vpc.main.id
ingress {
from_port = 0
to_port = 65535
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}- A) VPC IDの参照方法が間違っている
- B) セキュリティグループの名前が不適切
- C) 全ポートが全世界に公開されており、最小権限の原則に違反している
- D) egressルールが定義されていない
正解: C
このセキュリティグループは、全TCPポート(0〜65535)を全世界(0.0.0.0/0)に公開しています。これは最小権限の原則に大きく違反しており、SSH(22)、データベース(3306, 5432)など全てのポートが攻撃対象になります。正しくは、必要なポート(HTTP:80, HTTPS:443等)のみを必要なソースからのアクセスに限定すべきです。
</details>Q7. GitHub Actionsのキャッシュ(actions/cache)とアーティファクト(actions/upload-artifact)の使い分けとして正しいものはどれですか?
- A) キャッシュはビルド成果物の保存、アーティファクトは依存関係の高速復元に使う
- B) キャッシュは依存関係の高速復元、アーティファクトはビルド成果物のジョブ間受け渡しに使う
- C) キャッシュとアーティファクトは同じ機能で、名前が異なるだけ
- D) キャッシュはGitHub UIからダウンロードでき、アーティファクトはできない
正解: B
キャッシュは node_modules や pip キャッシュなどの依存関係を高速に復元するための仕組みで、ワークフローの実行時間を短縮します。アーティファクトは dist/ などのビルド成果物やテストレポートをジョブ間で受け渡したり、GitHub UIからダウンロードしたりするための仕組みです。キャッシュは7日で自動削除、アーティファクトは設定した保持期間で管理されます。
Q8. CI/CDとIaCを組み合わせた完全自動化パイプラインの説明として最も適切なものはどれですか?
- A) アプリケーションのデプロイだけを自動化すれば完全自動化である
- B) アプリのCI/CDとインフラのIaCをそれぞれ独立して運用し、手動で連携する
- C) アプリケーションコードの変更はCI/CDで、インフラの変更はTerraform + CI/CDで、両方がGitを通じてコードレビュー・自動テスト・自動デプロイされる
- D) 全てのインフラ変更はAWSコンソールで行い、CI/CDはアプリケーションにのみ適用す る
正解: C
完全自動化パイプラインでは、アプリケーションコードとインフラコードの両方がGitリポジトリで管理され、PRベースのコードレビュー、自動テスト(CI)、自動デプロイ(CD)の対象となります。アプリの変更は通常のCI/CDパイプラインで、インフラの変更はTerraform plan(PR時)とapply(マージ後)で自動化されます。パスフィルタにより、変更されたファイルに応じて適切なパイプラインのみが実行されます。
</details>結果
7問以上正解の場合
合格です。おめでとうございます。ミッション完了です!
「自動化パイプラインを構築しよう」ミッションを完了しました。
木村先輩が握手を差し出した。
「よくやった。これでCI/CDとIaCの基礎は身についた。 明日からチームのパイプライン構築を任せられるレベルだ。 でも忘れるな、自動化は手段であって目的じゃない。 チームが安心して高品質なソフトウェアを届け続けること。 それが本当のゴールだ」
6問以下の場合
もう少し復習しましょう。
| 問題 | 復習セクション |
|---|---|
| Q1 | Step 1 - step1_5 CI/CDのベストプラクティス |
| Q2 | Step 2 - step2_2 ワークフロー構文, step2_3 トリガーとイベント |
| Q3 | Step 3 - step3_2 マトリクスビルドと並列実行 |
| Q4 | Step 4 - step4_3 プロバイダとState管理 |
| Q5 | Step 4 - step4_3 プロバイダとState管理 |
| Q6 | Step 5 - step5_4 IaCセキュリティとベストプラクティス |
| Q7 | Step 3 - step3_4 キャッシュとアーティファクト |
| Q8 | Step 6 - step6_1 総合演習 |
ミッション完了
お疲れさまでした。
今月学んだこと
| ステップ | 内容 |
|---|---|
| Step 1 | CI/CDの概念、CIの原則、CDのデプロイ戦略、ツール比較 |
| Step 2 | GitHub Actionsの基本、ワークフロー構文、トリガー、Marketplace |
| Step 3 | テスト戦略、マトリクスビルド、シークレット管理、キャッシュ |
| Step 4 | IaCの概念、HCL構文、プロバイダ、State管理、変数とモジュール |
| Step 5 | AWS×Terraform、ネットワークIaC、GitHub Actions連携、セキュリティ |
| Step 6 | CI/CD + IaC 完全自動化パイプライン |
身についたスキル
- CI/CDパイプラインの設計と構築
- GitHub Actionsでのワークフロー作成
- マトリクスビルド、キャッシュ、シークレット管理
- Terraformの基本構文とAWSリソース管理
- Terraform + GitHub Actionsの連携
- IaCセキュリティとベストプラクティス
次のステップ(推奨学習)
- Docker + Kubernetes によるコンテナオーケストレーション
- AWS CDK / Pulumi によるプログラマブルIaC
- Terragrunt によるTerraformのDRY化
- ArgoCD / Flux によるGitOps
- 監視・オブザーバビリティ(Prometheus, Grafana, Datadog)
推定所要時間: 60分