GitHub Actions 模擬試験
### 再利用可能なWorkflowに権限を渡す際の正しい記述はどれですか？
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#access-and-permissions
1. [x] 呼び出し元Workflowから渡された `GITHUB_TOKEN` の権限は、呼び出されたWorkflowによってのみ制限（ダウングレード）することができる。
1. [ ] 呼び出し元Workflowから渡された `GITHUB_TOKEN` の権限は、呼び出されたWorkflowによってのみ引き上げ（エレベート）することができる。
1. [ ] 呼び出し元Workflowから渡された `GITHUB_TOKEN` の権限は、呼び出されたWorkflowによって制限および引き上げの両方が可能である。
1. [ ] 呼び出し元Workflowから渡された `GITHUB_TOKEN` の権限は、呼び出されたWorkflowによって制限も引き上げもできない。
### `permissions` ブロックで `GITHUB_TOKEN` に割り当てられる異なる権限レベルは何ですか？
> https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
1. [x] none, write, read
1. [ ] read, write, delete
1. [ ] read, write
### `permissions` を使用して `GITHUB_TOKEN` の権限を変更できるのはどのレベルですか？（2つ選択）
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token
- [x] Workflow レベル
- [x] Job レベル
- [ ] Step レベル
### GitHub Actions はパブリックRepositoryに対して無料ですか？
1. [x] はい
1. [ ] いいえ
### 次のうち、Workflowをトリガーする有効なイベントではないものはどれですか？
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Repositoryのクローン
1. [ ] masterブランチへのファイルのCommit
1. [ ] Branchの作成
1. [ ] Pull Requestへのラベル追加
### Workflowについて正しいのはどれですか？（3つ選択）
> https://docs.github.com/en/actions/using-workflows/about-workflows
- [x] Workflowは1つまたは複数のJobを同時に実行できる
- [x] Workflowは手動、イベント、またはスケジュールによってトリガーできる
- [x] Workflowは `.github/workflows` ディレクトリに定義する必要がある
- [ ] Workflowはスケジュールでのみ実行できる
- [ ] Workflowは1度に1つのJobしか実行できない
- [ ] Workflowは `.yaml`、`.json`、`.toml` のいずれかの形式で記述できる
- [ ] WorkflowはGitHub Marketplaceで共有できる
> GitHub Marketplaceで共有できるのはActions（Workflowではない）
### Workflowに必要なコンポーネントはどれですか？（2つ選択）
> https://docs.github.com/en/actions/using-workflows/about-workflows#workflow-basics
- [x] Workflowをトリガーする1つ以上のイベント
- [x] 1つ以上のJob
- [ ] Workflow名
- [ ] Workflowが実行されるBranchの定義
### Repositoryの外部からのWebhookアクションによってトリガーされるイベントはどれですか？
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
1. [x] repository_dispatch
1. [ ] webhook_dispatch
1. [ ] workflow_dispatch
1. [ ] remote_dispatch
1. [ ] api_dispatch
### Workflowはどの形式で定義されますか
1. [x] yaml
1. [ ] toml
1. [ ] json
1. [ ] xml
### Workflowで使用するパスワードや証明書などの機密データはどこに保存すべきですか
1. [x] secrets
1. [ ] config variables
1. [ ] vault
1. [ ] environment variables
### 複数のJobを持つWorkflowにおけるデフォルトの動作はどれですか？
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] すべてのJobは並列に実行される
1. [ ] Jobは順番に実行される
### Job BがJob Aの完了を必要とする場合、何をすべきですか？
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] Job Bで `needs` キーワードを使用して依存関係を作成する
1. [ ] Job Aで `needs` キーワードを使用して依存関係を作成する
1. [ ] Job Bで `requires` キーワードを使用して依存関係を作成する
1. [ ] Job Aで `requires` キーワードを使用して依存関係を作成する
### 複数のJobを持つWorkflowで、Job Aが失敗した場合はどうなりますか？
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] Job Aに依存しているJobはスキップされる
1. [ ] Job Aに依存しているJobは失敗する
1. [ ] Workflowは即座に他のすべてのJobをキャンセルする
### このコードはmatrix戦略を使用して6つの異なるJobを並列に起動します。matrix戦略を使用してWorkflow全体を並列化できますか？
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-a-matrix-strategy-with-a-reusable-workflow
1. [ ] いいえ
1. [x] はい
### 構文的に正しいmatrix Jobの定義はどれですか？
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [x]
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
1. [ ]
```yaml
jobs:
example_matrix:
matrix:
strategy:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
1. [ ]
```yaml
jobs:
example_matrix:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
1. [ ]
```yaml
jobs:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
### matrix戦略のJobでmatrix変数にアクセスするにはどうしますか？
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [ ] `vars` コンテキストを使用する
1. [x] `matrix` コンテキストを使用する
1. [ ] `job` コンテキストを使用する
1. [ ] `jobs` コンテキストを使用する
### `pull_request` および `pull_request_target` イベントを使用する場合、`prod` ブランチを対象とするときだけWorkflowを実行するにはどう設定しますか？
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-filters-to-target-specific-branches-for-pull-request-events
1. [x] `branches` フィルターを使用する
1. [ ] `branch` フィルターを使用する
1. [ ] Workflowを`prod`ブランチ上にのみ作成する
1. [ ] globパターンを使用する
### このWorkflowは次の場合にすべてのPull Requestで実行されます:
```yaml
on:
pull_request:
branches:
- 'release/**'
- '!release/**-alpha'
```
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#example-including-and-excluding-branches
1. [x] 対象ブランチ名が `release` で始まり、かつ `-alpha` で終わらない場合
1. [ ] 対象ブランチ名が `release` で始まる場合
1. [ ] ソースブランチ名が `release` で始まり、かつ `-alpha` で終わらない場合
1. [ ] ソースブランチ名が `release` で始まる場合
### 空欄を埋めてください: `push` イベントトリガーフィルターを使用する場合、複数のブランチを対象にするには <____> パターンを使用できます
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-filters-to-target-specific-branches-or-tags-for-push-events
1. [x] glob
1. [ ] regex
1. [ ] scheme
1. [ ] action
### GitHub UIから手動でWorkflowをトリガーできるイベントはどれですか？
> https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow
1. [x] workflow_dispatch
1. [ ] manual_dispatch
1. [ ] workflow_trigger
1. [ ] manual_trigger
### 手動でトリガーされるWorkflowの入力変数の型として可能なのはどれですか？（5つ選択）
> https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputsinput_idtype
- [x] choice
- [x] boolean
- [x] string
- [x] number
- [x] environment
- [ ] dropdown
- [ ] select
### `workflow_dispatch` イベントトリガーのみを持つWorkflowは、GitHubのREST APIを使用してトリガーできます
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs
1. [x] 正しい
1. [ ] 誤り
### ソースコードを変更せずに一時的にWorkflowの実行を止めるにはどうしますか？
> https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow
1. [x] GitHub Actionsの `Disable workflow` オプションを使用する
1. [ ] このWorkflowに必要なsecretsを削除する
1. [ ] このWorkflowに必要なenvironmentを削除する
1. [ ] mainブランチへの新しいCommitを禁止する
### イベントの `activity types` は何のために使用されますか？
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] `types` フィルターを使用して特定のアクティビティタイプにWorkflowの実行を制限する
1. [ ] アクティビティがユーザーまたはボットからのものであるかを確認する
1. [ ] Repositoryでの新しいアクティビティ（例: 新しいコントリビューター）に反応する
### コード変更時に品質チェック、Lint、テストを実行する再利用可能なWorkflow `CI` を作成したい。他のWorkflowから再利用できるようにするには、`CI` Workflowでどのイベントトリガーを定義すべきですか？
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
1. [x] workflow_call
1. [ ] workflow_trigger
> そのようなイベントトリガーは存在しない
1. [ ] workflow_dispatch
> これは手動トリガー用
1. [ ] workflow_run
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
### `build` という名前の再利用可能なWorkflowがzipファイルの成果物を作成します。`build` Workflowを呼び出す呼び出し元Workflowにzipファイルの場所を渡すにはどうしますか？（3つ選択）
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow
- [x] `build` WorkflowでWorkflowレベルのoutputを定義する
- [x] `build` WorkflowでJobレベルのoutputを定義する
- [x] `build` Workflow内のステップで `$GITHUB_OUTPUT` にoutputを書き込む
- [ ] すべてのoutputは自動的に呼び出し元Workflowに渡される
### **defaults** を使用する有効なユースケースはどれですか？（2つ選択）
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaults
- [x] Workflowレベルでdefaults.runを使用して、Workflow全体のデフォルトシェル（例: bash）を設定する
- [x] Jobレベルでdefaults.runを使用して、そのJob内のすべてのステップのデフォルト作業ディレクトリを設定する
- [ ] Stepレベルでdefaults.runを使用して、そのステップのみのデフォルトシェル（例: bash）を設定する
> defaults.runはWorkflowまたはJobレベルでのみ設定可能
- [ ] Workflowレベルでdefaults.envを使用して、Workflow全体のデフォルト環境変数を設定する
> defaults.envは存在しない
- [ ] Jobレベルでdefaults.envを使用して、そのJob内のすべてのステップのデフォルト環境変数を設定する
> defaults.envは存在しない
### `Deploy Prod` というWorkflowが常に同時に1つだけ実行されるようにするにはどうしますか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
1. [x] Workflowレベルで `concurrency` を使用する
```yaml
concurrency: ${{ github.workflow }}
```
1. [ ] Workflowレベルで `queue` を使用する
```yaml
queue: ${{ github.workflow }}
```
1. [ ] Workflowレベルで `order` を使用する
```yaml
order: ${{ github.workflow }}
```
1. [ ] Workflowレベルで `parallel` を使用する
```yaml
parallel: ${{ github.workflow }}
```
### Pull Request解析Workflowでは複数のコード解析ツールを使用しており、完了までに約20分かかります。このWorkflowは `pull_request` イベントで `branches` フィルターを `master` に設定してトリガーされています。そのため、開発者が数分以内に複数のCommitをプッシュすると複数のWorkflowが並列で実行されます。すべての以前のWorkflow実行を停止し、最新の変更のみを実行するにはどうしますか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-concurrency-to-cancel-any-in-progress-job-or-run
1. [x] cancel-in-progressを使用したconcurrencyを使う
```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
```
1. [ ] concurrencyを使用する
```yaml
concurrency:
group: ${{ github.ref }}
```
> これはそのgithub refで実行をキューに入れるだけで、以前の実行は停止しない
1. [ ] activity typesフィルターを使用する
```yaml
on:
pull_request:
branches:
- master
types: [latest]
```
> pull_requestイベントに `latest` というactivity typeは存在しない
1. [ ] `pull_request` イベント用のcancel-in-progressフラグを使用する
```yaml
on:
pull_request:
branches:
- master
cancel-in-progress: true
```
### いつjob3は実行されますか？
```yaml
jobs:
job1:
job2:
needs: job1
job3:
if: ${{ always() }}
needs: [job1, job2]
```
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-not-requiring-successful-dependent-jobs
1. [x] job1とjob2が完了した後、成功したかどうかに関係なくjob3が実行される
1. [ ] `if: ${{ always() }}` と `needs` を同時に使用することはできない。Workflowは起動時に失敗する
1. [ ] job1とjob2が両方とも正常に完了した後にjob3が実行される
1. [ ] job1とjob2が両方とも失敗した後にjob3が実行される
### `jobs.job_id.if` 条件式で、job `production-deploy` を `my-org/my-repo` Repositoryでのみ実行するようにするにはどれですか？（2つ選択）
```yaml
jobs:
production-deploy:
if: <CONDITION>
runs-on: ubuntu-latest
steps:
...
```
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
- [x] `if: github.repository == 'my-org/my-repo'`
- [x] `if: ${{ github.repository == 'my-org/my-repo' }}`
- [ ] `if: ${{ github.organization == 'my-org' && github.repository == 'my-repo' }}`
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
- [ ] `if: ${{ github.org == 'my-org' && github.repository == 'my-repo' }}`
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
### 利用可能な GitHub ホスト型ランナーの種類はどれですか？（3つ選択）
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners
- [x] Windows
- [x] Ubuntu Linux
- [x] macOS
- [ ] Android
### この記述は正しいですか？ ステップは必ずしもアクションを実行するとは限りませんが、アクションは必ずステップとして実行されます。
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps
1. [x] 正しい
1. [ ] 誤り
> ステップは必ずしも Actions を実行する必要はありません（例: run コマンドの実行）
### GitHub Marketplace で公開されている任意の Action について、複数のバージョンで使用できる場合、最も安定かつ安全な方法はどれですか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-versioned-actions
1. [x] コミット SHA を参照する
1. [ ] バージョンタグを参照する
1. [ ] main ブランチを参照する
### ステップの1つが失敗してもジョブを失敗させないようにするには、次のどれを含めますか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error
1. [x] 失敗するステップに `continue-on-error` フラグを設定する
```yaml
steps:
- uses: my-org/failing-action@v1
continue-on-error: true
```
1. [ ] 失敗するステップに `ignore-error` フラグを設定する
```yaml
steps:
- uses: my-org/failing-action@v1
ignore-error: true
```
1. [ ] 失敗するステップに `failure()` 条件を設定する
```yaml
steps:
- uses: my-org/failing-action@v1
if: failure()
```
1. [ ] 失敗するステップに `always()` 条件を設定する
```yaml
steps:
- uses: my-org/failing-action@v1
if: always()
```
### matrix ジョブ `example_matrix` を定義しました。最大2つのジョブのみを同時に実行するよう制限するにはどうしますか？
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymax-parallel
1. [x] `jobs.example_matrix.strategy.max-parallel` を 2 に設定する
1. [ ] `jobs.example_matrix.strategy.concurrency` を 2 に設定する
1. [ ] GitHub REST API を使用してジョブ数が2未満か確認する
1. [ ] 実行可能なランナーがあれば、matrix は常に全ジョブを並列実行するため制限できない
### `step` 内で値 `DOG` を持つ出力パラメータ `PET` を設定する正しい方法はどれですか？
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter
1. [x] `echo "PET=DOG" >> "$GITHUB_OUTPUT"`
1. [ ] `echo "DOG=PET" >> "$GITHUB_OUTPUT"`
1. [ ] `gh set-output "DOG=PET"`
1. [ ] `gh set-output "PET=DOG"`
### `step_two` で `action_state` を使用する方法として正しいのはどれですか？
```yaml
steps:
- name: Set the value
id: step_one
run: |
echo "action_state=yellow" >> "$GITHUB_ENV"
- name: Use the value
id: step_two
run: ?
```
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-of-writing-an-environment-variable-to-github_env
1. [x] `run: echo "$action_state"`
1. [ ] `run: echo "${{ steps.step_one.outputs.action_state }}"`
> これは `action_state` が `$GITHUB_OUTPUT` に書き込まれている場合
1. [ ] `run: echo "$steps.step_one.outputs.action_state"`
1. [ ] `run: echo "${{ action_state }}"`
### この記述は正しいですか？ Workflowsは再利用できるが、再利用可能なWorkflowは別の再利用可能なWorkflowを呼び出すことはできない。
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#nesting-reusable-workflows
1. [x] 誤り
1. [ ] 正しい
> 再利用可能なWorkflowsはネスト可能だが、制限がある https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations
### 次の例では、`workflow A` が inherit キーワードを使ってすべてのsecretsを `workflow B` に渡しています。その後、`workflow B` が `workflow C` を呼び出します。この例における `secrets` に関する正しい記述はどれですか？
```yaml
jobs:
workflowA-calls-workflowB:
uses: octo-org/example-repo/.github/workflows/B.yml@main
secrets: inherit
```
```yaml
jobs:
workflowB-calls-workflowC:
uses: different-org/example-repo/.github/workflows/C.yml@main
```
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#passing-secrets-to-nested-workflows
1. [x] `workflow A` で利用可能なすべてのsecretsは `workflow B` でも利用可能だが、`workflow C` では利用できない
1. [ ] `octo-org` Organizationおよび `octo-org/example-repo` Repositoryのすべてのsecretsは `workflow B` で利用可能だが、`workflow C` では利用できない
> `octo-org` Organizationのすべてのsecretsを`octo-org/example-repo`に公開する必要はない
1. [ ] `workflow A` で利用可能なすべてのsecretsは `workflow B` および `workflow C` でも利用可能である
> `workflow B` が `workflow C` を呼び出す際に `secrets: inherit` を追加する必要がある
1. [ ] `workflow A` で利用可能なRepositoryおよびEnvironmentのsecretsのみが `workflow B` で利用可能で、`workflow C` では利用できない。Organizationスコープのsecretsは継承できない
### `caching` を使用すべきなのはどのような場合ですか？
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
1. [x] パッケージ管理システムのビルド依存関係など、JobやWorkflowの実行間であまり変化しないファイルを再利用したい場合
1. [ ] パッケージ管理システムのビルド依存関係など、JobやWorkflowの実行間で頻繁に変化するファイルを再利用したい場合
1. [ ] ビルドされたバイナリやビルドログなど、Workflow実行後に確認するためにJobが生成したファイルを保存したい場合
> その場合はArtifactsを使用する https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
1. [ ] アプリケーションの新バージョンをデプロイするために、ビルドJobで生成されたバイナリを後続のデプロイJobで使用する場合
> その場合はArtifactsを使用する https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
### `artifacts` を使用すべきなのはどのような場合ですか？（2つ選択）
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#about-workflow-artifacts
- [x] テスト結果やビルドログなど、Workflow実行後に確認するためにJobが生成したファイルを保存する場合
- [x] アプリケーションの新バージョンをデプロイするために、ビルドJobで生成されたバイナリを後続のデプロイJobで使用する場合
- [ ] パッケージ管理システムのビルド依存関係など、JobやWorkflowの実行間であまり変化しないファイルを再利用する場合
> その場合はCachingを使用する https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
- [ ] リリースノートやメンション、コントリビューター情報と共にアプリケーションの新バージョンを作成する場合
> それはArtifactsではなくReleasesのユースケース
### `feature-a` ブランチでWorkflowが実行された場合、デフォルトブランチ `main` で作成された `caches` を復元できますか？
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache
1. [x] はい、すべてのブランチはデフォルトブランチで作成されたcachesを復元できる
1. [ ] はい、同じRepository内のすべてのブランチはすべてのcachesにアクセスできる
1. [ ] いいえ、cachesは同じブランチからのみ復元できる
1. [ ] はい、ただし `feature-a` ブランチでファイルが変更されていない場合に限る
### 別の以前にトリガーされたWorkflow実行で作成された `artifact` にアクセスするにはどうしますか？
> https://github.com/actions/download-artifact?tab=readme-ov-file#download-artifacts-from-other-workflow-runs-or-repositories
1. [ ] 別のWorkflow実行で作成された `artifact` にはアクセスできない
1. [x] `actions/download-artifact` Actionを昇格した権限で使用する
1. [ ] `actions/upload-artifact` Actionを使用する
1. [ ] `actions/download-artifact` Actionを使用し、artifactが期限切れでないことを確認する
### Repositoryの自動テストを実行するWorkflowで生成されたカバレッジレポートやスクリーンショットを保存するには何を使用すべきですか？
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#comparing-artifacts-and-dependency-caching
1. [x] Artifacts
1. [ ] Caches
1. [ ] Packages
> https://docs.github.com/en/packages/learn-github-packages/introduction-to-github-packages
1. [ ] Releases
> https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases
### `actions/upload-artifact` Actionを使用する場合、一度に1つのファイルしかアップロードできない
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#uploading-build-and-test-artifacts
1. [x] 誤り
1. [ ] 正しい
### Job `deploy` で、Job `build` で作成された（アプリケーションを含む）バイナリにアクセスしたい場合はどうしますか？
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#comparing-artifacts-and-dependency-caching
1. [x] `build` でバイナリをArtifactsとしてアップロードし、`deploy` でそれをダウンロードする
1. [ ] `deploy` でバイナリをArtifactsとしてアップロードし、`build` でそれをダウンロードする
1. [ ] `build` でバイナリをcacheし、`deploy` でcacheからファイルを読む
1. [ ] `deploy` でバイナリをcacheし、`build` でcacheからファイルを読む
### `job2` が `job1` で作成されたArtifactsを使用しています。そのため、`job1` が完了してから `job2` がArtifactsを探し始めるようにする必要があります。この依存関係はどのように作成しますか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] `job2` で `needs` キーワードを使用して依存関係を作成する
1. [ ] `job1` からArtifactをダウンロードするために `actions/download-artifact` を使用すると、この依存関係は暗黙的に作成される
1. [ ] Workflowの `.yaml` 定義で `job1` の後に `job2` を定義して依存関係を作成する
1. [ ] `job2` で `concurrency` キーワードを使用して依存関係を作成する
### `Starter Workflows` について正しいのはどれですか？（3つ選択）
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [x] 最小限の変更で使える、またはすぐに使えるWorkflowテンプレートを利用できる
- [x] GitHubはさまざまなカテゴリ、言語、ツール向けにStarter Workflowsを提供し、保守している
- [x] 自分のOrganizationで、Organization内のユーザー向けにカスタムStarter Workflowsを作成できる
- [ ] Starter Workflowsは再利用可能なWorkflowを呼び出すことはできない
- [ ] Starter WorkflowsはGitHubの有料機能である
- [ ] Starter Workflowsは提供された状態でそのまま使用するもので、変更や拡張はできない
> https://docs.github.com/en/actions/using-workflows/using-starter-workflows#using-starter-workflows
### Secretsと構成変数(Configuration Variables) はどのスコープに設定できますか？（3つ選択）
> https://docs.github.com/en/actions/using-workflows/sharing-workflows-secrets-and-runners-with-your-organization#sharing-secrets-and-variables-within-an-organization
- [x] Organization全体、またはOrganization内の特定のRepository
- [x] 単一のRepository
- [x] Repository内のEnvironment
- [ ] 複数のRepositoryで共有されるEnvironment
> EnvironmentはRepository間で共有できない
- [ ] OrganizationやEnterpriseを共有していない複数のRepository
- [ ] Repository内の特定のWorkflow
> 環境変数はWorkflow単位でスコープ設定できるが、構成変数はできない
- [ ] Workflow内の特定のJob
> 環境変数はWorkflow単位でスコープ設定できるが、構成変数はできない
### Actionsの種類は3つあります。それは何ですか？
> https://docs.github.com/en/actions/creating-actions/about-custom-actions#types-of-actions
1. [x] `Docker container actions`、`JavaScript Actions`、`Composite Actions`
1. [ ] `Python Actions`、`JavaScript Actions`、`Custom Actions`
1. [ ] `Docker container Actions`、`JavaScript Actions`、`Custom Actions`
1. [ ] `Docker container actions`、`Java Actions`、`Composite Actions`
### 次の記述は正しいですか？ Dockerコンテナアクションは、通常、JavaScriptアクションよりも遅いです。
> Docker container actions は JavaScript actions よりも遅い
1. [x] 正しい
1. [ ] 誤り
> コンテナのビルドおよび取得にかかる待ち時間のため、Docker container actions は JavaScript actions よりも遅い
### カスタムGitHub Actionを作成する場合、そのソースコードは `.github/workflows` ディレクトリに保存しなければならない
> https://docs.github.com/en/actions/creating-actions/about-custom-actions#choosing-a-location-for-your-action
1. [x] 誤り
1. [ ] 正しい
> `.github/workflows` はWorkflow用であり、Actions用ではない
### カスタムGitHub Actionsを作成する際、すべてのActionの `metadata` を定義する必要があるファイルはどれですか？
Metadata例: name、description、outputs、必須inputsなど
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions
1. [x] ActionのRepository内の `action.yml` または `action.yaml` ファイル
1. [ ] Repositoryの `README` ファイル
> 推奨ではあるが、Actionが動作するための必須条件ではない
1. [ ] 公開時にGitHub MarketplaceのUIで編集する
1. [ ] ActionのRepository内の `action.yml` または `action.yaml` ファイル（ただし、公開や共有を目的としない場合は必須ではない）
> すべてのActionsにmetadataファイルは必須
### Workflowが最初に `commit A` で実行され失敗しました。次の `commit B` でWorkflowを修正しました。Workflowを再実行すると、どのCommitのコードで実行されますか？
> https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs#about-re-running-workflows-and-jobs
1. [x] `commit A` のコードで実行される
1. [ ] `commit B` のコードで実行される
> Workflowの再実行では、元の実行をトリガーしたイベントと同じcommit SHAおよびGit refが使用される
1. [ ] GitHub ActionsではWorkflowを再実行できない。最新の変更でWorkflowを実行するには新たにトリガーする必要がある
1. [ ] `commit A` のコードと `commit B` のコードでそれぞれ1つずつ、合計2つのWorkflowがトリガーされる
### `production` Environmentを対象とするWorkflow実行に対して、メンテナーによる手動承認を必須にするにはどうしますか？
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
1. [x] デプロイ保護ルールを使用する
1. [ ] `production` Workflow内で必須レビュアーを設定する
1. [ ] Branch保護ルールを使用する
1. [ ] GitHub Actionsでは手動承認はサポートされていない
### Environmentsについて正しい記述はどれですか？
> Workflow内の各Jobは単一のEnvironmentを参照できる
1. [x] Workflow内の各Jobは単一のEnvironmentを参照できる
1. [ ] 各Workflowは単一のEnvironmentを参照できる
1. [ ] Workflow内の各Jobは最大2つのEnvironmentを参照できる
1. [ ] 各Workflowは最大2つのEnvironmentを参照できる
### GitHub Actionsを使用してAWS、Azure、GCPなどのクラウドプロバイダーのリソースにアクセスする場合、最も安全で推奨される認証方法はどれですか？
> https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
1. [x] OIDCを使用する
1. [ ] Vaultを使用する
1. [ ] アクセスキーを`secrets`に保存する
> 長期間有効なアクセスキーは、セキュリティ侵害や[スクリプトインジェクション](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#understanding-the-risk-of-script-injections)などの攻撃時に推奨されない
1. [ ] アクセスキーを`variables`に保存する
> `variables`に機密値を保存すべきではない
### オープンソースで公開されているRepositoryに`pull_request`イベントトリガーを持つWorkflowがあります。このRepositoryのForkからトリガーされたWorkflow実行に承認を必須とするにはどうしますか？
> https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks#about-workflow-runs-from-public-forks
1. [x] RepositoryでFork実行に対する必須承認を設定する
1. [ ] Repositoryにデプロイ保護ルールを設定する
> デプロイ保護ルールはEnvironment保護用
1. [ ] RepositoryにBranch保護ルールを設定する
1. [ ] `pull_request`イベントを使用する場合、ForkからのWorkflowはトリガーされない。これを行うには`fork_pull_request`イベントトリガーと`require-approval`フラグを使用する必要がある
### 次のうち、Workflow実行を開始した人物またはアプリ名が含まれるデフォルト環境変数はどれですか？
> https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables
1. [ ] `GITHUB_USER`
1. [ ] `GITHUB_REPOSITORY`
1. [ ] `GITHUB_WORKFLOW`
1. [x] `GITHUB_ACTOR`
### 次のうち、GitHub Actionsのデフォルト環境変数はどれですか？（3つ選択）
> https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables
- [x] `GITHUB_REPOSITORY`
- [x] `GITHUB_WORKFLOW`
- [x] `GITHUB_ACTOR`
- [ ] `GITHUB_USER`
- [ ] `GITHUB_ORGANIZATION`
- [ ] `GITHUB_TOKEN`
### Organizationで定義されたSecret `SomeSecret` を`${{ secrets.SomeSecret }}`で参照したところ、Organizationスコープで設定した値ではなく、別の値が取得されました。原因として最も考えられるのはどれですか？
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#naming-your-secrets
1. [x] 同名のSecret `SomeSecret` がRepositoryスコープでも定義されている
1. [ ] 同名のSecret `SomeSecret` がEnterpriseスコープでも定義されている
> 同じ名前のSecretが複数のレベルに存在する場合、最も低いレベルのSecretが優先される
1. [ ] `${{ secrets.SomeSecret }}` 式はRepositoryスコープのSecret専用である
1. [ ] OrganizationスコープのSecretにアクセスするにはGitHub APIを使用する必要がある
### デバッグメッセージを出力する正しい方法はどれですか？
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-setting-a-debug-message
1. [x] `echo "::debug::Watch out here!"`
1. [ ] `echo ":debug:Watch out here!"`
1. [ ] `echo "::debug::message=Watch out here!"`
1. [ ] `echo "Watch out here!" >> $GITHUB_DEBUG`
### GitHub Enterprise Server を使用している組織が、GitHub.com 上でホストされているサードパーティGitHub ActionsをGitHub Enterprise Serverインスタンスに自動同期できるようにするにはどうすればよいですか？
> https://docs.github.com/en/[email protected]/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect
1. [x] GitHub Connectを使用する
1. [ ] GitHub Enterprise Serverはデフォルトで全てのGitHub.com Actionsにアクセスできる
> GitHub Enterprise ServerのActionsは、インターネットアクセスが制限された環境でも動作するように設計されている。デフォルトではGitHub.comやGitHub MarketplaceのActionsは使用できない
1. [ ] actions-syncツールを使用する
> https://docs.github.com/en/[email protected]/admin/github-actions/managing-access-to-actions-from-githubcom/manually-syncing-actions-from-githubcom#about-the-actions-sync-tool
1. [ ] GitHub Enterprise Serverはオンプレミスの性質上インターネットアクセスがないため、GitHub.com Actionsは使用できない
### GitHub Self-hosted Runnerのネットワーク接続ログはどこで確認できますか？
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners#checking-self-hosted-runner-network-connectivity
1. [x] Runnerマシン上の `_diag` フォルダ内
1. [ ] GitHub.com の該当Runnerのページ
1. [ ] そのRunnerで実行されたJobの実行ログ
1. [ ] デバッグログを有効にしてそのRunnerで実行されたJobの実行ログ
### GitHub Self-hosted Runnerが必要なGitHubサービス全てにアクセスできることを検証するにはどうしますか？
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners#checking-self-hosted-runner-network-connectivity
1. [x] Runnerマシン上でGitHub提供のスクリプトを使用する
1. [ ] `ssh`でRunnerマシンにアクセスしてネットワーク接続を検証する
1. [ ] GitHub Actionsの事前定義Workflow `network-connectivity.yml` を使用する
1. [ ] RunnerアプリケーションをRunnerマシンにインストールした際にGitHubが自動的にネットワーク接続を検証する
### 構成変数(Configuration Variables) `MY_VAR` が `MY_VALUE` の値を持つ場合のみJobをトリガーする正しい方法はどれですか？
> https://docs.github.com/en/actions/learn-github-actions/contexts#example-usage-of-the-vars-context
1. [x] Jobレベルで次の条件を作成する
```yaml
my-job:
if: ${{ vars.MY_VAR == 'MY_VALUE' }}
```
1. [ ] Jobレベルで次の条件を作成する
```yaml
my-job:
if: ${{ vars.MY_VAR }} == 'MY_VALUE'
```
> これは常にTrueと評価される
1. [ ] 構成変数は`if`条件式で使用できないため不可能
> これは`secrets`に関しては正しいが、構成変数には当てはまらない
1. [ ] 構成変数はJobレベルの`if`条件式で使用できないため不可能
> これは`secrets`に関しては正しいが、構成変数には当てはまらない
### Secret `MY_SECRET` が設定されている場合にのみ `step` を実行するにはどうしますか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-secrets
1. [x] Secret `MY_SECRET` をJobレベルの環境変数として設定し、その環境変数を参照して条件付きでStepを実行する
```yaml
my-job:
runs-on: ubuntu-latest
env:
my_secret: ${{ secrets.MY_SECRET }}
steps:
- if: ${{ env.my_secret != '' }}
```
1. [ ] Jobレベルで次の条件を作成する
```yaml
my-job:
runs-on: ubuntu-latest
if: ${{ secrets.MY_SECRET == '' }}
```
> secretsは`if:`条件式で直接参照できない
1. [ ] Stepレベルで次の条件を作成する
```yaml
my-job:
runs-on: ubuntu-latest
steps:
- if: ${{ secrets.MY_SECRET == '' }}
```
> secretsは`if:`条件式で直接参照できない
1. [ ] Stepレベルで次の条件を作成する
```yaml
my-job:
runs-on: ubuntu-latest
steps:
- if: ${{ secrets.MY_SECRET }}
```
> secretsは`if:`条件式で直接参照できない
### GitHub APIを使用してWorkflow実行ログをダウンロードする方法はどれですか？
> https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#download-workflow-run-logs
1. [x] `GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
1. [ ] `POST /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
1. [ ] `HEAD /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
1. [ ] `PUT /repos/{owner}/{repo}/actions/runs/{run_id}/logs`
### GitHub APIを使用してRepository Secretを作成または更新する方法はどれですか？
> https://docs.github.com/en/rest/actions/secrets?create-or-update-a-repository-secret=&apiVersion=2022-11-28#create-or-update-a-repository-secret
1. [x] `PUT /repos/{owner}/{repo}/actions/secrets/{secret_name}`
1. [ ] `POST /repos/{owner}/{repo}/actions/secrets/{secret_name}`
1. [ ] `HEAD /repos/{owner}/{repo}/actions/secrets/{secret_name}`
1. [ ] `GET /repos/{owner}/{repo}/actions/secrets/{secret_name}`
### OrganizationレベルのGitHub Secret `API_KEY` を、Repository内で異なる値に上書きするにはどうしますか？（2つ選択）
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#naming-your-secrets
- [x] 同名の`API_KEY`を持つRepository Secretを作成する
- [x] 同名の`API_KEY`を持つEnvironment Secretを作成する
- [ ] 同名の`API_KEY`を持つEnterprise Secretを作成する
- [ ] `OVERRIDE_API_KEY`という名前のEnterprise Secretを作成する
- [ ] `OVERRIDE_API_KEY`という名前のRepository Secretを作成する
- [ ] `OVERRIDE_API_KEY`という名前のEnvironment Secretを作成する
- [ ] `REPOSITORY_API_KEY`という名前のRepository Secretを作成する
- [ ] `ENVIRONMENT_API_KEY`という名前のEnvironment Secretを作成する
### GitHub Organization内で再利用できるコンポーネントはどれですか？（4つ選択）
- [x] Secrets
- [x] Configuration Variables
- [x] Self Hosted Runners
- [x] Workflow Templates
- [ ] Artifacts
> Artifactsは、ジョブ完了後にデータを保持したり、同じWorkflow内の別のジョブとデータを共有するために使用される
- [ ] Cache
> Cacheは、1つのRepository内のWorkflows間で再利用できる
- [ ] Environment Variables
> 環境変数はステップ、ジョブ、またはWorkflowにスコープできるが、Workflows/Repositories/Organizations間で共有することはできない
### 次のWorkflowでは何個のジョブが実行されますか？
```yaml
jobs:
matrix-job:
runs-on: ubuntu-latest
strategy:
matrix:
pet: [cat, dog]
color: [pink, brown]
include:
- color: white
pet: dog
steps:
- run: echo "Hello ${{ matrix.color }} ${{ matrix.pet }}"
```
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [x] 5
1. [ ] 4
1. [ ] 6
1. [ ] 7
### 次のうち、Workflowが実行されているRepositoryのフルネーム（例: `octocat/hello-world`）を含むデフォルト環境変数はどれですか？
> https://docs.github.com/en/actions/reference/environment-variables#default-environment-variables
1. [x] `GITHUB_REPOSITORY`
1. [ ] `GITHUB_REPOSITORY_ID`
1. [ ] `GITHUB_REPOSITORY_OWNER`
1. [ ] `GITHUB_REPOSITORY_OWNER_ID`
### 複数のジョブを持ち、すべてがGitHub-hosted runner上で実行されるWorkflowでは、すべてのジョブが同じRunnerマシン上で実行されることが保証されますか？
> https://docs.github.com/en/actions/using-jobs/choosing-the-runner-for-a-job#choosing-github-hosted-runners
1. [x] No
1. [ ] Yes
> 各ジョブは、`runs-on`で指定されたRunnerイメージの新しいインスタンスで実行される
### 1つのWorkflowファイルから呼び出せる再利用可能Workflowの最大数はいくつですか？
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations
1. [x] 20
1. [ ] 5
1. [ ] 1
1. [ ] 10
### Self-hosted runnerとは何ですか？
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
1. [x] Self-hosted runnerとは、GitHub.com上のGitHub Actionsのジョブを実行するために、自分でデプロイ・管理するシステムのこと
1. [ ] Self-hosted runnerとは、コードをプライベートサーバーにアップロードするためのシステム
1. [ ] Self-hosted runnerとは、ワークロードを自動生成できるようにするシステム
1. [ ] Self-hosted runnerとは、OrganizationのユーザーからのPull Requestを管理するシステム
### GitHub WorkflowsとActionsに関する正しい記述はどれですか？
> https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
1. [ ] 各Actionは1つ以上のWorkflowで構成され、そのWorkflowは1つ以上のジョブで構成され、各ジョブは1つ以上のステップで構成される
1. [ ] 各Workflowは1つ以上のActionで構成され、そのActionは1つ以上のジョブで構成され、各ジョブは1つ以上のステップで構成される
1. [x] 各Workflowは1つ以上のジョブで構成され、各ジョブは1つ以上のステップで構成され、各ステップはActionまたはスクリプトである
1. [ ] 各Actionは1つ以上のジョブで構成され、各ジョブは1つ以上のステップで構成され、各ステップはWorkflowである
### GitHub ActionsでスケジュールされたWorkflowは、どのCommitとBranch上で実行されますか？
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] スケジュールされたWorkflowは、最後に変更されたBranch上の特定のCommitで実行される
> 誤り。特定のCommitと最後に変更されたBranchの両方
1. [ ] スケジュールされたWorkflowは、main Branch上の特定のCommitで実行される
> 誤り。特定のCommitとmain Branchの両方
1. [x] スケジュールされたWorkflowは、RepositoryのデフォルトBranch上の最新のCommitで実行される
1. [ ] スケジュールされたWorkflowは、main Branch上の最新のCommitで実行される
> 最新のCommitは正しいが、main Branchとは限らない
### ワークフロー内のすべての `run` コマンドでディレクトリを設定する正しい構文はどれですか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunworking-directory
1. [x] `defaults.run` の下に `working-directory` を設定する
```yaml
defaults:
run:
shell: bash
working-directory: ./scripts
```
1. [ ] `defaults.run` の下に `directory` を設定する
```yaml
defaults:
run:
shell: bash
directory: ./scripts
```
1. [ ] `job` の下に `working-directory` を設定する
```yaml
defaults:
run:
shell: bash
job:
working-directory: ./scripts
```
1. [ ] `job` の下に `directory` を設定する
```yaml
defaults:
run:
shell: bash
job:
directory: ./scripts
```
### 定義済みのWorkflowを複数のRepositoryで再利用するにはどうすればよいですか？（2つ選択してください）
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [ ] Workflowファイルを各Repositoryにコピーする
- [x] Workflowテンプレートを使用する
- [ ] 再利用可能なActionを作成する
- [x] 組織の共通RepositoryにWorkflowを定義する
### 特定のBranchでのみジョブを実行するにはどうすればよいですか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#using-filters
1. [x] branchesフィルターを使用する
1. [ ] runs-onフィルターを使用する
1. [ ] jobsフィルターを使用する
1. [ ] branchキーワードを使用する
### GitHub Actions Workflowで `needs` キーワードは何をしますか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] ジョブの依存関係を指定する
1. [ ] 環境変数を定義する
1. [ ] 実行環境を設定する
1. [ ] イベントに基づいてジョブをトリガーする
### GitHub Actions Workflowで環境変数を定義できるキーワードはどれですか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenv
1. [x] env
1. [ ] vars
1. [ ] secrets
1. [ ] config
### GitHub Actions Workflowにおける `with` キーワードの目的は何ですか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith
1. [ ] 環境変数を定義する
1. [x] Actionの入力パラメータを指定する
1. [ ] 依存関係を設定する
1. [ ] 別のWorkflowをトリガーする
### 1つのステップで複数のコマンドを実行するために使用されるGitHub Actionsの構文はどれですか？
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#example-of-a-multiline-string
1. [ ] コマンドを `&&` で連結する
1. [ ] コマンドを配列で定義する
1. [x] `|` を使った複数行文字列を使用する
1. [ ] コマンドをセミコロン `;` で区切る
### Workflowの実行を高速化するために依存関係をキャッシュするにはどうしますか？
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows#about-caching-workflow-dependencies
1. [ ] cacheキーワードを使用する
1. [x] actions/cache Actionを使用する
1. [ ] 依存関係をRepositoryに保存する
1. [ ] storeキーワードを使用する
### GitHub Actions Workflowで `matrix` キーワードは何をしますか？
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-a-matrix-for-your-jobs
1. [x] 複数のジョブ構成を定義して並列実行できるようにする
1. [ ] ジョブ用の環境変数を設定する
1. [ ] スケジュールに基づいてWorkflowをトリガーする
1. [ ] WorkflowのSecretを定義する
### GitHub Actions Workflowで同時に実行されるジョブ数を制限するために使用できるものはどれですか？
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-concurrency
1. [x] concurrency
1. [ ] limit
1. [ ] max-jobs
1. [ ] parallelism
### GitHub Actionsのジョブのデフォルトのタイムアウトは何分ですか？
> https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
1. [ ] 30分
1. [ ] 60分
1. [ ] 120分
1. [x] 360分
### GitHub ActionsでジョブのOSを指定するにはどうしますか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on
1. [ ] osキーワードを使用する
1. [x] runs-onキーワードを使用する
1. [ ] platformキーワードを使用する
1. [ ] envキーワードを使用する
### GitHub Actions Workflowでジョブに使用する特定のNode.jsバージョンを指定するにはどうしますか？
> https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs#specifying-the-nodejs-version
1. [x]
```yaml
uses: actions/setup-node@v4
with:
node-version: 20
```
1. [ ]
```yaml
uses: actions/node-setup@v4
with:
node-version: 20
```
1. [ ]
```yaml
uses: setup-node@v4
with:
version: 20
```
1. [ ]
```yaml
uses: setup-node@v4
with:
node: 20
```
### GitHub Secretsに保存されたSecretをWorkflowで参照するにはどうしますか？
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow
1. [x] ${{ secrets.SECRET_NAME }}
1. [ ] ${{ secret.SECRET_NAME }}
1. [ ] ${{ env.SECRET_NAME }}
1. [ ] ${{ config.SECRET_NAME }}
### WindowsランナーでGitHub Actionsが使用するデフォルトのシェルは何ですか？
> https://github.blog/changelog/2019-10-17-github-actions-default-shell-on-windows-runners-is-changing-to-powershell/
1. [ ] bash
1. [ ] sh
1. [x] powershell
1. [ ] cmd
### GitHub Actionsにセルフホストランナーを追加する際に正しい記述はどれですか？（3つ選択してください）
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners#adding-a-self-hosted-runner-to-a-repository
- [x] Repositoryにセルフホストランナーを追加できる
- [x] Organizationにセルフホストランナーを追加できる
- [x] Enterpriseにセルフホストランナーを追加できる
- [ ] Workflowにセルフホストランナーを追加できる
> Workflowレベルには追加できない
- [ ] ステップにセルフホストランナーを追加できる
> ステップレベルには追加できない
### ジョブを実行しているランナーのOSを含むデフォルトの環境変数はどれですか？
> https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables
1. [x] `RUNNER_OS`
1. [ ] `GITHUB_RUNNER_OS`
1. [ ] `RUNNER_ARCH`
1. [ ] `RUNNER_NAME`
### GitHub Actionsの`actions/cache` Actionは、キャッシュミスが発生した場合にどのように処理しますか？
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [ ] 新しいキャッシュを作成するために手動対応を要求する
1. [ ] 他のRepository内のキャッシュを検索する
1. [x] ジョブが正常に完了した場合、自動的に新しいキャッシュを作成する
1. [ ] キャッシュミスが発生した場合、Workflowを終了する
### GitHub Actions Workflowを平日のみ実行するようスケジュールするにはどうしますか？
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] 平日用の条件をWorkflow YAMLに追加する
1. [ ] GitHub Actionsでは不可能
1. [ ] on: schedule: weekdays イベントトリガーを使用する
1. [x] on: schedule: cron イベントトリガーを使用する
### 48 KBを超えるSecretを保存するための推奨方法はどれですか？
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#limits-for-secrets
1. [ ] セキュリティのため、大きなSecretの保存は避ける
1. [ ] 48 KBを超えるSecretは保存できない
1. [x] 暗号化してRepositoryに保存し、復号用パスフレーズはSecretとして保持する
1. [ ] 制限回避のため、大きなSecretを直接Repository Secretsに保存する
### GitHub Actionsのステータスチェック関数を選択してください
> https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions
1. [x] `success()`, `always()`, `cancelled()`, `failure()`
1. [ ] `completed()`, `always()`, `cancelled()`, `failure()`
1. [ ] `status()`, `always()`, `cancelled()`, `failure()`
1. [ ] `state()`, `always()`, `cancelled()`, `failure()`
### `Run Tests` ステップが失敗した場合のみ `Upload Failure test report` ステップを実行するにはどうしますか？
> https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions
1. [x]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
if: failure() && steps.run-tests.outcome == 'failure'
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
1. [ ]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
if: always() && steps.run-tests.outcome == 'failure'
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
1. [ ]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
if: steps.run-tests.outcome == 'failure'
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
1. [ ]
```yaml
- name: Run Tests
id: run-tests
run: npm run test
- name: Upload Failure test report
run: actions/upload-artifact@v3
with:
name: test-report
path: test-reports.html
```
### Workflow実行をトリガーしたイベントに関する情報を保持するコンテキストはどれですか？
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-event-information
1. [x] `github.event`
1. [ ] `github.repository`
1. [ ] `github.job`
1. [ ] `jobs.<job_id>.result`
### GitHub Actionsでbranchesフィルターとpathsフィルターを両方定義した場合、Workflow実行にどのような影響がありますか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore
1. [x] 両方の `branches` と `paths` が満たされたときのみWorkflowが実行される
1. [ ] `branches` または `paths` のいずれかが満たされたときにWorkflowが実行され、該当するフィルターのみ適用される
1. [ ] `branches` または `paths` のいずれかが満たされたときにWorkflowが実行される
1. [ ] 両方の `branches` と `paths` が満たされた場合はWorkflowが実行されない
### OSやシェルに関係なく、GitHub Actionsで環境変数を扱う際の推奨事項はどれですか？
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-environment-variable
1. [x] 環境変数は大文字小文字を区別して扱う
1. [ ] 環境変数名には大文字のみを使用する
1. [ ] 大文字小文字はGitHub Actionsが自動で処理するため無視する
1. [ ] 使用しているOSの動作に依存する
### 環境のデプロイ保護ルールを参照するWorkflowジョブの動作について正しく説明しているものはどれですか？
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
1. [x] 環境のデプロイ保護ルールがすべて通過するまでWorkflowジョブは開始されない
1. [ ] 環境にデプロイ保護ルールがある場合、Workflowジョブは決して開始されない
1. [ ] 環境のデプロイ保護ルールに関係なく、Workflowジョブはすぐに開始される
1. [ ] 環境のデプロイ保護ルールの一部が通過した場合のみWorkflowジョブが開始される
### GitHub Actionsの`actions/cache`における`restore-keys`パラメータの目的は何ですか？
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [x] キャッシュミス時に使用する代替キーを指定する
1. [ ] キャッシュヒットが発生したかどうかを示す
1. [ ] キャッシュされたファイルの場所を指定する
1. [ ] クロスOSでのキャッシュ機能を有効にする
### ステップのデバッグログを有効にするために`true`に設定する変数はどれですか？
> https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging
1. [x] `ACTIONS_STEP_DEBUG`
1. [ ] `ACTIONS_JOB_DEBUG`
1. [ ] `ACTIONS_RUNNER_DEBUG`
1. [ ] `ACTIONS_WORKFLOW_DEBUG`
### check_run Actionsに関連するWebhookイベントでWorkflowをトリガーする適切な設定はどれですか？
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#check_run
1. [x]
```yaml
on:
check_run:
types: [rerequested, completed]
```
1. [ ]
```yaml
on:
check_run:
types: [started]
```
1. [ ]
```yaml
on:
check_run:
type: [closed]
```
1. [ ]
```yaml
on:
check_run:
filter: [requested]
```
### ステップにおける`timeout-minutes`キーワードの目的は何ですか？
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes
1. [x] 個々のステップの実行時間を制限する
1. [ ] ステップ内の個々のコマンドの実行間隔を定義する
1. [ ] 次のステップに進む前に外部イベントを待つタイムアウトを設定する
1. [ ] ジョブ全体の最大実行時間を指定する
### Daveは組織用のテンプレートWorkflowを作成しています。テンプレートWorkflowのファイルと関連メタデータファイルはどこに保存する必要がありますか？
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
1. [x] `.github`というRepository内の`workflow-templates`というディレクトリ内
1. [ ] 現在のRepository内の`workflow-templates`というディレクトリ内
1. [ ] `.github/org-templates`というディレクトリ内
1. [ ] `.github/workflow-templates`というディレクトリ内
### DaveはGitHub Repository内でIssueにコメントが作成されたときに通知を受け取りたいと考えています。Workflow設定内で使用すべきイベントトリガーはどれですか？
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment
1. [x] `issue_comment`
1. [ ] `issues.comment`
1. [ ] `issues`
1. [ ] `comment`
### Workflow実行のログファイルを削除するには、GitHub Repositoryでどのレベルのアクセス権が必要ですか？
> https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs
1. [x] write
1. [ ] read
1. [ ] admin
1. [ ] owner
### `octo/my-dev-repo` Repository に対してトリガーされた場合、このワークフロー設定について正しいのはどれですか？
```yaml
name: deploy-workflow
on: [push]
jobs:
production-deploy:
if: github.repository == 'octo/my-prod-repo'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '14'
- run: npm install -g bats
```
> https://docs.github.com/en/actions/using-jobs/using-conditions-to-control-job-execution
1. [x] `production-deploy` ジョブは「スキップ」としてマークされる
1. [ ] `production-deploy` ジョブはエラーになる
1. [ ] `production-deploy` ジョブは3つのステップを実行する
1. [ ] `node-version` が `14` の場合、`production-deploy` ジョブが実行される
### 以下の例で、ジョブ内のマトリックス変数の現在の値にアクセスするにはどうすればよいですか:
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [x] `matrix.version` や `matrix.os` のように `matrix` コンテキストを通して変数を参照する
1. [ ] `matrix.property` 構文を使用する
1. [ ] ジョブ設定内で `context` キーワードを使用する
1. [ ] `version` や `os` の構文で直接変数にアクセスする
### Workflowを再実行するために必要な権限レベルはどれですか？
> https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs
1. [x] write
1. [ ] read
1. [ ] admin
1. [ ] owner
### Workflow実行を削除できるのはいつですか？（2つ選択してください）
> https://docs.github.com/en/actions/managing-workflow-runs/deleting-a-workflow-run
- [x] Workflow実行が完了したとき
- [x] Workflow実行から2週間経過したとき
- [ ] Workflow実行から10日経過したとき
- [ ] Workflow実行が進行中のとき
### 設定されたデプロイ保護ルールをバイパスして強制デプロイできるのは（デフォルトで）誰ですか？
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#allow-administrators-to-bypass-configured-protection-rules
1. [x] Repository管理者
1. [ ] Repositoryのwrite権限を持つ任意のユーザー
1. [ ] Repositoryのread権限を持つ任意のユーザー
### コミットまたはPRを作成する際に、以下のWorkflowの実行をスキップするにはどうすればよいですか？
```yaml
name: Build
on: [push, pull_request]
jobs:
build:
runs-on: ubuntu-latest
name: Extract artifact version
...
```
>https://docs.github.com/en/actions/managing-workflow-runs/skipping-workflow-runs
1. [x] コミットメッセージまたはPull Requestのタイトルに以下のいずれかのキーワードを含める
```yaml
[skip ci]
[ci skip]
[no ci]
[skip actions]
[actions skip]
```
1. [ ] コミットメッセージに `SKIP_WORKFLOW` を記載する
1. [ ] 上記のWorkflowは、pushまたはpull requestイベントが発生するたびに必ず実行される
### action.ymlファイルを見て、そのActionがコンテナーActionかどうかを判断する方法はどれですか？
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-docker-container-actions
1. [x] `runs.using` の値が `docker` である
1. [ ] `runs.using` の値が `container` である
1. [ ] `runs.using` の値が `Dockerfile` である
1. [ ] `runs.main` の値が `container` である
### コンテナアクションでクリーンアップスクリプトを指定する正しい構文はどれですか？
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runspost-entrypoint
1. [x]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
post-entrypoint: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
post: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
after: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
after-entrypoint: 'cleanup.sh'
```
1. [ ]
```yaml
runs:
using: 'docker'
image: 'Dockerfile'
entrypoint: 'entrypoint.sh'
cleanup: 'cleanup.sh'
```
### デフォルト変数について正しい説明はどれですか？（3つ選択してください）
> https://docs.github.com/en/actions/reference/workflows-and-actions/variables
- [x] デフォルト環境変数はGitHubによって設定され、Workflow内で定義されない
- [x] ほとんどのデフォルト環境変数には対応するコンテキストプロパティがある
- [x] 現在、デフォルトのCI環境変数の値は上書き可能だが、将来も常に可能である保証はない
- [ ] 接頭辞「GITHUB_」を付けることで新しいデフォルト環境変数を追加できる
- [ ] デフォルト環境変数は常に「GITHUB_」という接頭辞を持つ
- [ ] デフォルト環境変数はenvコンテキストを使ってアクセスできる
### Workflowで定義されたカスタム変数のスコープはどれですか？（3つ選択してください）
> https://docs.github.com/en/actions/learn-github-actions/variables#defining-environment-variables-for-a-single-workflow
- [x] Workflowファイルのトップレベルで`env`を使用してWorkflow全体
- [x] Workflow内のジョブ内容で`jobs.<job_id>.env`を使用
- [x] ジョブ内の特定のステップで`jobs.<job_id>.steps[*].env`を使用
- [ ] Workflow内のすべてのジョブで`jobs.env`を使用
- [ ] Workflowファイルのトップレベルで`custom.env`を使用してWorkflow全体
- [ ] Workflowファイルのトップレベルで`environment.<environment_id>.env`を使用してRepository内の特定の環境
### `my-org/my-private-repo` が現在のWorkflowを含むRepositoryとは異なるプライベートRepositoryの場合、`actions/checkout`に何を追加する必要がありますか？
```yaml
name: deploy-workflow
on: [push]
jobs:
my-job:
runs-on: ubuntu-latest
steps:
- name: "Checkout GitHub Action"
uses: actions/checkout@v4
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
```
> https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#example-using-an-action-inside-a-different-private-repository-than-the-workflow
1. [x] GitHub Secret `MY_ACCESS_TOKEN` を作成する
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: ${{ secrets.MY_ACCESS_TOKEN }}
```
1. [ ] 入力`MY_ACCESS_TOKEN`を作成する
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: ${{ MY_ACCESS_TOKEN }}
```
1. [ ] 環境変数`GITHUB_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: $GITHUB_TOKEN
```
1. [ ] アクセストークンは自動的に渡されるため、そのままにする
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
```
### 次の設定の場合、このmatrixが評価されるとGitHub Actionsは何個のジョブを実行しますか？
```yaml
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node: [14, 16]
include:
- os: macos-latest
node: 18
- os: ubuntu-latest
node: 14
```
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow#expanding-or-adding-matrix-configurations
1. [ ] 4 ジョブ
1. [x] 5 ジョブ
1. [ ] 6 ジョブ
1. [ ] 7 ジョブ
1. [ ] 構文が無効なためジョブは実行されない
### 環境変数はどのレベルで定義できますか？（3つ選択してください）
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables
- [x] Workflowレベル
- [x] ジョブレベル
- [x] ステップレベル
- [ ] Actionレベル
### 同じWorkflow内で先に実行された`job1`というジョブが生成した`output1`値を依存ジョブが参照するにはどうすればよいですか？
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs
1. [x] `${{needs.job1.outputs.output1}}`
1. [ ] `${{job1.outputs.output1}}`
1. [ ] `${{needs.job1.output1}}`
1. [ ] `${{depends.job1.output1}}`
### GitHub Actionsジョブの後続ステップに対して、'API_VERSION' という環境変数に '2.1' を設定する正しいWorkflowコマンド構文はどれですか？
> https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable
1. [x] `echo "API_VERSION=2.1" >> "$GITHUB_ENV"`
1. [ ] `echo "API_VERSION=2.1" >> "$GITHUB_OUTPUT"`
1. [ ] `export API_VERSION=2.1 >> "$GITHUB_ENV"`
1. [ ] `set-env name=API_VERSION value=2.1`
細部
この模擬試験が役立ちましたか？
repository に ⭐ を残し、以下の方法でコミュニティへの貢献を検討してください:
- contributing に従い、1問以上の模擬試験問題を追加（数分で可能）