A big part of my day-to-day work involves managing AWS infrastructure, so I’m usually thinking about services, permissions, environments, logs, deployments, costs, and how to keep everything running correctly for the teams that depend on it.

When I decided to take the AWS Certified AI Practitioner certification, I’ll admit I had a very simple idea of what AI was. Like many people, I mostly thought of it as a chatbot: you ask something, it gives you an answer, and that is where the interaction ends.

Once I started studying, that idea changed pretty quickly.

The more I went through the material, the more I realized there is a much larger ecosystem behind AI. There are new concepts, new services, new ways of working, and a vocabulary that is becoming more common across DevOps, development, and IT teams. Even if you are not deploying machine learning systems from scratch, it helps to understand what people mean when they talk about tokens, RAG, fine-tuning, foundation models, temperature, prompt engineering, or responsible AI.

That was one of the main reasons I wanted to go through the certification. I wanted to understand the language around AI better and see how it could apply to the AWS work I already do every day.

A foundational certification with practical value

AWS Certified AI Practitioner is a foundational-level exam. It is not designed to test whether you can deploy a full machine learning system or build a complex AI architecture from scratch.

The focus is more on AI concepts, the AWS services available in this space, and how those services can apply to real-world work.

In that sense, the certification is useful for people who want to build a stronger base before going deeper. It helps you understand the concepts people are already using in conversations about AI, especially when those conversations happen inside technical teams.

For me, the value was not only in preparing for the exam. It was also in connecting those concepts to the AWS ecosystem I already work with.

Understanding the concepts behind the tools

One of the most useful parts of the certification is that it gives names and structure to concepts many people have heard about but may not fully understand yet.

For example, temperature and top P are both related to how a model responds. Temperature controls how creative or predictable the output can be. A lower temperature usually gives more focused and consistent answers, while a higher temperature gives the model more room to vary its responses.

Top P is also related to response generation. A model constantly chooses the next word or token from a set of possibilities, and top P helps control how wide or narrow that set is. Together, temperature and top P affect how creative, consistent, or exploratory a model’s answer can be.

Those concepts matter because they change how you work with AI. If you need a direct technical answer, you probably do not want the model to be too creative. If you are brainstorming or comparing options, a little more variation may be useful.

The certification also covers concepts like RAG, or retrieval-augmented generation. In a practical sense, RAG lets a model answer based on a specific set of information you provide, such as documents in an S3 bucket or internal documentation from a knowledge base. That keeps the model focused on the sources you want it to use and can make the output more relevant, private, and up to date.

Why Amazon Bedrock stood out

One of the AWS services that stood out most to me was Amazon Bedrock.

Bedrock gives you access to a catalog of foundation models ready to use within the AWS ecosystem. That includes models from Amazon and other providers, such as Anthropic and Meta. You can choose a model, test it, compare responses, and adjust parameters as needed.

That was interesting because it made the model selection process feel more practical. Instead of thinking about AI as one generic tool, you can start comparing how different models respond to the same prompt and decide which one fits the use case better.

It also connects AI back to the cloud environment. The model is not separate from the broader infrastructure conversation. It lives inside the same ecosystem where teams are already thinking about permissions, security, cost, and governance.

That part matters a lot from a DevOps perspective.

Using prompts with more structure

Before studying for the certification, I interacted with AI in a more basic way. I would ask a question, get an answer, and then keep asking follow-up questions until I got closer to what I needed.

Going through the material helped me understand prompt engineering in a more structured way.

A good prompt provides the model with context, explains the task, defines the answer format, and includes restrictions when needed. That last part has been especially useful in my work.

For example, when I’m working with Terraform, I can tell the model not to use certain provisioners, not to hardcode ARNs, and to pass specific values through variables. I can also tell it which Terraform version or client-specific standards it should consider.

That changes the quality of the output. Instead of asking the model to guess what I want, I can guide it with the same constraints I would use when reviewing technical work.

AI as a productivity layer inside AWS

The certification also pushed me to use AI more intentionally in the AWS console, especially with tools like Amazon Q Developer.

Because I spend a lot of time in AWS, even small improvements in speed can make a difference. Q Developer helps me ask questions in the context of the AWS console, find resources faster, generate filters, and create commands that would normally require checking documentation.

One example is CloudWatch. If I want to search logs that contain errors, I can describe what I need in plain language, and Q Developer can help generate the right filter. That is useful because the issue is not always knowing what I want to find; sometimes, the time-consuming part is remembering the exact syntax AWS expects.

Another example is AWS CLI. There are commands I use often, but there are also cases where I know the general command and forget the exact flags. If I need to upload only .log files to an S3 bucket, I could check the documentation, search for the right combination of recursive, include, and exclude flags, and test it manually. Or I can ask Q Developer and get a usable command much faster.

That does not remove the need to understand what the command does. I still need to review it before running it. But it can save several minutes on tasks that come up often, and that adds up over time.

Permissions still matter

One important thing to understand about using AI in AWS is that it still follows your user’s permissions.

If I ask Q Developer to show me resources I do not have permission to access, it will not bypass those permissions. It will return an error or tell me what permission would be required. That is important because it keeps the tool tied to the same security model we already use in AWS.

From a DevOps perspective, that makes AI more useful and safer to work with. It can help you find information, generate commands, analyze logs, or investigate costs, but it still operates within the limits of your access.

That is the right model for enterprise environments. Productivity matters, but it cannot come at the expense of security and governance.

Cost awareness is part of the AI conversation

Another point that came up during the certification is cost.

In AI, the most complex option is not always the best one. Sometimes a use case could technically be solved with fine-tuning, but a better prompt or a RAG-based approach may be simpler, faster, and less expensive.

That way of thinking is useful for the exam and applies to real work. Before choosing a more complex AI approach, it is worth asking whether the problem can be solved with better context, better prompting, or existing AWS services.

Pretraining a model from scratch, for example, is usually a very expensive path. For many business use cases, teams can get value by using foundation models, retrieval, prompt engineering, and the right cloud architecture.

What changed in my day-to-day work

The main change for me is that I now see AI less as a standalone tool and more as something that can fit into the AWS workflows I already use.

With AWS CLI commands, Q Developer can help generate the right syntax and flags faster. In CloudWatch, it can help turn a plain-language request into the filter AWS expects. For resource inventories, it can reduce the number of clicks needed to find information. For cost questions, it can help identify which services are contributing to a higher bill, as long as the user has the right permissions.

These are not huge, dramatic changes to the way I work. They are small improvements in recurring tasks, and that is what makes them useful. When you are inside the AWS console every day, saving five or ten minutes on a command, a filter, or an investigation can make the work smoother.

Tips for preparing for the exam

For anyone interested in taking the AWS Certified AI Practitioner certification, I would recommend treating it as a vocabulary and concepts exam first.

You should understand the key AI terms, the AWS services involved, and the differences among approaches such as prompt engineering, RAG, fine-tuning, and pretraining. The exam includes five domains, and some carry more weight than others. In general, the focus is on AI fundamentals, foundation models, applications, prompts, and related concepts, while security, compliance, and governance also appear but account for a smaller percentage of questions.

I also recommend taking a course specific to the certification. In my case, I studied with a Udemy course focused on the AWS AI Practitioner exam, and it covered most of the scenarios and topics I saw during preparation.

The most important thing is not to memorize terms in isolation. Try to understand when each concept would apply and why one option may be simpler, safer, or more cost-effective than another.

Why this matters beyond the certification

This certification helped me understand that AI is becoming part of the technical vocabulary for many roles, not just for data scientists or machine learning engineers.

As DevOps engineers, developers, cloud engineers, and IT professionals, we are going to hear more about foundation models, RAG, prompt engineering, responsible AI, and AI-assisted development inside the environments we already work with. Having that context makes it easier to join the conversation and make better decisions when these tools become part of real workflows.

For me, the AWS AI Practitioner certification was a good starting point. It gave me a stronger foundation, helped me connect AI concepts to AWS services, and showed me practical ways to improve productivity inside the console.

The biggest shift for me was realizing that AI is already becoming part of the systems, tools, and workflows I use every day. Understanding the concepts behind it makes it easier to use those tools with more intention.

About the Author

Antonio Hernández is an AWS DevOps Engineer at Definity, where he works with AWS infrastructure, cloud operations, deployments, monitoring, and system reliability. His day-to-day work involves supporting cloud environments and finding practical ways to improve productivity across AWS workflows.