クイズ: カタログの品質と整合性

엔티티가 카탈로그에 없는 Group 을 spec.owner 로 가리키고 있습니다. Backstage 의 반응으로 가장 정확한 것은?

• 스키마 위반으로 판정되어 엔티티 등록 자체가 거부된다
• 포털이 그 이름의 Group 엔티티를 자동으로 만들어 채운다
• 등록은 되지만 소유 관계가 계산되지 않아 화면에 빈 칸으로 보인다
• 카탈로그 처리 주기가 멈추고 다른 엔티티도 갱신되지 않는다

참조를 비교하기 전에 정규화해야 하는 이유는?

• 같은 대상을 가리키는 세 가지 표기를 문자열로 비교하면 멀쩡한 참조가 끊긴 것으로 보고되기 때문
• 정규화하지 않은 참조는 카탈로그가 등록 단계에서 거부해 버리기 때문
• 네임스페이스를 생략해서 쓴 참조는 문법 오류로 취급되기 때문
• 정규화를 거쳐야 카탈로그가 관계를 양방향으로 계산해 주기 때문

spec.dependsOn 이 서로를 가리켜 순환이 생겼을 때 실질적인 문제는?

• 카탈로그 데이터베이스가 계속 커져 저장 공간이 마른다
• 순환에 참여한 엔티티가 다음 처리 주기에 자동으로 삭제된다
• 그 엔티티들의 TechDocs 문서가 더 이상 렌더링되지 않는다
• 영향도 분석이 의미를 잃는다. 답이 자기 자신으로 돌아온다

결함이 많은 카탈로그를 고칠 때 권장되는 순서는?

• 개별 엔티티의 필수 필드부터 채우고 조직 데이터는 가장 마지막에 본다
• 조직 데이터를 먼저, 묶음을 다음에, 개별 엔티티를 마지막에 고친다
• 순환부터 끊고 나머지 결함은 전부 다음 분기로 미뤄 둔다
• 가장 오래전에 만들어진 엔티티부터 순서대로 하나씩 고친다

결함이 있는 엔티티를 삭제해 진단 결과를 0 건으로 만드는 것에 대한 평가로 옳은 것은?

• 정상적인 정리 방법이다. 카탈로그는 유효한 엔티티만 담아야 한다
• 삭제해도 카탈로그가 자동으로 복원하므로 의미가 없다
• 고친 것이 아니다. 카탈로그의 목적은 가진 것을 빠짐없이 보여 주는 것이고, 안 보이게 만든 서비스도 장애는 낸다
• 엔티티 수가 줄어 처리 주기가 빨라지므로 권장된다

카탈로그 lint 게이트를 만들었을 때 반드시 해야 하는 확인은?

• 결함을 일부러 넣은 입력에서 0 이 아닌 값이 나오는지 확인한다
• 깨끗한 입력에서 0 이 나오는지만 확인하면 충분하다
• 실행 시간이 1초 미만인지 확인한다
• 게이트가 자동으로 파일을 고쳐 주는지 확인한다

다음 중 Resource 엔티티의 필수 필드 조합으로 옳은 것은?

• spec.type 과 spec.lifecycle
• spec.owner 와 spec.system
• spec.lifecycle 과 spec.owner
• spec.type 과 spec.owner