CAPA模擬試験A

Workflow 리소스의 entrypoint 필드가 지정하는 것은?

• 워크플로 파드가 실행할 컨테이너 이미지입니다
• 결과 아티팩트를 저장할 경로입니다
• 워크플로가 사용할 ServiceAccount 이름입니다
• templates 목록 중 어느 템플릿부터 실행을 시작할지입니다

Workflow 와 WorkflowTemplate 의 관계로 옳은 것은?

• WorkflowTemplate 은 제출되는 순간 스스로 실행됩니다
• WorkflowTemplate 은 네임스페이스 안에 저장해 두고 재사용하는 정의이며, 실행은 이를 참조하는 Workflow 나 제출 동작으로 시작됩니다
• Workflow 는 정의이고 WorkflowTemplate 은 실행 인스턴스입니다
• 둘은 같은 리소스이며 이름만 다릅니다

ClusterWorkflowTemplate 을 쓰는 이유는?

• 템플릿을 여러 클러스터에 자동으로 복제하기 위해서입니다
• 템플릿 실행 속도를 높이기 위해서입니다
• 네임스페이스에 묶이지 않는 클러스터 범위 템플릿이라, 여러 팀이 같은 공용 단계를 참조할 수 있기 때문입니다
• 클러스터 관리자만 워크플로를 제출할 수 있게 제한하기 위해서입니다

Argo Workflows의 script 템플릿이 container 템플릿에 비해 제공하는 편의 기능은?

• source에 적은 코드를 임시 파일로 만들고, 그 경로를 이미지 안의 인터프리터 command에 마지막 인자로 전달합니다
• source에 적은 코드는 컨트롤러 프로세스 안에서 실행되므로, 실행 이미지와 워크플로 파드가 필요하지 않습니다
• script만 표준 출력을 outputs.result로 제공하고, container는 파일 기반 출력 파라미터만 제공할 수 있습니다
• source에 적은 코드는 항상 Python으로 해석되므로, image 안에 다른 인터프리터를 설치해도 선택할 수 없습니다

resource 템플릿이 하는 일은?

• 워크플로 파드가 쓸 CPU 와 메모리 요청량을 템플릿마다 따로 지정해 둡니다
• 쿠버네티스 매니페스트를 create 나 apply 같은 동작으로 처리하고, 성공 조건을 지정해 그 리소스가 원하는 상태가 될 때까지 기다립니다
• 아티팩트 저장소의 용량을 예약합니다
• 워크플로가 쓸 볼륨을 생성합니다

suspend 템플릿을 쓰는 상황으로 가장 적절한 것은?

• 실패한 단계를 자동으로 재시도하고 싶을 때
• 여러 단계를 동시에 실행하고 싶을 때
• 운영 배포 직전에 사람의 승인을 기다리게 하고 싶을 때
• 아티팩트를 압축해 저장하고 싶을 때

steps가 [[A], [B, C]] 형태의 중첩 목록이고 세 단계 모두 성공하며 별도 조건이 없을 때, 실행 의존 관계는?

• A가 성공한 뒤 B와 C가 같은 병렬 그룹에서 실행 대상이 됩니다
• A가 성공한 뒤 B가 성공해야 C가 실행 대상이 됩니다
• 안쪽 목록이 달라도 A와 B와 C 모두 처음부터 실행 대상이 됩니다
• B와 C는 각각 별도 Workflow가 되어 A의 완료와 관계없이 실행됩니다

dag 템플릿에서 depends 필드가 dependencies 필드보다 나은 점은?

• 선행 태스크를 여러 개 나열해 동시에 지정할 수 있습니다
• 실행 시간을 단축해 줍니다
• 순환 의존을 허용합니다
• 선행 태스크의 결과 상태까지 조건으로 쓸 수 있어, 실패했을 때만 도는 태스크 같은 흐름을 표현할 수 있습니다

입력 목록의 항목마다 같은 단계를 반복 실행하려 합니다. 알맞은 것은?

• retryStrategy 로 반복 횟수를 지정합니다
• parallelism 값을 항목 수만큼 올립니다
• withItems 나 withParam 으로 항목을 펼쳐 병렬 태스크를 생성합니다
• 같은 단계를 항목 수만큼 복사해 적습니다

워크플로에서 파라미터와 아티팩트를 구분하는 기준은?

• 파라미터는 값이 작은 문자열로 오가고, 아티팩트는 파일이나 디렉터리를 저장소를 거쳐 주고받습니다
• 파라미터는 입력에만, 아티팩트는 출력에만 쓸 수 있습니다
• 파라미터는 dag 에서만, 아티팩트는 steps 에서만 쓸 수 있습니다
• 아티팩트는 같은 파드 안에서만 전달됩니다

출력 아티팩트가 다음 단계로 넘어가지 않고 오류가 납니다. 먼저 확인할 것은?

• 워크플로의 entrypoint 이름
• dag 태스크의 이름 길이
• 파드에 할당된 CPU 요청량
• 아티팩트 저장소가 설정되어 있고 워크플로가 그 자격 증명으로 읽고 쓸 수 있는지

단계 사이에 큰 중간 파일을 공유해야 합니다. volumeClaimTemplates 를 쓰는 이유는?

• 워크플로 실행 시간을 자동으로 줄여 주기 때문입니다
• 워크플로 단위로 볼륨을 만들어 여러 단계가 같은 디스크를 함께 쓰게 하고, 끝나면 정리되도록 할 수 있기 때문입니다
• 아티팩트 저장소를 대체하는 유일한 방법이기 때문입니다
• 파드 사이의 네트워크 트래픽을 암호화하기 때문입니다

retryStrategy 의 limit 과 backoff 를 함께 지정했을 때의 동작은?

• 첫 시도부터 backoff 만큼 기다린 뒤 실행합니다
• limit 은 무시되고 성공할 때까지 재시도합니다
• backoff 가 있으면 limit 이 자동으로 무제한이 됩니다
• 실패한 단계를 최대 limit 번까지 다시 실행하되, 재시도 간격을 backoff 규칙에 따라 점점 늘립니다

완료된 워크플로 오브젝트가 계속 쌓여 etcd 를 압박합니다. 알맞은 대응은?

• 워크플로마다 네임스페이스를 새로 만듭니다
• ttlStrategy 로 완료 후 보존 시간을 정해 자동으로 삭제되게 하고, 필요하면 아카이브를 켜서 이력을 따로 남깁니다
• 컨트롤러의 parallelism 을 1 로 낮춥니다
• 완료된 워크플로를 수동으로 삭제하는 주기 작업을 따로 만듭니다

워크플로가 끝난 뒤 파드는 남아 있고 로그만 필요한 상황입니다. 관련 설정은?

• activeDeadlineSeconds 로 파드 수명을 정합니다
• parallelism 을 0 으로 두어 파드를 멈춥니다
• podGC 정책으로 파드를 언제 정리할지 정하고, 로그는 아카이브 설정으로 저장소에 남깁니다
• suspend 템플릿을 마지막에 붙여 파드를 유지합니다

워크플로가 성공하든 실패하든 항상 알림을 보내려 합니다. 알맞은 방법은?

• onExit 로 종료 처리 템플릿을 지정해 워크플로 종료 시 항상 실행되게 합니다
• 마지막 단계에 알림 태스크를 추가합니다
• retryStrategy 의 limit 을 0 으로 둡니다
• CronWorkflow 로 알림 전용 워크플로를 주기 실행합니다

워크플로 컨트롤러와 실행기(executor)의 역할 구분으로 옳은 것은?

• 컨트롤러가 각 단계의 명령을 직접 실행합니다
• 컨트롤러는 워크플로 상태를 보고 다음에 만들 파드를 결정하고, 실행기는 파드 안에서 명령 실행과 아티팩트 처리와 출력 수집을 담당합니다
• 실행기가 워크플로 제출을 받아 파드를 스케줄링하고 컨트롤러에 알립니다
• 둘은 같은 파드 안에서 함께 실행됩니다

워크플로 단계가 쿠버네티스 리소스를 만들려다 권한 오류로 실패합니다. 확인할 것은?

• 워크플로의 entrypoint 가 올바른지
• 아티팩트 저장소 용량이 남아 있는지
• 워크플로가 쓰는 ServiceAccount 에 해당 리소스를 다룰 RBAC 권한이 있는지
• 컨트롤러의 로그 수준이 debug 인지

여러 워크플로가 같은 외부 시스템을 동시에 건드리지 못하게 하려 합니다. 알맞은 것은?

• synchronization 의 mutex 나 semaphore 로 동시 실행 수를 제한합니다
• 각 워크플로의 retryStrategy 를 늘립니다
• 워크플로를 서로 다른 네임스페이스에 둡니다
• podGC 정책을 OnPodCompletion 으로 바꿉니다

CronWorkflow 에서 컨트롤러가 잠시 멈춰 예정 시각을 놓쳤을 때의 처리를 정하는 필드는?

• ttlStrategy
• activeDeadlineSeconds
• parallelism
• startingDeadlineSeconds

여러 워크플로에서 같은 단계를 재사용하려 합니다. 템플릿 참조에 대한 설명으로 옳은 것은?

• 참조된 템플릿은 실행 시점이 아니라 저장 시점에 복사되어 굳습니다
• templateRef 로 다른 WorkflowTemplate 의 템플릿을 가리키면 정의를 한곳에서 관리하면서 여러 워크플로가 쓸 수 있습니다
• 템플릿 참조는 같은 워크플로 안에서만 가능합니다
• 참조하려면 템플릿을 미리 ConfigMap 으로 복사해 같은 네임스페이스에 두어야 합니다

한 태스크가 실패해도 나머지 흐름을 계속 진행시키려 합니다. 알맞은 설정은?

• continueOn 으로 실패한 경우에도 후속 태스크를 계속 진행하도록 지정합니다
• activeDeadlineSeconds 를 늘립니다
• podGC 를 OnWorkflowCompletion 으로 둡니다
• entrypoint 를 그 태스크로 바꿉니다

Argo CD Application 의 destination 이 지정하는 것은?

• 리소스를 배포할 대상 클러스터와 네임스페이스입니다
• 매니페스트가 들어 있는 깃 저장소 주소입니다
• 동기화 결과를 알릴 채널입니다
• Helm 차트의 values 파일 경로입니다

자동 동기화에서 prune 과 selfHeal 의 차이는?

• prune 은 실패한 동기화를 되돌리고 selfHeal 은 재시도합니다
• prune 은 깃에서 사라진 리소스를 클러스터에서 지우고, selfHeal 은 클러스터에서 직접 바뀐 상태를 깃 기준으로 되돌립니다
• prune 은 네임스페이스를, selfHeal 은 파드를 대상으로 합니다
• 둘은 같은 기능이며 하나만 켜면 됩니다

Application 이 배포할 네임스페이스가 아직 없을 때 쓰는 동기화 옵션은?

• Replace
• ApplyOutOfSyncOnly
• Validate
• CreateNamespace

데이터베이스 마이그레이션을 애플리케이션 배포 직전에 돌리려 합니다. 알맞은 리소스 훅은?

• PreSync
• PostSync
• SyncFail
• Skip

훅으로 만든 Job 이 계속 쌓입니다. 조절하는 설정은?

• 동기화 옵션의 Replace 를 켭니다
• AppProject 의 destinations 를 좁힙니다
• Application 의 revisionHistoryLimit 을 줄입니다
• 훅 삭제 정책을 지정해 성공 시나 다음 실행 전에 이전 훅 리소스를 지우게 합니다

인증서 컨트롤러가 관리하는 caBundle만 Git과 다릅니다. 의도된 외부 관리 필드임을 확인했고 나머지 차이는 계속 감시하려 합니다. 알맞은 비교 설정은?

• 자동 동기화만 끄면 비교도 중지되므로 OutOfSync 표시가 사라집니다
• 인증서 리소스 전체를 비교에서 제외해 다른 필드의 변경도 무시합니다
• ignoreDifferences를 해당 리소스와 caBundle 경로로 좁혀 설정합니다
• Git에서 인증서 리소스를 삭제하고 자동 prune으로 실물을 제거합니다

Argo CD 구성 요소와 역할을 올바르게 짝지은 것은?

• repo-server 가 사용자 인증을 처리합니다
• application-controller 가 웹 UI 를 제공합니다
• redis 가 깃 저장소를 복제해 보관합니다
• repo-server 는 매니페스트를 생성하고, application-controller 는 클러스터 상태와 비교해 동기화합니다

Argo CD 가 Helm 차트를 다룰 때의 동작으로 옳은 것은?

• 차트를 렌더링해 얻은 매니페스트를 적용하므로, 클러스터에는 Helm 릴리스가 아니라 개별 리소스가 남습니다
• helm install 을 그대로 실행해 릴리스 시크릿을 만듭니다
• Helm 차트는 지원하지 않아 Kustomize 로 변환해야 합니다
• 차트의 훅은 전혀 지원되지 않습니다

Application 을 삭제했더니 클러스터의 리소스도 함께 지워졌습니다. 이 동작을 결정한 것은?

• 동기화 정책의 selfHeal 설정입니다
• 리소스에 붙은 삭제 전파 파이널라이저가 있어 연쇄 삭제가 수행된 것입니다
• AppProject 의 역할 설정입니다
• repo-server 의 캐시 만료 설정입니다

Argo CD가 브랜치를 추적하고 주기적 새로고침은 켜져 있지만 웹훅은 없습니다. 저장소 접근·서명 검증 오류도 없습니다. push 직후 변경 감지가 늦는 이유와 개선 방법은?

• 다음 주기적 새로고침까지 기다릴 수 있으며, 웹훅을 연결하면 변경 감지 대기를 줄일 수 있습니다
• 브랜치 추적은 새 커밋을 읽지 않으므로, 모든 커밋에 태그를 붙여야 변경을 감지할 수 있습니다
• 자동 동기화를 켜면 Git 변경 감지 방식도 폴링에서 웹훅으로 자동 전환됩니다
• 웹훅은 비교 없이 매니페스트를 즉시 적용하므로, 수동 동기화 정책도 자동으로 무시됩니다

Sync 상태와 Health 상태를 구분하는 이유는?

• Sync 는 마지막 동기화의 성공 여부를, Health 는 그 동기화에 걸린 시간을 나타냅니다
• Sync 는 UI 에서만, Health 는 CLI 에서만 볼 수 있습니다
• Sync 는 깃과 클러스터의 매니페스트 일치 여부이고, Health 는 배포된 리소스가 실제로 정상 동작하는지를 나타내므로 Synced 이면서 Degraded 일 수 있습니다
• 두 값은 항상 같이 움직여 사실상 하나의 지표입니다

커스텀 리소스가 항상 Progressing 으로 남아 있습니다. 알맞은 대응은?

• 그 리소스를 동기화 대상에서 제외합니다
• 자동 동기화를 꺼 둡니다
• 리소스를 Deployment 로 바꿉니다
• 그 리소스 종류에 대한 커스텀 헬스 체크를 등록해 무엇을 정상으로 볼지 정의합니다

여러 팀이 한 Argo CD 를 함께 쓸 때 AppProject 가 하는 일은?

• 팀별로 별도의 Argo CD 인스턴스를 자동 생성합니다
• 어떤 저장소에서 어떤 클러스터와 네임스페이스로, 어떤 종류의 리소스를 배포할 수 있는지 경계를 정합니다
• 팀별 리소스 쿼터를 강제합니다
• 깃 저장소의 브랜치 보호 규칙을 설정합니다

Argo CD RBAC 에서 프로젝트 역할과 전역 정책의 관계로 옳은 것은?

• 프로젝트 역할이 전역 정책을 항상 덮어씁니다
• 전역 정책이 있으면 프로젝트 역할은 무시됩니다
• 전역 정책은 인스턴스 전체의 권한을 정하고, 프로젝트 역할은 그 프로젝트 범위 안에서 권한을 부여해 팀 단위 위임에 씁니다
• 두 설정은 같은 파일에 함께 있어야 하며 둘 중 하나만 쓸 수 있습니다

Argo CD 에 조직 계정으로 로그인하게 하려 합니다. 알맞은 접근은?

• OIDC 나 번들된 Dex 를 통해 외부 아이덴티티 제공자와 연동하고, 로컬 관리자 계정은 최소한으로 제한합니다
• 사용자마다 로컬 계정을 만들어 초기 비밀번호를 나눠 줍니다
• API 토큰을 팀 채팅으로 공유합니다
• 관리자 계정 하나를 공용으로 씁니다

여러 저장소의 매니페스트와 값 파일을 한 Application 에서 함께 쓰려 합니다. 알맞은 것은?

• 저장소마다 Application 을 만들어 수동으로 순서를 맞춥니다
• 매니페스트를 한 저장소로 모두 복사합니다
• 여러 소스를 지정할 수 있는 다중 소스 구성을 쓰고, 값 파일을 다른 소스에서 참조합니다
• repo-server 를 저장소 수만큼 배포합니다

ApplicationSet 의 cluster 제너레이터가 하는 일은?

• 저장소의 디렉터리 목록으로 Application 을 만듭니다
• Argo CD 에 등록된 클러스터 목록을 읽어 각 클러스터마다 Application 을 만들어 줍니다
• 새 클러스터를 자동으로 생성해 등록합니다
• 클러스터의 노드 수에 맞춰 레플리카를 조정합니다

Application 을 UI 에서 만들었는데 클러스터를 재구축하니 모두 사라졌습니다. 재발을 막는 방법은?

• Argo CD 의 내부 저장소를 주기적으로 덤프해 백업합니다
• UI 에서 만든 뒤 스크린샷을 남깁니다
• Application 을 매니페스트로 선언해 깃에 두고, 상위 Application 이 이를 관리하도록 구성합니다
• 클러스터를 재구축하지 않도록 정책을 정합니다

Argo CD 가 자신이 관리하는 리소스를 식별하는 방식에 대한 설명으로 옳은 것은?

• 리소스의 생성 시각으로 소유권을 판단합니다
• 네임스페이스 이름이 애플리케이션 이름과 같을 때에만 관리 대상으로 인식합니다
• 관리 대상 리소스에 추적 정보를 남겨 어떤 Application 에 속하는지 표시하며, 라벨 방식과 어노테이션 방식 중 무엇을 쓸지 설정할 수 있습니다
• 매니페스트에 명시적으로 소유자를 적어야만 인식합니다

동기화 순서를 제어해 CRD 를 먼저 만들고 그다음 커스텀 리소스를 만들려 합니다. 알맞은 것은?

• 리소스 파일 이름을 알파벳 순으로 정렬합니다
• sync wave 값을 부여해 낮은 값부터 순서대로 적용되게 합니다
• 각각 별도의 Argo CD 인스턴스로 나눕니다
• 동기화를 두 번 수동으로 실행합니다

기존 Deployment 를 Rollout 으로 옮길 때 워크로드 참조를 쓰면 얻는 이점은?

• Deployment 의 파드 템플릿을 그대로 참조해 중복 정의 없이 점진적 배포 전략만 얹을 수 있습니다
• Deployment 없이도 Rollout 이 동작하게 만듭니다
• 레플리카 수를 자동으로 두 배로 늘립니다
• 분석 없이도 자동 승격이 보장됩니다

카나리 전략의 setWeight 단계가 실제로 트래픽 비율을 정확히 나누려면 무엇이 필요합니까?

• 레플리카 수를 100 의 배수로 맞춰 비율을 정확히 나눠야 합니다
• 파드에 라벨을 추가해야 합니다
• 노드를 카나리 전용으로 분리해야 합니다
• 트래픽 라우팅을 지원하는 인그레스나 메시 같은 제공자와 연동해야 하며, 없으면 레플리카 비율로 근사할 뿐입니다

카나리 단계에서 duration 없이 pause 를 두면 어떻게 됩니까?

• 기본 5분 뒤에 자동으로 다음 단계로 넘어갑니다
• 사람이 승격 명령을 내릴 때까지 무기한 대기합니다
• 롤아웃이 실패로 처리됩니다
• 즉시 다음 단계로 넘어갑니다

AnalysisTemplate 이 하는 일은?

• 롤아웃 이력을 저장합니다
• 카나리 파드의 CPU 와 메모리 사용량을 제한합니다
• 지표 질의와 성공 조건을 정의해, 롤아웃 진행 중 자동으로 판정하고 실패하면 롤백을 유도합니다
• 인그레스 규칙을 생성합니다

분석의 지표 제공자로 쓸 수 있는 것에 해당하지 않는 것은?

• Prometheus 질의
• 임의의 HTTP 엔드포인트를 호출하는 웹 방식
• 쿠버네티스 Job 을 실행해 종료 코드를 보는 방식
• 깃 저장소의 커밋 메시지를 읽는 방식

블루그린 전략에서 activeService 와 previewService 를 나누는 이유는?

• 두 서비스가 각각 다른 네임스페이스를 담당하기 때문입니다
• 미리보기 주소로 새 버전을 검증한 뒤 준비가 됐을 때 실제 트래픽 주소를 새 버전으로 옮기기 위해서입니다
• 서비스 하나로는 레플리카를 두 개 이상 가질 수 없기 때문입니다
• 이전 버전의 로그를 분리해 수집하기 위해서입니다

블루그린에서 자동 승격을 끄면 어떤 동작이 됩니까?

• 새 버전이 배포되지 않습니다
• 이전 버전이 즉시 삭제됩니다
• 설정된 분석 단계가 자동으로 비활성화됩니다
• 새 버전이 준비된 뒤에도 활성 트래픽을 넘기지 않고 수동 승격을 기다립니다

카나리 배포 도중 문제를 발견해 즉시 되돌리려 합니다. 알맞은 조치는?

• 롤아웃을 중단하는 명령으로 이전 안정 버전으로 트래픽을 되돌립니다
• 레플리카 수를 0 으로 줄입니다
• 네임스페이스를 삭제합니다
• 다음 단계로 승격해 배포를 끝냅니다

Experiment 리소스를 쓰는 상황은?

• 완료된 롤아웃의 이력을 조회할 때
• 네임스페이스별 자원 쿼터를 팀 단위로 나누어 배분할 때
• 인그레스 인증서를 갱신할 때
• 정해진 기간 동안 여러 버전을 나란히 띄워 지표를 비교하고, 그 결과를 배포 판단에 쓰고 싶을 때

카나리 파드에만 임시로 라벨을 붙여 지표를 구분하려 합니다. 알맞은 기능은?

• 파드 템플릿에 라벨을 추가하고 매번 수동으로 지웁니다
• 카나리와 안정 상태에 각각 임시 메타데이터를 지정해, 현재 역할에 맞는 라벨이 자동으로 붙고 승격 후 정리되게 합니다
• AnalysisTemplate 에 라벨을 정의합니다
• 서비스의 셀렉터를 직접 수정합니다

Rollout 의 revisionHistoryLimit 이 하는 일은?

• 동시에 실행할 수 있는 카나리 단계 수를 제한합니다
• 분석 결과를 보관할 기간을 정합니다
• 롤백 대상으로 남겨 둘 이전 레플리카셋의 개수를 제한합니다
• 롤아웃 오브젝트의 최대 크기를 제한합니다

Argo Events 의 EventSource 가 하는 일은?

• 이벤트 조건이 맞을 때 실행할 동작을 정의합니다
• 웹훅이나 캘린더나 메시지 큐 같은 외부 이벤트를 받아 EventBus 로 흘려보냅니다
• 이벤트를 영구 저장소에 보관합니다
• 워크플로 실행 결과를 알림으로 전송합니다

EventBus 를 두는 이유는?

• 이벤트를 화면에 시각화하기 위해서입니다
• EventSource 가 보낸 이벤트의 권한과 서명을 검사하기 위해서입니다
• EventSource 와 Sensor 를 느슨하게 잇는 전달 계층을 두어, 하나의 이벤트를 여러 Sensor 가 받고 일시적 장애도 버티게 하기 위해서입니다
• 워크플로 파드를 스케줄링하기 위해서입니다

Sensor 의 dependencies 가 지정하는 것은?

• 트리거가 만들 리소스의 의존 순서입니다
• Sensor 파드가 필요로 하는 컨테이너 이미지 목록입니다
• EventBus 의 레플리카 수입니다
• 어떤 EventSource 의 어떤 이벤트를 기다릴지이며, 여기에 필터를 붙여 조건을 좁힐 수 있습니다

특정 브랜치로 들어온 푸시에만 반응하게 하려 합니다. 알맞은 방법은?

• 이벤트 본문의 필드를 검사하는 데이터 필터를 dependency 에 붙입니다
• EventSource 를 브랜치마다 하나씩 만듭니다
• 트리거 안에서 워크플로가 직접 브랜치를 확인하고 종료하게 합니다
• EventBus 를 브랜치마다 분리합니다

이벤트에 담긴 값을 트리거가 만드는 워크플로의 입력으로 넘기려면?

• 트리거의 파라미터 설정으로 이벤트 페이로드의 경로를 지정해 대상 리소스의 필드에 넣습니다
• 이벤트를 환경변수로 자동 주입해 주므로 별도 설정이 필요 없습니다
• Sensor 를 워크플로와 같은 파드에 배치합니다
• 이벤트를 ConfigMap 으로 저장한 뒤 워크플로가 읽게 합니다

여러 이벤트가 모두 도착했을 때만 동작을 실행하려 합니다. 알맞은 것은?

• 트리거를 이벤트 수만큼 복제합니다
• 각 이벤트마다 Sensor 를 따로 만들고 결과를 사람이 확인합니다
• 여러 dependency 를 선언하고 트리거의 조건식으로 논리 관계를 표현합니다
• EventSource 의 폴링 주기를 늘려 이벤트가 모이게 합니다

Sensor 의 트리거로 지정할 수 있는 대상에 해당하지 않는 것은?

• Argo Workflow 생성
• 임의의 쿠버네티스 오브젝트 생성이나 갱신
• HTTP 요청 전송
• 노드의 커널 파라미터 변경