LabHub

GitLab CI/CD · 현장에서의 파이프라인 · 퀴즈

퀴즈: 러너와 안전장치

LabHub 에서 이어서 보기

문항 5개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. 설정에 문법 오류가 없는데 잡이 계속 대기 상태로만 남아 있다. 가장 먼저 의심할 것은?

    1. 잡의 tags 를 만족하는 러너가 등록돼 있지 않다
    2. 스테이지 이름의 철자가 stages 목록과 다르다
    3. 앞 잡이 만든 아티팩트의 만료 기간이 지났다
    4. 캐시 저장 공간의 한도를 넘겨 축출이 일어났다
  2. CI 변수의 '마스킹' 에 대한 설명으로 옳은 것은?

    1. 보호 브랜치에서 도는 잡에만 값을 넘겨 주는 접근 제어 장치다
    2. 로그 출력에서 값을 가려 줄 뿐이라 인코딩해 찍으면 그대로 드러난다
    3. 값을 암호화해 저장하므로 관리자도 원본을 볼 수 없게 만든다
    4. 포크에서 온 병합 요청에 변수가 넘어가지 않게 막아 준다
  3. 다른 저장소의 템플릿을 `include` 로 가져올 때 `ref` 를 커밋 SHA 로 고정하는 이유는?

    1. SHA 로 적으면 템플릿을 내려받는 속도가 눈에 띄게 빨라지기 때문
    2. 브랜치 이름으로 적으면 GitLab 이 include 자체를 거부하기 때문
    3. 브랜치는 나중에 다른 커밋을 가리킬 수 있어 우리 설정이 조용히 바뀌기 때문
    4. 커밋 SHA 로 적어야 템플릿 안의 변수를 덮어쓸 수 있기 때문
  4. 운영 배포 잡을 승인 게이트로 만들려면 무엇이 필요한가?

    1. when 을 manual 로 두고 allow_failure 를 false 로 명시한다
    2. when 을 always 로 두고 stage 를 맨 뒤로 옮긴다
    3. needs 를 비워 다른 잡을 기다리지 않게 만든다
    4. rules 를 지우고 only 로 브랜치를 지정한다
  5. 배포에 쓰는 이미지 태그를 커밋 SHA 로 두면 얻는 것은?

    1. 레지스트리 저장 용량이 줄어 비용이 함께 내려간다
    2. 이미지 빌드 시간이 캐시 적중으로 크게 짧아진다
    3. 러너가 이미지를 내려받는 시간이 절반으로 줄어든다
    4. 사고 때 무엇이 나갔는지 확정할 수 있고 되돌릴 대상이 남는다