Microsoft AZ-400 Practice Test - Questions Answers, Page 18

User1: Project Administrators

You must have the permission Create Repository to publish code as wiki. By default, this permission is set for members of the Project Administrators group.

User2: Contributors

Anyone who is a member of the Contributors security group can add or edit wiki pages.

Anyone with access to the team project, including stakeholders, can view the wiki.

Reference:

https://docs.microsoft.com/en-us/azure/devops/project/wiki/wiki-create-repo

Box 1: " Microsoft.Resources/subscriptions/resourceGroups"

Box 2: "Deny",

Sample - Enforce tag and its value on resource groups

},

"policyRule": {

"if": {

"allOf": [

{

"field": "type",

"equals": "Microsoft.Resources/subscriptions/resourceGroups"

},

{

"not": {

"field": "[concat('tags[',parameters('tagName'), ']')]",

"equals": "[parameters('tagValue')]"

}

}

]

},

"then": {

"effect": "deny"

}

}

}

}

References:

https://docs.microsoft.com/en-us/azure/governance/policy/samples/enforce-tag-on-resource-groups

Step 1: Create a YAML file.

If your AKS cluster is RBAC-enabled, you must create a service account and role binding for use with Tiller. To create a service account and role binding, create a file named rbac-virtual-kubelet.yaml

Step 2: Run kubectl apply.

Apply the service account and binding with kubectl apply and specify your rbac-virtual-kubelet.yaml file.

Step 3: Run helm init.

Configure Helm to use the tiller service account:

helm init --service-account tiller

You can now continue to installing the Virtual Kubelet into your AKS cluster.

References: https://docs.microsoft.com/en-us/azure/aks/virtual-kubelet

All Azure Artifacts feeds require authentication, so you'll need to store credentials for the feed before you can install or publish packages. npm uses .npmrc configuration files to store feed URLs and credentials. Azure DevOps Services recommends using two .npmrc files.

Feed registry information: The .npmrc file in the project

One .npmrc should live at the root of your git repo adjacent to your project's package.json. It should contain a "registry" line for your feed and it should not contain credentials since it will be checked into git.

Credentials: The .npmrc file in the user's home folder

On your development machine, you will also have a .npmrc in $home for Linux or Mac systems or $env.HOME for win systems. This .npmrc should contain credentials for all of the registries that you need to connect to. The NPM client will look at your project's .npmrc, discover the registry, and fetch matching credentials from $home/.npmrc or $env.HOME/.npmrc.

References:

https://docs.microsoft.com/en-us/azure/devops/artifacts/npm/npmrc?view=azure-devops&tabs=windows

Box 1: A Build task

Trigger a build

You have a Java code provisioned by the Azure DevOps demo generator. You will use WhiteSource Bolt extension to check the vulnerable components present in this code.

1. Go to Builds section under Pipelines tab, select the build definition WhiteSourceBolt and click on Queue to trigger a build. 2. To view the build in progress status, click on ellipsis and select View build results.

Box 2: WhiteSource Bolt

WhiteSource is the leader in continuous open source software security and compliance management. WhiteSource integrates into your build process, irrespective of your programming languages, build tools, or development environments. It works automatically, continuously, and silently in the background, checking the security, licensing, and quality of your open source components against WhiteSource constantly-updated de?nitive database of open source repositories.

References:

https://www.azuredevopslabs.com/labs/vstsextend/whitesource/

Step 1 : az acr create

An Azure Container Registry (ACR) can also be created using the new Azure CLI.

az acr create

--name <REGISTRY_NAME>

--resource-group <RESOURCE_GROUP_NAME>

--sku Basic

Step 2: az ad sp create-for-rbac

Once the ACR has been provisioned, you can either enable administrative access (which is okay for testing) or you create a Service Principal (sp) which will provide a client_id and a client_secret.

az ad sp create-for-rbac

--scopes /subscriptions/<SUBSCRIPTION_ID>/resourcegroups/<RG_NAME>/providers/Microsoft.ContainerRegistry/registries/<REGISTRY_NAME> --role Contributor

--name <SERVICE_PRINCIPAL_NAME>

Step 3: kubectl create

Create a new Kubernetes Secret.

kubectl create secret docker-registry <SECRET_NAME>

--docker-server <REGISTRY_NAME>.azurecr.io

--docker-email <YOUR_MAIL>

--docker-username=<SERVICE_PRINCIPAL_ID>

--docker-password <YOUR_PASSWORD>

References:

https://thorsten-hans.com/how-to-use-private-azure-container-registry-with-kubernetes

Reference:

https://docs.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops

Box 1: Threat modeling -

Threat modeling’s motto should be, “The earlier the better, but not too late and never ignore.”

Box 2: Static code analysis -

Validation in the CI/CD begins before the developer commits his or her code. Static code analysis tools in the IDE provide the first line of defense to help ensure that security vulnerabilities are not introduced into the CI/CD process.

Box 3: Penetration testing -

Once your code quality is verified, and the application is deployed to a lower environment like development or QA, the process should verify that there are not any security vulnerabilities in the running application. This can be accomplished by executing automated penetration test against the running application to scan it for vulnerabilities.

Reference:

https://docs.microsoft.com/en-us/azure/devops/articles/security-validation-cicd-pipeline?view=vsts

You can use webhooks to route an Azure alert notification to other systems for post-processing or custom actions. You can use a webhook on an alert to route it to services that send SMS messages, to log bugs, to notify a team via chat or messaging services, or for various other actions.

Reference: https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-webhooks