[Update] Quick start | example ย่อ – NATAVIGUIDES

Introduction

Terragrunt is a thin wrapper that provides extra tools for keeping your configurations DRY, working with multiple Terraform modules, and managing remote state.

To use it, you:

1. Install Terraform.

2. Install Terragrunt.

3. Put your Terragrunt configuration in a terragrunt.hcl file. You’ll see several example configurations shortly.

4. Now, instead of running terraform directly, you run the same commands with terragrunt:

terragrunt plan
terragrunt apply
terragrunt output
terragrunt destroy

Terragrunt will forward almost all commands, arguments, and options directly to Terraform, but based on the settings in your terragrunt.hcl file.

Example

Here is an example configuration you can use to get started. The following configuration can be used to deploy the
terraform-aws-modules/vpc module from the
Terraform Registry:

terragrunt.hcl

# Indicate where to source the terraform module from.
# The URL used here is a shorthand for
# "tfr://registry.terraform.io/terraform-aws-modules/vpc/aws?version=3.5.0".
# Note the extra `/` after the protocol is required for the shorthand
# notation.
terraform {
  source = "tfr:///terraform-aws-modules/vpc/aws?version=3.5.0"
}

# Indicate what region to deploy the resources into
generate "provider" {
  path = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents = <<EOF
provider "aws" {
  region = "us-east-1"
}
EOF
}

# Indicate the input values to use for the variables of the module.
inputs = {
  name = "my-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  enable_vpn_gateway = false

  tags = {
    Terraform = "true"
    Environment = "dev"
  }
}

In the configuration, the terraform block is used to configure how Terragrunt will interact with Terraform. You can
configure things like before and after hooks for indicating custom commands to run before and after each terraform call,
or what CLI args to pass in for each commands. Here we only use it to indicate where terragrunt should fetch the
terraform code using the source attribute. We indicate that terragrunt should fetch the code from the
terraform-aws-modules/vpc/aws module hosted in the Public Terraform Registry, version
3.5.0. This is indicated by using the tfr:// protocol in the source URL, which takes the form:

tfr://REGISTRY_DOMAIN/MODULE?version=VERSION

Note that you can omit the REGISTRY_DOMAIN to default to the Public Terraform Registry.

The generate block is used to inject the provider configuration into the active Terraform module. This can be used to
customize how Terraform interacts with the cloud APIs, including configuring authentication parameters.

The inputs block is used to indicate what variable values should be passed to terraform. This is equivalent to having
the contents of the map in a tfvars file and passing that to terraform.

You can read more about all the supported blocks of the terragrunt configuration in the reference
documentation, including additional
sources that terragrunt supports.

You can deploy this example by copy pasting it into a folder and running terragrunt apply.

NOTE: Heads up, not all Registry modules can be deployed with Terragrunt, see A note aboud using modules from the
registry for details.

Key features

Terragrunt can help you accomplish the following:

Keep your backend configuration DRY

Terraform backends allow you to store Terraform state in a shared location that everyone on your team can access, such as an S3 bucket, and provide locking around your state files to protect against race conditions. To use a Terraform backend, you add a backend configuration to your Terraform code:

# stage/frontend-app/main.tf
terraform
 
{
  
backend
 
"s3"
 
{
    
bucket
         
=
 
"my-terraform-state"
    
key
            
=
 
"stage/frontend-app/terraform.tfstate"
    
region
         
=
 
"us-east-1"
    
encrypt
        
=
 
true
    
dynamodb_table
 
=
 
"my-lock-table"
  
}
}

The code above tells Terraform to store the state for a frontend-app module in an S3 bucket called my-terraform-state under the path stage/frontend-app/terraform.tfstate, and to use a DynamoDB table called my-lock-table for locking. This is a great feature that every single Terraform team uses to collaborate, but it comes with one major gotcha: the backend configuration does not support variables or expressions of any sort. That is, the following will NOT work:

# stage/frontend-app/main.tf
terraform
 
{
  
backend
 
"s3"
 
{
    
# Using variables does NOT work here!
    
bucket
         
=
 
var
.
terraform_state_bucket
    
key
            
=
 
var
.
terraform_state_key
    
region
         
=
 
var
.
terraform_state_region
    
encrypt
        
=
 
var
.
terraform_state_encrypt
    
dynamodb_table
 
=
 
var
.
terraform_state_dynamodb_table
  
}
}

That means you have to copy/paste the same backend configuration into every one of your Terraform modules. Not only do you have to copy/paste, but you also have to very carefully not copy/paste the key value so that you don’t have two modules overwriting each other’s state files! E.g., The backend configuration for a database module would look nearly identical to the backend configuration of the frontend-app module, except for a different key value:

# stage/mysql/main.tf
terraform
 
{
  
backend
 
"s3"
 
{
    
bucket
         
=
 
"my-terraform-state"
    
key
            
=
 
"stage/mysql/terraform.tfstate"
    
region
         
=
 
"us-east-1"
    
encrypt
        
=
 
true
    
dynamodb_table
 
=
 
"my-lock-table"
  
}
}

Terragrunt allows you to keep your backend configuration DRY (“Don’t Repeat Yourself”) by defining it once in a root location and inheriting that configuration in all child modules. Let’s say your Terraform code has the following folder layout:

stage
├── frontend-app
│   └── main.tf
└── mysql
    └── main.tf

To use Terragrunt, add a single terragrunt.hcl file to the root of your repo, in the stage folder, and one terragrunt.hcl file in each module folder:

stage
├── terragrunt.hcl
├── frontend-app
│   ├── main.tf
│   └── terragrunt.hcl
└── mysql
    ├── main.tf
    └── terragrunt.hcl

Now you can define your backend configuration just once in the root terragrunt.hcl file:

# stage/terragrunt.hcl
remote_state
 
{
  
backend
 
=
 
"s3"
  
generate
 
=
 
{
    
path
      
=
 
"backend.tf"
    
if_exists
 
=
 
"overwrite_terragrunt"
  
}
  
config
 
=
 
{
    
bucket
 
=
 
"my-terraform-state"

    
key
 
=
 
"${path_relative_to_include()}/terraform.tfstate"
    
region
         
=
 
"us-east-1"
    
encrypt
        
=
 
true
    
dynamodb_table
 
=
 
"my-lock-table"
  
}
}

The terragrunt.hcl files use the same configuration language as Terraform (HCL) and the configuration is more or less the same as the backend configuration you had in each module, except that the key value is now using the path_relative_to_include() built-in function, which will automatically set key to the relative path between the root terragrunt.hcl and the child module (so your Terraform state folder structure will match your Terraform code folder structure, which makes it easy to go from one to the other).

The generate attribute is used to inform Terragrunt to generate the Terraform code for configuring the backend. When
you run any Terragrunt command, Terragrunt will generate a backend.tf file with the contents set to the terraform
block that configures the s3 backend, just like what we had before in each main.tf file.

The final step is to update each of the child terragrunt.hcl files to tell them to include the configuration from the root terragrunt.hcl:

# stage/mysql/terragrunt.hcl
include
 
"root"
 
{
  
path
 
=
 
find_in_parent_folders
()
}

The find_in_parent_folders() helper will automatically search up the directory tree to find the root terragrunt.hcl and inherit the remote_state configuration from it.

Now, install Terragrunt, and run all the Terraform commands you’re used to, but with terragrunt as the command name rather than terraform (e.g., terragrunt apply instead of terraform apply). To deploy the database module, you would run:

$ 
cd 
stage/mysql
$ 
terragrunt apply

Terragrunt will automatically find the mysql module’s terragrunt.hcl file, configure the backend using the settings from the root terragrunt.hcl file, and, thanks to the path_relative_to_include() function, will set the key to stage/mysql/terraform.tfstate. If you run terragrunt apply in stage/frontend-app, it’ll do the same, except it will set the key to stage/frontend-app/terraform.tfstate.

You can now add as many child modules as you want, each with a terragrunt.hcl with the include "root" { …​ } block, and each of those modules will automatically inherit the proper backend configuration!

Keep your provider configuration DRY

Unifying provider configurations across all your modules can be a pain, especially when you want to customize
authentication credentials. To configure Terraform to assume an IAM role before calling out to AWS, you need to add a
provider block with the assume_role configuration:

# stage/frontend-app/main.tf
provider "aws" {
  assume_role {
    role_arn = "arn:aws:iam::0123456789:role/terragrunt"
  }
}

This code tells Terraform to assume the role arn:aws:iam::0123456789:role/terragrunt prior to calling out to the AWS
APIs to create the resources. Unlike the backend configurations, provider configurations support variables, so
typically you will resolve this by making the role configurable in the module:

# stage/frontend-app/main.tf
variable "assume_role_arn" {
  description = "Role to assume for AWS API calls"
}

provider "aws" {
  assume_role {
    role_arn = var.assume_role_arn
  }
}

You would then copy paste this configuration in every one of your Terraform modules. This isn’t a lot of lines of code,
but can be a pain to maintain. For example, if you needed to modify the configuration to expose another parameter (e.g
session_name), you would have to then go through each of your modules to make this change.

In addition, what if you wanted to directly deploy a general purpose module, such as that from the Terraform module
registry or the Gruntwork Infrastructure as Code
library? These modules typically do not expose provider
configurations as it is tedious to expose every single provider configuration parameter imaginable through the module
interface.

Terragrunt allows you to refactor common Terraform code to keep your Terraform modules DRY. Just like with the backend
configuration, you can define the provider configurations once in a root location. In the root terragrunt.hcl file,
you would define the provider configuration using the generate block:

# stage/terragrunt.hcl
generate
 
"provider"
 
{
  
path
 
=
 
"provider.tf"
  
if_exists
 
=
 
"overwrite_terragrunt"
  
contents
 
=
 
<<
EOF

provider "aws" {
  assume_role {
    role_arn = "arn:aws:iam::0123456789:role/terragrunt"
  }
}
EOF
}

This instructs Terragrunt to create the file provider.tf in the working directory (where Terragrunt calls terraform)
before it calls any of the Terraform commands (e.g plan, apply, validate, etc). This allows you to inject this
provider configuration in all the modules that includes the root file without having to define them in the underlying
modules.

When you run terragrunt plan or terragrunt apply, you can see that this file is created in the module working
directory:

$ 
cd 
stage/mysql
$ 
terragrunt apply
$ 
find 
.
 
-name
 
"provider.tf"
.terragrunt-cache/some-unique-hash/provider.tf

Keep your Terraform CLI arguments DRY

CLI flags are another common source of copy/paste in the Terraform world. For example, a typical pattern with Terraform is to define common account-level variables in an account.tfvars file:

# account.tfvars
account_id
     
=
 
"123456789012"
account_bucket
 
=
 
"my-terraform-bucket"

And to define common region-level variables in a region.tfvars file:

# region.tfvars
aws_region
 
=
 
"us-east-2"
foo
        
=
 
"bar"

You can tell Terraform to use these variables using the -var-file argument:

$ 
terraform apply 
\
    
-var-file
=
../../common.tfvars 
\
    
-var-file
=
../region.tfvars

Having to remember these -var-file arguments every time can be tedious and error prone. Terragrunt allows you to keep your CLI arguments DRY by defining those arguments as code in your terragrunt.hcl configuration:

# terragrunt.hcl
terraform
 
{
  
extra_arguments
 
"common_vars"
 
{
    
commands
 
=
 
[
"plan"
,
 
"apply"
]

    
arguments
 
=
 
[
      
"-var-file=../../common.tfvars"
,
      
"-var-file=../region.tfvars"
    
]
  
}
}

Now, when you run the plan or apply commands, Terragrunt will automatically add those arguments:

$ 
terragrunt apply

Running 
command
: terraform with arguments
[
apply 
-var-file
=
../../common.tfvars 
-var-file
=
../region.tfvars]

You can even use the get_terraform_commands_that_need_vars() built-in function to automatically get the list of all commands that accept -var-file and -var arguments:

# terragrunt.hcl
terraform
 
{
  
extra_arguments
 
"common_vars"
 
{
    
commands
 
=
 
get_terraform_commands_that_need_vars
()

    
arguments
 
=
 
[
      
"-var-file=../../common.tfvars"
,
      
"-var-file=../region.tfvars"
    
]
  
}
}

Promote immutable, versioned Terraform modules across environments

One of the most important lessons we’ve learned from writing hundreds of thousands of lines of infrastructure code is that large modules should be considered harmful. That is, it is a Bad Idea to define all of your environments (dev, stage, prod, etc), or even a large amount of infrastructure (servers, databases, load balancers, DNS, etc), in a single Terraform module. Large modules are slow, insecure, hard to update, hard to code review, hard to test, and brittle (i.e., you have all your eggs in one basket).

Therefore, you typically want to break up your infrastructure across multiple modules:

├── prod
│   ├── app
│   │   ├── main.tf
│   │   └── outputs.tf
│   ├── mysql
│   │   ├── main.tf
│   │   └── outputs.tf
│   └── vpc
│       ├── main.tf
│       └── outputs.tf
├── qa
│   ├── app
│   │   ├── main.tf
│   │   └── outputs.tf
│   ├── mysql
│   │   ├── main.tf
│   │   └── outputs.tf
│   └── vpc
│       ├── main.tf
│       └── outputs.tf
└── stage
    ├── app
    │   ├── main.tf
    │   └── outputs.tf
    ├── mysql
    │   ├── main.tf
    │   └── outputs.tf
    └── vpc
        ├── main.tf
        └── outputs.tf

The folder structure above shows how to separate the code for each environment (prod, qa, stage) and for each type of infrastructure (apps, databases, VPCs). However, the downside is that it isn’t DRY. The .tf files will contain a LOT of duplication. You can reduce it somewhat by defining all the infrastructure in reusable Terraform modules, but even the code to instantiate a module—including configuring the provider, backend, the module’s input variables, and output variables—means you still end up with dozens or hundreds of lines of copy/paste for every module in every environment:

# prod/app/main.tf
provider
 
"aws"
 
{
  
region
 
=
 
"us-east-1"
  
# ... other provider settings ...
}
terraform
 
{
  
backend
 
"s3"
 
{}
}
module
 
"app"
 
{
  
source
 
=
 
"../../../app"
  
instance_type
  
=
 
"m4.large"
  
instance_count
 
=
 
10
  
# ... other app settings ...
}
# prod/app/outputs.tf
output
 
"url"
 
{
  
value
 
=
 
module
.
app
.
url
}
# ... and so on!

Terragrunt allows you to define your Terraform code once and to promote a versioned, immutable “artifact” of that exact same code from environment to environment. Here’s a quick overview of how.

First, create a Git repo called infrastructure-modules that has your Terraform code (.tf files). This is the exact same Terraform code you just saw above, except that any variables that will differ between environments should be exposed as input variables:

# infrastructure-modules/app/main.tf
provider
 
"aws"
 
{
  
region
 
=
 
"us-east-1"
  
# ... other provider settings ...
}
terraform
 
{
  
backend
 
"s3"
 
{}
}
module
 
"app"
 
{
  
source
 
=
 
"../../../app"
  
instance_type
  
=
 
var
.
instance_type
  
instance_count
 
=
 
var
.
instance_count
  
# ... other app settings ...
}
# infrastructure-modules/app/outputs.tf
output
 
"url"
 
{
  
value
 
=
 
module
.
app
.
url
}
# infrastructure-modules/app/variables.tf

variable
 
"instance_type"
 
{}
variable
 
"instance_count"
 
{}

Once this is in place, you can release a new version of this module by creating a Git tag:

$ 
git tag 
-a
 
"v0.0.1"
 
-m
 
"First release of app module"
$ 
git push 
--follow-tags

Now, in another Git repo called infrastructure-live, you create the same folder structure you had before for all of your environments, but instead of lots of copy/pasted .tf files for each module, you have just a single terragrunt.hcl file:

# infrastructure-live
├── prod
│   ├── app
│   │   └── terragrunt.hcl
│   ├── mysql
│   │   └── terragrunt.hcl
│   └── vpc
│       └── terragrunt.hcl
├── qa
│   ├── app
│   │   └── terragrunt.hcl
│   ├── mysql
│   │   └── terragrunt.hcl
│   └── vpc
│       └── terragrunt.hcl
└── stage
    ├── app
    │   └── terragrunt.hcl
    ├── mysql
    │   └── terragrunt.hcl
    └── vpc
        └── terragrunt.hcl

The contents of each terragrunt.hcl file look something like this:

# infrastructure-live/prod/app/terragrunt.hcl
terraform
 
{
  
source
 
=
    
"github.com:foo/infrastructure-modules.git//app?ref=v0.0.1"
}
inputs
 
=
 
{
  
instance_count
 
=
 
10
  
instance_type
  
=
 
"m4.large"
}

The terragrunt.hcl file above sets the source parameter to point at the app module you just created in your infrastructure-modules repo, using the ref parameter to specify version v0.0.1 of that repo. It also configures the variables for this module for the prod environment in the inputs = {…​} block.

The terragrunt.hcl file in the stage environment will look similar, but it will configure smaller/fewer instances in the inputs = {…​} block to save money:

# infrastructure-live/stage/app/terragrunt.hcl
terraform
 
{
  
source
 
=
    
"github.com:foo/infrastructure-modules.git//app?ref=v0.0.1"
}
inputs
 
=
 
{
  
instance_count
 
=
 
3
  
instance_type
  
=
 
"t2.micro"
}

When you run terragrunt apply, Terragrunt will download your app module into a temporary folder, run terraform apply in that folder, passing the module the input variables you specified in the inputs = {…​} block:

$ 
terragrunt apply
Downloading Terraform configurations from github.com:foo/infrastructure-modules.git...
Running 
command
: terraform with arguments 
[
apply]...

This way, each module in each environment is defined by a single terragrunt.hcl file that solely specifies the Terraform module to deploy and the input variables specific to that environment. This is about as DRY as you can get!

Moreover, you can specify a different version of the module to deploy in each environment! For example, after making some changes to the app module in the infrastructure-modules repo, you could create a v0.0.2 tag, and update just the qa environment to run this new version:

# infrastructure-live/qa/app/terragrunt.hcl
terraform 
{
  
source
 
=
    
"github.com:foo/infrastructure-modules.git//app?ref=v0.0.2"
}
inputs 
=
 
{
  instance_count 
=
 3
  instance_type  
=
 
"t2.micro"
}

If it works well in the qa environment, you could promote the exact same code to the stage environment by updating its terragrunt.hcl file to run v0.0.2. And finally, if that code works well in stage, you could again promote the exact same code to prod by updating that terragrunt.hcl file to use v0.0.2 as well.

If at any point you hit a problem, it will only affect the one environment, and you can roll back by deploying a previous version number. That’s immutable infrastructure at work!

Next steps

Now that you’ve seen the basics of Terragrunt, here is some further reading to learn more:

1. Use cases: Learn about the core use cases Terragrunt supports.

2. Documentation: Check out the detailed Terragrunt documentation.

3. Terraform: Up & Running: This book is the fastest way to get up and running with Terraform! Terragrunt is a direct implementation of many of the ideas from this book.

What makes you good at your job?

 

Recruiters will assume it’s years of professional experience, a solid diploma, and a well-established certificate.

 

But these all represent something much more important:

 

Your skills. The ones that get the job done—

 

This guide will show you:

• How to list hard skills to make up for what you lack in experience.
• What hard skills are in demand in 2021.
• Why these skills beat any other selling point.

 

Want to save time and have your resume ready in 5 minutes? Try our resume builder. It’s fast and easy to use. Plus, you’ll get ready-made content to add with one click. See 20+ resume templates and create your resume here.

 

Sample resume made with our builder—See more templates and create your resume here.

One of our users, Nikos, had this to say:

 

[I used] a nice template I found on Zety. My resume is now one page long, not three. With the same stuff.

 

What Are Hard Skills?

 

 

It’s not about how difficult they are, it’s all about how process-oriented such abilities might be.

 

Hard Skills Definition:

 

Hard skills are abilities that let you tackle job-specific duties and responsibilities. Hard skills can be learned through courses, vocational training, and on the job. These skills are usually focused on specific tasks and processes such as the use of tools, equipment, or software.

 

In contrast, soft skills are your traits and abilities not unique to any job—think collaboration, time management, empathy, or leadership.

 

Which kind of skill set is more important? A LinkedIn study suggests that a slight majority (57% vs 43%) of employers value soft skills over hard skills.

 

But is this really an either/or situation?

 

Not really. The best way to think about it that hard skills get interviews, soft skills get jobs.

(Not to mention the thin line between definitions—how soft a skill is time management?)

 

If the hard-vs-soft-skills contrast isn’t quite clear to you, see our guide: The Difference Between Hard and Soft Skills Explained

 

Hard Skills Examples List

 

 

(And here’s a few tips regarding Top Skills Employers Look for in 2021)

 

How to List Hard Skills on a Resume

 

Below, you’ll see more specific examples of hard skills in each category. Before we get to that, though, two crucial things:

 

How to put them on a resume?

 

• Don’t just copy-and-paste the skills you think you have.
• Go through the job description and identify skills-related keywords.
• Create a list based on what you find. 
• Highlight these strengths on your resume.

 

Where to list them?

 

• Include a list of your most relevant skills in a separate “skills” section. This way, they’re prominent and easy to spot.
• Refer to your professional hard skills in the employment history section: give examples of achievements and duties that illustrate your skills.
• Mention 2–3 key skills for this job in a professional profile on a resume (the paragraph at the top): either a summary statement or a job/career objective.

 

For more strategies of highlighting your job skills, see: Crucial Skills to Put on Your Resume 2021

 

Top 10 Hard Skills for a Resume: List of Examples

 

1. Technical Skills

 

Technical skills include specialized knowledge and expertise in fields such as IT, engineering, or science. Typical technical skills are abilities to use specialized software or equipment.

 

Here are some examples of technical hard skills:

• CAD
• Lean manufacturing
• Multivariate analysis
• Linear regression
• Prototyping
• Workflow development
• STEM skills
• Web: HTML, CSS, Javascript
• Payment processing 
• Automated Billing Systems
• CRM Platforms
• Research
• Troubleshooting

 

Now, here’s a few samples extracted from resumes:

 

• Created MS Excel pivot tables to identify 500+ new high-traffic, low-competition keywords that pushed us to $250,000+ more annual revenue.
• Applied Lean manufacturing principles to redesign Kanban system. Decreased inventory costs 32%.
• Efficient Mechanical Engineer with 3+ years’ combined experience as a Design Engineer. Can perform static, fatigue, and fracture analyzes for F-35 structural components of main landing gear.

 

For a dedicated guide to putting technical hard skills on a resume, see: The Best Technical Skills for Resumes

 

2. Computer Skills

 

Computer skills are your abilities to use software and hardware: from basic and general, to highly specialized.

 

On today’s job market, computer skills are a must in any industry. Be sure to include list them on your resume especially if you’re applying for office jobs and if the job ad requires specifics.

 

Here’s a list of some basic computer skills:

• MS Office:
• Word
• Excel
• Outlook
• Powerpoint
• OneNote
• Access
• Google Drive
• Spreadsheets
• Email
• Presentations/Slideshows
• Database Management
• Quickbooks
• Social media
• Web
• Typing
• Graphics
• Enterprise systems
• WPM

 

And here you’ll see some typical programming skills:

• Java
• PHP
• MySQL
• SQL
• C#
• JavaScript
• C++
• Python
• iOS/Swift
• Ruby on Rails

 

This is how you can make them work on your resume:

 

• Composed an app to allow voice control of lights, garage door, and home thermostat, using an Amazon Echo and Raspberry Pi.
• Wrote Excel formulas to add conditional formatting to a budgeting spreadsheet.
• Automated reports with Oracle Netsuite to cut reporting costs by 25%.

 

Need more information? Here’s a must-read for you: Key Computer Skills to Put on a Resume in 2019

 

If you want to laser-in on MS Office skills, see: Microsoft Office Suite Skills for the Workforce

 

3. Analytical Skills

 

Analytical skills are the skills of gathering data, analyzing it, deciphering the meaning, and presenting it. 

 

No matter what job you’re pursuing, if you’re able to show that you’re good with data analysis, the recruiter will score you some bonus points.

 

Here are some analytical skills to put on a resume:

 

• Research
• Forecasting
• Data mining
• Data presentation
• Resource management
• Data engineering
• Database management
• Data and metrics interpreting
• Reporting
• Diagnostics
• Creativity
• Theorizing

 

Analytical skills proven on your resume:

 

• Utilized Microsoft SPSS statistical software to track and analyze data. Created machine learning tools that computed adjusted P/E values.
• Used MS Access to identify and improve low-performing portfolios. Increased average client revenue by 19%.

 

Learn more: Analytical Skills/Data Analysis Skills to Boost Your Resume

 

4. Marketing Skills

 

Marketing skills include the general knowledge of sales, advertising, and consumer research, as well as a plethora of highly technical, digital skills required for success in modern-day online marketing.

 

Marketing hard skills are of greatest value to candidates in media, advertising, social media, e-commerce, and product management.

 

Some examples include:

• SEO/SEM: Ahrefs, SEMRush, SEO Power Suite, Majestic
• PPC
• Social media marketing and paid social media advertising
• Writing
• CRO and A/B testing
• Email marketing and automation
• HubSpot, Aritic PinPoint, ONTRAPORT, Infusionsoft
• Funnel management
• UX Design
• Data visualization
• Google Analytics and Google Search Console
• AdWords, Facebook Paid Ads

 

The list could go on, and on, and on. But what marketing skills are most relevant today?

According to a 2018 report by ADMA, this is the top 7:

• Data-driven marketing
• Analytics
• Data visualization
• SEO/SEM
• Campaign management
• Content creation and storytelling
• Omnichannel communication

 

Not sure how to make your resume show your marketing expertise? Get inspired by these samples of hard marketing skills on resumes:

 

Marketing ability highlights:

 

• Introduced an incentive-driven A/B testing competition among team members which resulted in increasing landing page conversions by 114% in 4 months.
• Adept at Using HubSpot, Kissmetrics, and Google Analytics.
• Created 20+ SEO campaigns for websites with complex media and big structures.

 

Hungry for more? Check this out: Top-Level Marketing Skills for Your Resume & How to List Them

 

5. Presentation Skills

 

Wait, what? Aren’t presentation skills a soft skill?

 

Not exactly. Sure, you need certain soft, transferable skills to deliver a good presentation: confidence, adaptability, self-awareness, or stress management. But—

 

To facilitate your presentation or report, you’ll need at least a few of these hard skills:

• Visual communication
• Slideshows
• Research
• Data analysis
• Reporting
• Persuasion
• Graphic design

 

And here’s how to prove you’re a savvy presenter on a resume:

 

• Created 150+ business reports and newsletters, using data visualization to facilitate the message.
• Assisted the CEO with creating slideshows in Powerpoint, Prezi, and Movavi.

 

See more: How to List Presentation Skills on Resumes

 

6. Management Skills

 

Again, you might feel like people skills are in the core of good management and leadership. Again…

 

That’s just half-right.

 

To be a good manager, you also need some job-specific skills such as these:

• Business knowledge
• Budgeting
• Project management
• Hiring
• Finance
• Office management skills
• Logistics
• New business development
• Negotiating
• Planning

 

And here’s how to convey your management expertise on an exec resume:

 

• Implemented team-wide use of Google Docs, Slack, and Trello to slash project time-to-delivery 35%.
• Redesigned budgeting methods to increase project delivery rate by 20%.

 

For more examples and step-by-step tutorials see: Managerial Skills List (Not Only For Managers!)

 

When making a resume in our builder, drag & drop bullet points, skills, and auto-fill the boring stuff. Spell check? Check. Start building professional resume template here for free.

When you’re done, Zety’s resume builder will score your resume and tell you exactly how to make it better.

7. Project Management Skills

 

In short, project management skills guarantee that things get done.

 

More than that, actually: done in time and within budget. If you’re skilled in project management, it will be a plus for any sort of job where you need to coordinate processes or people’s work.

 

Project management skills include general managerial expertise as well as proficiency in certain frameworks and software. Here are some examples of PM hard skills:

• Project scheduling
• Strategic planning
• Project lifecycle management
• Agile software
• Scrum management
• Financial modeling
• Kanban
• Forecasting
• Performance tracking
• Budgeting

 

And these samples will show you how to present your PM expertise on a resume:

 

• Highly skilled in Agile software: employed Jira and Taiga to improve team velocity 35%.
• Budgeting: saved $800,000 through a company-wide automation drive.
• Implemented Lean Training project for all employees.

 

For more tips on showcasing your PM hard skills, head over to Project Management Skills Crucial for Your Career (And Resume!)

 

8. Writing Skills

 

A solid grasp of writing techniques will give your career a boost if your job requires any sort of writing (think typing up quarterly reports, onboarding documents, presentations for clients, sales pitches, etc.).

 

Check out these examples:

• Basic writing: grammar, punctuation, spelling, vocabulary
• Note-taking
• Letter writing
• Email writing
• Business writing reports, press releases, content management
• Data visualization
• Creative writing: plotting, worldbuilding, dialogue
• Academic writing
• Storytelling
• Copywriting
• SEO
• Editing
• Journalism
• Proposal writing
• Social media
• Presentation writing

 

Now, an ultimate writing assignment… Conveying your writing skills on a resume. This is how to do it:

 

• Content writing: produced up to 4 1000+ words long articles weekly.
• Authored a 90-page user guide for a cloud-based webinar app.
• Wrote 3 successful grant applications that received $160,000 in funding.

 

We’ve written a super detailed piece on writing skills, give it a read: 150+ Writing Skills for Jobs & How to Boost Them

 

9. Language Skills

 

Another somewhat obvious point on our list. But that doesn’t make it less important.

 

Knowing more than one language will set you apart from your competition for any job in a company that deals with international customers or stakeholders.

 

First of all, create a section for languages. List all foreign languages you know and indicate your proficiency level.

 

But you can also emphasize your multilingual skills in other parts.

 

• Offered meticulous customer support for clients in 3 languages: English, Spanish, French.

 

Need more information? See: How to Show Off Your Language Skills on a Resume

 

10. Design Skills

 

If you’re a skilled illustrator, modern employers will fight one another for who gets to hire you. No, not only if your niche is graphic design. The ability to create polished visual materials is a great asset in all work environments.

 

Here are some graphic design skills examples.

• Photoshop
• Illustrator
• InDesign
• UX/UI design
• UX research
• Data visualization
• Color theory
• Acrobat
• HTML/CSS
• Free Hand
• Corel Draw
• Sketching
• Typography
• Print design
• Layout

 

Now, here’s a few samples from other resume sections:

 

• Authored superior graphic design, print production, ads, marketing collateral, viewbooks, and logo design.
• Designed logo for Nabor Gro groceries and liquor, Arondale, Connecticut.

 

Need more inspiration to highlight your creative powers? While we don’t have a dedicated piece on design skills, I’m sure you’ll find this one useful: How to Write a Head-Turning Graphic Design Resume

 

Certifications: The Best Way to Validate Your Hard Skills

 

If you have certifications that back up your skills, list them in a separate resume section. Include the name of the certificate and the year you received it.

 

Learn more: How to Include Certifications on Resumes

 

Plus, a great cover letter that matches your resume will give you an advantage over other candidates. You can write it in our cover letter builder here. Here’s what it may look like:

 

See more cover letter templates and start writing.

Key Takeaway

 

Here’s everything you need to know about putting hard skills on a resume:

• Hard skills are the job-specific skills that make you well suited for a particular role.
• Always match your hard skills to those from the job ad.
• Use skills-related keywords in the work experience section, along with real-life evidence of how you used those skills to achieve spectacular results.
• Don’t forget to list the most important abilities in a separate skills section.
• Mention 2–3 most relevant skills in your resume profile.
• Validate your skills by listing professional certifications.

 

Got more questions? Need assistance in picking the right hard skills for your resume? Drop me a line in the comments, I’ll get right back to you.