Teste Prático de GitHub Actions
### 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/pt/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
### As GitHub Actions são gratuitas para repositórios públicos?
1. [x] Sim
1. [ ] Não
### Qual é a verdade sobre os workflows? (Selecione três.)
> https://docs.github.com/en/actions/using-workflows/about-workflows
- [x] Os workflows podem executar um ou vários jobs ao mesmo tempo
- [x] Os workflows podem ser acionados manualmente, por um evento ou executados em uma programação
- [x] Os workflows devem ser definidos no diretório `.github/workflows`
- [ ] Os workflows só podem ser executados com base em uma programação
- [ ] Um workflow pode executar apenas um job de cada vez
- [ ] Os workflows são escritos em qualquer um dos formatos `.yaml`, `.json` ou `.toml`
- [ ] Os 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 fluxo de trabalho? (Selecione dois.)
> https://docs.github.com/en/actions/using-workflows/about-workflows#workflow-basics
- [x] Um ou mais eventos que irão acionar o fluxo de trabalho
- [x] Um ou mais jobs
- [ ] Nome do fluxo de trabalho
- [ ] Branches definidas nas quais o fluxo de trabalho 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 fluxos de trabalho são definidos em qual formato
1. [x] yaml
1. [ ] toml
1. [ ] json
1. [ ] xml
### Onde você deve armazenar dados sensíveis, como senhas ou certificados, que serão usados em fluxos de trabalho
1. [x] secrets
1. [ ] variáveis de configuração
1. [ ] cofre
1. [ ] variáveis de ambiente
### Em um fluxo de trabalho com vários 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 fluxo de trabalho cancela imediatamente todos os outros jobs
### Este código lançará 6 trabalhos diferentes em paralelo usando a estratégia de matriz. Você pode usar a estratégia de matriz para paralelizar fluxos de trabalho inteiros?
```yaml
jobs:
example_matrix:
strategy:
matrix:
version: [10, 12, 14]
os: [ubuntu-latest, windows-latest]
```
> https://docs.github.com/pt/actions/using-workflows/reusing-workflows#using-a-matrix-strategy-with-a-reusable-workflow
1. [ ] Não
1. [x] Sim
### Como você acessa variáveis de matriz em um trabalho 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 somente ao direcionar para o 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 no branch `prod`
1. [ ] Usando padrões globais
### Preencha o espaço em branco: Ao usar filtros de gatilho do evento `push`, você pode usar padrões <____> 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
### Quais são os possíveis tipos de uma variável de entrada para um fluxo de trabalho 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 fluxo de trabalho que possui apenas o gatilho de evento `workflow_dispatch` pode ser acionado usando a API REST do GitHub
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs
1. [x] Verdadeiro
1. [ ] Falso
### Para parar temporariamente a execução de um fluxo de trabalho 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 `Desativar fluxo de trabalho` no GitHub Actions
1. [ ] Remover segredos necessários para esse fluxo de trabalho
1. [ ] Excluir o ambiente necessário para esse fluxo de trabalho
1. [ ] Impedir novos commits no ramo principal
### Para que servem os `tipos de atividade` de um evento?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#about-events-that-trigger-workflows
1. [x] Restringir a execução de workflows a tipos específicos de atividade usando o filtro `types`
1. [ ] Verificar se a atividade é originada por um usuário ou um bot
1. [ ] Reagir a novas atividades em um repositório (ex.: novo colaborador)
### Você quer criar um fluxo de trabalho reutilizável `CI` que execute algumas verificações de qualidade, linting e testes em alterações de código. Qual evento gatilho o fluxo de trabalho `CI` deve definir para permitir seu uso em outros fluxos de trabalho?
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
1. [x] workflow_call
1. [ ] workflow_trigger
> Não existe tal evento gatilho
1. [ ] workflow_dispatch
> Isso é usado para gatilhos manuais
1. [ ] workflow_run
> https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
### Um fluxo de trabalho reutilizável chamado `build` cria artefatos de arquivos zip. Como você passa a localização do arquivo zip para o fluxo de trabalho chamador que está chamando o fluxo de trabalho `build`? (Selecione três.)
> https://docs.github.com/pt/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow
- [x] Você define uma saída no nível do fluxo de trabalho no fluxo de trabalho `build`
- [x] Você define uma saída no nível do trabalho no fluxo de trabalho `build`
- [x] No fluxo de trabalho `build` você grava a saída em `$GITHUB_OUTPUT` em um dos passos
- [ ] Todas as saídas são automaticamente passadas para os fluxos de trabalho 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 todos os steps em um único job
- [ ] Usar defaults.run no nível do step para definir o shell padrão (por exemplo, bash) para aquele único step
> 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 todos os steps em um único job
> Não existe defaults.env
### Como garantir que um workflow chamado `Deploy Prod` esteja sempre executando no máximo uma instância por 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 }}
```
### Quais tipos de runners hospedados no 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
### Para evitar que um job falhe quando um dos steps falha, 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` no step que falha
```yaml
steps:
- uses: my-org/failing-action@v1
continue-on-error: true
```
1. [ ] Flag `ignore-error` no step que falha
```yaml
steps:
- uses: my-org/failing-action@v1
ignore-error: true
```
1. [ ] Condicional `failure()` no step que falha
```yaml
steps:
- uses: my-org/failing-action@v1
if: failure()
```
1. [ ] Condicional `always()` no step que falha
```yaml
steps:
- uses: my-org/failing-action@v1
if: always()
```
### Você definiu um job de matriz `example_matrix`. Como limitar a matriz para executar um máximo de 2 jobs por vez?
```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] Definir `jobs.example_matrix.strategy.max-parallel` como 2
1. [ ] Definir `jobs.example_matrix.strategy.concurrency` como 2
1. [ ] Usar a API REST do GitHub para verificar se a quantidade de jobs é menor que 2
1. [ ] Não é possível, uma matriz sempre executará todos os jobs em paralelo se houver runners disponíveis
### Qual dessas é 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"`
### Essa afirmação é verdadeira? `Os fluxos de trabalho podem ser reutilizados, mas um fluxo de trabalho reutilizável não pode chamar outro fluxo de trabalho reutilizável.`
> https://docs.github.com/en/actions/using-workflows/reusing-workflows#nesting-reusable-workflows
1. [x] Falso
1. [ ] Verdadeiro
> Os fluxos de trabalho reutilizáveis podem ser aninhados, mas existem limitações https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations
### No seguinte exemplo, o `workflow A` passa todos os seus segredos para o `workflow B`, utilizando a palavra-chave inherit. Em seguida, o `workflow B` chama o `workflow C`. Qual afirmativa 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 estar disponíveis 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 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.
### Se um fluxo de trabalho for executado em um branch `feature-a`, ele pode restaurar `caches` criados no 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, todos os branches podem restaurar caches criados no branch padrão
1. [ ] Sim, todos os caches podem ser acessados por fluxos de trabalho em qualquer branch dentro do mesmo repositório
1. [ ] Não, os caches só podem ser restaurados do mesmo branch
1. [ ] Sim, mas apenas se nenhum arquivo tiver sido alterado no branch `feature-a`
### Para acessar um `artifact` que foi criado em outro fluxo de trabalho anteriormente acionado, você pode:
> https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#about-workflow-artifacts
1. [x] Você não pode acessar `artifacts` que foram criados em um fluxo de trabalho diferente
1. [ ] Usar a ação `actions/download-artifact`.
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 gerados durante um fluxo de trabalho que executa testes automatizados para um repositório?
> https://docs.github.com/pt/actions/using-workflows/storing-workflow-data-as-artifacts#comparing-artifacts-and-dependency-caching
1. [x] Artefatos
1. [ ] Caches
1. [ ] Pacotes
> https://docs.github.com/pt/packages/learn-github-packages/introduction-to-github-packages
1. [ ] Releases
> https://docs.github.com/pt/repositories/releasing-projects-on-github/about-releases
### Você só pode enviar 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
### Um trabalho chamado `job2` está utilizando artefatos criados no `job1`. Portanto, é importante garantir que `job1` termine antes que `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] criar essa dependência utilizando a palavra-chave `needs` em `job2`
1. [ ] essa dependência é criada implicitamente ao usar `actions/download-artifact` para baixar o artefato de `job1`
1. [ ] criar essa dependência definindo `job2` após `job1` na definição do arquivo `.yaml` do workflow
1. [ ] criar essa dependência utilizando a palavra-chave `concurrency` em `job2`
### 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`
### Esta afirmação é verdadeira? `As ações de contêiner Docker geralmente são mais lentas do que as ações em JavaScript`
> As ações de contêiner Docker são mais lentas do que as ações em JavaScript
1. [x] Verdadeiro
1. [ ] Falso
> Devido à latência para construir e recuperar o contêiner, as ações de contêiner Docker são mais lentas do que as ações em JavaScript.
### Um fluxo de trabalho foi inicialmente executado no `commit A` e falhou. Você corrigiu o fluxo de trabalho com o subsequente `commit B`. Quando você reexecutar esse fluxo de trabalho, 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 fluxo de trabalho usa o mesmo SHA do commit e ref Git do evento original que acionou a execução do fluxo de trabalho.
1. [ ] Você não pode reexecutar fluxos de trabalho no GitHub Actions. Você deve acionar um novo fluxo de trabalho que será executado com as alterações mais recentes
1. [ ] Ele acionará dois fluxos de trabalho, 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 fluxo de trabalho está 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 fluxo de trabalho `production`
1. [ ] Usando regras de proteção de branch
1. [ ] Aprovações manuais não são suportadas pelo GitHub Actions
### Qual é a verdade sobre os ambientes?
> Cada trabalho em um fluxo de trabalho pode referenciar um único ambiente.
1. [x] Cada trabalho em um fluxo de trabalho pode referenciar um único ambiente.
1. [ ] Cada fluxo de trabalho pode referenciar um único ambiente.
1. [ ] Cada trabalho em um fluxo de trabalho pode referenciar no máximo dois ambientes.
1. [ ] Cada fluxo de trabalho 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 maneira mais segura e recomendada de autenticar é
> 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`
> O uso de chaves de acesso de longa duração não é recomendado em caso de vazamentos de segurança ou ataques, como [injeção de script](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`
> Nenhum valor sensível deve ser armazenado em `variables`
### Seu repositório público de código aberto contém um workflow com um gatilho de evento `pull_request`. Como você pode exigir aprovações para execuções de workflow acionadas 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
> 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 workflow não será acionado para forks ao usar o evento `pull_request`. Se você deseja fazer isso, deve usar o gatilho de evento `fork_pull_request` com a 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 fluxo de trabalho?
> 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`
### 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 hospedados no GitHub.com com 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 GitHub Connect
1. [ ] O GitHub Enterprise Server tem acesso a todas as Actions do GitHub.com por padrão
> O GitHub Actions no GitHub Enterprise Server foi projetado para funcionar em ambientes sem acesso total à internet. Por padrão, os workflows não podem usar ações 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 local e à falta de acesso à internet
### Onde você pode encontrar logs de conectividade de rede para um runner self-hosted do 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] 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 job que foi executado naquele Runner
1. [ ] Nos logs de execução de um job que foi executado naquele Runner com log de depuração ativado
### Qual é a maneira correta de disparar 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 de job
```yaml
my-job:
if: ${{ vars.MY_VAR == 'MY_VALUE' }}
```
1. [ ] Criando a seguinte condicional no nível de 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 é verdade 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 de job
> Isso é verdade para `secrets`, mas não para variáveis de configuração
### Para executar um `step` somente se o segredo `MY_SECRET` foi definido, você pode:
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-secrets
1. [x] Definir o segredo `MY_SECRET` como uma variável de ambiente no nível do job, e então referenciar essa variável de ambiente para condicionalmente executar o step
```yaml
my-job:
runs-on: ubuntu-latest
env:
my_secret: ${{ secrets.MY_SECRET }}
steps:
- if: ${{ env.my_secret != '' }}
```
1. [ ] Criando 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 `if:`
1. [ ] Criando 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 `if:`
1. [ ] Criando 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 `if:`
### Como você pode usar a API do GitHub para baixar os logs de execução de workflows?
> 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 segredo 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 segredo de organização do GitHub `API_KEY` por um valor diferente ao trabalhar em um repositório? (Selecione duas.)
> https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#naming-your-secrets
- [x] Criando um segredo de repositório com o mesmo nome `API_KEY`
- [x] Criando um segredo de ambiente com o mesmo nome `API_KEY`
- [ ] Criando um segredo de empresa com o mesmo nome `API_KEY`
- [ ] Criando um segredo de empresa com o nome `OVERRIDE_API_KEY`
- [ ] Criando um segredo de repositório com o nome `OVERRIDE_API_KEY`
- [ ] Criando um segredo de ambiente com o nome `OVERRIDE_API_KEY`
- [ ] Criando um segredo de repositório com o nome `REPOSITORY_API_KEY`
- [ ] Criando um segredo de ambiente com o nome `ENVIRONMENT_API_KEY`
### Qual das seguintes variáveis de ambiente padrão contém o nome completo (por exemplo, `octocat/hello-world`) do repositório onde o fluxo de trabalho 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 fluxo de trabalho com vários jobs, todos executando em runners hospedados no GitHub, é verdade que todos os jobs estão garantidos para 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 da imagem do 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 self-hosted?
> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
1. [x] Um runner self-hosted é um sistema que você implanta e gerencia para executar jobs do GitHub Actions no GitHub.com
1. [ ] Um runner self-hosted é um sistema para fazer upload de código para um servidor privado
1. [ ] Um runner self-hosted é um sistema para criar cargas de trabalho automaticamente
1. [ ] Um runner self-hosted é um sistema para gerenciar pull requests de usuários da organização
### Qual das seguintes afirmativas está correta sobre Workflows e Actions do GitHub?
> https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
1. [ ] Cada action é composta por um ou mais workflows, que é composto por um ou mais jobs, e cada job é composto por um ou mais steps
1. [ ] Cada workflow é composto por uma ou mais actions, que é composta 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 é composto por um ou mais steps, e cada step é uma action ou um script
1. [ ] Cada action é composta por um ou mais jobs, que é composto 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 branch modificada por último.
> incorreto, tanto o commit específico quanto na branch modificada por último
1. [ ] Workflows agendados são executados no commit específico na branch principal.
> incorreto, tanto commit específico quanto branch principal
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 principal.
> commit mais recente está correto, mas a branch principal não.
### 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` dentro de `job`
```yaml
defaults:
run:
shell: bash
job:
working-directory: ./scripts
```
1. [ ] definir `directory` dentro de `job`
```yaml
defaults:
run:
shell: bash
job:
directory: ./scripts
```
### Como você pode reutilizar um fluxo de trabalho definido em vários repositórios? (Escolha duas.)
> https://docs.github.com/en/actions/using-workflows/creating-starter-workflows-for-your-organization
- [ ] Copiando o arquivo de fluxo de trabalho para cada repositório
- [x] Usando templates de fluxo de trabalho
- [ ] Criando uma ação reutilizável
- [x] Definindo o fluxo de trabalho 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 fluxo de trabalho 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 fluxo de trabalho 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 fluxo de trabalho do GitHub Actions?
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith
1. [ ] Para definir variáveis de ambiente
1. [x] Para especificar parâmetros de entrada para uma ação
1. [ ] Para configurar dependências
1. [ ] Para acionar outro fluxo de trabalho
### Como você pode armazenar em cache dependências para acelerar a execução do fluxo de trabalho?
> 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
### Qual das opções 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 fluxo de trabalho 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 segredo armazenado no GitHub Secrets em um fluxo de trabalho?
> 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 pelos runners do GitHub Actions no 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
### Como a ação `actions/cache` no GitHub Actions lida com uma falha 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 um cache em outros repositórios
1. [x] criando automaticamente um novo cache se o job for concluído com sucesso
1. [ ] encerrando o workflow se ocorrer uma falha de cache
### Como você pode especificar a programação de um fluxo de trabalho 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 fluxo de trabalho 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
### Qual contexto contém informações sobre o evento que acionou a execução de um workflow?
> https://docs.github.com/pt/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 filtros de branches e 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 atendidos
1. [ ] o workflow será executado quando `branches` ou `paths` forem atendidos, mas aplicará apenas o filtro correspondente
1. [ ] o workflow será executado quando `branches` ou `paths` forem atendidos
1. [ ] o workflow não será executado quando ambos `branches` e `paths` forem atendidos
### 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/pt/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 é o propósito do parâmetro `restore-keys` em `actions/cache` no GitHub Actions?
> https://docs.github.com/pt/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
1. [x] fornecer chaves alternativas para usar em caso de falha no cache
1. [ ] indicar se ocorreu um acerto no cache
1. [ ] especificar a localização dos arquivos em cache
1. [ ] habilitar a funcionalidade de cache entre sistemas operacionais
### Qual variável você definiria como `true` para habilitar o registro de depuração em etapas?
> 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 em eventos de webhook relacionados a ações de 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] ela limita o tempo de execução para um passo individual
1. [ ] ela define o intervalo de tempo para comandos individuais dentro de um passo
1. [ ] ela define o tempo limite para aguardar eventos externos antes de prosseguir para o próximo passo
1. [ ] ela especifica a duração máxima que um trabalho tem permissão para executar
### Dave está criando um fluxo de trabalho modelado para sua organização. Onde Dave deve armazenar os arquivos do fluxo de trabalho e os arquivos de metadados associados para o fluxo de trabalho 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 gatilho de evento 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 GitHub para excluir arquivos de log de 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 fluxo de trabalho se acionada no 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 trabalho `production-deploy` será marcado como pulado
1. [ ] o trabalho `production-deploy` apresentará erro
1. [ ] o trabalho `production-deploy` executará três etapas
1. [ ] o trabalho `production-deploy` será executado se a `node-version` for `14`
### Qual nível de permissão é necessário para reexecutar os fluxos de trabalho
> 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 fluxo de trabalho? (selecione duas)
> https://docs.github.com/en/actions/managing-workflow-runs/deleting-a-workflow-run
- [x] Quando a execução do fluxo de trabalho foi concluída
- [x] Quando a execução do fluxo de trabalho tem duas semanas
- [ ] Quando a execução do fluxo de trabalho tem 10 dias
- [ ] Quando a execução do fluxo de trabalho 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 pular a execução do workflow seguinte ao cometer ou criar um PR?
```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. [ ] Fornecer `SKIP_WORKFLOW` na mensagem do commit
1. [ ] O workflow acima será executado em todos os eventos de push ou pull request em qualquer caso
### Como você pode determinar se uma ação é uma ação de container analisando 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 ação de 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'
```
### O que é verdadeiro sobre variáveis padrão? (escolha três)
> https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables
- [x] Variáveis padrão de ambiente são definidas pelo GitHub e não em um workflow
- [x] A maioria das variáveis padrão de ambiente possui uma propriedade de contexto correspondente
- [x] Atualmente, o valor da variável de ambiente padrão CI pode ser sobrescrito, mas não há garantia de que isso sempre será possível
- [ ] Você pode adicionar uma nova variável padrão de ambiente adicionando o prefixo "GITHUB_" ao nome dela
- [ ] Variáveis padrão de ambiente sempre têm o prefixo "GITHUB_"
- [ ] Variáveis padrão de ambiente 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, utilizando `env` no nível superior do arquivo do workflow
- [x] O conteúdo de um job dentro de um workflow, utilizando `jobs.<job_id>.env`
- [x] Uma etapa específica dentro de um job, utilizando `jobs.<job_id>.steps[*].env`
- [ ] Todos os jobs dentro de um workflow, utilizando `jobs.env`
- [ ] Todo o workflow, utilizando `custom.env` no nível superior do arquivo do workflow
- [ ] Um ambiente específico no repositório, utilizando `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 daquele 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 um input `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 de ambiente `GITHUB_TOKEN`
```yaml
with:
repository: my-org/my-private-repo
path: ./.github/actions/my-org/my-private-repo
token: $GITHUB_TOKEN
```
1. [ ] Manter como está, já que 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 jobs 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 jobs
1. [x] 5 jobs
1. [ ] 6 jobs
1. [ ] 7 jobs
1. [ ] Nenhum job 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 afirmaçã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 reduzidas 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 reduzidas e elevadas pelo workflow chamado.
1. [ ] As permissões do `GITHUB_TOKEN` passadas do workflow chamador não podem ser nem reduzidas nem elevadas pelo workflow chamado.
### 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. [ ] Commit de um arquivo na branch master
1. [ ] Uma branch é criada
1. [ ] Adicionar um rótulo a um pull request
### Em um fluxo de trabalho 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 trabalho B requer que o trabalho 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 trabalho B para criar essa dependência
1. [ ] usar a palavra-chave `needs` no trabalho A para criar essa dependência
1. [ ] usar a palavra-chave `requires` no trabalho B para criar essa dependência
1. [ ] usar a palavra-chave `requires` no trabalho A para criar essa dependência
### Qual definição de trabalho de 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]
```
### 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`
### Qual evento permite que você acione manualmente um workflow a partir da interface do usuário do GitHub?
> https://docs.github.com/pt/actions/using-workflows/manually-running-a-workflow
1. [x] workflow_dispatch
1. [ ] manual_dispatch
1. [ ] workflow_trigger
1. [ ] manual_trigger
### 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] o job3 será executado após o job1 e o job2 terem sido 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. [ ] o job3 será executado após o job1 e o job2 terem sido concluídos com sucesso
1. [ ] o job3 será executado após o job1 e o job2 terem falhado
### Qual condicional `jobs.job_id.if` garantirá que o trabalho `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
### Esta declaração é verdadeira? `Nem todos os passos executam ações, mas todas as ações são executadas como um passo`
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps
1. [x] Verdadeiro
1. [ ] Falso
> Os passos podem, mas não precisam executar ações (por exemplo, executar um comando run)
### Para qualquer ação publicada no GitHub Marketplace, você pode frequentemente usá-la em várias 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
### Qual destas é 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` fosse escrito para `$GITHUB_OUTPUT`
1. [ ] `run: echo "$steps.step_one.outputs.action_state"`
1. [ ] `run: echo "${{ action_state }}"`
### Quando você deve usar `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 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 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 build.
> Artefatos 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.
> Artefatos 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, como resultados de testes ou logs de build.
- [x] Use artifacts para salvar binários produzidos por um job de build para usar em um job subsequente de deploy 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 workflow, como dependências de build de um gerenciador de pacotes.
> Caching deve ser usado para isso 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 de sua aplicação juntamente com notas de release, menções e/ou contribuintes.
> Esse é um caso de uso para releases, não artifacts.
### 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 upload dos binários como artefatos em `build` e baixá-los em `deploy`
1. [ ] fazer upload dos binários como artefatos em `deploy` e baixá-los em `build`
1. [ ] armazenar os binários em cache no `build` e ler os arquivos do cache em `deploy`
1. [ ] armazenar os binários em cache no `deploy` e ler os arquivos do cache em `build`
### Qual é a verdade 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 modelos de workflows prontos para uso (ou que exigem mínimas alterações)
- [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 workflows reutilizáveis
- [ ] 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
### Os segredos e as 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 vários repositórios
> Ambientes não podem ser compartilhados entre repositórios
- [ ] Vários repositórios que não compartilham uma organização/empresa
- [ ] 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 podem
- [ ] Um job específico em um workflow
> Variáveis de ambiente podem ser definidas para um workflow; variáveis de configuração não podem
### Ao criar Ações Personalizadas no GitHub, em que arquivo todos os `metadados` da ação precisam ser definidos?
Exemplos de metadados: nome, descrição, saídas ou entradas obrigatórias
> 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 ação
1. [ ] No arquivo `README` do repositório
> Embora seja uma boa prática fazer isso, não é um requisito para que a ação funcione
1. [ ] É editado na interface do GitHub Marketplace ao ser publicado para compartilhamento
1. [ ] No arquivo `action.yml` ou `action.yaml` no repositório da ação, mas não é necessário se a ação não for destinada ao público em geral
> Todas as ações exigem o arquivo de metadados.
### 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, quando você referencia esse segredo em um fluxo de trabalho usando `${{ secrets.SomeSecret }}`, ele fornece um valor diferente do esperado. Qual pode ser o motivo disso?
> 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 vários níveis, o segredo no nível mais baixo tem precedência.
1. [ ] A expressão `${{ secrets.SomeSecret }}` é usada apenas para segredos no escopo do repositório
1. [ ] Você precisa usar a API do GitHub para acessar segredos no escopo da organização
### Como você pode validar se o seu self-hosted runner do GitHub pode acessar todos os serviços necessários do 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] Usando um script fornecido pelo GitHub na máquina do runner
1. [ ] Tentando acessar a máquina do runner via `ssh` para validar a conectividade de rede
1. [ ] Usando o workflow pré-definido do GitHub Actions `network-connectivity.yml`
1. [ ] O GitHub validará automaticamente a conectividade de rede quando o aplicativo do runner for instalado na máquina do runner
### Quais componentes podem ser reutilizados dentro de uma Organização no GitHub? (Selecione quatro.)
- [x] Secrets
- [x] Variáveis de Configuração
- [x] Runners Autohospedados
- [x] Modelos de Workflow
- [ ] Artefatos
> Artefatos 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 em workflows dentro de um repositório.
- [ ] Variáveis de Ambiente
> Variáveis de ambiente podem ser vinculadas a um passo, job ou workflow. Elas não podem ser compartilhadas entre workflows/repositórios 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 sintaxes do GitHub Actions é usada para executar múltiplos comandos em um único passo?
> 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 ;
### O que a palavra-chave `matrix` faz em um fluxo de trabalho do GitHub Actions?
> https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-a-matrix-for-your-jobs
1. [x] Permite definir várias configurações de trabalho para serem executadas em paralelo
1. [ ] Define variáveis de ambiente para o trabalho
1. [ ] Aciona fluxos de trabalho com base em um cronograma
1. [ ] Define segredos para o fluxo de trabalho
### 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 empresa
- [ ] Você pode adicionar um runner auto-hospedado a um workflow
> Você não pode adicionar no nível de workflow
- [ ] Você pode adicionar um runner auto-hospedado a um passo
> Você não pode adicionar no nível de passo
### Selecione a variável de ambiente padrão que contém o sistema operacional do runner que está executando 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`
### Selecione 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 garantir que a etapa `Upload Failure test report` seja 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 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 começarão até que todas as regras de proteção do ambiente sejam atendidas
1. [ ] os jobs do workflow nunca começarão se o ambiente tiver regras de proteção
1. [ ] os jobs do workflow começarão imediatamente, independentemente das regras de proteção do ambiente
1. [ ] os jobs do workflow só começarão se algumas das regras de proteção do ambiente forem atendidas
### 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 sintaxe como `matrix.version` e `matrix.os`
1. [ ] utilizando a sintaxe `matrix.property`
1. [ ] utilizando a palavra-chave `context` dentro da configuração do job
1. [ ] acessando as variáveis diretamente com a sintaxe `version` e `os`
### Seu fluxo de trabalho de análise de 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` definido para `master`. Portanto, se um desenvolvedor enviar vários commits em poucos minutos, vários fluxos de trabalho são executados em paralelo. Como você pode parar todas as execuções de fluxo de trabalho anteriores e executar apenas aquele com as alterações mais recentes?
> 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 concorrência com cancelamento em andamento
```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
```
1. [ ] Use concorrência
```yaml
concurrency:
group: ${{ github.ref }}
```
> Isso enfileiraria execuções nesse github ref. Não interromperá execuções anteriores
1. [ ] Use filtro de tipos de atividade
```yaml
on:
pull_request:
branches:
- master
types: [latest]
```
> Não existe tal tipo de atividade como `latest` para o evento pull_request
1. [ ] Use a flag de cancelamento em progresso para o evento `pull_request`
```yaml
on:
pull_request:
branches:
- master
cancel-in-progress: true
```
### 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`
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)