From official source,

• Exam details - https://developer.hashicorp.com/certifications/security-automation#vault-associate-(002)-details

Study materials

• Learning path - https://developer.hashicorp.com/vault/tutorials/associate-cert/associate-study
• Exam content list - https://developer.hashicorp.com/vault/tutorials/associate-cert/associate-review
• Sample questions - https://developer.hashicorp.com/vault/tutorials/associate-cert/associate-questions

Key points

1. Authentication Methods

Vault offers various ways to authenticate users and systems. Make sure you know the different authentication methods available, such as token-based, LDAP, and OAuth. Know how each method works, and understand when to use human versus system authentication. You should know when to choose the right method for different scenarios.

2. Vault Policies

Vault policies control who can access what within Vault. Revise how to create and manage these policies. Get comfortable with policy syntax, including paths and capabilities, so you can craft policies that meet specific requirements. Knowing how to manage these policies is very important for securing Vault environment.

3. Vault Tokens

Tokens are a core part of Vault’s security model. Learn about the different types of tokens eg service, batch, root along with their uses and lifecycles. Understand how to create and manage these tokens effectively. Also, make sure you understand the concept of token accessors and the significance of time-to-live (TTL) for tokens.

4. Vault Leases

Vault uses leases to manage the lifetime of secrets. Understand what a lease ID is, and how to renew or revoke leases. This knowledge is important in order for one to ensure that secrets are managed securely and are valid only for as long as needed.

5. Secrets Engines

Secrets engines are Vault components that store and manage secrets. Get familiar with different types of secrets engines and their use cases. Learn the difference between dynamic and static secrets, and understand the purpose of the transit secrets engine for encryption.

6. Vault CLI and UI

Vault provides both a command-line interface (CLI) and a user interface (UI) for managing Vault environment. Learn how to authenticate, configure policies, access secrets, and enable secret engines using both CLI and UI.

7. Vault API

The Vault API allows us to interact with Vault programmatically. Learn how to authenticate and access secrets using tools like curl, which is a common tool for interacting with APIs.

8. Vault Architecture

Vault’s architecture includes several important components. Learn about data encryption, cluster strategies, storage backends, and the Vault agent. Also, understand concepts like secrets caching, Shamir secret sharing, and replication.

9. Encryption as a Service

Learn how to configure the transit secret engine, what’s the benefit of using it, how to perform encryption and decryption, and rotate encryption keys.

Useful Links for Reference

These are some documents I reviewed when preparing

• Vault Agent Auto-Auth
• Vault Agent Caching
• Vault AppRole Auth Method
• Vault Auto-Unseal
• Vault Disaster Recovery
• Vault Dynamic Secrets
• Vault HTTP API Authentication
• Vault Identity Group
• Vault Key Rotation
• Vault KV Secrets Engine
• Vault LDAP Authentication
• Vault Lease Renew Command
• Vault Lease
• Vault Performance Replication
• Vault PKI Secrets Engine
• Vault Seal Configuration
• Vault Storage Configuration
• Vault Tokens
• Vault Userpass Auth Method
• Transit Secrets Engine

• https://github.com/helm/helm-2to3
• https://helm.sh/docs/topics/v2_v3_migration/
• https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/

Concepts

• Helm 2 and Helm 3 represent significant change in Kubernetes package management
• Helm 2 which was deprecated in Nov 2020, used a server-side component called Tiller to manage deployments
• Tiller was responsible for storing release information in ConfigMaps or Secrets within the Tiller namespace
• Helm 3 eliminates Tiller entirely, adopting a client-only architecture where all management tasks are handled directly by the Helm binary
• This change simplifies security and storage: Helm 3 now stores release data as Secrets in the deployment namespace rather than relying on Tiller’s namespace
• Helm 2 to 3 migration involves updating configuration and release management to align with these changes.

Notes

This was what I had to do to migrate Helm 2 releases.

1. Install Helm2 and Tiller

Download Helm v2.17.0 from official github https://github.com/helm/helm/releases/tag/v2.17.0 Extract and move to bin

$ tar zvxf helm-v2.17.0-darwin-amd64.tar.gz
$ sudo mv darwin-amd64/helm /usr/local/bin/helm2
$ sudo mv darwin-amd64/tiller /usr/local/bin/

2. Install Helm 2to3 Plugin

$ helm plugin install https://github.com/helm/helm-2to3.git
$ helm 2to3 --help

Migrate and Cleanup Helm v2 configuration and releases in-place to Helm v3

Usage:
  2to3 [command]

Available Commands:
  cleanup     cleanup Helm v2 configuration, release data and Tiller deployment
  completion  Generate the autocompletion script for the specified shell
  convert     migrate Helm v2 release in-place to Helm v3
  help        Help about any command
  move        migrate Helm v2 configuration in-place to Helm v3

Flags:
  -h, --help   help for 2to3

Use "2to3 [command] --help" for more information about a command.

3. Start Tiller Locally

In my case, Tiller has been removed from my cluster, I had to start Tiller locally

$ tiller

Starting Tiller v2.16.1 (tls=false)
GRPC listening on :44134
Probes listening on :44135
Storage driver is ConfigMap
Max history per release is 0

4. Backup Helm 2 Release

Always backup!

Replace $TILLER_PORT with local tiller port from previous step, in my case it was 44134

$ helm2 --host localhost:$TILLER_PORT get values $RELEASE > backup-values.yaml
$ helm2 --host localhost:$TILLER_PORT get manifest $RELEASE > backup-manifest.yaml

5. Convert to Helm 3 Release

I used -s configmaps because in my case Tiller stored the release data in ConfigMaps

$ helm 2to3 convert $RELEASE --tiller-out-cluster -s configmaps --dry-run
$ helm 2to3 convert $RELEASE --tiller-out-cluster -s configmaps

6. Verify

$ helm list -n $NAMESPACE

7. (Optional) Cleanup Helm 2 Data

$ helm 2to3 cleanup --name $RELEASE --release-cleanup --tiller-out-cluster -s configmaps --dry-run
$ helm 2to3 cleanup --name $RELEASE --release-cleanup --tiller-out-cluster -s configmaps

• https://kubernetes.io/docs/concepts/workloads/controllers/​deployment/
• Also check out my previous posts on:
  • Kubernetes: Pods
  • Kubernetes: ReplicaSets

Concepts

Deployments manage the deployment and scaling of a set of Pods and provide declarative updates to applications.

• A Deployment is described as a set of identical Pods with no unique identities. A Deployment runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive.
• In essence, Deployments are higher-level concepts that manage ReplicaSets and provide additional features like rolling updates and rollbacks.
• As such, it’s recommended to use Deployment instead of directly managing ReplicaSets because it provides additional useful features.
• Deployments manage stateless applications, while StatefulSets manage stateful applications

Notes

Declarative manifest

• Simple example of Deployment yaml definition, you will find this very similar to ReplicaSet

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-deployment
    labels:
      app: nginx
  spec:
    strategy: # how to replace old pods with new ones
      type: RollingUpdate # default strategy
      rollingUpdate:
        maxUnavailable: 1
        maxSurge: 1
    replicas: 3 # number of replica pods
    selector:
      matchLabels:
        app: nginx # selector
    template: # pod template (just like what we would define in pod yaml)
      metadata:
        labels:
          app: nginx # label of pod
      spec:
        containers:
        - name: nginx
          image: nginx:1.14.2
  

Imperative commands

• Get deployment details
  k get deploy <deployment-name> -o wide
• Update Deployment replicas
  k scale deployment <deployment-name> --replicas=<num>
• Rollback to an earlier Deployment revision
  k rollout undo deploy <deployment-name>
• View the rollout history of a Deployment
  k rollout history deploy <deployment-name>
• Determine Deployment (owner) of a pod
  k get pods <pod-name> -o yaml | grep -A 5 owner
• Delete Deployment and all its pods
  k delete deploy <deployment-name>
• Delete Deployment only
  k delete deploy <deployment-name> --cascade=orphan

Constraints

• n ≤ 100,000 where n is the length of s0
• m ≤ 100,000 where m is the length of s1

https://binarysearch.com/problems/Anagram-Substrings

Examples

Example 1

Input

• s0 = abc
• s1 = bcabxabc

Output

• answer = 3

Explanation

The substrings "bca", "cab" and "abc" of s0 are permutations of "abc".

Solution

Return whether it’s possible to partition the n people into two groups such that no two people that are enemies are in the same group.

Constraints

• n ≤ 1,000
• m ≤ 10,000 where m is the length of enemies

https://binarysearch.com/problems/Separate-People-Given-Dislike-Relations

Examples

Example 1

Input

• n = 4
• enemies =

[[0,1],
 [1,2]]

Output

• answer = True

Explanation

We can have these two groups [0, 2, 3] and [1].

Example 2

Input

• n = 3
• enemies =

[[0,1],
 [0,2],
 [1,2]]

Output

• answer = False

Explanation

No matter how we split the two groups, there will be two people that are enemies in a group.

Solution

Given that you can take at most capacity weights, and that you can take a fraction of an item’s weight with proportionate value, return the maximum amount of value you can get, rounded down to the nearest integer.

Constraints

• n ≤ 100,000 where n is the length of weights and values

https://binarysearch.com/problems/Fractional-Knapsack

Examples

Example 1

Input

• weights = [5, 6, 2]
• values = [100, 100, 1]
• capacity = 8

Output

• answer = 150

Explanation

The best we can do is:

• Take the item with 5 weight and take the 100 value, leaving us with 3 capacity
• Take half of the item with 6 weight and take half of the 100 value.

Example 2

Input

• weights = [5, 6, 2]
• values = [100, 100, 1]
• capacity = 13

Output

• answer = 201

Explanation

We can take all 3 items in full

Solution

Constraints

• 0 ≤ n ≤ 100,000 where n is the length of nums

https://binarysearch.com/problems/Longest-Arithmetic-Subsequence-with-Difference-Constraint

Examples

Example 1

Input

• nums = [-2, 0, 3, 6, 1, 9]
• diff = 3

Output

• answer = 4

Explanation

We can pick the subsequence [0, 3, 6, 9].

Example 2

Input

• nums = [9, 8, 7, 5, 3]
• diff = -2

Output

• answer = 4

Explanation

We can pick the subsequence [9, 7, 5, 3].

Solution

Constraints

• n, m ≤ 100 where n and m are the number of rows and columns in matrix.

https://binarysearch.com/problems/Maximum-Sum-Rectangle-with-Condition

Examples

Example 1

Input

• matrix =

[[ 2,-2],
 [ 3, 2]]

• k = 6

Output

• answer = 5

Explanation

We can take the rectangle [2, 3] to get sum of 5.

Solution

Constraints

• n ≤ 1,000 where n is the length of nums
• nums[i] ≤ 1,000

https://binarysearch.com/problems/Create-Largest-Number-From-a-List

Examples

Example 1

Input

• nums = [10, 7, 76, 415]

Output

• answer = 77641510

Example 2

Input

• nums = [961, 745, 331, 794, 923]

Output

• answer = 961923794745331

Example 3

Input

• nums = [45, 14, 70, 67, 95]

Output

• answer = 9570674514

Example 4

Input

• nums = [70, 5, 94, 18, 78]

Output

• answer = 947870518

Solution

It should use \(\mathcal{O}(k)\) space where k is the number of unique integers.

Constraints

• n ≤ 100,000 where n is the length of nums

https://binarysearch.com/problems/Remove-Duplicate-Numbers

Examples

Example 1

Input

• nums = [1, 3, 5, 0, 3, 5, 8]

Output

• answer = [1, 0, 8]

Explanation

Only [1, 0, 8] are unique in the list and that’s the order they appear in.

Solution