Cloud Security Basics Every Beginner Should Know

Most cloud security incidents that beginners hear about are not clever attacks. They are an access key pushed to a public GitHub repository, a storage bucket left open to the internet, a database port exposed to the world, or an administrator account with no multi-factor authentication. The good news is that these are exactly the mistakes you can learn to avoid in your first few months. This guide covers the five areas every beginner should understand before calling themselves cloud-ready: identity and access management (IAM), least privilege, secrets, networking and logging. Each section has real commands you can run, the common mistakes, and a practice plan at the end.

The examples mostly use AWS because its free tier and documentation make it easy to practise, but every idea carries over to Azure and Google Cloud. Where the names differ, the comparison table shows you the equivalent.

Why security is a beginner skill, not an advanced one

A lot of people treat security as something to learn "later", after Linux, Docker and Kubernetes. That is backwards. Every cloud account you create is a live system on the internet, attached to your bank card. The day you sign up, you are already responsible for securing it.

There is also a career reason. Hiring managers for junior cloud and DevOps roles want to see that you will not create problems for the team. If your portfolio project shows you used IAM roles instead of hard-coded keys, kept secrets out of Git and locked down your security groups, that says more about you than another tutorial certificate.

The cloud providers describe this split with the shared responsibility model. The provider secures the physical data centres, the hardware and the underlying platform. You secure what you put on it: your users and permissions, your data, your network rules, your operating system patches on virtual machines, and your application code. Almost every beginner mistake lives on your side of that line.

Step zero: lock down your own account

Before you learn anything else, protect the account you practise on. This matters even more when the bill is in dollars and your card is a naira card with an international spending limit, because a compromised account can run up charges very quickly.

1. Turn on MFA for the root user. In AWS, the root user is the email address you signed up with. Sign in, open the account menu, choose Security credentials, and assign an MFA device. An authenticator app on your phone works fine.
2. Stop using the root user for daily work. Create a separate administrative identity. AWS now recommends IAM Identity Center for this, but for a personal learning account a single IAM user with MFA is acceptable while you learn.
3. Never create access keys for the root user. If any exist, delete them.
4. Set a budget alert. In AWS Billing, create a budget (for example, a monthly cost budget of a few dollars) with an email alert at 80% and 100%. On Azure, use Cost Management budgets. On Google Cloud, use Billing budgets and alerts.
5. Use a strong, unique password stored in a password manager, not the same password as your email.

You can also create a budget from the command line once the AWS CLI is configured:

aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{"BudgetName":"learning-cap","BudgetLimit":{"Amount":"5","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80,"ThresholdType":"PERCENTAGE"},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"you@example.com"}]}]'

Replace the account ID and email with your own. A budget alert does not stop spending; it only tells you. That is why the rest of this guide matters. For a deeper look at managing cloud costs, see our FinOps guide.

IAM: who can do what

Identity and access management answers two questions: who are you? (authentication) and what are you allowed to do? (authorisation). Every request to a cloud API, whether from the web console, the CLI or a program, is checked against IAM.

The main building blocks in AWS are:

• Users: long-lived identities for people (and, in older setups, for programs).
• Groups: collections of users that share permissions.
• Roles: identities that are assumed temporarily. A role has no password or long-term keys; whoever assumes it gets short-lived credentials.
• Policies: JSON documents that list which actions are allowed or denied on which resources.

Reading a policy

Here is a simple identity policy that allows reading objects from one S3 bucket and nothing else:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadReportsBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-reports-bucket",
        "arn:aws:s3:::my-reports-bucket/*"
      ]
    }
  ]
}

Read it line by line. Effect is Allow or Deny. Action is the list of API operations. Resource is what they apply to. Notice there are two resources: ListBucket acts on the bucket itself, while GetObject acts on the objects inside it (the /*). Getting this wrong is one of the most common reasons a policy "doesn't work".

Two rules to remember about how AWS evaluates policies: everything is denied by default, and an explicit Deny always wins over any Allow.

Roles instead of keys

The single most valuable IAM habit is this: programs running in the cloud should use roles, not access keys. An EC2 instance gets an instance profile. A Lambda function gets an execution role. A GitHub Actions workflow can use OpenID Connect (OIDC) to assume a role without storing any keys at all.

Why? Long-lived access keys sit in files, environment variables and, too often, Git history. If they leak, they work until someone notices and deletes them. Role credentials expire on their own, usually within an hour.

You can see which identity you are currently using with:

aws sts get-caller-identity

Run this every time something behaves unexpectedly. Many "permission denied" problems turn out to be the wrong profile or the wrong account.

Least privilege: give only what is needed

Least privilege means every identity gets the minimum permissions it needs to do its job, and nothing more. It sounds obvious. In practice, beginners attach AdministratorAccess to everything because it makes errors go away.

The problem is blast radius. If a web server has admin rights and the application is compromised, the attacker has admin rights to your whole account. If the server can only read one bucket, that is all the attacker gets.

A worked example

Say you have a small app on an EC2 instance that uploads user files to an S3 bucket called skillsch-demo-uploads. Here is how to grant exactly that.

First, write a trust policy that lets EC2 assume the role. Save it as trust.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Then a permissions policy, upload-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::skillsch-demo-uploads/*"
    }
  ]
}

Now create the role, attach the policy, and wrap it in an instance profile:

aws iam create-role \
  --role-name demo-uploader \
  --assume-role-policy-document file://trust.json

aws iam put-role-policy \
  --role-name demo-uploader \
  --policy-name upload-only \
  --policy-document file://upload-policy.json

aws iam create-instance-profile --instance-profile-name demo-uploader
aws iam add-role-to-instance-profile \
  --instance-profile-name demo-uploader \
  --role-name demo-uploader

Attach the instance profile when you launch the instance (or later with aws ec2 associate-iam-instance-profile). On the instance, the AWS SDK and CLI pick up the role credentials automatically. There are no keys to copy, rotate or leak.

To test that least privilege is working, try something the role should not be able to do:

aws s3 ls
# An error occurred (AccessDenied) when calling the ListBuckets operation

That error is a success. It means the role is scoped correctly.

Practical tips for least privilege

• Start narrow and add. It is easier to add one missing permission than to work out which of 300 granted ones are unused.
• Use AWS managed policies as a reference, not a destination. ReadOnlyAccess is useful for an auditor; it is far too broad for an app.
• Use IAM Access Analyzer. It can flag resources shared outside your account and, with CloudTrail data, help generate policies based on what an identity actually used.
• Separate environments. Ideally, development and production live in different accounts. At minimum, use different roles.
• Review regularly. Remove users who have left and keys that have not been used in months. The IAM credential report shows this:

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > report.csv

Secrets: keep them out of code

A secret is anything that grants access: database passwords, API tokens, access keys, private SSH keys, webhook URLs with tokens in them. The rule is simple: secrets never go into source code or Git.

Automated bots scan public GitHub repositories for credentials continuously. Once a key is pushed, assume it is compromised, even if you delete the commit a minute later, because it remains in the history and may already have been copied.

The basic workflow

1. Add a .gitignore before your first commit:

cat >> .gitignore <<'EOF'
.env
*.pem
*.key
terraform.tfstate
terraform.tfstate.backup
.terraform/
EOF

Terraform state files deserve a special mention: they can contain secrets in plain text, so they should be stored in a protected remote backend, not committed. Our Terraform for beginners guide explains remote state.

1. Keep local development secrets in a .env file that is ignored, and commit a .env.example with placeholder values so others know what is needed.

1. In the cloud, store secrets in a managed service and let your app read them at runtime using its role:

aws secretsmanager create-secret \
  --name demo/db-password \
  --secret-string 'change-me-to-a-long-random-value'

aws secretsmanager get-secret-value \
  --secret-id demo/db-password \
  --query SecretString --output text

For simple configuration values, AWS Systems Manager Parameter Store with the SecureString type is a cheaper option. Check the official pricing pages for both before you choose, as Secrets Manager charges per secret per month.

1. In CI/CD, use the platform's secret store (GitHub Actions secrets, GitLab CI/CD variables marked masked and protected) and, better still, OIDC so there are no cloud keys stored at all. Our GitHub Actions guide walks through a pipeline.

Scan before you push

Use a secret scanner locally. Gitleaks is a popular open-source option:

# scan the current repository, including history
gitleaks git .

# scan files in a directory without Git history
gitleaks dir .

Older Gitleaks versions used gitleaks detect instead; run gitleaks --help to check which your version supports. GitHub also offers secret scanning and push protection on public repositories, which can block a push that contains a recognised credential.

If you leak a key

Act in this order, quickly:

1. Deactivate and delete the key in IAM straight away. Do not wait to clean up Git first.
2. Check CloudTrail for activity using that key, and look for new users, roles, instances or unexpected regions.
3. Check billing for unexpected charges and contact AWS Support if needed.
4. Then remove it from Git history, knowing this is clean-up, not protection.

Networking: control what can reach what

Networking is where beginners most often expose things to the whole internet without realising. The core ideas:

• A VPC (virtual private cloud) is your own private network inside the provider.
• Public subnets have a route to an internet gateway. Private subnets do not.
• Security groups are stateful firewalls attached to resources such as instances and databases. They only have allow rules.
• Network ACLs are stateless firewalls at the subnet level, with allow and deny rules.

The address 0.0.0.0/0 means "anywhere on the internet". Every time you type it into an inbound rule, pause and ask why.

A sensible three-tier layout

Notice that the database rule references a security group, not an IP range. That means "only things wearing the app server badge can connect", which keeps working as servers come and go.

Commands to check and fix exposure

Find security groups that allow SSH from anywhere:

aws ec2 describe-security-groups \
  --filters Name=ip-permission.from-port,Values=22 Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query 'SecurityGroups[].[GroupId,GroupName]' --output table

Replace an open SSH rule with one limited to your current public IP:

MYIP=$(curl -s https://checkip.amazonaws.com)

aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 22 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 22 --cidr ${MYIP}/32

A local reality: many home and mobile internet connections in Nigeria change public IP often, so your SSH rule may stop working the next day. Rather than reopening to 0.0.0.0/0, use AWS Systems Manager Session Manager, which gives you a shell on the instance through the AWS console or CLI with no inbound SSH port at all. It needs the SSM agent (preinstalled on Amazon Linux) and an instance role with the AmazonSSMManagedInstanceCore managed policy.

aws ssm start-session --target i-0123456789abcdef0

(The CLI also needs the Session Manager plugin installed locally.) This is a good habit for production too, and it gives you an audit log of sessions.

Storage is networking too

S3 buckets are not inside your VPC, but they can still be exposed. Keep S3 Block Public Access turned on at the account level unless you have a specific, understood reason to host public content:

aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

If you want to host a static website publicly, put CloudFront in front of a private bucket rather than opening the bucket itself.

Good Linux networking knowledge makes all of this easier to debug; our Linux skills guide covers ss, curl and dig.

Logging: know what happened

You cannot respond to what you cannot see. Logging answers "who did what, when, and from where?"

The key AWS logging sources for a beginner are:

• CloudTrail: records API calls in your account (console sign-ins, resource creation, IAM changes). Event history keeps the last 90 days of management events for free; create a trail to keep logs longer in S3.
• CloudWatch Logs: application and system logs from your instances, containers and Lambda functions.
• VPC Flow Logs: records of accepted and rejected network traffic in your VPC.
• GuardDuty: a threat detection service that analyses these sources and raises findings such as unusual API calls or crypto-mining behaviour. It has a free trial; check the official site for current pricing.

Create a trail

aws s3api create-bucket --bucket my-cloudtrail-logs-123456789012 --region us-east-1

# attach the bucket policy CloudTrail requires (see the AWS docs), then:
aws cloudtrail create-trail \
  --name main-trail \
  --s3-bucket-name my-cloudtrail-logs-123456789012 \
  --is-multi-region-trail

aws cloudtrail start-logging --name main-trail

The bucket needs a policy that allows CloudTrail to write to it. The console creates this for you automatically, which is the easier route the first time.

Ask useful questions of your logs

Who deleted something recently?

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteBucket \
  --max-results 10

Were there console sign-ins?

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin \
  --query 'Events[].[EventTime,Username]' --output table

What to alert on first

You do not need a full security operations centre. Start with alerts for:

• Root user sign-in.
• Changes to IAM policies or creation of new access keys.
• Security group changes that add 0.0.0.0/0.
• Your budget threshold.

A CloudWatch metric filter on your CloudTrail log group, or an EventBridge rule, can send these to an SNS topic that emails you. If you want structured practice, the SRE and DevOps Arena and CyberShield Arena in CloudArcade have challenges built around incident thinking.

AWS, Azure and Google Cloud equivalents

If you are deciding which provider to start with, read AWS vs Azure: which to learn first.

Common mistakes

• Using the root user day to day, or with no MFA.
• Attaching AdministratorAccess to apps because it "fixes" errors.
• Committing `.env` files, keys or Terraform state to Git.
• Opening SSH (22) or RDP (3389) to 0.0.0.0/0 and forgetting about it.
• Making a bucket public to share one file, instead of using a pre-signed URL (aws s3 presign s3://bucket/file --expires-in 3600).
• Putting the database in a public subnet so you can connect from your laptop.
• No budget alert, so the first sign of trouble is a declined card or an unexpected debit.
• Leaving practice resources running. Delete what you create at the end of each session. A stopped instance still has storage costs, and unattached Elastic IPs and NAT gateways are charged.
• Ignoring logs until something goes wrong, then discovering logging was never on.

A six-week practice plan

This assumes about five to seven hours a week. If power or data is unreliable, do the reading and policy-writing offline, and save your hands-on sessions for when you have a stable connection, so you are not leaving resources running because you got cut off mid-lab.

Week 1: Account hygiene. Create a fresh AWS free tier account. Turn on root MFA, create an admin identity with MFA, set a budget alert, and install and configure the AWS CLI. Run aws sts get-caller-identity. Read the shared responsibility model page.

Week 2: IAM fundamentals. Create a group and a user with read-only access. Write three custom policies by hand (one S3 read, one S3 write to a prefix, one EC2 describe). Use the IAM policy simulator to test them. Deliberately cause and fix an AccessDenied error.

Week 3: Roles and least privilege. Launch a free-tier EC2 instance with the demo-uploader role from this guide. Upload a file from the instance with no keys configured. Add Session Manager access and remove the SSH rule entirely. Terminate everything at the end.

Week 4: Secrets. Install Gitleaks, scan one of your repositories, and fix anything found. Store a secret in Parameter Store or Secrets Manager and read it from a small Python or shell script running under a role. Set up a GitHub Actions workflow that uses OIDC to assume a role. The Git Arena is useful for getting comfortable rewriting history safely.

Week 5: Networking. Build a VPC with a public and a private subnet (Terraform or the console). Put a small web server in the private subnet behind a load balancer, with security groups referencing each other. Enable VPC Flow Logs and look at rejected traffic. Tear it down, since load balancers and NAT gateways are not free.

Week 6: Logging and review. Create a CloudTrail trail, set up an alert for root sign-in, and turn on the GuardDuty trial in one region. Write a short README for a portfolio repository describing the security decisions you made and why. That write-up is something you can talk through in interviews; see cloud portfolio projects for more ideas.

FAQ

Do I need a security certification to get a junior cloud job?

Not usually. Foundational certifications such as AWS Certified Cloud Practitioner or Microsoft Azure Fundamentals (AZ-900) already include security basics, and demonstrated habits in your projects matter more. Specialist certifications like AWS Certified Security - Specialty are better aimed for later in your career. Check the official sites for current exam details and prices.

Is the free tier safe to practise on?

It is safe if you set a budget alert, protect the account with MFA and delete resources after each session. Not every service is covered by the free tier, so check before you launch something unfamiliar.

Can I use a virtual dollar card for my cloud account?

Many learners do, and some cards are declined by providers at sign-up or renewal. Whichever card you use, the bigger protection is a budget alert plus good security, because a compromised account can charge whatever card is on file.

What is the difference between authentication and authorisation?

Authentication proves who you are (password, MFA, a role's credentials). Authorisation decides what that identity may do (IAM policies). You need both to be right.

Should I learn security before or after Docker and Kubernetes?

Alongside. Learn the basics in this guide first, then apply them as you go: non-root containers and image scanning for Docker, RBAC and network policies for Kubernetes.

Get guidance on your next step

Cloud security is less about memorising services and more about building habits: MFA, least privilege, no secrets in code, nothing open that does not need to be, and logs switched on from day one. If you want a structured path that builds these habits through real projects, look at our courses, or book a free consultation and we will help you plan where to start based on your background and goals.