Teste Prático de GitHub Actions
### Qual declaração está correta em relação à passagem de permissões para workflows reutilizáveis?
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#access-and-permissions
1. [x] As permissões do `GITHUB_TOKEN` passadas do workflow chamador só podem ser rebaixadas pelo workflow chamado.
1. [ ] As permissões do `GITHUB_TOKEN` passadas do workflow chamador só podem ser elevadas pelo workflow chamado.
1. [ ] As permissões do `GITHUB_TOKEN` passadas do workflow chamador podem ser tanto rebaixadas quanto elevadas pelo workflow chamado.
1. [ ] As permissões do `GITHUB_TOKEN` passadas do workflow chamador não podem ser nem rebaixadas nem elevadas pelo workflow chamado.
### Quais são os diferentes níveis de permissão que você pode atribuir ao `GITHUB_TOKEN` no bloco `permissions`?
> https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
1. [x] none, write, read
1. [ ] read, write, delete
1. [ ] read, write
### Você pode usar `permissions` para modificar as permissões do `GITHUB_TOKEN` em: (Selecione duas.)
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token
- [x] Nível de Workflow
- [x] Nível de Job
- [ ] Nível de Step
### Os GitHub Actions são gratuitos para repositórios públicos?
1. [x] Sim
1. [ ] Não
### Qual desses não é um evento válido que poderia acionar um workflow?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Clonar o repositório
1. [ ] Realizar um commit em um arquivo na branch master
1. [ ] Criar uma branch
1. [ ] Adicionar um rótulo a um pull request
### O que é verdadeiro sobre workflows? (Selecione três.)
> https://docs.github.com/en/actions/using-workflows/about-workflows
- [x] Workflows podem executar um ou vários jobs ao mesmo tempo
- [x] Workflows podem ser acionados manualmente, por um evento ou executados em um cronograma
- [x] Workflows precisam ser definidos no diretório `.github/workflows`
- [ ] Workflows podem ser executados apenas em um cronograma
- [ ] Workflow pode executar apenas um job por vez
- [ ] Workflows são escritos em qualquer um dos formatos `.yaml`, `.json` ou `.toml`
- [ ] Workflows podem ser compartilhados no GitHub Marketplace
> Actions (não workflows) podem ser compartilhadas no GitHub Marketplace
### Quais componentes são necessários para um workflow? (Selecione dois.)
> https://docs.github.com/en/actions/using-workflows/about-workflows#workflow-basics
- [x] Um ou mais eventos que irão acionar o workflow
- [x] Um ou mais jobs
- [ ] Nome do workflow
- [ ] Branches definidas nas quais o workflow será executado
### Qual evento é acionado por uma ação de webhook fora do repositório?
> 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
### Os Workflows são definidos em qual formato
1. [x] yaml
1. [ ] toml
1. [ ] json
1. [ ] xml
### Onde você deve armazenar dados confidenciais, como senhas ou certificados, que serão usados em workflows
1. [x] secrets
1. [ ] config variables
1. [ ] vault
1. [ ] environment variables
### Em um workflow com múltiplos jobs, o comportamento padrão é:
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] Todos os jobs são executados em paralelo
1. [ ] Os jobs são executados em sequência
### Se o job B requer que o job A esteja concluído, você deve:
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] usar a palavra-chave `needs` no job B para criar essa dependência
1. [ ] usar a palavra-chave `needs` no job A para criar essa dependência
1. [ ] usar a palavra-chave `requires` no job B para criar essa dependência
1. [ ] usar a palavra-chave `requires` no job A para criar essa dependência
### Em um workflow com múltiplos jobs, se o job A falhar, então:
> https://docs.github.com/en/actions/using-workflows/about-workflows#creating-dependent-jobs
1. [x] os jobs que dependem do job A são ignorados
1. [ ] os jobs que dependem do job A falham
1. [ ] o workflow cancela imediatamente todos os outros jobs
### Este código executará 6 jobs diferentes em paralelo usando a estratégia de matriz. Você pode usar a estratégia de matriz para paralelizar workflows inteiros?
```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. [ ] Não
1. [x] Sim
### Qual definição de trabalho com matriz é sintaticamente correta?
> 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]
```
### Como você acessa variáveis de matriz em um job de estratégia de matriz?
> https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#using-a-matrix-strategy
1. [ ] Usando o contexto `vars`
1. [x] Usando o contexto `matrix`
1. [ ] Usando o contexto `job`
1. [ ] Usando o contexto `jobs`
### Ao usar os eventos `pull_request` e `pull_request_target`, como você configura o workflow para ser executado apenas ao direcionar para a branch `prod`?
> https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#using-filters-to-target-specific-branches-for-pull-request-events
1. [x] Usando o filtro `branches`
1. [ ] Usando o filtro `branch`
1. [ ] Você cria o workflow apenas na branch `prod`
1. [ ] Usando padrões globais
### Este fluxo de trabalho será executado em todos os pull requests onde:
```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] o nome da branch de destino começa com `release`, mas não termina com `-alpha`
1. [ ] o nome da branch de destino começa com `release`
1. [ ] o nome da branch de origem começa com `release`, mas não termina com `-alpha`
1. [ ] o nome da branch de origem começa com `release`
### Preencha o espaço em branco: Ao usar filtros de gatilho do evento `push`, você pode usar padrões de <____> para direcionar vários branches.
> 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
### Qual evento permite que você acione manualmente um workflow pela interface do GitHub?
> 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
### Quais são os possíveis tipos de uma variável de entrada para um workflow acionado manualmente? (Selecione cinco.)
> 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
### Um workflow que possui apenas o gatilho de evento `workflow_dispatch` pode ser acionado usando a REST API do GitHub
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs
1. [x] Verdadeiro
1. [ ] Falso
### Para interromper a execução de um workflow temporariamente sem modificar o código-fonte, você deve
> https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow
1. [x] Usar a opção `Disable workflow` no GitHub Actions
1. [ ] Remover secrets necessários para esse workflow
1. [ ] Excluir o ambiente necessário para esse workflow
1. [ ] Impedir novos commits na branch principal
### Para que são usados os `activity types` de um evento?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Limitar as execuções de workflows a tipos específicos de atividade usando o filtro `types`
1. [ ] Verificar se a atividade é oriunda de um usuário ou de um bot
1. [ ] Reagir a uma nova atividade em um repositório (por exemplo, um novo colaborador)
### Você deseja criar um workflow reutilizável `CI` que execute algumas verificações de qualidade, linting e testes em alterações no código. Qual gatilho de evento o workflow `CI` deve definir para permitir sua reutilização em outros workflows?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
1. [x] workflow_call
1. [ ] workflow_trigger
> Não existe tal gatilho de evento
1. [ ] workflow_dispatch
> Este é usado para gatilhos manuais
1. [ ] workflow_run
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
### Um workflow reutilizável chamado `build` cria artefatos zip. Como você passa a localização do arquivo zip para o workflow chamador que está chamando o workflow `build`? (Selecione três.)
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow
- [x] Você define uma saída no nível do workflow no workflow `build`
- [x] Você define uma saída no nível do job no workflow `build`
- [x] No workflow `build` você escreve a saída em `$GITHUB_OUTPUT` em um dos passos
- [ ] Todas as saídas são automaticamente passadas para os workflows chamadores
### Quais são os casos de uso válidos para usar **defaults**? (Selecione dois.)
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaults
- [x] Usar defaults.run no nível do workflow para definir o shell padrão (por exemplo, bash) para todo o workflow
- [x] Usar defaults.run no nível do job para definir o diretório de trabalho padrão para todas as etapas de um único job
- [ ] Usar defaults.run no nível da etapa para definir o shell padrão (por exemplo, bash) para essa única etapa
> defaults.run só pode ser definido no nível do workflow ou do job
- [ ] Usar defaults.env no nível do workflow para definir variáveis de ambiente padrão para todo o workflow
> Não existe defaults.env
- [ ] Usar defaults.env no nível do job para definir variáveis de ambiente padrão para todas as etapas de um único job
> Não existe defaults.env
### Como você pode garantir que um workflow chamado `Deploy Prod` esteja sempre sendo executado, no máximo, um de cada vez?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
1. [x] Use `concurrency` no nível do workflow
```yaml
concurrency: ${{ github.workflow }}
```
1. [ ] Use `queue` no nível do workflow
```yaml
queue: ${{ github.workflow }}
```
1. [ ] Use `order` no nível do workflow
```yaml
order: ${{ github.workflow }}
```
1. [ ] Use `parallel` no nível do workflow
```yaml
parallel: ${{ github.workflow }}
```
### O fluxo de trabalho de análise do seu Pull Request usa várias ferramentas de análise de código e leva cerca de 20 minutos para ser concluído completamente. Ele é acionado no evento `pull_request` com o filtro `branches` configurado para `master`. Portanto, se um desenvolvedor enviar múltiplos commits em poucos minutos, vários fluxos de trabalho serão executados em paralelo. Como você pode interromper todas as execuções anteriores do fluxo de trabalho e executar apenas a mais recente com as alterações mais atuais?
> 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] Use concurrency com cancel-in-progress
```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
```
1. [ ] Use concurrency
```yaml
concurrency:
group: ${{ github.ref }}
```
> Isso colocaria as execuções na fila para aquele github ref. Não interromperá as execuções anteriores.
1. [ ] Use filtro de tipos de atividade
```yaml
on:
pull_request:
branches:
- master
types: [latest]
```
> Não existe um tipo de atividade chamado `latest` para o evento pull_request.
1. [ ] Use a flag cancel-in-progress para o evento `pull_request`
```yaml
on:
pull_request:
branches:
- master
cancel-in-progress: true
```
### Quando o job3 será executado?
```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] job3 será executado após job1 e job2 serem concluídos, independentemente de terem sido bem-sucedidos
1. [ ] Você não pode usar `if: ${{ always() }}` e `needs` juntos. O workflow falhará na inicialização.
1. [ ] job3 será executado após job1 e job2 serem concluídos com sucesso
1. [ ] job3 será executado após tanto job1 quanto job2 falharem
### Qual condicional `jobs.job_id.if` garantirá que o job `production-deploy` seja acionado apenas no repositório `my-org/my-repo`? (Selecione duas.)
```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
### Quais tipos de runners hospedados pelo GitHub estão disponíveis para uso? (Selecione três.)
> 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
### Essa afirmação é verdadeira? `Nem todos os steps executam actions, mas todas as actions são executadas como um step`
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps
1. [x] Verdadeiro
1. [ ] Falso
> Steps podem, mas não precisam executar actions (por exemplo, executar um comando run)
### Para qualquer ação publicada no GitHub Marketplace, você pode frequentemente usá-la em múltiplas versões, qual abordagem é a mais estável e segura?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-versioned-actions
1. [x] Referenciar o commit SHA
1. [ ] Referenciar uma tag de versão
1. [ ] Referenciar a branch principal
### Para evitar que um job falhe quando uma das etapas falhar, você pode incluir:
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error
1. [x] Flag `continue-on-error` na etapa com falha
```yaml
steps:
- uses: my-org/failing-action@v1
continue-on-error: true
```
1. [ ] Flag `ignore-error` na etapa com falha
```yaml
steps:
- uses: my-org/failing-action@v1
ignore-error: true
```
1. [ ] Condicional `failure()` na etapa com falha
```yaml
steps:
- uses: my-org/failing-action@v1
if: failure()
```
1. [ ] Condicional `always()` na etapa com falha
```yaml
steps:
- uses: my-org/failing-action@v1
if: always()
```
### Você definiu um trabalho de matriz `example_matrix`. Como limitar a matriz para executar no máximo 2 trabalhos ao mesmo tempo?
```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] Defina `jobs.example_matrix.strategy.max-parallel` como 2
1. [ ] Defina `jobs.example_matrix.strategy.concurrency` como 2
1. [ ] Use a REST API do GitHub para verificar se a contagem de trabalhos é menor que 2
1. [ ] Não é possível, uma matriz sempre executará todos os trabalhos em paralelo se houver runners disponíveis
### Qual destas é uma maneira correta de definir um parâmetro de saída `PET` com o valor `DOG` em um `step`.
> 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"`
### Qual dessas é uma maneira de usar `action_state` em `step_two`?
```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 }}"`
> Isso seria o caso se `action_state` tivesse sido escrito para `$GITHUB_OUTPUT`
1. [ ] `run: echo "$steps.step_one.outputs.action_state"`
1. [ ] `run: echo "${{ action_state }}"`
### Esta afirmação é verdadeira? `Workflows podem ser reutilizados, mas um reusable workflow não pode chamar outro reusable workflow.`
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#nesting-reusable-workflows
1. [x] Falso
1. [ ] Verdadeiro
> Reusable workflows podem ser aninhados, mas existem limitações https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations
### No exemplo a seguir, `workflow A` passa todos os seus segredos para `workflow B`, utilizando a palavra-chave inherit. Em seguida, `workflow B` chama `workflow C`. Qual afirmação sobre os `secrets` é verdadeira para esse exemplo?
```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] Todos os segredos disponíveis para o `workflow A` também estarão disponíveis para o `workflow B`, mas não para o `workflow C`.
1. [ ] Todos os segredos da organização `octo-org` e do repositório `octo-org/example-repo` estarão disponíveis para o `workflow B`, mas não para o `workflow C`.
> Nem todos os segredos da organização `octo-org` precisam ser disponibilizados para o `octo-org/example-repo`.
1. [ ] Todos os segredos disponíveis para o `workflow A` também estarão disponíveis para o `workflow B` e para o `workflow C`.
> O `workflow B` precisaria adicionar `secrets: inherit` ao chamar o `workflow C`.
1. [ ] Apenas os segredos de repositório e ambiente disponíveis para o `workflow A` estarão disponíveis para o `workflow B`, mas não para o `workflow C`. Segredos com escopo de organização não podem ser herdados.
### Quando você deve usar o `caching`?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
1. [x] Quando você deseja reutilizar arquivos que não mudam com frequência entre jobs ou execuções de workflows, como dependências de build de um sistema de gerenciamento de pacotes.
1. [ ] Quando você deseja reutilizar arquivos que mudam frequentemente entre jobs ou execuções de workflows, como dependências de build de um sistema de gerenciamento de pacotes.
1. [ ] Quando você deseja salvar arquivos produzidos por um job para visualizar após a execução de um workflow ter terminado, como binários construídos ou logs de construção.
> Artifacts devem ser usados para isso https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
1. [ ] Quando você deseja salvar binários produzidos por um job de build para usar em um job de deploy subsequente para implantar uma nova versão de uma aplicação
> Artifacts devem ser usados para isso https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
### Quando você deve usar `artifacts`? (Selecione duas.)
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#about-workflow-artifacts
- [x] Use artifacts para salvar arquivos produzidos por um job para visualizar após a execução de um workflow ter terminado, como resultados de testes ou logs de construção.
- [x] Use artifacts para salvar binários produzidos por um job de construção para usar em um job de implantação subsequente para implantar uma nova versão de uma aplicação.
- [ ] Use artifacts para reutilizar arquivos que não mudam frequentemente entre jobs ou execuções de workflows, como dependências de construção de um sistema de gerenciamento de pacotes.
> Para isso, o caching deve ser usado https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#comparing-artifacts-and-dependency-caching
- [ ] Use artifacts para criar novas versões do seu aplicativo junto com notas de release, menções e/ou contribuidores.
> Esse é um caso de uso para releases, não para artifacts.
### Se um workflow executa na branch `feature-a`, ele pode restaurar `caches` criados na branch padrão `main`?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache
1. [x] Sim, todas as branches podem restaurar caches criados na branch padrão
1. [ ] Sim, todos os caches podem ser acessados por workflows em qualquer branch dentro do mesmo repositório
1. [ ] Não, os caches só podem ser restaurados a partir da mesma branch
1. [ ] Sim, mas somente se nenhum arquivo foi alterado na branch `feature-a`
### Para acessar um `artifact` que foi criado em outra execução de workflow previamente acionada, você pode:
> https://github.com/actions/download-artifact?tab=readme-ov-file#download-artifacts-from-other-workflow-runs-or-repositories
1. [ ] Você não pode acessar `artifacts` que foram criados em uma execução de workflow diferente
1. [x] Usar a ação `actions/download-artifact` com permissões elevadas.
1. [ ] Usar a ação `actions/upload-artifact`.
1. [ ] Usar a ação `actions/download-artifact` e garantir que o artifact não tenha expirado
### O que você deve usar para armazenar relatórios de cobertura ou capturas de tela geradas durante um workflow que executa testes automatizados para um repositório?
> 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
### Você só pode fazer upload de um único arquivo por vez ao usar a ação `actions/upload-artifact`
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#uploading-build-and-test-artifacts
1. [x] Falso
1. [ ] Verdadeiro
### No trabalho `deploy`, se você quiser acessar os binários (contendo sua aplicação) que foram criados no trabalho `build`, você deve
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#comparing-artifacts-and-dependency-caching
1. [x] fazer o upload dos binários como artefatos em `build` e baixá-los em `deploy`
1. [ ] fazer o upload dos binários como artefatos em `deploy` e baixá-los em `build`
1. [ ] armazenar os binários em cache em `build` e ler os arquivos do cache em `deploy`
1. [ ] armazenar os binários em cache em `deploy` e ler os arquivos do cache em `build`
### Um trabalho chamado `job2` está utilizando artefatos criados no `job1`. Portanto, é importante garantir que o `job1` seja concluído antes que o `job2` comece a procurar pelos artefatos. Como você deve criar essa dependência?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] crie essa dependência usando a palavra-chave `needs` em `job2`
1. [ ] essa dependência é criada implicitamente ao usar `actions/download-artifact` para baixar o artefato do `job1`
1. [ ] crie essa dependência definindo `job2` após `job1` na definição do `.yaml` do workflow
1. [ ] crie essa dependência usando a palavra-chave `concurrency` em `job2`
### O que é verdadeiro sobre `Starter Workflows`? (Selecione três.)
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [x] Eles permitem que os usuários utilizem templates de workflow prontos para uso (ou que requeiram mudanças mínimas)
- [x] O GitHub fornece e mantém starter workflows para diferentes categorias, linguagens e ferramentas
- [x] Sua organização pode criar starter workflows personalizados para os usuários da sua organização
- [ ] Starter workflows não podem chamar reusable workflows
- [ ] Starter workflows são um recurso pago do GitHub
- [ ] Starter workflows são fornecidos prontos para uso e não podem ser modificados ou aprimorados
> https://docs.github.com/en/actions/using-workflows/using-starter-workflows#using-starter-workflows
### Segredos e variáveis de configuração podem ser definidos para: (Selecione três.)
> https://docs.github.com/en/actions/using-workflows/sharing-workflows-secrets-and-runners-with-your-organization#sharing-secrets-and-variables-within-an-organization
- [x] Toda a organização ou repositórios selecionados em uma organização
- [x] Um único repositório
- [x] Um ambiente em um repositório
- [ ] Um ambiente compartilhado entre múltiplos repositórios
> Ambientes não podem ser compartilhados entre repositórios
- [ ] Múltiplos repositórios que não compartilham uma organização/enterprise
- [ ] Um workflow específico em um repositório
> Variáveis de ambiente podem ser definidas para um workflow, variáveis de configuração não
- [ ] Uma job específica em um workflow
> Variáveis de ambiente podem ser definidas para um workflow, variáveis de configuração não
### Quais são os três tipos de Actions?
> 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`
### Essa afirmação é verdadeira? `Docker container actions are usually slower than JavaScript actions`
> Docker container actions são mais lentas do que JavaScript actions
1. [x] Verdadeiro
1. [ ] Falso
> Por causa da latência para construir e recuperar o container, Docker container actions são mais lentas do que JavaScript actions.
### Ao criar uma GitHub Action personalizada, você deve armazenar o código-fonte no diretório `.github/workflows`
> https://docs.github.com/en/actions/creating-actions/about-custom-actions#choosing-a-location-for-your-action
1. [x] Falso
1. [ ] Verdadeiro
> Isso é verdade para `workflows`, não para `actions`
### Ao criar GitHub Actions personalizadas - em qual arquivo todas as informações de `metadata` da action devem ser definidas?
Exemplos de metadata: nome, descrição, outputs ou inputs obrigatórios
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions
1. [x] No arquivo `action.yml` ou `action.yaml` no repositório da action
1. [ ] No arquivo `README` do repositório
> Apesar de ser uma boa prática, não é um requisito para que a action funcione
1. [ ] É editado na interface do GitHub Marketplace quando publicado para compartilhamento
1. [ ] No arquivo `action.yml` ou `action.yaml` no repositório da action, mas não é obrigatório se a action não for destinada a ser compartilhada e utilizada pelo público
> Todas as actions requerem o arquivo de metadata.
### Um workflow foi inicialmente executado no `commit A` e falhou. Você corrigiu o workflow no `commit B`. Quando você reexecutar esse workflow, ele será executado com o código de qual commit?
> https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs#about-re-running-workflows-and-jobs
1. [x] Ele será executado com o código do `commit A`
1. [ ] Ele será executado com o código do `commit B`
> Reexecutar um workflow usa o mesmo SHA do commit e a mesma referência do Git do evento original que acionou a execução do workflow.
1. [ ] Você não pode reexecutar workflows no GitHub Actions. Você precisa acionar um novo workflow que será executado com as alterações mais recentes
1. [ ] Ele acionará dois workflows, um com o código do `commit A` e outro com o código do `commit B`
### Como você pode exigir aprovações manuais por um mantenedor se a execução do workflow estiver direcionada ao ambiente `production`?
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
1. [x] Usando regras de proteção de implantação
1. [ ] Definindo os revisores necessários no workflow `production`
1. [ ] Usando regras de proteção de branch
1. [ ] Aprovações manuais não são suportadas pelo GitHub Actions
### Qual é verdadeiro sobre os ambientes?
> Cada job em um workflow pode referenciar um único ambiente.
1. [x] Cada job em um workflow pode referenciar um único ambiente.
1. [ ] Cada workflow pode referenciar um único ambiente.
1. [ ] Cada job em um workflow pode referenciar no máximo dois ambientes.
1. [ ] Cada workflow pode referenciar no máximo dois ambientes.
### Ao usar o GitHub Actions para acessar recursos em um dos provedores de nuvem (como AWS, Azure ou GCP), a forma mais segura e recomendada de autenticação é
> https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
1. [x] Usando OIDC
1. [ ] Usando Vault
1. [ ] Armazenando chaves de acesso em `secrets`
> Usar chaves de acesso de longa duração não é recomendado em caso de vazamentos de segurança ou ataques, como [injeção de scripts](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#understanding-the-risk-of-script-injections)
1. [ ] Armazenando chaves de acesso em `variables`
> Valores sensíveis não devem ser armazenados em `variables`
### O seu repositório de código aberto e publicamente disponível contém um fluxo de trabalho com um gatilho de evento `pull_request`. Como você pode exigir aprovações para execuções de fluxos de trabalho acionados a partir de forks do seu repositório?
> https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks#about-workflow-runs-from-public-forks
1. [x] Configurar aprovações obrigatórias para execuções de forks no repositório
1. [ ] Configurar regras de proteção de implantação para o repositório
> As regras de proteção de implantação são usadas para proteger ambientes
1. [ ] Configurar regras de proteção de branch para o repositório
1. [ ] O fluxo de trabalho não será acionado para forks se estiver usando o evento `pull_request`. Se você quiser fazer isso, deve usar o gatilho de evento `fork_pull_request` com o flag `require-approval`.
### Qual das seguintes variáveis de ambiente padrão contém o nome da pessoa ou aplicativo que iniciou a execução do 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`
### Quais das seguintes são variáveis de ambiente padrão no GitHub Actions? (Selecione três.)
> 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`
### Sua organização define um segredo `SomeSecret`, no entanto, ao referenciar esse segredo em um workflow usando `${{ secrets.SomeSecret }}`, ele fornece um valor diferente do esperado. Qual pode ser a razão para isso?
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#naming-your-secrets
1. [x] O segredo `SomeSecret` também está declarado no escopo do repositório
1. [ ] O segredo `SomeSecret` também está declarado no escopo da empresa
> Se um segredo com o mesmo nome existir em múltiplos níveis, o segredo no nível mais baixo tem precedência.
1. [ ] A expressão `${{ secrets.SomeSecret }}` é usada apenas para segredos com escopo de repositório
1. [ ] Você precisa usar a GitHub API para acessar segredos com escopo de organização
### Qual é uma maneira correta de imprimir uma mensagem de depuração?
> 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`
### Como as organizações que utilizam o GitHub Enterprise Server podem habilitar a sincronização automática de GitHub Actions de terceiros hospedadas no GitHub.com para sua instância do 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] Usando o GitHub Connect
1. [ ] O GitHub Enterprise Server tem acesso a todas as Actions do GitHub.com por padrão
> As GitHub Actions no GitHub Enterprise Server são projetadas para funcionar em ambientes sem acesso completo à internet. Por padrão, os workflows não podem usar actions do GitHub.com e do GitHub Marketplace.
1. [ ] Usando a ferramenta 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. [ ] O GitHub Enterprise Server não pode usar Actions do GitHub.com devido à sua natureza on-premise e à falta de acesso à internet
### Onde você pode encontrar os logs de conectividade de rede para um 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] Na pasta `_diag` diretamente na máquina do runner
1. [ ] No GitHub.com na página específica daquele Runner
1. [ ] Nos logs de execução de um trabalho que foi executado naquele Runner
1. [ ] Nos logs de execução de um trabalho que foi executado naquele Runner com a depuração habilitada
### Como você pode validar que seu GitHub self-hosted-runner pode acessar todos os serviços GitHub necessários?
> 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] Usando um script fornecido pelo GitHub na máquina do runner
1. [ ] Tentando acessar a máquina do runner por `ssh` para validar a conectividade de rede
1. [ ] Usando o workflow pré-definido do GitHub Actions `network-connectivity.yml`
1. [ ] O GitHub validará a conectividade de rede automaticamente quando o aplicativo de runner for instalado na máquina do runner
### Qual é a maneira correta de acionar um job apenas se a variável de configuração `MY_VAR` tiver o valor de `MY_VALUE`?
> https://docs.github.com/en/actions/learn-github-actions/contexts#example-usage-of-the-vars-context
1. [x] Criando a seguinte condicional no nível do job
```yaml
my-job:
if: ${{ vars.MY_VAR == 'MY_VALUE' }}
```
1. [ ] Criando a seguinte condicional no nível do job
```yaml
my-job:
if: ${{ vars.MY_VAR }} == 'MY_VALUE'
```
> Isso sempre será avaliado como True
1. [ ] Não é possível porque variáveis de configuração não podem ser usadas em condicionais `if`
> Isso é verdadeiro para `secrets`, mas não para variáveis de configuração
1. [ ] Não é possível porque variáveis de configuração não podem ser usadas em condicionais `if` no nível do job
> Isso é verdadeiro para `secrets`, mas não para variáveis de configuração
### Para executar um `step` somente se o segredo `MY_SECRET` tiver sido configurado, você pode:
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-secrets
1. [x] Configurar o segredo `MY_SECRET` como uma variável de ambiente no nível do job e, em seguida, referenciar essa variável de ambiente para condicionalmente executar esse step
```yaml
my-job:
runs-on: ubuntu-latest
env:
my_secret: ${{ secrets.MY_SECRET }}
steps:
- if: ${{ env.my_secret != '' }}
```
1. [ ] Criar a seguinte condicional no nível do job
```yaml
my-job:
runs-on: ubuntu-latest
if: ${{ secrets.MY_SECRET == '' }}
```
> segredos não podem ser referenciados diretamente em condicionais de if:
1. [ ] Criar a seguinte condicional no nível do step
```yaml
my-job:
runs-on: ubuntu-latest
steps:
- if: ${{ secrets.MY_SECRET == '' }}
```
> segredos não podem ser referenciados diretamente em condicionais de if:
1. [ ] Criar a seguinte condicional no nível do step
```yaml
my-job:
runs-on: ubuntu-latest
steps:
- if: ${{ secrets.MY_SECRET }}
```
> segredos não podem ser referenciados diretamente em condicionais de if:
### Como você pode usar a GitHub API para baixar os logs de execução do 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`
### Como você pode usar a API do GitHub para criar ou atualizar um secret de repositório?
> 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}`
### Como você pode substituir um GitHub Secret `API_KEY` em nível de organização por um valor diferente ao trabalhar dentro de um repositório? (Selecione duas.)
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#naming-your-secrets
- [x] Criando um secret de repositório com o mesmo nome `API_KEY`
- [x] Criando um secret de ambiente com o mesmo nome `API_KEY`
- [ ] Criando um secret de empresa com o mesmo nome `API_KEY`
- [ ] Criando um secret de empresa com o nome `OVERRIDE_API_KEY`
- [ ] Criando um secret de repositório com o nome `OVERRIDE_API_KEY`
- [ ] Criando um secret de ambiente com o nome `OVERRIDE_API_KEY`
- [ ] Criando um secret de repositório com o nome `REPOSITORY_API_KEY`
- [ ] Criando um secret de ambiente com o nome `ENVIRONMENT_API_KEY`
### Quais componentes podem ser reutilizados dentro de uma GitHub Organization? (Selecione quatro.)
- [x] Secrets
- [x] Variáveis de Configuração
- [x] Self Hosted Runners
- [x] Workflow Templates
- [ ] Artifacts
> Artifacts são usados para preservar dados após a conclusão de um job e/ou compartilhar esses dados com outro job dentro do mesmo workflow.
- [ ] Cache
> Cache pode ser reutilizado entre workflows dentro de um único repository.
- [ ] Variáveis de Ambiente
> Variáveis de ambiente podem ser atribuídas a um step, job ou workflow. Elas não podem ser compartilhadas entre workflows/repositories ou organizações.
### Quantos jobs serão executados no seguinte 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
### Qual das seguintes variáveis de ambiente padrão contém o nome completo (por exemplo, `octocat/hello-world`) do repositório onde o workflow está sendo executado?
> 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`
### Em um workflow que possui múltiplos jobs, todos executados em GitHub-hosted runners, é verdade que todos os jobs são garantidos de serem executados na mesma máquina runner?
> https://docs.github.com/en/actions/using-jobs/choosing-the-runner-for-a-job#choosing-github-hosted-runners
1. [x] Não
1. [ ] Sim
> Cada job é executado em uma nova instância de uma imagem de runner especificada por runs-on
### Qual é o número máximo de workflows reutilizáveis que podem ser chamados a partir de um único arquivo de workflow?
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations
1. [x] 20
1. [ ] 5
1. [ ] 1
1. [ ] 10
### O que é um runner auto-hospedado?
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
1. [x] Um runner auto-hospedado é um sistema que você implanta e gerencia para executar jobs do GitHub Actions no GitHub.com
1. [ ] Um runner auto-hospedado é um sistema para fazer upload de código para um servidor privado
1. [ ] Um runner auto-hospedado é um sistema para criar cargas de trabalho automaticamente
1. [ ] Um runner auto-hospedado é um sistema para gerenciar pull requests de usuários da organização
### Qual das seguintes afirmações está correta sobre GitHub Workflows e Actions?
> https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
1. [ ] Cada action é composta por um ou mais workflows, que são compostos por um ou mais jobs, e cada job é composto por um ou mais steps.
1. [ ] Cada workflow é composto por uma ou mais actions, que são compostas por um ou mais jobs, e cada job é composto por um ou mais steps.
1. [x] Cada workflow é composto por um ou mais jobs, que são compostos por um ou mais steps, e cada step é uma action ou um script.
1. [ ] Cada action é composta por um ou mais jobs, que são compostos por um ou mais steps, e cada step é um workflow.
### Em qual commit e branch os workflows agendados são executados no GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] Workflows agendados são executados no commit específico na última branch modificada.
> incorreto, tanto commit específico quanto na última branch modificada
1. [ ] Workflows agendados são executados no commit específico na branch main.
> incorreto, tanto commit específico quanto na branch main
1. [x] Workflows agendados são executados no commit mais recente na branch padrão do repositório.
1. [ ] Workflows agendados são executados no commit mais recente na branch main.
> o commit mais recente está correto, mas a branch main não está correta
### Qual é a sintaxe correta para definir o diretório para todos os comandos `run` em um workflow?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunworking-directory
1. [x] definir `working-directory` em `defaults.run`
```yaml
defaults:
run:
shell: bash
working-directory: ./scripts
```
1. [ ] definir `directory` em `defaults.run`
```yaml
defaults:
run:
shell: bash
directory: ./scripts
```
1. [ ] definir `working-directory` em `job`
```yaml
defaults:
run:
shell: bash
job:
working-directory: ./scripts
```
1. [ ] definir `directory` em `job`
```yaml
defaults:
run:
shell: bash
job:
directory: ./scripts
```
### Como você pode reutilizar um workflow definido em múltiplos repositórios? (Escolha duas.)
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [ ] Copiando o arquivo de workflow para cada repositório
- [x] Usando templates de workflow
- [ ] Criando uma ação reutilizável
- [x] Definindo o workflow em um repositório central
### Como você pode garantir que um job seja executado apenas em um branch específico?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#using-filters
1. [x] Usando o filtro branches
1. [ ] Usando o filtro runs-on
1. [ ] Usando o filtro jobs
1. [ ] Usando a palavra-chave branch
### O que a palavra-chave `needs` faz em um workflow do GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds
1. [x] Especifica as dependências de um job
1. [ ] Define variáveis de ambiente
1. [ ] Configura o ambiente
1. [ ] Aciona um job com base em um evento
### Qual palavra-chave permite que você defina variáveis de ambiente em um workflow do GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenv
1. [x] env
1. [ ] vars
1. [ ] secrets
1. [ ] config
### Qual é o propósito da palavra-chave `with` em um workflow do GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith
1. [ ] Definir variáveis de ambiente
1. [x] Especificar parâmetros de entrada para uma ação
1. [ ] Configurar dependências
1. [ ] Disparar outro workflow
### Qual das seguintes sintaxes do GitHub Actions é usada para executar vários comandos em uma única etapa?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#example-of-a-multiline-string
1. [ ] Usando && para encadear comandos
1. [ ] Definindo comandos em um array
1. [x] Usando uma string multilinha com |
1. [ ] Separando comandos com um ponto e vírgula ;
### Como você pode armazenar em cache dependências para acelerar a execução do workflow?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows#about-caching-workflow-dependencies
1. [ ] Usando a palavra-chave cache
1. [x] Usando a ação actions/cache
1. [ ] Armazenando-as no repositório
1. [ ] Usando a palavra-chave store
### O que a palavra-chave `matrix` faz em um workflow do GitHub Actions?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-a-matrix-for-your-jobs
1. [x] Permite definir múltiplas configurações de jobs para serem executadas em paralelo
1. [ ] Define variáveis de ambiente para o job
1. [ ] Aciona workflows com base em um cronograma
1. [ ] Define secrets para o workflow
### Qual das alternativas a seguir pode ser usada para limitar o número de jobs concorrentes em execução em um workflow do GitHub Actions?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-concurrency
1. [x] concurrency
1. [ ] limit
1. [ ] max-jobs
1. [ ] parallelism
### Qual é o tempo limite padrão para um trabalho do GitHub Actions?
> https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
1. [ ] 30 minutos
1. [ ] 60 minutos
1. [ ] 120 minutos
1. [x] 360 minutos
### Como você pode especificar o sistema operacional para um job no GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on
1. [ ] Usando a palavra-chave os
1. [x] Usando a palavra-chave runs-on
1. [ ] Usando a palavra-chave platform
1. [ ] Usando a palavra-chave env
### Em um workflow do GitHub Actions, como você especifica uma versão específica do Node.js para usar em um job?
> 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
```
### Como você referencia um secret armazenado no GitHub Secrets em um 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 }}
### Qual é o shell padrão usado pelo GitHub Actions em runners Windows?
> 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
### Quais das seguintes afirmações são verdadeiras sobre adicionar um runner auto-hospedado no GitHub Actions? (Escolha três.)
> 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] Você pode adicionar um runner auto-hospedado a um repositório
- [x] Você pode adicionar um runner auto-hospedado a uma organização
- [x] Você pode adicionar um runner auto-hospedado a uma enterprise
- [ ] Você pode adicionar um runner auto-hospedado a um workflow
> Não é possível adicionar no nível de workflow
- [ ] Você pode adicionar um runner auto-hospedado a um passo
> Não é possível adicionar no nível de passo
### Selecione a variável de ambiente padrão que contém o sistema operacional do runner que executa o job
> 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`
### Como a ação `actions/cache` no GitHub Actions lida com uma falta de cache?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [ ] exigindo intervenção manual para criar um novo cache
1. [ ] procurando por um cache em outros repositórios
1. [x] criando automaticamente um novo cache se o trabalho for concluído com sucesso
1. [ ] encerrando o workflow se ocorrer uma falta de cache
### Como você pode especificar a programação de um workflow do GitHub Actions para ser executado apenas em dias úteis?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
1. [ ] adicionar uma condição no YAML do workflow para dias úteis
1. [ ] não é possível no GitHub Actions
1. [ ] usar o gatilho de evento on: schedule: weekdays
1. [x] usar o gatilho de evento on: schedule: cron
### Qual é a abordagem recomendada para armazenar segredos maiores que 48 KB?
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#limits-for-secrets
1. [ ] evitar armazenar segredos grandes completamente para garantir a segurança
1. [ ] segredos maiores que 48 KB não podem ser armazenados
1. [x] criptografar e armazenar segredos no repositório, mas manter a frase de descriptografia como um segredo
1. [ ] armazenar segredos grandes diretamente como segredos do repositório para evitar limitações
### Selecione as funções de verificação de status no GitHub Actions
> https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functions
1. [x] `success()`, `always()`, `cancelled()` e `failure()`
1. [ ] `completed()`, `always()`, `cancelled()` e `failure()`
1. [ ] `status()`, `always()`, `cancelled()` e `failure()`
1. [ ] `state()`, `always()`, `cancelled()` e `failure()`
### Como você garante que a etapa `Upload Failure test report` é executada apenas se a etapa `Run Tests` falhar?
> 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
```
### Qual contexto contém informações sobre o evento que acionou a execução de um 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`
### No GitHub Actions, se você definir tanto o filtro de branches quanto de paths, qual é o efeito na execução do workflow?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore
1. [x] o workflow será executado somente quando ambos `branches` e `paths` forem satisfeitos
1. [ ] o workflow será executado quando `branches` ou `paths` forem satisfeitos, mas aplicará somente o filtro correspondente
1. [ ] o workflow será executado quando `branches` ou `paths` forem satisfeitos
1. [ ] o workflow não será executado quando ambos `branches` e `paths` forem satisfeitos
### Qual é a prática recomendada para tratar variáveis de ambiente no GitHub Actions, independentemente do sistema operacional e shell utilizados?
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-environment-variable
1. [x] tratar variáveis de ambiente como sensíveis a maiúsculas e minúsculas
1. [ ] usar apenas letras maiúsculas para nomes de variáveis de ambiente
1. [ ] ignorar a sensibilidade a maiúsculas e minúsculas, pois o GitHub Actions lida com isso automaticamente
1. [ ] depender do comportamento do sistema operacional em uso
### Qual das seguintes afirmações descreve com precisão o comportamento dos jobs do workflow que fazem referência às regras de proteção de um ambiente?
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment
1. [x] os jobs do workflow não serão iniciados até que todas as regras de proteção do ambiente sejam atendidas
1. [ ] os jobs do workflow nunca serão iniciados se o ambiente tiver regras de proteção
1. [ ] os jobs do workflow serão iniciados imediatamente, independentemente das regras de proteção do ambiente
1. [ ] os jobs do workflow serão iniciados apenas se algumas das regras de proteção do ambiente forem atendidas
### Qual é o propósito do parâmetro `restore-keys` em `actions/cache` no GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [x] fornecer chaves alternativas para usar em caso de perda do cache
1. [ ] indicar se houve um acerto de cache
1. [ ] especificar a localização dos arquivos em cache
1. [ ] habilitar a funcionalidade de cache entre sistemas operacionais
### Qual variável você configuraria como `true` para ativar o registro de depuração por etapa?
> 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`
### Qual configuração é apropriada para acionar um workflow para ser executado em eventos de webhook relacionados a ações check_run?
> 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]
```
### Qual é o propósito da palavra-chave `timeout-minutes` em um passo?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes
1. [x] limita o tempo de execução para um passo individual
1. [ ] define o intervalo de tempo para comandos individuais dentro de um passo
1. [ ] define o tempo limite para esperar eventos externos antes de prosseguir para o próximo passo
1. [ ] especifica a duração máxima que um job pode executar
### Dave está criando um workflow modelado para sua organização. Onde Dave deve armazenar os arquivos do workflow e os arquivos de metadados associados ao workflow modelado?
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
1. [x] dentro de um diretório chamado `workflow-templates` em um repositório chamado `.github`
1. [ ] dentro de um diretório chamado `workflow-templates` no repositório atual
1. [ ] dentro de um diretório chamado `.github/org-templates`
1. [ ] dentro de um diretório chamado `.github/workflow-templates`
### Dave quer ser notificado quando um comentário for criado em uma issue dentro de um repositório do GitHub. Qual evento de gatilho deve ser usado na configuração do 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`
### Qual nível de acesso é necessário em um repositório do GitHub para excluir os arquivos de log das execuções de workflows?
> https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs
1. [x] write
1. [ ] read
1. [ ] admin
1. [ ] owner
### O que é verdadeiro sobre a seguinte configuração de workflow quando disparada contra o repositório `octo/my-dev-repo`?
```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] o job `production-deploy` será marcado como ignorado
1. [ ] o job `production-deploy` apresentará erro
1. [ ] o job `production-deploy` executará três etapas
1. [ ] o job `production-deploy` será executado se o `node-version` for `14`
### Como você pode acessar os valores atuais das variáveis em uma matriz dentro de um job no exemplo abaixo:
```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] referenciar variáveis através do contexto `matrix` com a sintaxe como `matrix.version` e `matrix.os`
1. [ ] usando a sintaxe `matrix.property`
1. [ ] usando a palavra-chave `context` dentro da configuração do job
1. [ ] acessando as variáveis diretamente com a sintaxe `version` e `os`
### Qual nível de permissão é necessário para reexecutar os workflows
> https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs
1. [x] write
1. [ ] read
1. [ ] admin
1. [ ] owner
### Quando você pode excluir execuções de workflows? (selecione duas)
> https://docs.github.com/en/actions/managing-workflow-runs/deleting-a-workflow-run
- [x] Quando a execução do workflow foi concluída
- [x] Quando a execução do workflow tem duas semanas
- [ ] Quando a execução do workflow tem 10 dias
- [ ] Quando a execução do workflow está em andamento
### Quem pode ignorar as regras de proteção de implantação configuradas para forçar a implantação (por padrão)
> https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#allow-administrators-to-bypass-configured-protection-rules
1. [x] Administradores do repositório
1. [ ] Qualquer pessoa com permissão de escrita no repositório
1. [ ] Qualquer pessoa com permissão de leitura no repositório
### Como você pode pular a execução do seguinte workflow ao fazer um commit ou criar um Pull Request?
```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] Incluindo qualquer uma das seguintes palavras-chave na mensagem do commit ou no título do Pull Request
```yaml
[skip ci]
[ci skip]
[no ci]
[skip actions]
[actions skip]
```
1. [ ] Fornecendo `SKIP_WORKFLOW` na mensagem do commit
1. [ ] O workflow acima será executado em todo evento de push ou pull request em todos os casos
### Como você pode determinar se uma ação é uma container action ao olhar para seu arquivo action.yml?
> https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-docker-container-actions
1. [x] `runs.using` tem `docker` como valor
1. [ ] `runs.using` tem `container` como valor
1. [ ] `runs.using` tem `Dockerfile` como valor
1. [ ] `runs.main` tem `container` como valor
### Qual é a sintaxe correta para especificar um script de limpeza em uma container action?
> 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'
```
### O que é verdade sobre variáveis padrão? (escolha três)
> https://docs.github.com/en/actions/reference/workflows-and-actions/variables
- [x] Variáveis de ambiente padrão são definidas pelo GitHub e não configuradas em um workflow
- [x] A maioria das variáveis de ambiente padrão tem uma propriedade de contexto correspondente
- [x] Atualmente, o valor da variável de ambiente padrão CI pode ser sobrescrito, mas não é garantido que isso será sempre possível
- [ ] Você pode adicionar uma nova variável de ambiente padrão adicionando o prefixo “GITHUB_” a ela
- [ ] Variáveis de ambiente padrão sempre têm o prefixo “GITHUB_”
- [ ] Variáveis de ambiente padrão podem ser acessadas usando o contexto env
### Quais são os escopos definidos para variáveis personalizadas em um workflow? (escolha três)
> https://docs.github.com/en/actions/learn-github-actions/variables#defining-environment-variables-for-a-single-workflow
- [x] Todo o workflow, usando `env` no nível superior do arquivo do workflow
- [x] O conteúdo de um job dentro de um workflow, usando `jobs.<job_id>.env`
- [x] Um passo específico dentro de um job, usando `jobs.<job_id>.steps[*].env`
- [ ] Todos os jobs dentro de um workflow, usando `jobs.env`
- [ ] Todo o workflow, usando `custom.env` no nível superior do arquivo do workflow
- [ ] Um ambiente específico no repositório, usando `environment.<environment_id>.env` no nível superior do arquivo do workflow
### O que deve ser adicionado ao `actions/checkout` se `my-org/my-private-repo` for um repositório privado diferente do que contém o workflow atual?
```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] Criar um segredo do GitHub `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. [ ] Criar uma entrada `MY_ACCESS_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: ${{ MY_ACCESS_TOKEN }}
```
1. [ ] A variável ambiental `GITHUB_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: $GITHUB_TOKEN
```
1. [ ] Deixar como está, pois os tokens de acesso serão passados automaticamente
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
```
### Dada a seguinte configuração, quantos trabalhos o GitHub Actions executará quando essa matriz for avaliada?
```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 trabalhos
1. [x] 5 trabalhos
1. [ ] 6 trabalhos
1. [ ] 7 trabalhos
1. [ ] Nenhum trabalho será executado porque a sintaxe é inválida.
### Em quais níveis as variáveis de ambiente podem ser definidas? (Escolha três)
> https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables
- [x] Nível de Workflow
- [x] Nível de Job
- [x] Nível de Step
- [ ] Nível de Action
### Como um job dependente deve referenciar o valor `output1` produzido por um job chamado `job1` anteriormente no mesmo workflow?
> 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}}`
### Qual sintaxe de comando de workflow define corretamente uma variável de ambiente chamada 'API_VERSION' com o valor '2.1' para etapas subsequentes em um trabalho do GitHub Actions?
> 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`
Detalhes
Achou este teste prático útil?
Deixe uma ⭐ no repositório e considere retribuir à comunidade:
- contribuindo com uma ou mais perguntas para um exame simulado (leva minutos)