Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution.
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen.
You manage a project in Azure DevOps.
You need to prevent the configuration of the project from changing over time.
Solution: Implement Continuous Assurance for the project.
Does this meet the goal?
Click on the arrows to vote for the correct answer
A. B.A
The basic idea behind Continuous Assurance (CA) is to setup the ability to check for "drift" from what is considered a secure snapshot of a system. Support for
Continuous Assurance lets us treat security truly as a 'state' as opposed to a 'point in time' achievement. This is particularly important in today's context when
'continuous change' has become a norm.
There can be two types of drift:
-> Drift involving 'baseline' configuration: This involves settings that have a fixed number of possible states (often pre-defined/statically determined ones). For instance, a SQL DB can have TDE encryption turned ON or OFFor a Storage Account may have auditing turned ON however the log retention period may be less than 365 days.
-> Drift involving 'stateful' configuration: There are settings which cannot be constrained within a finite set of well-known states. For instance, the IP addresses configured to have access to a SQL DB can be any (arbitrary) set of IP addresses. In such scenarios, usually human judgment is initially required to determine whether a particular configuration should be considered 'secure' or not. However, once that is done, it is important to ensure that there is no "stateful drift" from the attested configuration. (E.g., if, in a troubleshooting session, someone adds the IP address of a developer machine to the list, the Continuous Assurance feature should be able to identify the drift and generate notifications/alerts or even trigger 'auto-remediation' depending on the severity of the change).
https://azsk.azurewebsites.net/04-Continous-Assurance/Readme.htmlThe solution presented, "Implement Continuous Assurance for the project", does not directly address the goal of preventing configuration changes over time. Continuous Assurance is a concept that involves automated testing and monitoring of a system's health to ensure that it meets predefined quality standards. Although it can help detect configuration changes, it does not prevent them from happening.
To prevent configuration changes over time, some possible solutions might include:
Implement version control for the project's configuration files: Using a version control system such as Git, you can track changes made to the configuration files and easily revert to a previous version if needed.
Enforce strict access controls: Restrict access to the configuration files to authorized personnel only, and ensure that changes are reviewed and approved before being implemented.
Implement a configuration management tool: Tools such as Ansible or Chef can be used to automate the configuration of systems and ensure that they remain consistent over time.
Use Azure DevOps Pipelines to manage configuration changes: By defining the configuration changes as part of the pipeline, you can ensure that changes are made in a controlled and consistent manner, with the ability to roll back changes if necessary.
In summary, the solution presented in the question does not meet the goal of preventing configuration changes over time. Instead, implementing version control, enforcing strict access controls, using configuration management tools, or using Azure DevOps Pipelines can help achieve this goal.