A contratação de qualquer novo sistema, módulo ou funcionalidade privados que cause dependência tecnológica do seu fornecedor poderá ensejar a responsabilização do ordenador de despesas por improbidade administrativa, sem prejuízo da comunicação da ocorrência ao respectivo tribunal de contas.

As soluções adotadas pela PDPJ-Br deverão, obrigatoriamente, abranger a autenticação uniformizada, a interoperabilidade e a usabilidade.

O grupo revisor de código-fonte das soluções da PDPJ-Br, de caráter permanente, será integrado por membros indicados pelos tribunais e pelo Departamento de Tecnologia da Informação e Comunicação do CNJ.

Os sistemas informatizados de gestão de processos e documentos utilizados em atividades judiciais e administrativas dos órgãos integrantes do Poder Judiciário deverão aderir aos requisitos do MoReq-Jus, com o objetivo de assegurar, entre outros, a confidencialidade, a integridade, a disponibilidade, a autenticidade e o não repúdio de processos e documentos do Poder Judiciário.

O programa de avaliação do grau de aderência dos sistemas ao MoReq-Jus e de atualização permanente é executado pela Secretaria Executiva do CNJ, com o apoio do Comitê do Programa Nacional de Gestão Documental e Memória do Poder Judiciário (PRONAME).

Acerca do Rancher, julgue o seguinte item.

No arquivo project.yaml a seguir, utilizado para criar projetos dentro de um cluster Kubernetes gerenciado pelo Rancher, o campo namespace no bloco metadata deve ter o mesmo valor que o campo clusterName do bloco spec para que o recurso criado seja associado a um cluster específico.

apiVersion: management.cattle.io/v3
kind: Project
metadata:
  name: p-abc123
  namespace: local
spec:
  clusterName: local
  description: Example Project
  displayName: Example

Considere que o seguinte arquivo YAML tenha sido utilizado para criar um deployment no Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

A partir das informações da situação hipotética precedente, julgue o item a seguir.

No código em questão, o campo replicas: 2 no bloco spec indica que dois contêineres serão executados dentro de um único pod de nome nginx, que será ouvido na porta 80.

Considere que o seguinte arquivo YAML tenha sido utilizado para criar um deployment no Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

A partir das informações da situação hipotética precedente, julgue o item a seguir.

O campo selector dentro do grupo spec, no código em apreço, é usado para encontrar os pods que pertencem a esse deployment, com base no rótulo app: nginx.

A respeito de CI/CD (continuous integration/continuous delivery), julgue o próximo item.

No trecho do arquivo .gitlab-ci.yml, utilizado no GitLab CI/CD para definir regras de execução de pipelines com base em variáveis de ambiente, na execução do bloco job2, o valor da variável ALL_JOBS_VAR será “Different value than default”, pois variáveis definidas no nível do job têm precedência sobre as globais com o mesmo nome.

variables:
  ALL_JOBS_VAR: "A default variable"

job1:
  variables:
    JOB1_VAR: "Job 1 variable"
  script:
    - echo "Variables are '$ ALL_JOBS_VAR' and '$ JOB1_VAR'"

job2:
  variables:
    ALL_JOBS_VAR: "Different value than default"
    JOB2_VAR: "Job 2 variable"
  script:
    - echo "Variables are '$ ALL_JOBS_VAR', '$ JOB2_VAR', and '$ JOB1_VAR'"

A respeito de CI/CD (continuous integration/continuous delivery), julgue o próximo item.

No trecho de arquivo .gitlab-ci.yml, utilizado no GitLab CI/CD para definir regras de execução de pipelines, só será criada a pipeline se as três regras de ativação do workflow.rules forem verdadeiras.

workflow:
  rules:
    -   if:         $ CI_PIPELINE_SOURCE      ==
'merge_request_event'
    - if: $ CI_COMMIT_TAG
    -   if:         $ CI_COMMIT_BRANCH        ==
$ CI_DEFAULT_BRANCH