CBA 모의고사 A

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

1. 새 Backstage 앱을 처음 만들 때 사용하는 방법으로 옳은 것은?

   1. 코어 패키지를 의존성으로 추가하면 앱 구조가 자동으로 생깁니다
   2. upstream 저장소를 그대로 복제해 사내 저장소로 옮겨 씁니다
   3. 공식 앱 생성기를 실행해 앱 골격을 만들고 그 저장소를 사내에서 관리합니다
   4. 공개 컨테이너 이미지를 그대로 실행하면 됩니다

2. 로컬 개발에서 개발 서버를 띄웠을 때 일어나는 일은?

   1. 프로덕션 번들을 만들어 정적 파일로 출력하고 종료합니다
   2. 백엔드만 기동하고 프론트엔드는 따로 띄워야 합니다
   3. 데이터베이스 마이그레이션만 수행하고 종료합니다
   4. 프론트엔드와 백엔드를 함께 기동해 코드 변경을 즉시 반영합니다

3. Backstage 앱 저장소에서 `packages/` 와 `plugins/` 디렉터리가 나뉜 이유는?

   1. `packages/` 에는 앱 자체인 프론트엔드와 백엔드가, `plugins/` 에는 이 저장소에서 개발하는 플러그인이 들어갑니다
   2. `packages/` 는 프론트엔드 전용이고 `plugins/` 는 백엔드 전용입니다
   3. `packages/` 는 빌드 산출물이 쌓이는 곳이고 `plugins/` 가 소스 디렉터리입니다
   4. `packages/` 는 공개 레지스트리에 배포되고 `plugins/` 는 배포되지 않습니다

4. 개발 서버가 정상으로 도는데도 타입 검사를 따로 실행해야 하는 이유는?

   1. 번들러가 타입 오류가 있는 코드는 절대 빌드하지 않고 즉시 멈추기 때문입니다
   2. 개발 서버의 번들러는 타입 검사를 건너뛰므로 타입 오류가 실행 중에는 드러나지 않기 때문입니다
   3. 타입 검사가 끝나야 의존성 설치가 시작되기 때문입니다
   4. 타입스크립트 컴파일러만 JSX 문법을 해석할 수 있기 때문입니다

5. 워크스페이스에 새 플러그인 패키지를 추가하는 방법으로 적절한 것은?

   1. 제공되는 생성 명령으로 종류를 골라 플러그인 골격을 만듭니다
   2. 새 Backstage 앱을 처음부터 다시 만들어 그 안에 넣습니다
   3. 카탈로그에 새 Component 엔티티로 등록하면 코드가 생성됩니다
   4. 데이터베이스에 플러그인 테이블을 먼저 만듭니다

6. Backstage 저장소에서 의존성 잠금 파일을 커밋해 두어야 하는 이유는?

   1. 잠금 파일이 있어야 플러그인이 카탈로그에 등록되기 때문입니다
   2. 잠금 파일에 앱 설정값이 함께 저장되기 때문입니다
   3. 잠금 파일이 없으면 타입스크립트가 컴파일되지 않기 때문입니다
   4. 빌드 환경마다 전이 의존성 버전이 달라지는 것을 막아 재현 가능한 빌드를 얻기 위해서입니다

7. 프로덕션용 백엔드 빌드 명령이 하는 일은?

   1. 프론트엔드 정적 파일만 생성합니다
   2. 컨테이너 이미지를 만들어 레지스트리에 올립니다
   3. 백엔드 패키지를 번들해 컨테이너 이미지에 넣을 수 있는 형태로 만듭니다
   4. 데이터베이스에 스키마를 적용합니다

8. Backstage 문서가 권장하는 기본 컨테이너 빌드 방식은?

   1. 소스 전체를 이미지 안에 넣고 컨테이너 안에서 의존성 설치부터 수행하는 방식입니다
   2. 호스트에서 먼저 빌드한 뒤 산출물만 이미지에 복사하는 방식입니다
   3. 빌드 없이 개발 서버를 그대로 이미지로 굳히는 방식입니다
   4. 프론트엔드와 백엔드를 반드시 서로 다른 이미지로 분리하는 방식입니다

9. 이미지에 프로덕션 설정 파일을 넣고도 환경마다 값을 다르게 하려면?

   1. 환경마다 이미지를 따로 빌드합니다
   2. 컨테이너가 시작할 때 설정 파일을 스크립트로 덮어씁니다
   3. 설정을 소스 코드에 상수로 넣고 분기합니다
   4. 설정에서 환경 변수 치환을 쓰고 실행 시점에 변수를 주입합니다

10. 프론트엔드 번들이 빌드 시점의 설정을 담게 되는 결과로 주의할 점은?

    1. 번들에 담긴 값은 실행 중에 언제든 안전하게 바뀝니다
    2. 번들에는 백엔드 설정까지 빠짐없이 포함됩니다
    3. 빌드 시점에 굳은 값이 브라우저에 노출되므로 비밀값을 넣으면 안 됩니다
    4. 프론트엔드는 설정을 전혀 사용하지 않습니다

11. 로컬에서 백엔드 플러그인의 동작을 확인하려 합니다. 가장 먼저 볼 곳은?

    1. 브라우저 개발자 도구의 요소 검사 탭입니다
    2. 개발 서버를 실행한 터미널에 찍히는 백엔드 로그입니다
    3. 카탈로그 엔티티 페이지의 개요 카드입니다
    4. 빌드 산출물 디렉터리에 생긴 번들 파일입니다

12. Backstage 관련 패키지 버전을 한꺼번에 올려 주는 명령의 역할은?

    1. 저장소 안의 Backstage 패키지 버전을 서로 맞는 조합으로 함께 올립니다
    2. 앱의 릴리스 태그를 올려 새 버전을 발행합니다
    3. 데이터베이스 스키마 버전을 올립니다
    4. 카탈로그 엔티티의 apiVersion 을 최신으로 바꿉니다

13. Backstage 프로젝트에서 기본 테스트 명령이 실행하는 것은?

    1. 브라우저를 띄워 종단 간 시나리오를 검증합니다
    2. 각 패키지의 단위 테스트를 테스트 러너로 실행합니다
    3. 타입 검사만 수행하고 테스트는 건너뜁니다
    4. 린트 규칙 위반만 검사합니다

14. Backstage 를 빌드할 때 Node.js 버전을 프로젝트가 요구하는 범위로 맞춰야 하는 이유는?

    1. Node 버전에 따라 카탈로그 스키마가 달라지기 때문입니다
    2. Node 버전이 다르면 설정 파일 문법이 바뀌기 때문입니다
    3. 네이티브 모듈 빌드와 패키지가 선언한 실행 환경 제약이 버전에 묶여 있어 설치나 실행이 실패하기 때문입니다
    4. Node 버전이 포털의 기본 테마를 결정하기 때문입니다

15. Backstage 의 클라이언트-서버 구조를 옳게 설명한 것은?

    1. 브라우저에서 도는 React 앱과 Node.js 백엔드가 HTTP 로 통신하며 백엔드가 외부 시스템 연동을 담당합니다
    2. 브라우저가 외부 시스템 API 를 직접 호출하고 백엔드는 정적 파일만 제공합니다
    3. 백엔드가 서버에서 HTML 을 만들어 내려 주는 서버 사이드 렌더링 구조입니다
    4. 프론트엔드와 백엔드가 한 프로세스에서 동작하는 단일 바이너리 구조입니다

16. 기본 설정 파일과 프로덕션 설정 파일을 함께 읽었을 때의 동작은?

    1. 나중 파일이 앞 파일을 통째로 대체합니다
    2. 두 파일의 값이 다르면 기동이 실패합니다
    3. 프로덕션 파일은 프론트엔드에만 적용됩니다
    4. 두 파일이 병합되며 나중에 지정한 파일의 값이 앞선 값을 덮어씁니다

17. 프로덕션 Backstage 에 PostgreSQL 을 권장하는 이유는?

    1. 카탈로그와 여러 백엔드 플러그인이 영속 저장소를 쓰는데 기본 인메모리 저장소는 재시작에 사라지기 때문입니다
    2. PostgreSQL 을 써야 문서 플러그인의 빌드 기능이 동작하기 때문입니다
    3. SQLite 는 타입스크립트에서 사용할 수 없기 때문입니다
    4. PostgreSQL 을 써야 인증 플러그인이 동작하기 때문입니다

18. 프로덕션에 올렸더니 프론트엔드에서 백엔드 요청이 모두 실패합니다. 가장 먼저 볼 설정은?

    1. 카탈로그의 정적 위치 목록입니다
    2. 앱과 백엔드의 기준 주소, 그리고 교차 출처 허용 설정입니다
    3. 문서 플러그인의 빌드 방식 설정입니다
    4. 인증 제공자의 콜백 주소입니다

19. 프론트엔드와 백엔드를 같은 호스트 이름으로 서비스하는 구성의 이점은?

    1. 백엔드 플러그인을 설치하지 않아도 화면이 동작합니다
    2. 설정 파일 개수를 하나로 줄일 수 있습니다
    3. 데이터베이스 연결 수가 줄어듭니다
    4. 브라우저에서 교차 출처 요청이 생기지 않아 관련 설정과 쿠키 처리가 단순해집니다

20. 프로덕션에서 게스트 인증 제공자를 그대로 두면 안 되는 이유는?

    1. 게스트 제공자를 쓰면 백엔드가 기동하지 못합니다
    2. 게스트 제공자로는 카탈로그를 읽을 수 없습니다
    3. 누구나 로그인할 수 있어 신원과 소유권에 기반한 권한 판정이 무의미해지기 때문입니다
    4. 게스트 제공자는 PostgreSQL 과 함께 쓸 수 없기 때문입니다

21. 소스 관리 시스템 연동에 토큰을 설정하는 목적은?

    1. 로그인 화면을 대신 표시하기 위해서입니다
    2. 빌드 워크플로를 대신 실행하기 위해서입니다
    3. 카탈로그 엔티티를 소스 저장소에 백업하기 위해서입니다
    4. 백엔드가 저장소 내용을 읽고 API 호출 한도를 넉넉히 쓰기 위해서입니다

22. 설정 파일에 토큰을 직접 적지 않고 외부에서 주입하는 방법은?

    1. 값 자리에 환경 변수 참조를 적고 실행 환경에서 그 변수를 채웁니다
    2. 설정 파일 전체를 암호화한 뒤 백엔드가 복호화하게 합니다
    3. 토큰을 데이터베이스 테이블에 넣고 설정에서 참조합니다
    4. 토큰을 프론트엔드 번들에 넣고 백엔드가 읽어 가게 합니다

23. Backstage 를 쿠버네티스에 배포하면서 컨테이너 재시작에도 데이터가 남게 하려면?

    1. 파드에 영속 볼륨을 붙여 로컬 파일 데이터베이스를 저장합니다
    2. 레플리카 수를 하나로 고정해 재시작을 막습니다
    3. 외부 PostgreSQL 을 연결하고 접속 정보를 시크릿으로 주입합니다
    4. 카탈로그 처리 주기를 길게 잡아 재수집을 줄입니다

24. Backstage 백엔드를 두 개 이상의 레플리카로 늘릴 때 확인해야 할 것은?

    1. 프론트엔드 번들을 레플리카마다 다르게 빌드해야 합니다
    2. 여러 인스턴스가 같은 데이터베이스를 공유하고 주기 작업이 중복 실행되지 않게 조율되는지 확인해야 합니다
    3. 각 레플리카가 자신만의 카탈로그 데이터베이스를 갖도록 분리해야 합니다
    4. 레플리카 수만큼 연동 토큰을 나눠 발급해야 합니다

25. 브라우저에서 사내 API 를 직접 호출하지 않고 백엔드의 프록시 설정을 쓰는 이유는?

    1. 프론트엔드에서는 타입스크립트를 쓸 수 없기 때문입니다
    2. 프록시가 모든 응답을 캐시해 항상 더 빠르기 때문입니다
    3. 자격증명을 백엔드에 두고 교차 출처 문제도 함께 피할 수 있기 때문입니다
    4. 사내 API 가 REST 가 아니어도 자동으로 변환해 주기 때문입니다

26. Backstage 를 새 릴리스로 올릴 때 권장되는 절차는?

    1. 새 앱을 처음부터 만들어 기존 소스를 그대로 덮어쓴 뒤 배포합니다
    2. 버전 일괄 상향과 업그레이드 도우미가 알려 주는 변경을 함께 적용한 뒤 로컬에서 기동을 확인합니다
    3. 패키지 파일의 버전 문자열만 손으로 고칩니다
    4. 컨테이너 이미지 태그만 바꿔 재배포합니다

27. 권한 프레임워크를 켰을 때 실제로 결정되는 것은?

    1. 사용자가 어떤 인증 제공자로 로그인할 수 있는지입니다
    2. 백엔드가 어떤 포트로 요청을 받을지입니다
    3. 카탈로그 데이터를 어느 데이터베이스에 저장할지입니다
    4. 특정 사용자가 특정 엔티티나 동작에 대해 요청을 수행할 수 있는지입니다

28. 카탈로그에서 Location 엔티티의 역할은?

    1. 다른 엔티티 정의가 있는 위치를 가리켜 카탈로그가 그곳을 읽어 오게 합니다
    2. 엔티티가 배포된 물리적 데이터센터를 기록합니다
    3. 문서가 저장된 버킷 경로를 지정합니다
    4. 사용자가 소속된 사무실을 나타냅니다

29. 설정 파일의 위치 목록에 URL 을 적어 두는 정적 등록 방식의 성격으로 옳은 것은?

    1. 포털 화면에서 지우면 설정 파일에서도 함께 사라집니다
    2. 설정 파일이 출처이므로 화면에서 지워도 다음 수집에서 다시 나타납니다
    3. 정적 등록은 Component 만 지원하고 API 는 지원하지 않습니다
    4. 정적 등록된 위치는 처리 주기와 무관하게 한 번만 읽힙니다

30. 애너테이션 `backstage.io/managed-by-location` 이 알려 주는 것은?

    1. 엔티티를 담당하는 팀의 연락처입니다
    2. 엔티티가 배포된 쿠버네티스 네임스페이스입니다
    3. 엔티티가 마지막으로 갱신된 시각입니다
    4. 이 엔티티 정의가 어디에서 읽혀 왔는지의 출처입니다

31. 등록한 저장소의 엔티티가 화면에 나타나지 않습니다. 진단으로 가장 효율적인 것은?

    1. 데이터베이스를 초기화하고 백엔드를 재시작합니다
    2. 프론트엔드 번들을 다시 빌드합니다
    3. 해당 위치의 처리 오류 메시지를 확인하고 매니페스트 스키마와 접근 권한을 점검합니다
    4. 엔티티 이름을 바꿔 다시 등록해 봅니다

32. 엔티티의 이름 필드에 적용되는 제약으로 옳은 것은?

    1. 소문자와 숫자, 그리고 일부 구분 기호만 쓸 수 있고 길이 상한이 있습니다
    2. 공백을 포함한 사람이 읽기 좋은 문장을 그대로 쓸 수 있습니다
    3. 대문자를 반드시 하나 이상 포함해야 합니다
    4. 네임스페이스를 접두어로 붙여 적어야 합니다

33. 카탈로그의 관계가 만들어지는 방식으로 옳은 것은?

    1. 엔티티의 spec 필드를 처리기가 해석해 양쪽 방향의 관계로 생성합니다
    2. 운영자가 화면에서 두 엔티티를 손으로 이어 주어야 합니다
    3. 관계 전용 엔티티 종류를 따로 만들어야 합니다
    4. 데이터베이스의 관계 테이블에 직접 행을 넣어야 합니다

34. 데이터베이스나 오브젝트 스토리지처럼 서비스가 의존하는 인프라를 표현하는 엔티티 종류는?

    1. System 엔티티입니다
    2. Domain 엔티티입니다
    3. Resource 엔티티입니다
    4. Location 엔티티입니다

35. 컴포넌트 정의에 특정 리소스를 의존 대상으로 적었을 때 생기는 일은?

    1. 해당 리소스가 자동으로 프로비저닝됩니다
    2. 엔티티 페이지에 접속 문자열이 표시됩니다
    3. 그 리소스가 아직 없으면 엔티티 등록이 거부됩니다
    4. 두 엔티티 사이에 의존 관계가 생겨 서로의 페이지에서 확인할 수 있습니다

36. 조직의 저장소를 자동으로 훑어 엔티티 정의 파일을 찾아 등록하는 방식을 부르는 이름은?

    1. 스캐폴더 액션 실행입니다
    2. 엔티티 제공자를 통한 디스커버리입니다
    3. 권한 정책 평가입니다
    4. 프록시 엔드포인트 등록입니다

37. 저장소에서 엔티티 정의 파일을 지웠는데 엔티티가 남아 있습니다. 이 상태에 대한 설명은?

    1. 정상 상태이며 백엔드를 재시작하면 사라집니다
    2. 오류 상태이며 백엔드가 기동에 실패합니다
    3. 고아 상태로 표시되며 설정에 따라 정리 대상이 됩니다
    4. 잠금 상태가 되어 더 이상 수정할 수 없습니다

38. 애너테이션 `backstage.io/source-location` 을 지정하는 목적은?

    1. 엔티티 페이지에서 실제 소스 코드 위치로 바로 이동할 수 있게 하기 위해서입니다
    2. 빌드 파이프라인이 소스를 내려받을 경로를 지정하기 위해서입니다
    3. 문서 빌더가 문서 원본을 찾을 경로를 지정하기 위해서입니다
    4. 카탈로그가 엔티티 정의를 읽어 올 위치를 바꾸기 위해서입니다

39. 카탈로그가 이미 등록된 엔티티를 주기적으로 다시 처리하는 이유는?

    1. 데이터베이스 인덱스를 다시 만들기 위해서입니다
    2. 원본 매니페스트나 참조 대상이 바뀐 것을 반영해 카탈로그를 최신으로 유지하기 위해서입니다
    3. 엔티티 식별자를 새로 발급하기 위해서입니다
    4. 권한 정책을 다시 평가하기 위해서입니다

40. 존재하지 않는 엔티티 종류를 적은 정의 파일을 등록하면 어떻게 되나요?

    1. 알 수 없는 종류가 그대로 등록되고 화면에 빈 페이지가 생깁니다
    2. 백엔드가 기동에 실패해 포털 전체가 멈춥니다
    3. 가장 비슷한 종류로 자동 교정되어 등록됩니다
    4. 해당 위치에 처리 오류가 기록되고 엔티티는 등록되지 않습니다

41. 새 프론트엔드 플러그인을 앱에 붙이려면 무엇을 해야 하나요?

    1. 플러그인 패키지를 설치하면 라우트가 자동으로 추가됩니다
    2. 백엔드에 플러그인을 등록하면 프론트엔드에도 함께 반영됩니다
    3. 앱 패키지에 의존성을 추가하고 라우트와 화면 요소를 앱 코드에 직접 연결합니다
    4. 설정 파일에 플러그인 이름만 적으면 됩니다

42. 엔티티 페이지에 새 탭을 추가하려면 주로 어느 곳을 고치나요?

    1. 앱 패키지의 엔티티 페이지 구성 파일에서 레이아웃 라우트를 추가합니다
    2. 백엔드의 카탈로그 플러그인 소스를 직접 수정합니다
    3. 엔티티 정의 파일에 탭 정의를 추가합니다
    4. 데이터베이스의 엔티티 테이블에 열을 추가합니다

43. 특정 애너테이션이 있는 엔티티에서만 카드를 보여 주려면?

    1. 애너테이션마다 별도의 엔티티 페이지 파일을 만듭니다
    2. 카드 안에서 애너테이션이 없으면 오류를 던지게 합니다
    3. 백엔드에서 해당 엔티티만 남도록 걸러 냅니다
    4. 조건부 렌더링 장치를 써서 그 애너테이션이 있을 때만 카드를 그리게 합니다

44. Backstage UI 를 확장할 때 코어가 쓰는 것과 같은 UI 라이브러리를 쓰는 이유는?

    1. 그 라이브러리만 타입스크립트를 지원하기 때문입니다
    2. 코어 컴포넌트와 같은 기반 위에 있어 테마와 스타일이 일관되게 적용되기 때문입니다
    3. 그 라이브러리를 써야 번들 크기가 줄어들기 때문입니다
    4. 다른 UI 라이브러리는 설치가 차단되어 있기 때문입니다

45. 포털 전체의 색상과 타이포그래피를 회사 브랜드에 맞추려면?

    1. 각 플러그인의 스타일 파일을 하나씩 수정합니다
    2. 커스텀 테마를 만들어 앱에 등록하고 필요한 팔레트 값을 재정의합니다
    3. 설정 파일의 조직 항목에 색상 코드를 적습니다
    4. 브라우저 확장 프로그램으로 스타일을 덮어씁니다

46. 프론트엔드 컴포넌트에서 백엔드 데이터를 가져올 때 권장되는 방식은?

    1. 컴포넌트 안에서 토큰을 직접 만들어 요청을 보냅니다
    2. 전역 변수에 응답을 저장해 두고 계속 재사용합니다
    3. 백엔드 주소를 소스에 상수로 적어 호출합니다
    4. API 레지스트리에서 클라이언트를 받아 훅 안에서 호출하고 로딩과 오류 상태를 함께 다룹니다

47. 백엔드 플러그인을 앱에 추가할 때 하는 일은?

    1. 백엔드 패키지에서 해당 플러그인을 백엔드 인스턴스에 등록합니다
    2. 프론트엔드 라우트에 화면 컴포넌트를 추가합니다
    3. 카탈로그에 Component 엔티티로 등록합니다
    4. 데이터베이스에 플러그인 테이블을 직접 만듭니다

48. 플러그인이 외부 서비스와 통신하는 클라이언트를 팩토리로 등록해 두는 이점은?

    1. 번들 크기가 줄어 초기 로딩이 빨라집니다
    2. 백엔드를 거치지 않고 곧바로 호출할 수 있습니다
    3. 구현을 교체하거나 테스트에서 대역으로 바꿔 끼울 수 있습니다
    4. 설정 파일 없이도 서비스 주소를 자동으로 찾아냅니다

49. 스캐폴더에 사내 전용 단계를 넣으려면?

    1. 커스텀 액션을 만들어 스캐폴더 백엔드에 등록하고 템플릿에서 그 액션을 부릅니다
    2. 템플릿 파일에 셸 스크립트를 그대로 적어 넣습니다
    3. 프론트엔드 컴포넌트에서 그 작업을 직접 수행합니다
    4. 카탈로그 처리기에 해당 로직을 넣습니다

50. 템플릿 입력 화면에 사내 시스템에서 값을 골라 오는 입력 칸을 넣으려면?

    1. 스키마의 열거 목록에 가능한 값을 모두 나열해 둡니다
    2. 사용자가 값을 직접 입력하게 하고 액션에서 검증합니다
    3. 커스텀 필드 확장을 만들어 템플릿에서 그 필드를 쓰게 합니다
    4. 프록시 설정만 추가하면 목록이 자동으로 나타납니다

51. 플러그인 사이를 오가는 링크를 만들 때 경로 문자열 대신 라우트 참조를 쓰는 이유는?

    1. 라우트 참조가 없으면 링크가 새 탭으로 열리기 때문입니다
    2. 앱에서 플러그인이 붙은 실제 경로를 바꿔도 링크가 따라오기 때문입니다
    3. 라우트 참조를 써야 권한 검사가 수행되기 때문입니다
    4. 경로 문자열은 프로덕션 빌드에서 제거되기 때문입니다

52. Backstage 프론트엔드 컴포넌트를 테스트할 때 테스트용 앱 래퍼를 쓰는 이유는?

    1. 테스트에서 실제 백엔드를 반드시 띄워야 하기 때문입니다
    2. 래퍼가 컴포넌트의 타입을 자동으로 생성해 주기 때문입니다
    3. 래퍼 없이는 테스트 러너가 타입스크립트를 해석하지 못하기 때문입니다
    4. 컴포넌트가 기대하는 API 와 라우팅 문맥을 테스트에서 대신 제공해야 하기 때문입니다

53. 포털 첫 화면을 팀마다 다르게 구성하고 싶습니다. 적절한 접근은?

    1. 팀 수만큼 Backstage 인스턴스를 따로 배포합니다
    2. 엔티티 정의 파일에 화면 구성을 적어 둡니다
    3. 각 팀의 필터 화면을 북마크로 저장하게 안내합니다
    4. 홈 화면의 카드 구성을 앱 코드에서 조립하고 사용자 정보에 따라 다르게 그립니다

54. 검색 결과에 사내 위키 문서를 포함시키려면?

    1. 검색 화면에 위키로 이동하는 링크를 하나 추가합니다
    2. 위키 문서를 색인하는 수집기를 붙이고 결과 종류에 맞는 표시 컴포넌트를 추가합니다
    3. 위키 문서를 모두 Component 엔티티로 카탈로그에 등록합니다
    4. 프록시 설정으로 위키 검색 API 를 그대로 노출합니다

55. 코어 컴포넌트의 기본 모양을 바꾸고 싶을 때 가장 안전한 방법은?

    1. 설치된 패키지 디렉터리 안의 코어 소스를 직접 고칩니다
    2. 전역 스타일로 코어의 클래스 이름을 덮어씁니다
    3. 테마의 컴포넌트 재정의나 제공되는 확장 지점을 사용합니다
    4. 코어 패키지를 포크해 사내 레지스트리에 올려 씁니다

56. 플러그인 패키지 안의 개발용 디렉터리가 하는 일은?

    1. 플러그인만 따로 띄워 개발하고 확인할 수 있는 최소 앱을 정의합니다
    2. 플러그인의 프로덕션 빌드 산출물을 담습니다
    3. 플러그인 문서의 원본 파일을 담습니다
    4. 플러그인이 쓰는 데이터베이스 마이그레이션을 담습니다

57. 카탈로그 엔티티 삭제를 소유 팀에게만 허용하려면?

    1. 인증 제공자에서 그 사용자들만 로그인할 수 있게 제한합니다
    2. 권한 정책에서 해당 동작에 소유권 조건을 붙여 판정하게 합니다
    3. 프론트엔드에서 삭제 버튼을 숨깁니다
    4. 데이터베이스 사용자에게서 삭제 권한을 회수합니다

58. 엔티티 페이지에 카드를 나란히 배치할 때 적절한 방식은?

    1. 그리드 컨테이너와 항목을 조합해 화면 폭에 따라 열 수가 달라지게 합니다
    2. 카드마다 고정 픽셀 폭을 지정합니다
    3. 카드를 표 태그로 감싸 배치합니다
    4. 카드마다 절대 위치를 지정합니다

59. 사내에서만 쓰는 플러그인을 여러 Backstage 인스턴스에서 공유하려면?

    1. 각 인스턴스의 소스에 파일을 복사해 넣습니다
    2. 플러그인 코드를 카탈로그 엔티티에 첨부합니다
    3. 설정 파일에 플러그인 소스 경로를 적어 원격에서 읽게 합니다
    4. 패키지로 빌드해 사내 레지스트리에 배포하고 각 앱이 의존성으로 설치합니다

60. 앱 코드를 많이 고친 상태에서 업그레이드가 어려워지는 이유와 완화책으로 옳은 것은?

    1. 업그레이드가 앱 코드를 자동으로 되돌리므로 백업만 해 두면 됩니다
    2. 수정한 파일은 업그레이드 대상에서 제외되므로 신경 쓸 필요가 없습니다
    3. 수정 지점이 흩어질수록 병합 부담이 커지므로 변경을 별도 플러그인이나 확장 지점으로 모아 두는 편이 낫습니다
    4. 업그레이드는 의존성만 바꾸므로 앱 코드와는 무관합니다