PS PowerShell · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Реестр Windows

Реестр Windows: практический тест по PowerShell с чтением кода, поиском причины ошибки и выбором надёжного решения. Темы: Провайдер реестра Windows, Ключи и значения, Проверка существования, Права. Базовая линия — PowerShell 7.6.3; Windows-зависимые команды и отличия Windows PowerShell 5.1 отмечены в условиях.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В каждом вопросе верен только один вариант; близкие ответы различаются механизмом, порядком выполнения, областью действия или эксплуатационной границей. После завершения вы увидите общий результат, результаты по 4 тематическим шкалам и подробные объяснения.

Вопрос 1 из 20

Как перечислить разделы HKCU через обычный командлет?

$result = Get-ChildItem HKCU:\Software | Select-Object -First 3
$resultType = if($null -eq $result){'<null>'}else{$result.GetType().FullName}
[pscustomobject]@{ Result=$result; Type=$resultType; Count=@($result).Count }

Test-Path HKCU:\Software\Demo проверяет item-раздел, но не подтверждает наличие конкретного значения внутри него. Обычный Registry provider работает с локальным процессом; удалённое изменение выполняют в удалённом сеансе или через специализированный API. Провайдер Registry представляет разделы как контейнеры PowerShell; Get-ChildItem HKCU: перечисляет подразделы, а не значения текущего раздела. Диски HKLM: и HKCU: создаются провайдером Registry только на Windows; кроссплатформенный сценарий должен проверять платформу и наличие PSDrive. В PowerShell item соответствует разделу реестра, а item property — именованному значению; это различие определяет нужный командлет.

Вопрос 2 из 20

На Linux выполняется обращение к HKLM:. Как следует читать этот фрагмент?

$result = Get-PSDrive -PSProvider Registry
$shape = if($null -eq $result){'<null>'}elseif($result -is [array]){'array'}else{$result.GetType().Name}
[pscustomobject]@{ Shape=$shape; Values=@($result) }

Test-Path HKCU:\Software\Demo проверяет item-раздел, но не подтверждает наличие конкретного значения внутри него. Обычный Registry provider работает с локальным процессом; удалённое изменение выполняют в удалённом сеансе или через специализированный API. Диски HKLM: и HKCU: создаются провайдером Registry только на Windows; кроссплатформенный сценарий должен проверять платформу и наличие PSDrive. Resolve-Path требует существования; для построения ещё не созданного пути используют Join-Path и затем New-Item. В PowerShell item соответствует разделу реестра, а item property — именованному значению; это различие определяет нужный командлет.

Вопрос 3 из 20

Resolve-Path применяется к несуществующему будущему разделу. На каком правиле основан результат?

$result = Join-Path HKCU:\Software "DemoApp"
$items = @($result)
[pscustomobject]@{ Count=$items.Count; First=$items | Select-Object -First 1; IsNull=($null -eq $result) }

Диски HKLM: и HKCU: создаются провайдером Registry только на Windows; кроссплатформенный сценарий должен проверять платформу и наличие PSDrive. Обычный Registry provider работает с локальным процессом; удалённое изменение выполняют в удалённом сеансе или через специализированный API. В PowerShell item соответствует разделу реестра, а item property — именованному значению; это различие определяет нужный командлет. Resolve-Path требует существования; для построения ещё не созданного пути используют Join-Path и затем New-Item. Для отката нужно записать наличие, тип и исходное значение; «удалить созданное» неверно, если значение существовало до запуска.

Вопрос 4 из 20

Сценарий смешивает термин «ключ» для раздела и значения. Как следует читать этот фрагмент?

Обычный Registry provider работает с локальным процессом; удалённое изменение выполняют в удалённом сеансе или через специализированный API. В PowerShell item соответствует разделу реестра, а item property — именованному значению; это различие определяет нужный командлет. Провайдер Registry представляет разделы как контейнеры PowerShell; Get-ChildItem HKCU: перечисляет подразделы, а не значения текущего раздела. Rename-Item переименовывает раздел, а Rename-ItemProperty — значение внутри раздела; это разные уровни модели провайдера. Resolve-Path требует существования; для построения ещё не созданного пути используют Join-Path и затем New-Item.

Вопрос 5 из 20

Удалённый реестр открывается как локальный PSDrive. Какое утверждение верно для этого случая?

В PowerShell item соответствует разделу реестра, а item property — именованному значению; это различие определяет нужный командлет. Диски HKLM: и HKCU: создаются провайдером Registry только на Windows; кроссплатформенный сценарий должен проверять платформу и наличие PSDrive. RegistrySecurity описывает владельца и правила доступа; изменение ACL требует точной правки нужного правила, а не замены списка вслепую. Провайдер Registry представляет разделы как контейнеры PowerShell; Get-ChildItem HKCU: перечисляет подразделы, а не значения текущего раздела. Обычный Registry provider работает с локальным процессом; удалённое изменение выполняют в удалённом сеансе или через специализированный API.

Вопрос 6 из 20

New-ItemProperty создаёт DWORD. Какой вывод можно подтвердить?

New-Item -Path HKCU:\Software\Demo -Force | Out-Null
New-ItemProperty -Path HKCU:\Software\Demo -Name Enabled -Value 1 -PropertyType DWord -Force

Тип задаётся -PropertyType DWord; строка, число и двоичные данные должны соответствовать ожидаемому типу потребителя. Get-ItemProperty возвращает объект со свойствами значений и служебными PSPath/PSParentPath; нужное значение следует выбирать явно. Rename-Item переименовывает раздел, а Rename-ItemProperty — значение внутри раздела; это разные уровни модели провайдера. Для отката нужно записать наличие, тип и исходное значение; «удалить созданное» неверно, если значение существовало до запуска. Get-ItemPropertyValue возвращает непосредственно значение и выдаёт ошибку при отсутствии; её можно преобразовать в контролируемый результат.

Вопрос 7 из 20

Get-ItemProperty читает именованное значение. Как поступить, чтобы поведение осталось предсказуемым?

$result = (Get-ItemProperty HKCU:\Software\Demo -Name Enabled).Enabled
$resultType = if($null -eq $result){'<null>'}else{$result.GetType().FullName}
[pscustomobject]@{ Result=$result; Type=$resultType; Count=@($result).Count }

Get-ItemPropertyValue возвращает непосредственно значение и выдаёт ошибку при отсутствии; её можно преобразовать в контролируемый результат. Get-ItemProperty возвращает объект со свойствами значений и служебными PSPath/PSParentPath; нужное значение следует выбирать явно. Тип задаётся -PropertyType DWord; строка, число и двоичные данные должны соответствовать ожидаемому типу потребителя. Для отката нужно записать наличие, тип и исходное значение; «удалить созданное» неверно, если значение существовало до запуска. Работа с безымянным значением зависит от API и представления провайдера; его нужно тестировать отдельно, а не подменять обычным именованным свойством.

Вопрос 8 из 20

Значение переименовывается. Что точнее всего описывает поведение?

$result = Rename-ItemProperty -Path HKCU:\Software\Demo -Name Enabled -NewName IsEnabled
$shape = if($null -eq $result){'<null>'}elseif($result -is [array]){'array'}else{$result.GetType().Name}
[pscustomobject]@{ Shape=$shape; Values=@($result) }

Тип задаётся -PropertyType DWord; строка, число и двоичные данные должны соответствовать ожидаемому типу потребителя. Для отката нужно записать наличие, тип и исходное значение; «удалить созданное» неверно, если значение существовало до запуска. Rename-Item переименовывает раздел, а Rename-ItemProperty — значение внутри раздела; это разные уровни модели провайдера. В PowerShell item соответствует разделу реестра, а item property — именованному значению; это различие определяет нужный командлет. Get-ItemProperty возвращает объект со свойствами значений и служебными PSPath/PSParentPath; нужное значение следует выбирать явно.

Вопрос 9 из 20

Значение по умолчанию раздела имеет пустое отображаемое имя. Какое условие нужно проверить отдельно?

Проверка только значения не различает отсутствующее свойство и существующее с null-подобным содержимым; нужно исследовать PSObject.Properties. Rename-Item переименовывает раздел, а Rename-ItemProperty — значение внутри раздела; это разные уровни модели провайдера. Для отката нужно записать наличие, тип и исходное значение; «удалить созданное» неверно, если значение существовало до запуска. Работа с безымянным значением зависит от API и представления провайдера; его нужно тестировать отдельно, а не подменять обычным именованным свойством. Тип задаётся -PropertyType DWord; строка, число и двоичные данные должны соответствовать ожидаемому типу потребителя.

Вопрос 10 из 20

Сценарий меняет параметр реестра без сохранения прежнего значения. Как исправить причину, а не только симптом?

Get-ItemProperty возвращает объект со свойствами значений и служебными PSPath/PSParentPath; нужное значение следует выбирать явно. Rename-Item переименовывает раздел, а Rename-ItemProperty — значение внутри раздела; это разные уровни модели провайдера. Работа с безымянным значением зависит от API и представления провайдера; его нужно тестировать отдельно, а не подменять обычным именованным свойством. В PowerShell item соответствует разделу реестра, а item property — именованному значению; это различие определяет нужный командлет. Для отката нужно записать наличие, тип и исходное значение; «удалить созданное» неверно, если значение существовало до запуска.

Вопрос 11 из 20

Test-Path проверяет наличие раздела. Как следует читать этот фрагмент?

$result = Test-Path HKCU:\Software\Demo
$items = @($result)
[pscustomobject]@{ Count=$items.Count; First=$items | Select-Object -First 1; IsNull=($null -eq $result) }

Get-ItemPropertyValue возвращает непосредственно значение и выдаёт ошибку при отсутствии; её можно преобразовать в контролируемый результат. Провайдер Registry представляет разделы как контейнеры PowerShell; Get-ChildItem HKCU: перечисляет подразделы, а не значения текущего раздела. Между Test-Path и New-Item возможна гонка; операция должна быть идемпотентной и корректно обрабатывать уже созданный объект. Test-Path HKCU:\Software\Demo проверяет item-раздел, но не подтверждает наличие конкретного значения внутри него. Проверка только значения не различает отсутствующее свойство и существующее с null-подобным содержимым; нужно исследовать PSObject.Properties.

Вопрос 12 из 20

Проверяется значение через Get-ItemPropertyValue. Что фактически произойдёт при выполнении?

$result = Get-ItemPropertyValue -Path HKCU:\Software\Demo -Name Enabled -ErrorAction Stop
$items = @($result)
[pscustomobject]@{ Count=$items.Count; First=$items | Select-Object -First 1; IsNull=($null -eq $result) }

Get-ItemPropertyValue возвращает непосредственно значение и выдаёт ошибку при отсутствии; её можно преобразовать в контролируемый результат. Нужно ограничить допустимые корни и имена, потому что проверка существования не делает произвольное изменение безопасным. Get-ItemProperty возвращает объект со свойствами значений и служебными PSPath/PSParentPath; нужное значение следует выбирать явно. Test-Path HKCU:\Software\Demo проверяет item-раздел, но не подтверждает наличие конкретного значения внутри него. Между Test-Path и New-Item возможна гонка; операция должна быть идемпотентной и корректно обрабатывать уже созданный объект.

Вопрос 13 из 20

Свойство существует, но его значение равно $null. Что стоит изменить в первую очередь?

Проверка только значения не различает отсутствующее свойство и существующее с null-подобным содержимым; нужно исследовать PSObject.Properties. Работа с безымянным значением зависит от API и представления провайдера; его нужно тестировать отдельно, а не подменять обычным именованным свойством. Нужно ограничить допустимые корни и имена, потому что проверка существования не делает произвольное изменение безопасным. Между Test-Path и New-Item возможна гонка; операция должна быть идемпотентной и корректно обрабатывать уже созданный объект. Test-Path HKCU:\Software\Demo проверяет item-раздел, но не подтверждает наличие конкретного значения внутри него.

Вопрос 14 из 20

Проверка и создание выполняются раздельно в параллельных процессах. Какой принцип PowerShell здесь работает?

Test-Path HKCU:\Software\Demo проверяет item-раздел, но не подтверждает наличие конкретного значения внутри него. Resolve-Path требует существования; для построения ещё не созданного пути используют Join-Path и затем New-Item. Между Test-Path и New-Item возможна гонка; операция должна быть идемпотентной и корректно обрабатывать уже созданный объект. Get-ItemPropertyValue возвращает непосредственно значение и выдаёт ошибку при отсутствии; её можно преобразовать в контролируемый результат. Нужно ограничить допустимые корни и имена, потому что проверка существования не делает произвольное изменение безопасным.

Вопрос 15 из 20

Путь реестра поступает извне. Что остаётся непроверенным после успешного запуска?

Перед правкой нужно сохранить дескриптор безопасности и проверять восстановление; неверный ACL способен заблокировать и приложение, и администраторов. Между Test-Path и New-Item возможна гонка; операция должна быть идемпотентной и корректно обрабатывать уже созданный объект. Проверка только значения не различает отсутствующее свойство и существующее с null-подобным содержимым; нужно исследовать PSObject.Properties. Нужно ограничить допустимые корни и имена, потому что проверка существования не делает произвольное изменение безопасным. Test-Path HKCU:\Software\Demo проверяет item-раздел, но не подтверждает наличие конкретного значения внутри него.

Вопрос 16 из 20

Чтение HKLM проходит, а запись выдаёт отказ. Какая граница важна для автоматизации?

$result = & { try { New-Item HKLM:\Software\Demo -ErrorAction Stop } catch { $_.Exception.Message } }
$items = @($result)
[pscustomobject]@{ Count=$items.Count; First=$items | Select-Object -First 1; IsNull=($null -eq $result) }

Представления 32- и 64-разрядного реестра могут различаться; критичный код должен явно учитывать архитектуру процесса и ожидаемое представление. Повышение прав расширяет последствия ошибки; лучше отделить узкую привилегированную операцию и проверить минимально нужные разрешения. Диски HKLM: и HKCU: создаются провайдером Registry только на Windows; кроссплатформенный сценарий должен проверять платформу и наличие PSDrive. Доступ определяется ACL раздела и токеном процесса; наличие административной учётной записи не означает, что текущий процесс повышен. Перед правкой нужно сохранить дескриптор безопасности и проверять восстановление; неверный ACL способен заблокировать и приложение, и администраторов.

Вопрос 17 из 20

Set-Acl применяется к разделу реестра. Какое объяснение не зависит от случайностей окружения?

$acl=Get-Acl HKCU:\Software\Demo
$acl | Format-List Owner,AccessToString

Нужно ограничить допустимые корни и имена, потому что проверка существования не делает произвольное изменение безопасным. Доступ определяется ACL раздела и токеном процесса; наличие административной учётной записи не означает, что текущий процесс повышен. Представления 32- и 64-разрядного реестра могут различаться; критичный код должен явно учитывать архитектуру процесса и ожидаемое представление. Повышение прав расширяет последствия ошибки; лучше отделить узкую привилегированную операцию и проверить минимально нужные разрешения. RegistrySecurity описывает владельца и правила доступа; изменение ACL требует точной правки нужного правила, а не замены списка вслепую.

Вопрос 18 из 20

Сценарий запускается в 32-разрядном процессе на 64-разрядной Windows. Как следует читать этот фрагмент?

Перед правкой нужно сохранить дескриптор безопасности и проверять восстановление; неверный ACL способен заблокировать и приложение, и администраторов. Диски HKLM: и HKCU: создаются провайдером Registry только на Windows; кроссплатформенный сценарий должен проверять платформу и наличие PSDrive. Доступ определяется ACL раздела и токеном процесса; наличие административной учётной записи не означает, что текущий процесс повышен. Представления 32- и 64-разрядного реестра могут различаться; критичный код должен явно учитывать архитектуру процесса и ожидаемое представление. RegistrySecurity описывает владельца и правила доступа; изменение ACL требует точной правки нужного правила, а не замены списка вслепую.

Вопрос 19 из 20

Для обхода отказа доступа предлагается всегда запускать всё от администратора. Какое решение здесь надёжнее?

Перед правкой нужно сохранить дескриптор безопасности и проверять восстановление; неверный ACL способен заблокировать и приложение, и администраторов. Для отката нужно записать наличие, тип и исходное значение; «удалить созданное» неверно, если значение существовало до запуска. Повышение прав расширяет последствия ошибки; лучше отделить узкую привилегированную операцию и проверить минимально нужные разрешения. Представления 32- и 64-разрядного реестра могут различаться; критичный код должен явно учитывать архитектуру процесса и ожидаемое представление. Доступ определяется ACL раздела и токеном процесса; наличие административной учётной записи не означает, что текущий процесс повышен.

Вопрос 20 из 20

ACL изменён, но откат не предусмотрен. Какое действие не создаст новой скрытой зависимости?

Нужно ограничить допустимые корни и имена, потому что проверка существования не делает произвольное изменение безопасным. Повышение прав расширяет последствия ошибки; лучше отделить узкую привилегированную операцию и проверить минимально нужные разрешения. Доступ определяется ACL раздела и токеном процесса; наличие административной учётной записи не означает, что текущий процесс повышен. Перед правкой нужно сохранить дескриптор безопасности и проверять восстановление; неверный ACL способен заблокировать и приложение, и администраторов. RegistrySecurity описывает владельца и правила доступа; изменение ACL требует точной правки нужного правила, а не замены списка вслепую.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу