CAPA — Argo 프로젝트 인증 어소시에이트 · 모의고사 · 퀴즈

CAPA 모의고사 A

LabHub 에서 이어서 보기

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

Workflow 리소스의 entrypoint 필드가 지정하는 것은?
1. 워크플로 파드가 실행할 컨테이너 이미지입니다
2. 결과 아티팩트를 저장할 경로입니다
3. 워크플로가 사용할 ServiceAccount 이름입니다
4. templates 목록 중 어느 템플릿부터 실행을 시작할지입니다
Workflow 와 WorkflowTemplate 의 관계로 옳은 것은?
1. WorkflowTemplate 은 제출되는 순간 스스로 실행됩니다
2. WorkflowTemplate 은 네임스페이스 안에 저장해 두고 재사용하는 정의이며, 실행은 이를 참조하는 Workflow 나 제출 동작으로 시작됩니다
3. Workflow 는 정의이고 WorkflowTemplate 은 실행 인스턴스입니다
4. 둘은 같은 리소스이며 이름만 다릅니다
ClusterWorkflowTemplate 을 쓰는 이유는?
1. 템플릿을 여러 클러스터에 자동으로 복제하기 위해서입니다
2. 템플릿 실행 속도를 높이기 위해서입니다
3. 네임스페이스에 묶이지 않는 클러스터 범위 템플릿이라, 여러 팀이 같은 공용 단계를 참조할 수 있기 때문입니다
4. 클러스터 관리자만 워크플로를 제출할 수 있게 제한하기 위해서입니다
container 템플릿과 script 템플릿의 차이는?
1. script 템플릿은 소스 코드를 본문에 적으면 파일로 만들어 실행해 주고, 그 표준 출력이 자동으로 result 출력 파라미터가 됩니다
2. script 템플릿은 파드를 만들지 않고 컨트롤러 안에서 실행됩니다
3. container 템플릿은 파라미터를 받을 수 없습니다
4. script 템플릿은 파이썬만 지원합니다
resource 템플릿이 하는 일은?
1. 워크플로 파드가 쓸 CPU 와 메모리 요청량을 템플릿마다 따로 지정해 둡니다
2. 쿠버네티스 매니페스트를 create 나 apply 같은 동작으로 처리하고, 성공 조건을 지정해 그 리소스가 원하는 상태가 될 때까지 기다립니다
3. 아티팩트 저장소의 용량을 예약합니다
4. 워크플로가 쓸 볼륨을 생성합니다
suspend 템플릿을 쓰는 상황으로 가장 적절한 것은?
1. 실패한 단계를 자동으로 재시도하고 싶을 때
2. 여러 단계를 동시에 실행하고 싶을 때
3. 운영 배포 직전에 사람의 승인을 기다리게 하고 싶을 때
4. 아티팩트를 압축해 저장하고 싶을 때
steps 템플릿에서 목록을 한 단계 더 들여쓰면 어떤 의미가 됩니까?
1. 같은 그룹에 들어가 서로 병렬로 실행됩니다
2. 그 단계가 건너뛰어집니다
3. 실행 순서가 역순이 됩니다
4. 각 단계가 별도의 워크플로로 분리됩니다
dag 템플릿에서 depends 필드가 dependencies 필드보다 나은 점은?
1. 선행 태스크를 여러 개 나열해 동시에 지정할 수 있습니다
2. 실행 시간을 단축해 줍니다
3. 순환 의존을 허용합니다
4. 선행 태스크의 결과 상태까지 조건으로 쓸 수 있어, 실패했을 때만 도는 태스크 같은 흐름을 표현할 수 있습니다
입력 목록의 항목마다 같은 단계를 반복 실행하려 합니다. 알맞은 것은?
1. retryStrategy 로 반복 횟수를 지정합니다
2. parallelism 값을 항목 수만큼 올립니다
3. withItems 나 withParam 으로 항목을 펼쳐 병렬 태스크를 생성합니다
4. 같은 단계를 항목 수만큼 복사해 적습니다
워크플로에서 파라미터와 아티팩트를 구분하는 기준은?
1. 파라미터는 값이 작은 문자열로 오가고, 아티팩트는 파일이나 디렉터리를 저장소를 거쳐 주고받습니다
2. 파라미터는 입력에만, 아티팩트는 출력에만 쓸 수 있습니다
3. 파라미터는 dag 에서만, 아티팩트는 steps 에서만 쓸 수 있습니다
4. 아티팩트는 같은 파드 안에서만 전달됩니다
출력 아티팩트가 다음 단계로 넘어가지 않고 오류가 납니다. 먼저 확인할 것은?
1. 워크플로의 entrypoint 이름
2. dag 태스크의 이름 길이
3. 파드에 할당된 CPU 요청량
4. 아티팩트 저장소가 설정되어 있고 워크플로가 그 자격 증명으로 읽고 쓸 수 있는지
단계 사이에 큰 중간 파일을 공유해야 합니다. volumeClaimTemplates 를 쓰는 이유는?
1. 워크플로 실행 시간을 자동으로 줄여 주기 때문입니다
2. 워크플로 단위로 볼륨을 만들어 여러 단계가 같은 디스크를 함께 쓰게 하고, 끝나면 정리되도록 할 수 있기 때문입니다
3. 아티팩트 저장소를 대체하는 유일한 방법이기 때문입니다
4. 파드 사이의 네트워크 트래픽을 암호화하기 때문입니다
retryStrategy 의 limit 과 backoff 를 함께 지정했을 때의 동작은?
1. 첫 시도부터 backoff 만큼 기다린 뒤 실행합니다
2. limit 은 무시되고 성공할 때까지 재시도합니다
3. backoff 가 있으면 limit 이 자동으로 무제한이 됩니다
4. 실패한 단계를 최대 limit 번까지 다시 실행하되, 재시도 간격을 backoff 규칙에 따라 점점 늘립니다
완료된 워크플로 오브젝트가 계속 쌓여 etcd 를 압박합니다. 알맞은 대응은?
1. 워크플로마다 네임스페이스를 새로 만듭니다
2. ttlStrategy 로 완료 후 보존 시간을 정해 자동으로 삭제되게 하고, 필요하면 아카이브를 켜서 이력을 따로 남깁니다
3. 컨트롤러의 parallelism 을 1 로 낮춥니다
4. 완료된 워크플로를 수동으로 삭제하는 주기 작업을 따로 만듭니다
워크플로가 끝난 뒤 파드는 남아 있고 로그만 필요한 상황입니다. 관련 설정은?
1. activeDeadlineSeconds 로 파드 수명을 정합니다
2. parallelism 을 0 으로 두어 파드를 멈춥니다
3. podGC 정책으로 파드를 언제 정리할지 정하고, 로그는 아카이브 설정으로 저장소에 남깁니다
4. suspend 템플릿을 마지막에 붙여 파드를 유지합니다
워크플로가 성공하든 실패하든 항상 알림을 보내려 합니다. 알맞은 방법은?
1. onExit 로 종료 처리 템플릿을 지정해 워크플로 종료 시 항상 실행되게 합니다
2. 마지막 단계에 알림 태스크를 추가합니다
3. retryStrategy 의 limit 을 0 으로 둡니다
4. CronWorkflow 로 알림 전용 워크플로를 주기 실행합니다
워크플로 컨트롤러와 실행기(executor)의 역할 구분으로 옳은 것은?
1. 컨트롤러가 각 단계의 명령을 직접 실행합니다
2. 컨트롤러는 워크플로 상태를 보고 다음에 만들 파드를 결정하고, 실행기는 파드 안에서 명령 실행과 아티팩트 처리와 출력 수집을 담당합니다
3. 실행기가 워크플로 제출을 받아 파드를 스케줄링하고 컨트롤러에 알립니다
4. 둘은 같은 파드 안에서 함께 실행됩니다
워크플로 단계가 쿠버네티스 리소스를 만들려다 권한 오류로 실패합니다. 확인할 것은?
1. 워크플로의 entrypoint 가 올바른지
2. 아티팩트 저장소 용량이 남아 있는지
3. 워크플로가 쓰는 ServiceAccount 에 해당 리소스를 다룰 RBAC 권한이 있는지
4. 컨트롤러의 로그 수준이 debug 인지
여러 워크플로가 같은 외부 시스템을 동시에 건드리지 못하게 하려 합니다. 알맞은 것은?
1. synchronization 의 mutex 나 semaphore 로 동시 실행 수를 제한합니다
2. 각 워크플로의 retryStrategy 를 늘립니다
3. 워크플로를 서로 다른 네임스페이스에 둡니다
4. podGC 정책을 OnPodCompletion 으로 바꿉니다
CronWorkflow 에서 컨트롤러가 잠시 멈춰 예정 시각을 놓쳤을 때의 처리를 정하는 필드는?
1. ttlStrategy
2. activeDeadlineSeconds
3. parallelism
4. startingDeadlineSeconds
여러 워크플로에서 같은 단계를 재사용하려 합니다. 템플릿 참조에 대한 설명으로 옳은 것은?
1. 참조된 템플릿은 실행 시점이 아니라 저장 시점에 복사되어 굳습니다
2. templateRef 로 다른 WorkflowTemplate 의 템플릿을 가리키면 정의를 한곳에서 관리하면서 여러 워크플로가 쓸 수 있습니다
3. 템플릿 참조는 같은 워크플로 안에서만 가능합니다
4. 참조하려면 템플릿을 미리 ConfigMap 으로 복사해 같은 네임스페이스에 두어야 합니다
한 태스크가 실패해도 나머지 흐름을 계속 진행시키려 합니다. 알맞은 설정은?
1. continueOn 으로 실패한 경우에도 후속 태스크를 계속 진행하도록 지정합니다
2. activeDeadlineSeconds 를 늘립니다
3. podGC 를 OnWorkflowCompletion 으로 둡니다
4. entrypoint 를 그 태스크로 바꿉니다
Argo CD Application 의 destination 이 지정하는 것은?
1. 리소스를 배포할 대상 클러스터와 네임스페이스입니다
2. 매니페스트가 들어 있는 깃 저장소 주소입니다
3. 동기화 결과를 알릴 채널입니다
4. Helm 차트의 values 파일 경로입니다
자동 동기화에서 prune 과 selfHeal 의 차이는?
1. prune 은 실패한 동기화를 되돌리고 selfHeal 은 재시도합니다
2. prune 은 깃에서 사라진 리소스를 클러스터에서 지우고, selfHeal 은 클러스터에서 직접 바뀐 상태를 깃 기준으로 되돌립니다
3. prune 은 네임스페이스를, selfHeal 은 파드를 대상으로 합니다
4. 둘은 같은 기능이며 하나만 켜면 됩니다
Application 이 배포할 네임스페이스가 아직 없을 때 쓰는 동기화 옵션은?
1. Replace
2. ApplyOutOfSyncOnly
3. Validate
4. CreateNamespace
데이터베이스 마이그레이션을 애플리케이션 배포 직전에 돌리려 합니다. 알맞은 리소스 훅은?
1. PreSync
2. PostSync
3. SyncFail
4. Skip
훅으로 만든 Job 이 계속 쌓입니다. 조절하는 설정은?
1. 동기화 옵션의 Replace 를 켭니다
2. AppProject 의 destinations 를 좁힙니다
3. Application 의 revisionHistoryLimit 을 줄입니다
4. 훅 삭제 정책을 지정해 성공 시나 다음 실행 전에 이전 훅 리소스를 지우게 합니다
컨트롤러가 매번 변경으로 인식하는 필드가 있어 애플리케이션이 계속 OutOfSync 로 보입니다. 알맞은 대응은?
1. 자동 동기화를 꺼서 OutOfSync 표시가 뜨지 않게 합니다
2. 리소스를 프로젝트에서 제외합니다
3. ignoreDifferences 로 그 필드 경로를 비교 대상에서 제외합니다
4. 매니페스트에서 그 리소스를 삭제합니다
Argo CD 구성 요소와 역할을 올바르게 짝지은 것은?
1. repo-server 가 사용자 인증을 처리합니다
2. application-controller 가 웹 UI 를 제공합니다
3. redis 가 깃 저장소를 복제해 보관합니다
4. repo-server 는 매니페스트를 생성하고, application-controller 는 클러스터 상태와 비교해 동기화합니다
Argo CD 가 Helm 차트를 다룰 때의 동작으로 옳은 것은?
1. 차트를 렌더링해 얻은 매니페스트를 적용하므로, 클러스터에는 Helm 릴리스가 아니라 개별 리소스가 남습니다
2. helm install 을 그대로 실행해 릴리스 시크릿을 만듭니다
3. Helm 차트는 지원하지 않아 Kustomize 로 변환해야 합니다
4. 차트의 훅은 전혀 지원되지 않습니다
Application 을 삭제했더니 클러스터의 리소스도 함께 지워졌습니다. 이 동작을 결정한 것은?
1. 동기화 정책의 selfHeal 설정입니다
2. 리소스에 붙은 삭제 전파 파이널라이저가 있어 연쇄 삭제가 수행된 것입니다
3. AppProject 의 역할 설정입니다
4. repo-server 의 캐시 만료 설정입니다
깃에 커밋을 밀었는데 Argo CD 가 한동안 변화를 알아채지 못합니다. 가장 정확한 설명은?
1. 컨트롤러가 주기적으로 저장소를 폴링하기 때문이며, 웹훅을 붙이면 반영이 즉시에 가까워집니다
2. 커밋 서명이 없어서 무시된 것입니다
3. Argo CD 는 태그가 붙은 커밋만 읽습니다
4. 저장소 권한이 없으면 상태가 Synced 로 표시됩니다
Sync 상태와 Health 상태를 구분하는 이유는?
1. Sync 는 마지막 동기화의 성공 여부를, Health 는 그 동기화에 걸린 시간을 나타냅니다
2. Sync 는 UI 에서만, Health 는 CLI 에서만 볼 수 있습니다
3. Sync 는 깃과 클러스터의 매니페스트 일치 여부이고, Health 는 배포된 리소스가 실제로 정상 동작하는지를 나타내므로 Synced 이면서 Degraded 일 수 있습니다
4. 두 값은 항상 같이 움직여 사실상 하나의 지표입니다
커스텀 리소스가 항상 Progressing 으로 남아 있습니다. 알맞은 대응은?
1. 그 리소스를 동기화 대상에서 제외합니다
2. 자동 동기화를 꺼 둡니다
3. 리소스를 Deployment 로 바꿉니다
4. 그 리소스 종류에 대한 커스텀 헬스 체크를 등록해 무엇을 정상으로 볼지 정의합니다
여러 팀이 한 Argo CD 를 함께 쓸 때 AppProject 가 하는 일은?
1. 팀별로 별도의 Argo CD 인스턴스를 자동 생성합니다
2. 어떤 저장소에서 어떤 클러스터와 네임스페이스로, 어떤 종류의 리소스를 배포할 수 있는지 경계를 정합니다
3. 팀별 리소스 쿼터를 강제합니다
4. 깃 저장소의 브랜치 보호 규칙을 설정합니다
Argo CD RBAC 에서 프로젝트 역할과 전역 정책의 관계로 옳은 것은?
1. 프로젝트 역할이 전역 정책을 항상 덮어씁니다
2. 전역 정책이 있으면 프로젝트 역할은 무시됩니다
3. 전역 정책은 인스턴스 전체의 권한을 정하고, 프로젝트 역할은 그 프로젝트 범위 안에서 권한을 부여해 팀 단위 위임에 씁니다
4. 두 설정은 같은 파일에 함께 있어야 하며 둘 중 하나만 쓸 수 있습니다
Argo CD 에 조직 계정으로 로그인하게 하려 합니다. 알맞은 접근은?
1. OIDC 나 번들된 Dex 를 통해 외부 아이덴티티 제공자와 연동하고, 로컬 관리자 계정은 최소한으로 제한합니다
2. 사용자마다 로컬 계정을 만들어 초기 비밀번호를 나눠 줍니다
3. API 토큰을 팀 채팅으로 공유합니다
4. 관리자 계정 하나를 공용으로 씁니다
여러 저장소의 매니페스트와 값 파일을 한 Application 에서 함께 쓰려 합니다. 알맞은 것은?
1. 저장소마다 Application 을 만들어 수동으로 순서를 맞춥니다
2. 매니페스트를 한 저장소로 모두 복사합니다
3. 여러 소스를 지정할 수 있는 다중 소스 구성을 쓰고, 값 파일을 다른 소스에서 참조합니다
4. repo-server 를 저장소 수만큼 배포합니다
ApplicationSet 의 cluster 제너레이터가 하는 일은?
1. 저장소의 디렉터리 목록으로 Application 을 만듭니다
2. Argo CD 에 등록된 클러스터 목록을 읽어 각 클러스터마다 Application 을 만들어 줍니다
3. 새 클러스터를 자동으로 생성해 등록합니다
4. 클러스터의 노드 수에 맞춰 레플리카를 조정합니다
Application 을 UI 에서 만들었는데 클러스터를 재구축하니 모두 사라졌습니다. 재발을 막는 방법은?
1. Argo CD 의 내부 저장소를 주기적으로 덤프해 백업합니다
2. UI 에서 만든 뒤 스크린샷을 남깁니다
3. Application 을 매니페스트로 선언해 깃에 두고, 상위 Application 이 이를 관리하도록 구성합니다
4. 클러스터를 재구축하지 않도록 정책을 정합니다
Argo CD 가 자신이 관리하는 리소스를 식별하는 방식에 대한 설명으로 옳은 것은?
1. 리소스의 생성 시각으로 소유권을 판단합니다
2. 네임스페이스 이름이 애플리케이션 이름과 같을 때에만 관리 대상으로 인식합니다
3. 관리 대상 리소스에 추적 정보를 남겨 어떤 Application 에 속하는지 표시하며, 라벨 방식과 어노테이션 방식 중 무엇을 쓸지 설정할 수 있습니다
4. 매니페스트에 명시적으로 소유자를 적어야만 인식합니다
동기화 순서를 제어해 CRD 를 먼저 만들고 그다음 커스텀 리소스를 만들려 합니다. 알맞은 것은?
1. 리소스 파일 이름을 알파벳 순으로 정렬합니다
2. sync wave 값을 부여해 낮은 값부터 순서대로 적용되게 합니다
3. 각각 별도의 Argo CD 인스턴스로 나눕니다
4. 동기화를 두 번 수동으로 실행합니다
기존 Deployment 를 Rollout 으로 옮길 때 워크로드 참조를 쓰면 얻는 이점은?
1. Deployment 의 파드 템플릿을 그대로 참조해 중복 정의 없이 점진적 배포 전략만 얹을 수 있습니다
2. Deployment 없이도 Rollout 이 동작하게 만듭니다
3. 레플리카 수를 자동으로 두 배로 늘립니다
4. 분석 없이도 자동 승격이 보장됩니다
카나리 전략의 setWeight 단계가 실제로 트래픽 비율을 정확히 나누려면 무엇이 필요합니까?
1. 레플리카 수를 100 의 배수로 맞춰 비율을 정확히 나눠야 합니다
2. 파드에 라벨을 추가해야 합니다
3. 노드를 카나리 전용으로 분리해야 합니다
4. 트래픽 라우팅을 지원하는 인그레스나 메시 같은 제공자와 연동해야 하며, 없으면 레플리카 비율로 근사할 뿐입니다
카나리 단계에서 duration 없이 pause 를 두면 어떻게 됩니까?
1. 기본 5분 뒤에 자동으로 다음 단계로 넘어갑니다
2. 사람이 승격 명령을 내릴 때까지 무기한 대기합니다
3. 롤아웃이 실패로 처리됩니다
4. 즉시 다음 단계로 넘어갑니다
AnalysisTemplate 이 하는 일은?
1. 롤아웃 이력을 저장합니다
2. 카나리 파드의 CPU 와 메모리 사용량을 제한합니다
3. 지표 질의와 성공 조건을 정의해, 롤아웃 진행 중 자동으로 판정하고 실패하면 롤백을 유도합니다
4. 인그레스 규칙을 생성합니다
분석의 지표 제공자로 쓸 수 있는 것에 해당하지 않는 것은?
1. Prometheus 질의
2. 임의의 HTTP 엔드포인트를 호출하는 웹 방식
3. 쿠버네티스 Job 을 실행해 종료 코드를 보는 방식
4. 깃 저장소의 커밋 메시지를 읽는 방식
블루그린 전략에서 activeService 와 previewService 를 나누는 이유는?
1. 두 서비스가 각각 다른 네임스페이스를 담당하기 때문입니다
2. 미리보기 주소로 새 버전을 검증한 뒤 준비가 됐을 때 실제 트래픽 주소를 새 버전으로 옮기기 위해서입니다
3. 서비스 하나로는 레플리카를 두 개 이상 가질 수 없기 때문입니다
4. 이전 버전의 로그를 분리해 수집하기 위해서입니다
블루그린에서 자동 승격을 끄면 어떤 동작이 됩니까?
1. 새 버전이 배포되지 않습니다
2. 이전 버전이 즉시 삭제됩니다
3. 설정된 분석 단계가 자동으로 비활성화됩니다
4. 새 버전이 준비된 뒤에도 활성 트래픽을 넘기지 않고 수동 승격을 기다립니다
카나리 배포 도중 문제를 발견해 즉시 되돌리려 합니다. 알맞은 조치는?
1. 롤아웃을 중단하는 명령으로 이전 안정 버전으로 트래픽을 되돌립니다
2. 레플리카 수를 0 으로 줄입니다
3. 네임스페이스를 삭제합니다
4. 다음 단계로 승격해 배포를 끝냅니다
Experiment 리소스를 쓰는 상황은?
1. 완료된 롤아웃의 이력을 조회할 때
2. 네임스페이스별 자원 쿼터를 팀 단위로 나누어 배분할 때
3. 인그레스 인증서를 갱신할 때
4. 정해진 기간 동안 여러 버전을 나란히 띄워 지표를 비교하고, 그 결과를 배포 판단에 쓰고 싶을 때
카나리 파드에만 임시로 라벨을 붙여 지표를 구분하려 합니다. 알맞은 기능은?
1. 파드 템플릿에 라벨을 추가하고 매번 수동으로 지웁니다
2. 카나리와 안정 상태에 각각 임시 메타데이터를 지정해, 현재 역할에 맞는 라벨이 자동으로 붙고 승격 후 정리되게 합니다
3. AnalysisTemplate 에 라벨을 정의합니다
4. 서비스의 셀렉터를 직접 수정합니다
Rollout 의 revisionHistoryLimit 이 하는 일은?
1. 동시에 실행할 수 있는 카나리 단계 수를 제한합니다
2. 분석 결과를 보관할 기간을 정합니다
3. 롤백 대상으로 남겨 둘 이전 레플리카셋의 개수를 제한합니다
4. 롤아웃 오브젝트의 최대 크기를 제한합니다
Argo Events 의 EventSource 가 하는 일은?
1. 이벤트 조건이 맞을 때 실행할 동작을 정의합니다
2. 웹훅이나 캘린더나 메시지 큐 같은 외부 이벤트를 받아 EventBus 로 흘려보냅니다
3. 이벤트를 영구 저장소에 보관합니다
4. 워크플로 실행 결과를 알림으로 전송합니다
EventBus 를 두는 이유는?
1. 이벤트를 화면에 시각화하기 위해서입니다
2. EventSource 가 보낸 이벤트의 권한과 서명을 검사하기 위해서입니다
3. EventSource 와 Sensor 를 느슨하게 잇는 전달 계층을 두어, 하나의 이벤트를 여러 Sensor 가 받고 일시적 장애도 버티게 하기 위해서입니다
4. 워크플로 파드를 스케줄링하기 위해서입니다
Sensor 의 dependencies 가 지정하는 것은?
1. 트리거가 만들 리소스의 의존 순서입니다
2. Sensor 파드가 필요로 하는 컨테이너 이미지 목록입니다
3. EventBus 의 레플리카 수입니다
4. 어떤 EventSource 의 어떤 이벤트를 기다릴지이며, 여기에 필터를 붙여 조건을 좁힐 수 있습니다
특정 브랜치로 들어온 푸시에만 반응하게 하려 합니다. 알맞은 방법은?
1. 이벤트 본문의 필드를 검사하는 데이터 필터를 dependency 에 붙입니다
2. EventSource 를 브랜치마다 하나씩 만듭니다
3. 트리거 안에서 워크플로가 직접 브랜치를 확인하고 종료하게 합니다
4. EventBus 를 브랜치마다 분리합니다
이벤트에 담긴 값을 트리거가 만드는 워크플로의 입력으로 넘기려면?
1. 트리거의 파라미터 설정으로 이벤트 페이로드의 경로를 지정해 대상 리소스의 필드에 넣습니다
2. 이벤트를 환경변수로 자동 주입해 주므로 별도 설정이 필요 없습니다
3. Sensor 를 워크플로와 같은 파드에 배치합니다
4. 이벤트를 ConfigMap 으로 저장한 뒤 워크플로가 읽게 합니다
여러 이벤트가 모두 도착했을 때만 동작을 실행하려 합니다. 알맞은 것은?
1. 트리거를 이벤트 수만큼 복제합니다
2. 각 이벤트마다 Sensor 를 따로 만들고 결과를 사람이 확인합니다
3. 여러 dependency 를 선언하고 트리거의 조건식으로 논리 관계를 표현합니다
4. EventSource 의 폴링 주기를 늘려 이벤트가 모이게 합니다
Sensor 의 트리거로 지정할 수 있는 대상에 해당하지 않는 것은?
1. Argo Workflow 생성
2. 임의의 쿠버네티스 오브젝트 생성이나 갱신
3. HTTP 요청 전송
4. 노드의 커널 파라미터 변경