Lubinik Packages, Rollback & Deployment Evidence

Training mode

Lubinik Packages, Rollback & Deployment Evidence

Time remaining:

0 / 20 answered

1. What does config/packages.json map for each managed package?

What does config/packages.json map for each managed package? Identity, type, install identifier, and GitHub repository Generated backup contents Remote secrets Database credentials

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
2. How is an installed plugin identified and later validated?

How is an installed plugin identified and later validated? By its plugin_file and expected main-file basename By CSS handle By active child theme By post type only

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
3. What file validates an extracted theme package?

What file validates an extracted theme package? style.css functions.php only plugin.json wp-config.php

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
4. Can PackageInstaller install a registry package that is not already installed?

Can PackageInstaller install a registry package that is not already installed? Only themes Only through batch Yes, it provisions arbitrary targets No, the current installer requires an existing target directory

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
5. What PHP facility is required to extract the downloaded archive?

What PHP facility is required to extract the downloaded archive? ZipArchive SimpleXML PDO GD only

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
6. Where is the updater workspace created?

Where is the updater workspace created? Inside WordPress core Inside packages.json Under the WordPress uploads basedir in lubinik-updater In the browser cache

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
7. Why clean temporary ZIP/extract paths before starting?

Why clean temporary ZIP/extract paths before starting? To verify HMAC To delete backups To remove stale workspace artifacts from interrupted runs To reset package versions

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
8. What should happen if GitHub returns an empty ZIP?

What should happen if GitHub returns an empty ZIP? Return an error before extraction or replacement Mark the update successful Replace with an empty directory Delete the current package

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
9. What source shape does the GitHub ZIP extraction expect?

What source shape does the GitHub ZIP extraction expect? A top-level package directory inside the extraction folder PHP files at filesystem root only Multiple unrelated roots merged automatically A database dump

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
10. When is extracted source validation performed?

When is extracted source validation performed? Only during rollback Before backing up or modifying the installed target After success logging After the target is emptied

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
11. When is the current package backed up?

When is the current package backed up? Never Before download After successful replacement only After source validation and before target replacement

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
12. What is the default number of backups retained per package?

What is the default number of backups retained per package? 1 Unlimited 50 5

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
13. How is rollback backup=latest selected?

How is rollback backup=latest selected? Alphabetically smallest name Randomly From the GitHub tag The newest backup by filesystem modification time

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
14. Why must a requested backup name appear in backups_for the package?

Why must a requested backup name appear in backups_for the package? To prevent selecting an arbitrary filesystem directory To compare versions To verify its WordPress nonce To download it again

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
15. What happens before a backup replaces the current package?

What happens before a backup replaces the current package? It is converted to JSON It is uploaded to GitHub It is trusted only by its folder name The backup is validated as the expected plugin or theme

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
16. Why back up the current state before rollback?

Why back up the current state before rollback? It clears logs The rollback itself remains recoverable It improves HMAC strength It installs a new package

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
17. Why is replace_directory_contents not strictly atomic?

Why is replace_directory_contents not strictly atomic? It empties the target and then copies files, leaving an interruption window It uses version_compare It validates the ZIP first It stores backups

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
18. What risk remains if copying fails after the target was emptied?

What risk remains if copying fails after the target was emptied? GitHub reruns PHP A partially restored package may remain and require rollback/recovery The old target is automatically intact HMAC repairs files

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
19. What does successful local syntax/runtime validation prove?

What does successful local syntax/runtime validation prove? The package works in the tested local context, not that live sites updated successfully Every production site is confirmed Rollback is unnecessary DNS and hosting are identical

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.
20. What confirms a production fleet update?

What confirms a production fleet update? The dashboard button being clicked A local Git diff only Signed responses and refreshed status/version evidence from each targeted live site A ZIP existing on disk

Hint
Follow authentication, validation, backup, replacement, and evidence boundaries.

1. What does config/packages.json map for each managed package?

2. How is an installed plugin identified and later validated?

3. What file validates an extracted theme package?

4. Can PackageInstaller install a registry package that is not already installed?

5. What PHP facility is required to extract the downloaded archive?

6. Where is the updater workspace created?

7. Why clean temporary ZIP/extract paths before starting?

8. What should happen if GitHub returns an empty ZIP?

9. What source shape does the GitHub ZIP extraction expect?

10. When is extracted source validation performed?

11. When is the current package backed up?

12. What is the default number of backups retained per package?

13. How is rollback backup=latest selected?

14. Why must a requested backup name appear in backups_for the package?

15. What happens before a backup replaces the current package?

16. Why back up the current state before rollback?

17. Why is replace_directory_contents not strictly atomic?

18. What risk remains if copying fails after the target was emptied?

19. What does successful local syntax/runtime validation prove?

20. What confirms a production fleet update?