플랫폼 엔지니어는 개발팀이 사용할 카탈로그와 스키마를 만들고 있습니다.
엔지니어는 초기 카탈로그(catalog_A)와 초기 스키마(schema_A)를 생성했습니다. 또한 개발팀에게 USE CATALOG, USE SCHEMA 및 CREATE TABLE 권한을 부여하여 엔지니어가 스키마에 새 테이블을 추가할 수 있도록 했습니다.
카탈로그와 스키마의 소유자임에도 불구하고, 엔지니어는 Schema_A의 기본 테이블에 접근할 수 없다는 사실을 발견했습니다.
엔지니어가 기본 테이블에 접근할 수 없는 이유는 무엇입니까?

• A. USE CATALOG 권한이 부여된 사용자는 하위 테이블에 대한 소유자의 권한을 수정할 수 있습니다.
• B. 스키마 소유자는 스키마 내 테이블에 대한 권한을 자동으로 갖지 않지만, 언제든지 자신에게 권한을 부여할 수 있습니다.
• C. 테이블 생성자가 명시적으로 부여한 권한만이 플랫폼 엔지니어가 해당 스키마의 기본 테이블에 접근할 수 있는 유일한 방법입니다.
• D. 테이블 소유자 권한이 자동으로 업데이트되지 않았으므로 플랫폼 엔지니어는 REFRESH 문을 실행해야 합니다.

데이터 엔지니어링 팀의 한 구성원이 더 큰 데이터 파이프라인의 일부로 실행되도록 예약하려는 간단한 노트북 파일을 제출했습니다. 아래 제공된 명령어를 제시된 대로 실행하면 논리적으로 올바른 결과가 생성된다고 가정합니다.

노트북을 작업으로 예약하기 전에 어떤 명령어를 제거해야 할까요?

• A. 명령 3
• B. 명령 6
• C. 명령 2
• D. 명령 4
• E. 명령 5

데이터 엔지니어가 Lakeflow Spark Declarative Pipelines Expectations를 사용하여 수신되는 센서 데이터의 품질을 추적하고 있습니다. 센서에서 주기적으로 범위를 벗어난 잘못된 측정값이 전송되는데, 현재 팀은 이러한 행에 경고 표시를 하고 정상 데이터와 함께 실버 테이블에 기록하고 있습니다. 그런데 새로운 요구 사항이 생겼습니다. 잘못된 행을 별도의 격리 테이블에 저장하고 더 이상 실버 테이블에 포함시키지 않아야 한다는 것입니다.
이것은 실버 테이블에 대한 기존 코드입니다.
@dlt.table
@dlt.expect( " valid_sensor_reading " , " reading < 120 " )
def silver_sensor_readings():
spark.readStream.table(" bronze_sensor_readings " )를 반환합니다.
어떤 코드가 요구 사항을 충족할까요?

• A. @dlt.table
  @dlt.expect_or_drop( " valid_sensor_reading " , " reading < 120 " )
  def silver_sensor_readings():
  return spark.readStream.table( " bronze_sensor_readings " )
• B. @dlt.table
  @dlt.expect_or_drop( " valid_sensor_reading " , " reading < 120 " )
  def silver_sensor_readings():
  return spark.readStream.table( " bronze_sensor_readings " )
  @dlt.table
  @dlt.expect( " invalid_sensor_reading " , " reading < 120 " )
  def quarantine_sensor_readings():
  return spark.readStream.table( " bronze_sensor_readings " )
• C. @dlt.table
  @dlt.expect_or_drop( " valid_sensor_reading " , " reading < 120 " )
  def silver_sensor_readings():
  return spark.readStream.table( " bronze_sensor_readings " )
  @dlt.table
  @dlt.expect( " invalid_sensor_reading " , " reading > = 120 " )
  def quarantine_sensor_readings():
  return spark.readStream.table( " bronze_sensor_readings " )
• D. @dlt.table
  @dlt.expect( " valid_sensor_reading " , " reading < 120 " )
  def silver_sensor_readings():
  return spark.readStream.table( " bronze_sensor_readings " )
  @dlt.table
  @dlt.expect( " invalid_sensor_reading " , " reading > = 120 " )
  def quarantine_sensor_readings():
  return spark.readStream.table( " bronze_sensor_readings " )

데이터 엔지니어가 의료비 청구 데이터를 처리하기 위해 Lakeflow Declarative Pipelines 파이프라인을 구축하고 있습니다. 메타데이터 JSON 파일에는 다음을 포함한 여러 테이블에 대한 데이터 품질 규칙이 정의되어 있습니다.
{
" claims " : [
{ " name " : " valid_patient_id " , " constraint " : " patient_id IS NOT NULL " },
{ " name " : " non_negative_amount " , " constraint " : " claim_amount > = 0 " }
]
}
파이프라인은 규칙을 하드코딩하지 않고 이러한 규칙을 클레임 테이블에 동적으로 적용해야 합니다.
데이터 엔지니어는 어떻게 이를 달성해야 할까요?

• A. JSON 파일 경로를 참조하는 SQL CONSTRAINT 블록을 사용하십시오.
• B. JSON 메타데이터를 로드하고, 해당 항목을 순회하며, dlt.expect_all을 사용하여 기대치를 적용합니다.
• C. 테이블 선언에서 각 기대치를 참조할 때 @dlt.expect 데코레이터를 사용하세요.
• D. 외부 API를 호출하여 메타데이터 규칙에 따라 레코드의 유효성을 검사합니다.