Practice Test #6

Blob storage는 AzCopy에서 세 가지 인증 방법을 모두 지원합니다: Azure AD, access keys, SAS. - Azure AD: AzCopy는 "azcopy login"을 통해 OAuth 토큰을 사용하여 인증할 수 있습니다. 해당 ID에는 Storage Blob Data Reader/Contributor/Owner와 같은 적절한 RBAC data-plane 역할이 있어야 합니다. 이는 장기적으로 유지되는 shared secret을 피하고 최소 권한을 지원하므로 Azure Well-Architected Framework의 security pillar에서 선호되는 접근 방식입니다. - SAS: blob/container URL에 SAS 토큰을 추가할 수 있습니다. 이는 범위가 제한되고 시간 제한이 있기 때문에 자동화 및 cross-tenant 시나리오에서도 흔히 사용됩니다. - Access keys: AzCopy는 storage account key(예: environment variables 또는 connection strings를 통해)를 사용할 수 있습니다. 동작은 하지만 key는 광범위한 액세스를 제공하고 신중한 rotation이 필요하므로 가장 덜 안전합니다. 따라서 정답은 Azure AD, access keys, SAS를 모두 포함하는 선택지입니다.

Azure File storage의 경우, AzCopy 인증은 일반적으로 파일 공유에 대해 storage account access key 또는 SAS token을 사용하여 수행됩니다. - Access keys: AzCopy는 account key를 사용하여 Azure Files에 인증할 수 있으며, 이는 file service endpoint에 대한 작업을 승인합니다. 이는 간단하지만 높은 권한을 가진 shared-secret 방식입니다. - SAS: share-level SAS를 파일 공유 URL과 함께 사용할 수 있으며, 시간 제한 및 권한 범위가 지정된 액세스를 제공하므로 위임된 액세스에는 일반적으로 account keys보다 선호됩니다. - Azure AD: Azure Files는 구성에 따라 SMB 액세스에 대해 identity-based authorization(AD DS/Azure AD DS/Entra Kerberos)을 지원하지만, 일반적인 AZ-104 시험 맥락에서 AzCopy가 Blob 데이터 작업에 사용하는 방식과 동일하게 Azure AD OAuth를 사용하지는 않습니다. 따라서, AzCopy를 사용하는 Azure Files에 가장 적합한 선택지는 "Access keys 및 shared access signatures (SAS)만"입니다.

VM size를 변경하면 VMSS model이 수정되며, upgrade policy mode가 Automatic이므로 Azure는 해당 model 변경을 기존 instance에 자동으로 적용합니다. 그러나 scale set의 automatic upgrade는 가용성을 유지하기 위해 모든 instance에 한 번에 수행되지 않고, 한 번에 하나의 update domain씩 수행됩니다. instance가 4개인 경우 동시에 업데이트되는 최대 수는 1개입니다. 다른 선택지는 올바르지 않습니다. 0은 Manual mode에 해당하고, 2 또는 4는 여기서 사용되는 automatic update-domain-based 동작보다 더 큰 동시 batch를 의미하기 때문입니다.

Windows Server 2016 platform image의 새 빌드는 OS image 업데이트 시나리오이며, 이는 VMSS 자동 OS image 업그레이드 기능(AutomaticOSUpgradePolicy)에 의해 관리됩니다. 출력에서는 WindowsConfiguration에서 EnableAutomaticUpdates가 False로 표시되며, AutomaticOSUpgradePolicy 객체는 존재하지만 자동 OS 업그레이드가 활성화되어 있다는 표시가 없습니다. 시험 관점에서: 자동 OS 업그레이드가 활성화되어 있지 않으면, Azure는 기존 VMSS 인스턴스에 새 platform image 빌드를 자동으로 롤아웃하지 않습니다. 인스턴스는 사용자가 명시적으로 업그레이드/리이미지(또는 다른 방식으로 업그레이드 프로세스를 트리거)할 때까지 현재 image 버전을 계속 실행합니다. 따라서, 새 빌드는 자동으로 최대 0개의 virtual machines에 배포됩니다. 다른 선택지가 틀린 이유: B(1), C(2), D(4)는 자동 OS image 업그레이드가 활성화된 경우에만 가능하며, 그 경우 Azure가 가용성을 유지하기 위해 배치 단위로 업그레이드를 오케스트레이션합니다. 여기서는 자동 OS image 롤아웃이 사실상 비활성화되어 있습니다.

정답: A (az). Computer1에 이미 Azure CLI가 설치되어 있으므로, kubectl을 설치하는 가장 직접적이며 시험에서 기대하는 방법은 다운로드 및 설치를 자동화하는 Azure CLI 명령을 사용하는 것입니다. Azure CLI 실행 파일은 “az”이며, AKS는 “aks” 명령 그룹 아래에 “install-cli” 도우미를 제공합니다. 다른 선택지가 틀린 이유: - B (docker): Docker는 kubectl이 포함된 컨테이너 이미지를 실행할 수 있지만, 이는 “Computer1에 kubectl client를 설치”하는 것이 아니라 대체 실행 방식이며 AZ-104에서 테스트하는 표준 AKS 도구 설치 접근 방식이 아닙니다. - C (msiexec.exe): msiexec는 MSI 패키지를 설치하지만, kubectl은 일반적으로 Microsoft에서 제공하는 MSI를 통해 설치하는 것이 AKS의 주요 가이드가 아니며, 시험에서는 Azure CLI 사용을 기대합니다. - D (Install-Module): 이는 리포지토리(예: Az module)에서 PowerShell module을 설치하기 위한 PowerShell cmdlet입니다. kubectl은 PowerShell module이 아니라 독립 실행형 binary입니다.

정답: A (aks). Azure CLI를 통해 kubectl을 설치하는 전체 명령은 “az aks install-cli”입니다. 여기서 “aks”는 Azure Kubernetes Service 작업을 위한 Azure CLI 명령 그룹입니다. “install-cli” 하위 명령은 로컬 머신에 Kubernetes command-line client (kubectl)를 설치하도록 특별히 설계되었습니다. 다른 선택지가 틀린 이유: - B (/package): 이는 msiexec 같은 설치 프로그램에서 사용하는 파라미터처럼 보이며, Azure CLI의 AKS 명령에는 사용되지 않습니다. - C (-name): “--name”은 많은 az 명령(AKS cluster 작업 포함)에서 흔히 사용되지만, kubectl을 설치하기 위한 “az aks install-cli” 구문에는 포함되지 않습니다. - D (pull): “pull”은 container image 작업(예: docker pull)과 관련이 있으며, Azure CLI를 통해 kubectl을 설치하는 것과는 관련이 없습니다. 시험 팁: “az aks install-cli”(로컬에 kubectl 설치)와 “az aks get-credentials”(특정 AKS cluster에 연결하도록 kubeconfig 구성)를 혼동하지 마세요.

Pass가 적절합니다. 제시된 자료(exhibits)가 각 결과를 결정론적으로 판단하기에 충분한 정보를 제공하기 때문입니다. 이미지에서 확인 가능한 핵심 사실: - SSPR이 “Selected” 사용자에 대해 활성화되어 있으며, 선택된 그룹은 Group2입니다. - 활성화된 방법은 Mobile phone과 Security questions뿐입니다. - 재설정에 필요한 방법 수(Number of methods required to reset)가 2로 설정되어 있습니다. - Security questions는 재설정을 위해 3개의 정답이 필요합니다. - 관리자는 항상 SSPR이 활성화되며 두 가지 방법을 사용해야 한다는 메모가 있습니다. 이를 바탕으로 각 사용자를 그룹 멤버십(User1은 Group1만; User2는 Group2; User3는 admin이며 두 그룹 모두)에 따라 평가한 다음, 방법 요구 사항을 적용할 수 있습니다. 이 시험 스타일 시나리오의 로직을 답하는 데 필요한(예: licensing 같은) 누락된 의존성이 없습니다.

User2는 Group2의 멤버이고, 선택한 그룹 Group2에 대해 SSPR이 활성화되어 있으므로 User2는 self-service password reset의 적용 범위에 포함됩니다. 그러나 authentication methods policy는 비밀번호를 재설정하기 위해 두 가지 방법을 요구합니다. 세 개의 security questions에 올바르게 답하는 것은 security questions method 하나만 충족할 뿐, 전체 재설정 요구 사항을 충족하지는 않습니다. 따라서 User2는 security questions에만 답한 직후에는 비밀번호를 재설정할 수 없으며, mobile phone과 같은 두 번째 허용된 method를 완료해야 합니다.

User1은 Group1의 멤버일 뿐이며, SSPR은 선택된 그룹인 Group2에 대해서만 활성화되어 있습니다. User1은 SSPR 범위에 포함되지 않고 administrator role도 보유하고 있지 않으므로, self-service password reset을 사용할 수 없습니다. 또한 authentication methods 구성에서 mobile phone app methods는 활성화되어 있지 않으며, Mobile phone과 Security questions만 활성화되어 있습니다. 따라서 해당 진술은 거짓입니다.

User3는 privileged Azure AD role인 User administrator입니다. administrator 계정의 경우, Azure AD SSPR는 두 가지 authentication method를 요구하며 admin의 reset method로 security questions를 허용하지 않습니다. tenant에서 end user에 대해 security questions가 활성화되어 있더라도, 해당 설정은 administrator password reset 시나리오에는 적용되지 않습니다. 따라서 User3는 password reset process에 security questions를 추가할 수 없으며, admin user는 활성화된 경우 mobile phone 또는 app-based method와 같은 다른 허용된 method를 사용해야 합니다.

Pass가 적절한 이유는 recovery point 개수를 policy 설정과 타임라인으로부터 결정론적으로 도출할 수 있기 때문입니다. 이 문제를 푸는 방법: 1) 목표 timestamp까지 발생한 모든 scheduled backup 시간을 나열합니다. 2) retention을 적용합니다: daily retention 기간을 지난 daily point는 만료되며, 단 weekly/monthly/yearly로 더 긴 retention 대상으로도 표시된 경우는 예외입니다. 3) 남아 있는 고유한 recovery point를 계산합니다. 여기서는 policy가 명확합니다(UTC 기준 매일 오전 2:00; daily retention 5일; Sunday에 weekly). 목표 시각(1월 8일과 1월 15일 14:00)은 해당 날짜의 오전 2:00 backup 이후이므로, 그날의 backup은 이미 수행되었습니다. monthly/yearly 설정은 첫 2주 내에서 추가 point를 더하는 방식으로 트리거되지 않습니다. 따라서 올바른 답은 신뢰성 있게 계산할 수 있습니다.

1월 8일 14:00 UTC 기준으로, 백업은 1월 1일부터 1월 8일까지(포함) 매일 오전 2:00에 실행되어 총 8개가 생성되었습니다. 이제 보존 기간(retention)을 적용합니다. 일일 보존 기간은 5일이므로, 마지막 5개의 일일 복구 지점만 일일 포인트로 남습니다: 1월 4일, 5일, 6일, 7일, 8일(총 5개). 주간 보존 기간: 매주 일요일 오전 2:00 백업은 20주 동안 주간 포인트로도 보존됩니다. 이 기간에서 일요일은 1월 4일입니다. 해당 복구 지점(1월 4일 오전 2:00)은 이미 5개의 일일 포인트 목록에 포함되어 있으므로, 추가로 별도의 복구 지점을 더하지는 않습니다. 다만 일일 보존 기간에서 제외될 만큼 시간이 지나더라도 1월 4일 백업이 계속 사용 가능하도록 보장합니다. 따라서 1월 8일에 사용 가능한 복구 지점의 개수는 5개입니다.

1월 15일 오후 2:00 기준으로, backup은 1월 1일부터 1월 15일 오전 2:00까지 매일 수행되었습니다. 5일 daily retention에서는 여전히 유지되는 daily point가 1월 11일, 12일, 13일, 14일, 15일입니다. Weekly retention은 Sunday backup을 20주 동안 유지하므로, 1월 4일은 daily retention window 밖에 있더라도 여전히 사용할 수 있으며, 1월 11일은 이미 daily-retained set에 포함되어 있습니다. Monthly retention은 2일에 수행된 1월 2일을 보존하고, yearly retention은 1월 9일에 수행된 1월 9일을 보존하므로, 고유하게 유지되는 전체 recovery point 집합은 1월 2일, 1월 4일, 1월 9일, 1월 11일, 1월 12일, 1월 13일, 1월 14일, 1월 15일이며, 총 8개입니다.